* [Bitcoin-development] Serialised P2SH HD chains
@ 2014-12-04 15:42 Luke Dashjr
2014-12-04 16:46 ` Gavin Andresen
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Luke Dashjr @ 2014-12-04 15:42 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 15:42 [Bitcoin-development] Serialised P2SH HD chains Luke Dashjr @ 2014-12-04 16:46 ` Gavin Andresen 2014-12-04 17:25 ` William Swanson 2014-12-04 20:02 ` Jeffrey Paul 2 siblings, 0 replies; 8+ messages in thread From: Gavin Andresen @ 2014-12-04 16:46 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 15:42 [Bitcoin-development] Serialised P2SH HD chains Luke Dashjr 2014-12-04 16:46 ` Gavin Andresen @ 2014-12-04 17:25 ` William Swanson 2014-12-04 18:04 ` Mike Hearn 2014-12-04 20:02 ` Jeffrey Paul 2 siblings, 1 reply; 8+ messages in thread From: William Swanson @ 2014-12-04 17:25 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev, Eric Lombrozo 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 17:25 ` William Swanson @ 2014-12-04 18:04 ` Mike Hearn 0 siblings, 0 replies; 8+ messages in thread From: Mike Hearn @ 2014-12-04 18:04 UTC (permalink / raw) To: William Swanson; +Cc: Bitcoin Dev, Eric Lombrozo [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 15:42 [Bitcoin-development] Serialised P2SH HD chains Luke Dashjr 2014-12-04 16:46 ` Gavin Andresen 2014-12-04 17:25 ` William Swanson @ 2014-12-04 20:02 ` Jeffrey Paul 2014-12-04 20:43 ` Peter Todd 2014-12-04 21:10 ` Luke Dashjr 2 siblings, 2 replies; 8+ messages in thread From: Jeffrey Paul @ 2014-12-04 20:02 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 20:02 ` Jeffrey Paul @ 2014-12-04 20:43 ` Peter Todd 2014-12-04 21:10 ` Luke Dashjr 1 sibling, 0 replies; 8+ messages in thread From: Peter Todd @ 2014-12-04 20:43 UTC (permalink / raw) To: Jeffrey Paul, Luke Dashjr; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Serialised P2SH HD chains 2014-12-04 20:02 ` Jeffrey Paul 2014-12-04 20:43 ` Peter Todd @ 2014-12-04 21:10 ` Luke Dashjr 1 sibling, 0 replies; 8+ messages in thread From: Luke Dashjr @ 2014-12-04 21:10 UTC (permalink / raw) To: Jeffrey Paul; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <mailman.473107.1417725057.2207.bitcoin-development@lists.sourceforge.net>]
* Re: [Bitcoin-development] Serialised P2SH HD chains [not found] <mailman.473107.1417725057.2207.bitcoin-development@lists.sourceforge.net> @ 2014-12-04 20:40 ` Michael Perklin 0 siblings, 0 replies; 8+ messages in thread From: Michael Perklin @ 2014-12-04 20:40 UTC (permalink / raw) To: bitcoin-development; +Cc: Eric Lombrozo [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-12-04 21:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-04 15:42 [Bitcoin-development] Serialised P2SH HD chains Luke Dashjr
2014-12-04 16:46 ` Gavin Andresen
2014-12-04 17:25 ` William Swanson
2014-12-04 18:04 ` Mike Hearn
2014-12-04 20:02 ` Jeffrey Paul
2014-12-04 20:43 ` Peter Todd
2014-12-04 21:10 ` Luke Dashjr
[not found] <mailman.473107.1417725057.2207.bitcoin-development@lists.sourceforge.net>
2014-12-04 20:40 ` Michael Perklin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox