Put this into a separate thread about Alan Reiner's user validatable HD address idea.
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote: >On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <a...@cypherspace.org> wrote >>Maybe in the payment address case the service should choose the >>derivation factor and communicate it and the client with the static >>address, as suggested by Alan Reiner because then it can also serve >>the function of allowing the service to tie the payment to the users >>account. > >I think any change which requires more than a single published public >message (e.g. a posting in a forum, or in a README.me in Github) >should be seen as solving an entirely different problem. Yes it is. This part is a separate topic, about simple TOFU cross-check & verifiability of deposit addresses by users. (However as we've seen in practice users treat as static and expect service deposit addresses to be reusable. So it could be useful to combine.) >But once you admit having that directed communication, then you are >swimming very close to the payment protocol. My view is that certification (X509 or raw ECDSA message signature) is functionally inferior (and more complex) than communicating scalar, base address because certification requires an online private key to authenticate. Scalar, base does not require a private key. In fact you could use HD address public derivation as the mechanism to derive the scalar, where the deposit address recipient does not know the scalar. So I am a fan of Alan Reiner's simple authenticatable derived address proposal. Now of course you can take the private key offline and use eg private derivation and upload batches, but that is complexity and work; so again its an approach with arguably inferior characteristics. Also to date payment message is application level, and while you could add another level of signed message with a different offline X509 key, which Mike Hearn did suggest as a future possibility, and upload signed addresses in batches, its clunky by comparison, involves many more lines of code, adds a security dependency on CAs, and I think you could somewhat argue is a protocol layering violation. Anyway if people want to do that, there is no loss in X509 signing a TOFU validatable address form. ie go ahead and combine them. TOFU validatability of the low level address format is useful, you can cross check. One could also consider augmenting the derivation with Timo Hanke's bind to contract hash, though there is risk that both parties lose the contract and if it has too much entropy that could lose coins. Adam ------------------------------------------------------------------------------ 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
