On 06/20/2013 05:10 AM, Jeremy Spilman wrote:

which could involve proving something to a third party that has not seen 
the communication between payer and payee.

OK - I think I follow now.  So a third-party who does not see any of the 
communication between the payer and payee only knows the HASH160.  Let's say 
the payee denies receipt of the funds....

It's easy to prove what public key it was sent to (it's the preimage), but 
you can't prove the parent of that public key. You can provide any number of 
ParentPubKey * Multiplier that could have been used, so the 3rd party is 
unconvinced by a "matching" ParentPubKey * Multiplier.

However, if you calculated the destination using: PubKeyParent * 
HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a 
PubKeyParent and Multiplier (or Addend) that produces the destination 
address, you've proven the payment is in fact spendable by PubKeyParent, and 
they can't deny receipt. Very cool.

Sorry for "echoing" this back, it took me a little while to work it out, so 
I thought I'd write it down. Hope I got it right...

If you give {PubKey, ChainCode} you do get this feature. If you give 
{ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to 
having plausible deniability.

If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you 
could give HMAC(cpar, i) instead of Addend, and then you would get this 
feature; a way to 'skip down' a level in the wallet hierarchy, keep the 
'chain of custody' so to speak back to the ParentPubKey intact, without 
having to disclose the ChainCode. Meh...

I agree, if we used Timo's suggestion, that seems to clean up the remaining uncertainties with this recommendation. I'm not convinced those uncertainties matter in this situation, where there is no question about the parent public key. That is the part of the process that was already verified, per my previous examples. But certainly, for this to be more versatile it would need that.

If I modify my request to match Timo's recommendation, then it loses the benefit of being a simple, non-disruptive extension of BIP 32. I'm not fond of deviating from BIP 32, as it kind of defeats one of the benefits of BIP 32: standardization. And I'm not inclined to make an Armory-specific wallet variant.

But I can't tell if the benefits are lost on you, or you just don't think they are worth it (or I'm overstating them). I'm strongly opposed to bring extra wallets/chains into this equation *just* to get a benefit that can be had with a simple alternative encoding. This isn't a question of which is better, it's a matter of recognizing that both forms have usefulness and should both be supported.

-Alan