Serialised P2SH HD chains

Is anyone working on a serialisation format to convey P2SH HD chains? For 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 script.

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?

Luke

On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr <luke@dashjr•org> wrote:

> Is anyone working on a serialisation format to convey P2SH HD chains? For 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 script.

Seems like the wrong approach to me, because in practice you really need a reasonable expiration date or some way of determining that whatever you are paying is still around (I still get random transactions to the Bitcoin Faucet's old addresses).

See the discussion from January about extending the payment protocol for recurring transactions:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03823.html

"Give them a single token" == "give them a recurring PaymentRequest" in my mind. Or maybe "Give them a URL where they can fetch PaymentRequests whenever they need to make a payment" or maybe "Give them an array of PaymentRequests for the next X days/months/years of payments."

Yes. A few of us over here in San Diego actually started working on a format like this a few months ago, but it's been on the back burner for a while.

Our motivation was to come up with a shared HD wallet format. Say I would like create a 2-of-3 multisig wallet using my phone, PC, and hardware key fob. All three devices would presumably be running different wallet software, so we need some sort of standardized HD multisig chain-description format that all three wallets can understand. That way, regardless of their other differences, the wallets can at least agree on how to generate new addresses.

Of course, once you share this chain-description file with a third party, they too can generate addresses out of the wallet. This can be used for auditing (like for charities), for receive-only wallets (like a merchant kiosk), and for recurring payments. The recurring payment case is a little problematic, since you need to trust the payee with your privacy. I imagine this would only be useful for payouts you manage yourself, like a mining pool, and not something you share with the general public.

Our format is very similar to yours. We have a script template, just like you do, but we describe the HD chains in a separate section rather than in-line with the script. The script template only comes into being once the chains have been gathered together into one place, so the chain descriptions need to stand alone.

Unfortunately, we still have a lot of details to work through before we have a concrete proposal that's ready for this mailing list. Perhaps we can work together to come up with something.

-William

On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr <luke@dashjr•org> wrote:

> Is anyone working on a serialisation format to convey P2SH HD chains? For
> 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 script.
>
> 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?
>
> Luke

I wrote a little Javascript program <https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/javascript/payprotocol.js> to print some minimal protobufs to base64.

Result for a multisig output:

Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfaawdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf26HEINeUq4YAA

Result for a regular pay to address output:

Ih8SGxIZdqkU4nFAzWDBp6LEi4uXgddL65H11nGIrBgA

That is without any expiry time, which you'd want in practice. For an HD-iterating payment request you'd also need a few flags and fields, but a well designed protocol should only add a handful of bytes. The above strings are, I think, short enough to set as a username in a mining program so the general UX of Eligius can be maintained.

How to generate them? That's not too hard. Building specialised one-off SPV wallets is quite easy these days with bitcoinj, there's a template app and a video tutorial on how to customise it available here:

https://bitcoinj.github.io/simple-gui-wallet

You can just copy/paste the code into a new directory and start modifying it. The final result is like Lighthouse - you run a program and get an EXE installer or MSI for Windows, a DMG for MacOS and a .deb for Linux (though a tarball would work just as well).

So producing a little GUI that lets you build a base64 encoded payment protocol request that supports HD iteration for one or more keys, along with a little BIP70 extension that says "although this output is a multisig output, please actually create a p2sh output", would make a nice starter project for someone. It could also then act as a watching wallet and plot a graph of mining payouts over time, for example.

If anyone wants to take this on let me know. I can help out with the final code signing steps to make Gatekeeper/Internet Explorer happy so don't worry about distribution.

On Thu, Dec 4, 2014 at 6:25 PM, William Swanson <swansontec@gmail•com> wrote:

> Yes. A few of us over here in San Diego actually started working on a
> format like this a few months ago, but it's been on the back burner
> for a while.
>
> Our motivation was to come up with a shared HD wallet format. Say I
> would like create a 2-of-3 multisig wallet using my phone, PC, and
> hardware key fob. All three devices would presumably be running
> different wallet software, so we need some sort of standardized HD
> multisig chain-description format that all three wallets can
> understand. That way, regardless of their other differences, the
> wallets can at least agree on how to generate new addresses.
>
> Of course, once you share this chain-description file with a third
> party, they too can generate addresses out of the wallet. This can be
> used for auditing (like for charities), for receive-only wallets (like
> a merchant kiosk), and for recurring payments. The recurring payment
> case is a little problematic, since you need to trust the payee with
> your privacy. I imagine this would only be useful for payouts you
> manage yourself, like a mining pool, and not something you share with
> the general public.
>
> Our format is very similar to yours. We have a script template, just
> like you do, but we describe the HD chains in a separate section
> rather than in-line with the script. The script template only comes
> into being once the chains have been gathered together into one place,
> so the chain descriptions need to stand alone.
>
> Unfortunately, we still have a lot of details to work through before
> we have a concrete proposal that's ready for this mailing list.
> Perhaps we can work together to come up with something.
>
> -William
>
> On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > Is anyone working on a serialisation format to convey P2SH HD chains? For
> > 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
> script.
> >
> > 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?
> >
> > Luke
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> On 20141204, at 07:42, Luke Dashjr <luke@dashjr•org> wrote:
>
> Is anyone working on a serialisation format to convey P2SH HD chains? For
> 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 script.
>
> 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

   bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new

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?

The model that you describe where a payer can, without communication with the payee, generate additional multisig p2sh addresses based on a set of xpubs presumes that the payee would never want to e.g. cycle their own keys or change their cooperating multisig participants’ keys. Is this wise?

Lately I’ve been thinking of bitcoin addresses (even multisig) as sort of MX records - something that the paying user shouldn’t depend on being static, because they are derived from keys that may change (or be lost or compromised) over time. The canonical “pay me at this address forever QR code” should be a bitcoin: URI that points to a payment request generating URL, should it not?

Best, -jp

Luke,

Eric Lombrozo is doing work similar to that. You may wish to connect.

He's building a BIP to standardize a multisig application of BIP32. Like there are xprv and xpubs for single keychains, he is developing a similar construct that would embed all information necessary for a "multisig xpub" (total keychains in system, minimum # of keys required, and which derivation paths on each keychain are to be combined to make the resultant multisig wallet)

The result would be taking an xpub style string and piping it through a BIP32-like algorithm to pop off P2SH addresses in a deterministic order, just like BIP32 pops off standard addresses in deterministic order.

I will ping Eric to connect with you in case the both of you are working on something similar and you can help each other.

Michael Perklin Bitcoinsultants Inc.

On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr <luke@dashjr•org <mailto:luke@dashjr.org>> wrote:

> Is anyone working on a serialisation format to convey P2SH HD chains? For
> 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 script.
>
> 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?
>
> Luke

On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul <jp@eeqj•com> wrote:

>
>> On 20141204, at 07:42, Luke Dashjr <luke@dashjr•org> wrote:
>>
>> Is anyone working on a serialisation format to convey P2SH HD chains?
>For
>> 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
>script.
>>
>> 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
>
>bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new
>
>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)

On Thursday, December 04, 2014 8:02:17 PM Jeffrey Paul wrote:

> 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
>
>    bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new

This requires the payee operate a server. My use case is for payment to individuals, who may or may not have a computer powered at the time of the transactions being sent. Furthermore, the users I am targeting (miners, to be specific), wish to remain entirely anonymous, and not hold accounts of any sort.

> The model that you describe where a payer can, without communication with
> the payee, generate additional multisig p2sh addresses based on a set of
> xpubs presumes that the payee would never want to e.g. cycle their own
> keys or change their cooperating multisig participants’ keys.  Is this
> wise?

This depends on the framework. As of present day, miners are limited to only use a single address ever, and cannot change it even to avoid address reuse. One goal is to solve that, without breaking multisig.

Luke