* [Bitcoin-development] Merge avoidance and P2P connection encryption @ 2013-12-12 16:03 Mike Hearn 2013-12-12 17:28 ` Paul Rabahy 0 siblings, 1 reply; 9+ messages in thread From: Mike Hearn @ 2013-12-12 16:03 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 713 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 921 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-12 16:03 [Bitcoin-development] Merge avoidance and P2P connection encryption Mike Hearn @ 2013-12-12 17:28 ` Paul Rabahy 2013-12-12 18:24 ` Mike Hearn 0 siblings, 1 reply; 9+ messages in thread From: Paul Rabahy @ 2013-12-12 17:28 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2706 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 3748 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-12 17:28 ` Paul Rabahy @ 2013-12-12 18:24 ` Mike Hearn 2013-12-13 0:20 ` Gavin Andresen 0 siblings, 1 reply; 9+ messages in thread From: Mike Hearn @ 2013-12-12 18:24 UTC (permalink / raw) To: Paul Rabahy; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3677 bytes --] 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: > 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 >> >> > [-- Attachment #2: Type: text/html, Size: 5198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-12 18:24 ` Mike Hearn @ 2013-12-13 0:20 ` Gavin Andresen 2013-12-13 0:26 ` Jeff Garzik 2013-12-13 17:26 ` Mike Hearn 0 siblings, 2 replies; 9+ messages in thread From: Gavin Andresen @ 2013-12-13 0:20 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Paul Rabahy [-- Attachment #1: Type: text/plain, Size: 892 bytes --] On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn <mike@plan99•net> wrote: > 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). -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1318 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-13 0:20 ` Gavin Andresen @ 2013-12-13 0:26 ` Jeff Garzik 2013-12-13 14:43 ` Peter Todd 2013-12-13 17:26 ` Mike Hearn 1 sibling, 1 reply; 9+ messages in thread From: Jeff Garzik @ 2013-12-13 0:26 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Paul Rabahy 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. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-13 0:26 ` Jeff Garzik @ 2013-12-13 14:43 ` Peter Todd 0 siblings, 0 replies; 9+ messages in thread From: Peter Todd @ 2013-12-13 14:43 UTC (permalink / raw) To: Jeff Garzik, Gavin Andresen; +Cc: Bitcoin Dev, Paul Rabahy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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: >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. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iQFQBAEBCAA6BQJSqxz9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTMBB/9L8h5NuSHxsC6W5ptm gucxg2AbCwReuWQzRzqW42TYKQ7MnAhpfLLbSQrewNoXRP4H/j6aG8uWOt+z7fZf pJZ9K8kxmSltHm8SJcmPLTb62yazEKQXF5TDsdpgBdH14M/pFsjUR4H2hypW8k4T gcEAIhymZvlXev1NXDMh6rbuw0LtRTBE4NgE2buCuFzp0sEwTNTLxMU1WenMXfRQ PooSBn8UoAVNw7Vztnag0T0f5D45VFNJBvQ8m42ee0u3gvMCa4JNRTBM49N2U9qc Gk6WAvDakOf7FwaJiNMYoDpGyWphx6g697j28NnfB2q2hdjUVnZF+UVuBzkjnNwD Y40/ =4dxZ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-13 0:20 ` Gavin Andresen 2013-12-13 0:26 ` Jeff Garzik @ 2013-12-13 17:26 ` Mike Hearn 2013-12-13 19:19 ` Mark Friedenbach 1 sibling, 1 reply; 9+ messages in thread From: Mike Hearn @ 2013-12-13 17:26 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Paul Rabahy [-- Attachment #1: Type: text/plain, Size: 942 bytes --] > > 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. > 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. [-- Attachment #2: Type: text/html, Size: 1749 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-13 17:26 ` Mike Hearn @ 2013-12-13 19:19 ` Mark Friedenbach 2013-12-13 21:49 ` Mike Hearn 0 siblings, 1 reply; 9+ messages in thread From: Mark Friedenbach @ 2013-12-13 19:19 UTC (permalink / raw) To: bitcoin-development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/13/2013 09:26 AM, Mike Hearn wrote: > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSq12pAAoJEAdzVfsmodw4MC4QAI9cjmQXz8AVawwr1htFc6b+ DVAAs1Y4hzbChPeeJCmy13m8a/BuXqc6G0WEWGSzIIa1or3IXCd01JQ2a5waD0IC uOjlIMD0tTT7yxwxRjxPc2df82s82traGJC2caOMYjrN4T5VPtj7erB2poNyvOF+ p0lmj+duxUZ8IoyDaih5mgNKzIVujfX7o3lPoOMDdIi6Q1LF9SZ9XbUAxHCpCLfw ieqVIm8zqtH0NprZ7/JLbqstl1iq5jCPKbORc+9qQWESZH1hFAeS29/ptjnRR8y6 HqrpDP236vSlrLDW4dLcW9UiQP42tSTwrLCgud08VqeKapSlMX8fjukLyNlTD7h5 GtPHEo1/j+LmpMfwsXA2OotUIVQBeFfEoi7PwV/Jd+SRVqC6zCTPky1lfg0P7JXA 7qD9m3u/Ey0+nk888zzff8N7AfBe7GaqFuUByXIyHh6dkcr0xUHBU4afiadFpNhg 8dTvmP4yqY0g05uz/Cq/ZqrSb5y/yPqsysuruAjWG2GT0M8rFM9oYepVHpUJr01K QOHY6qSoqyX/KDCkZgpTMZFDq9gvyPyMFuCQbdecNcCeMPV5kiwPyqqH4rHliJ8I gsXW44re5GfdL90nCOTboYFf2CFEn+66zyJ5vBskKSyDRDcU3t5YyCtrDzXdtJMu MjVeMFRluY700zLBajw0 =+MjP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Merge avoidance and P2P connection encryption 2013-12-13 19:19 ` Mark Friedenbach @ 2013-12-13 21:49 ` Mike Hearn 0 siblings, 0 replies; 9+ messages in thread From: Mike Hearn @ 2013-12-13 21:49 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 603 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 873 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-12-13 21:49 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-12 16:03 [Bitcoin-development] Merge avoidance and P2P connection encryption Mike Hearn 2013-12-12 17:28 ` Paul Rabahy 2013-12-12 18:24 ` Mike Hearn 2013-12-13 0:20 ` Gavin Andresen 2013-12-13 0:26 ` Jeff Garzik 2013-12-13 14:43 ` Peter Todd 2013-12-13 17:26 ` Mike Hearn 2013-12-13 19:19 ` Mark Friedenbach 2013-12-13 21:49 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox