[Bitcoin-development] Serialised P2SH HD chains

Peter Todd pete at petertodd.org
Thu Dec 4 20:43:32 UTC 2014

Hash: SHA256

On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul <jp at eeqj.com> wrote:
>> On 20141204, at 07:42, Luke Dashjr <luke at dashjr.org> wrote:
>> Is anyone working on a serialisation format to convey P2SH HD chains?
>> example, to give someone who wants to make recurring payments a
>single token
>> that can be used to generate many P2SH addresses paying to a multisig
>> I'm thinking of something along the lines of a simple series of
>tokens, each
>> indicating either a HD chain or literal script content. For all HD
>chains in
>> the data, a child key would be generated based on the payment number,
>and all
>> tokens concatenated to form the P2SH serialised script. Eg, for a
>simple 2-
>> of-2, you would do something like this:
>>    literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
>> Does this sufficiently cover all reasonable use cases?
>What is the use case for something like this?  It’s my impression that
>a single token that can be used to obtain many P2SH addresses paying to
>a multisig script looks something like
>As it’s impossible to actually transmit a tx without network access,
>why would it be necessary to, at payment time, not contact the payee
>and use the existing bip70 authenticated payment request protocol to
>find out exactly what multisig address they’d like paid at that moment?

It's quite common to run into situations where the payee is *not* online. Similarly requiring them to be online is a security risk and defeats many ways of authenticating payment addresses. This stuff isn't evident in trivial consumer<->merchant use-cases, but is very common in anything else. For instance, consider the case of moving funds from a hot wallet or cold, and vice-versa.

Luke-Jr: sounds like some of the ideas I've been playing around with for generalised stealth addresses, using a declarative template scheme to avoid specifying scriptPubKey formats too explicitly. (though obcs k-anon set issues)
Version: APG v1.1.1


More information about the bitcoin-dev mailing list