Author: Jeremy Spilman 2013-06-20 09:10:26
Published on: 2013-06-20T09:10:26+00:00
The context discusses the challenge of proving a payment to a third party who has not seen the communication between the payer and payee. The HASH160 is the only information that the third party has. The problem arises when the payee denies receiving the funds, as it's easy to prove what public key it was sent to (the preimage), but you can't prove the parent of that public key. However, a solution proposed by Timo suggests calculating the destination using PubKeyParent * HMAC(Multiplier,PubKeyParent). If this method is used, providing the 3rd party with a PubKeyParent and Multiplier that produces the destination address would prove the payment is spendable by PubKeyParent, leaving no room for denial. Using {PubKey, ChainCode} provides this feature, but using {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} brings plausible deniability back into play. BIP32's CKD'((Kpar, cpar), i) could provide a way to 'skip down' a level in the wallet hierarchy while keeping the chain of custody back to the ParentPubKey intact without disclosing the ChainCode.
Updated on: 2023-06-06T18:54:34.418383+00:00