Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
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. -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
-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- -- 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
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. -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Merge avoidance and P2P connection encryption
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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
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 prab...@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 m...@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=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn m...@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 -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen gavinandre...@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/ -- 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
