Merge avoidance and P2P connection encryption
9 messages, 12 to 13 Dec 2013. Started by Mike Hearn.
Mike Hearn (4), Paul Rabahy, Gavin Andresen, Jeff Garzik, Peter Todd, Mark Friedenbach
I wrote an article intended for a broad/non-developer audience on a few Bitcoin privacy topics:
- P2P connection encryption - Address re-use/payment protocol - CoinJoin and merge avoidance
I don't think there's anything much new here for people who were involved with the BIP70 design discussions, but it may prove a useful resource when talking about privacy features in the payment protocol. Specifically the ability to request multiple outputs and submit multiple transactions that satisfy them. The article elaborates on how to use that feature to achieve some useful privacy outcomes.
I also analyze what using SSL for P2P connections would buy us and what it wouldn't.
First off, nice article. Very clear and informative.
I don't know if this is the best place to post this, but it seems related to me.
As more wallets implement BIP32, I believe that bitcoin wallets should begin to encourage people to use https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-mi0style address instead of traditional addresses. In the end, this would improve privacy because users never need to merge coin if they had one of these "super addresses".
In addition, "super addresses" would fit nicely into BIP70. Right now, the PaymentDetails message allows the merchant to provide multiple outputs. If instead the PaymentDetails provide 1 traditional output (for reverse compatibility) and 1 "super address", the payment could be broken into as many pieces as is needed to match unspent outputs already in the customers wallet. Finally, the refund_to address in Payment could also be upgraded to a "super address" to enhance privacy there.
I am not sure if there is a large memory requirement for "super addresses", but to me, it seems that a lot of these privacy enhancing possibilities will be simple to implement once BIP32 is widely deployed.
On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (33 lines)
> I wrote an article intended for a broad/non-developer audience on a few > Bitcoin privacy topics: > > - P2P connection encryption > - Address re-use/payment protocol > - CoinJoin and merge avoidance > > I don't think there's anything much new here for people who were involved > with the BIP70 design discussions, but it may prove a useful resource when > talking about privacy features in the payment protocol. Specifically the > ability to request multiple outputs and submit multiple transactions that > satisfy them. The article elaborates on how to use that feature to achieve > some useful privacy outcomes. > > I also analyze what using SSL for P2P connections would buy us and what it > wouldn't. > > https://medium.com/p/7f95a386692f > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
I think the right way to integrate BIP32 and BIP70 would be to specify output scripts as normal for backwards compatibility, and then allow each output to have an additional xpubkey and iteration count field. The iteration counts could be unsigned.
Unfortunately to add data that isn't signed requires a backwards incompatible change to the protocol :( There isn't currently any area that isn't covered by the signature. We would have to add one, and then have a matching array of iteration counts for each xpubkey that was specified in the output.
I wonder if we should make a last minute change to BIP70 before wallets have shipped and merchant support starts, something like
message PaymentRequest {
optional byte unsigned_data = 6;
}
that would be deleted like the signature is before reserialization.
On Thu, Dec 12, 2013 at 9:28 AM, Paul Rabahy <prabahy@gmail•com> wrote:
Quoted text (61 lines)
> First off, nice article. Very clear and informative. > > I don't know if this is the best place to post this, but it seems related > to me. > > As more wallets implement BIP32, I believe that bitcoin wallets should > begin to encourage people to use > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-mi0style address instead of traditional addresses. In the end, this would > improve privacy because users never need to merge coin if they had one of > these "super addresses". > > In addition, "super addresses" would fit nicely into BIP70. Right now, the > PaymentDetails message allows the merchant to provide multiple outputs. If > instead the PaymentDetails provide 1 traditional output (for reverse > compatibility) and 1 "super address", the payment could be broken into as > many pieces as is needed to match unspent outputs already in the customers > wallet. Finally, the refund_to address in Payment could also be upgraded to > a "super address" to enhance privacy there. > > I am not sure if there is a large memory requirement for "super > addresses", but to me, it seems that a lot of these privacy enhancing > possibilities will be simple to implement once BIP32 is widely deployed. > > > On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn <mike@plan99•net> wrote: > >> I wrote an article intended for a broad/non-developer audience on a few >> Bitcoin privacy topics: >> >> - P2P connection encryption >> - Address re-use/payment protocol >> - CoinJoin and merge avoidance >> >> I don't think there's anything much new here for people who were involved >> with the BIP70 design discussions, but it may prove a useful resource when >> talking about privacy features in the payment protocol. Specifically the >> ability to request multiple outputs and submit multiple transactions that >> satisfy them. The article elaborates on how to use that feature to achieve >> some useful privacy outcomes. >> >> I also analyze what using SSL for P2P connections would buy us and what >> it wouldn't. >> >> https://medium.com/p/7f95a386692f >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge•net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >
On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (5 lines)
> I think the right way to integrate BIP32 and BIP70 would be to specify > output scripts as normal for backwards compatibility, and then allow each > output to have an additional xpubkey and iteration count field. The > iteration counts could be unsigned. >
Why would there be an iteration count? The payer would handle that, wouldn't they?
If the use case is: I give the Foundation a "here's where to pay my salary" PaymentRequest, maybe with several Outputs each having a different xpubkey, then it seems to me the Foundation's wallet software should take care of iterating.
(either saving state, so it knows it used xpubkey+10 last month and should use xpubkey+11 this month, or maybe it knows I'm paid monthly and just uses xpubkey+(number_of_months_from_date_in_original_payment_request).
On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (4 lines)
> If the use case is: I give the Foundation a "here's where to pay my salary" > PaymentRequest, maybe with several Outputs each having a different xpubkey, > then it seems to me the Foundation's wallet software should take care of > iterating.
Absolutely. This is a key address-non-reuse case we really need to solve. Miner payouts, BitPay salary payouts, etc. all use a statically provided, manually changed address.
Rotating through multiple outputs is a stopgap -- but IMO a useful one. HD wallets will solve this in a better way, but existing randkey systems will be around for a long time.
So, vendors hat on, what would it take for, say, BitPay to implement merge avoidance and coinjoin together?
At the dark wallet hackathon when we were talking usability we decided that the main way to get coinjoin working well is to take advantage of non-time-critical payments to act as counterparties to time-critical payments. For instance BitPay could schedule a vendor payment to happen in full by some time in the future, say 1 day, and send the funds in one or more joins. The actual amounts sent in each tx are then picked to match the amounts desired by the counterparty who needs funds sent right now.
We expect this to be first implemented just as a "anonymize my coins" button for wallet software on always on machines; getting vendors on board would be gravy.
We may even allow joins to happen when one party pays less fees than the other, although this is tricky: the main Sybil resistance of coinjoin is fees so you don't want to overdo it. OTOH the idea of the NSA and Chinese equivalent wasting money completing each others joins is hilarious...
Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (17 lines)
>On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen ><gavinandresen@gmail•com> wrote: >> If the use case is: I give the Foundation a "here's where to pay my >salary" >> PaymentRequest, maybe with several Outputs each having a different >xpubkey, >> then it seems to me the Foundation's wallet software should take care >of >> iterating. > >Absolutely. This is a key address-non-reuse case we really need to >solve. Miner payouts, BitPay salary payouts, etc. all use a >statically provided, manually changed address. > >Rotating through multiple outputs is a stopgap -- but IMO a useful >one. HD wallets will solve this in a better way, but existing randkey >systems will be around for a long time.
Quoted text (4 lines)
> > Why would there be an iteration count? The payer would handle that, > wouldn't they? >
I'm thinking about a use case I hope will become common next year - pastebin style hosting sites for payment requests. Like, if I as a regular end user wish to use the payment protocol, I could just upload a (possibly signed) payment request to:
payr.com/a62gahZ
or whatever, and then payr.com can take care of incrementing the iteration count on each download of my file. That's why it's useful for it to be unsigned.
Quoted text (5 lines)
> If the use case is: I give the Foundation a "here's where to pay my > salary" PaymentRequest, maybe with several Outputs each having a different > xpubkey, then it seems to me the Foundation's wallet software should take > care of iterating. >
Absolutely. The two use cases can both be supported. You could give iteration ranges, for instance, if you want to specify expiry in terms of number of payments rather than time.
On 12/13/2013 09:26 AM, Mike Hearn wrote:
Quoted text (10 lines)
> I'm thinking about a use case I hope will become common next year > - pastebin style hosting sites for payment requests. Like, if I as > a regular end user wish to use the payment protocol, I could just > upload a (possibly signed) payment request to: > > payr.com/a62gahZ <http://payr.com/a62gahZ> > > or whatever, and then payr.com <http://payr.com> can take care of > incrementing the iteration count on each download of my file. > That's why it's useful for it to be unsigned.
Or alternatively, the user-signed payment request without iteration count is enclosed within a payr.com-signed envelope that contains the iteration count. Having fields completely unsigned by anybody leaves me a little nervous.
Mark
Quoted text (4 lines)
> > Or alternatively, the user-signed payment request without iteration > count is enclosed within a payr.com-signed envelope that contains the > iteration count.
But how does that show up in the user interface? I don't know how you would explain what the signature means or implies, or what you do if the signature is broken/missing.
The only thing that a maliciously modified iteration count can do is cause money to be sent to an address that's beyond the recipients gap limit, meaning they won't receive it (unless they reconfigure their software and rescan). But you can't steal money that way.