Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mike Hearn
> > 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 d

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mark Friedenbach
-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 > upl

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mike Hearn
> > 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

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Peter Todd
-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

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Jeff Garzik
On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen 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

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Gavin Andresen
On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn 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

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Mike Hearn
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 requi

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Paul Rabahy
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.mediaw

[Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Mike Hearn
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,