On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: > It's a given this will be implemented for Payment Protocol. The question > is whether it's also usable outside of PP.
I think what stealth addresses is showing is that the concept of an address being "instructions on how to generate a txout/tx that results in me getting Bitcoins" is actually quite valuable; it and BIP32-derivation addresses with chaincodes are pretty clear cases where just replacing address with scriptPubKey isn't sufficient. > I was kind of imagining that we could encourage people to replace all > their static address text that live on Github pages, and README.me, and > forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention > could be to require only transporting xSTL addresses within a URI, even > going so far as to not support them copy/pasted. 101 characters is not > much longer (and sometimes shorter) than PaymentRequest URIs end up being. Yeah, I don't see anything wrong with stealth addresses whatever length they wind up being. It's a good intermediate step, and without them people will just pass around unsigned payment requests and other stuff. > I think there are ways to make stealth addresses easy enough to use that > people actually prefer using them for P2P payments which do not involve a > full-stack merchant. In that case, if it was a PaymentRequest it would > almost certainly not be signed, and would be more easily shared over email > or SMS as a URI than as a file attachment or, even worse, putting the > unsigned PR file up on a third-party server which probably won't do a good > job securing it. At the DarkWallet hackathon we had discussed how to integrate stealth addresses into OpenPGP keys as a new user id type for instance, and similarly into x.509 certs. The big advantage here is the identity of *who* you are paying is important, not just "I got this signed payment request". Basically the concept becomes "identity signed payment address" and the signature binding the identity to the address is a one time and offline thing; an issue with the payment protocol as it stands is that it encourages signing keys to be kept online to issue payment requests. If you have a scheme where the private keys that bound the identity to the address can be kept offline you're much better off, because the attacker can only create a fake payment request, they can't divert the funds to themselves. So with that in mind, I strongly suggest sticking with defining a reasonable stealth address spec. But when you do, keep in mind that you may want to upgrade it in the future, preferably in a backwards compatible way. Also, it shouldn't be limited to exactly 2-of-2 CHECKMULTISIG, there's no reason why n and m can't be picked as needed. Sure, it means the addresses are not fixed length, but for something that is mostly an internal detail and only occasionally visible to advanced users, I see no issues there. Along those lines: what would a BIP32 chain code address look like? What happens when you want to use that with a multisig-protected wallet? > * PP Implementation Overview * > > The basic PaymentRequest>PaymentDetails is expecting 'output' containing > one or more TxOuts with script and amount. I believe the general approach > is to put a fallback address into 'output' for backward compatibility, and > put Q and Q2 into an extension field. > > So we add a new optional field to PaymentDetails which contains the one or > two PubKeys. Not sure if we want different protobuf tags, or if the > difference in length of the value makes it obvious enough which approach > is being used; > > optional bytes stealthOnePubKey = 1000 > optional bytes stealthTwoPubKey = 1001 I think you're missing the bigger picture here, not least of which is that backwards compatibility is a bit of a misnomer for an unreleased standard. :) Why put this into the PaymentDetails? That a stealth address is to be used for the payment is a property of the outputs being requested, not the payment itself. We're better off if that goes into the Output message, and further more it suggests that the Output message shouldn't contain raw scriptPubKey's but rather addresses. After all, IsStandard() means we have to inspect the scriptPubKey to see if we can even pay to what the sender is requesting. Once you establish that it's addresses that Outputs specify, then it's easy enough to make a stealth address type, or a BIP32-chain-code address type, or whatever else comes up in the future. > Also, ideally I think I would want multiple different stealth payments > within a single wallet to the same merchant / pubkeys to be identifiable > as such. Agreed. -- 'peter'[:-1]@petertodd.org 00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
