[Bitcoin-development] 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 -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr l...@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 -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
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 l...@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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
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 swanson...@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 l...@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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Serialised P2SH HD chains
On 20141204, at 07:42, Luke Dashjr l...@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 j...@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 -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
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 l...@dashjr.org mailto:l...@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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul j...@eeqj.com wrote: On 20141204, at 07:42, Luke Dashjr l...@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- -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
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 -- 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=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
