Date: Thu, 16 Jan 2014 13:31:05 +0100
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20140116123105.GA30307@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Alan Reiner <alan@bitcoinarmory.com>
Subject: [Bitcoin-development] TOFU verifiable HD publicly derived addresses
Precedence: list

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 <adam@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