Re: [Bitcoin-development] Serialised P2SH HD chains

Re: [Bitcoin-development] Serialised P2SH HD chains

[Michael Perklin]

[-- Attachment #1.1: Type: text/plain, Size: 1688 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2840 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

[Bitcoin-development] Serialised P2SH HD chains

[Luke Dashjr]

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

Re: [Bitcoin-development] Serialised P2SH HD chains

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

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."

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1927 bytes --]

Re: [Bitcoin-development] Serialised P2SH HD chains

[William Swanson]

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

Re: [Bitcoin-development] Serialised P2SH HD chains

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5113 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6568 bytes --]

Re: [Bitcoin-development] Serialised P2SH HD chains

[Jeffrey Paul]

> 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

--
Jeffrey Paul                                                      EEQJ
jp@eeqj.com                                           https://eeqj.com
+1-800-403-1126 (America)                  +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1                      1575 0524 43F4 DF2A 55C2

Re: [Bitcoin-development] Serialised P2SH HD chains

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



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)
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJUgMd0MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRJjB/0fvNisFR4cktOhDJYl
nq2gb39aiV7Wufh7NcTI0mqsC1yhIgFW5fgl7TmiK76Tn4gH0rhfJe3u7GhVsmSy
Sx1qEJJN6yNsiu6elmLe8xISVTwHu+kLqKFTyZNrd4BObHVumyLAhea2lFSzZmBu
GQF/AnVzf06vAT8CnZZm3hMgt1kFv32KglIIWLdztvvgi7yK6fi2GlZUW1J+jCUk
6AyQbnpPkHPHIJe7UMM0oeC2w6cN5nH0ccIutwkYDHwo/APa0TkX1hu3bJh5/Cor
zh+BLdOYgAP28wUZ1fkQoAj/0l79+3wyBC7+6lblV90y7C68G6zqMav7lDZdsBK9
4DU0
=Atvv
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Serialised P2SH HD chains

[Luke Dashjr]

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