Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <mh.in.england@gmail.com>) id 1XwalZ-0000Lx-Vx for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 18:04:45 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.173 as permitted sender) client-ip=209.85.212.173; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f173.google.com; Received: from mail-wi0-f173.google.com ([209.85.212.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XwalX-0006su-T6 for bitcoin-development@lists.sourceforge.net; Thu, 04 Dec 2014 18:04:37 +0000 Received: by mail-wi0-f173.google.com with SMTP id r20so35678805wiv.0 for <bitcoin-development@lists.sourceforge.net>; Thu, 04 Dec 2014 10:04:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.105.131 with SMTP id gm3mr45439378wib.34.1417716261105; Thu, 04 Dec 2014 10:04:21 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.89.130 with HTTP; Thu, 4 Dec 2014 10:04:21 -0800 (PST) In-Reply-To: <CABjHNoRJV4r9YxjFamnA1G2CJwmig3FqbJhpXt9LAovMkPCPvA@mail.gmail.com> References: <201412041542.44207.luke@dashjr.org> <CABjHNoRJV4r9YxjFamnA1G2CJwmig3FqbJhpXt9LAovMkPCPvA@mail.gmail.com> Date: Thu, 4 Dec 2014 19:04:21 +0100 X-Google-Sender-Auth: s7Gw3BgXvZDz2JrVKlYSGB7mrOQ Message-ID: <CANEZrP2AErGjNtynaKb-a-9ScTJVWNpVzbeebCfGHuNoZK8Y3A@mail.gmail.com> From: Mike Hearn <mike@plan99.net> To: William Swanson <swansontec@gmail.com> Content-Type: multipart/alternative; boundary=f46d0418257c22c5f4050967ca49 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.1 TRACKER_ID BODY: Incorporates a tracking ID number 0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist [URIs: dashjr.org] 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XwalX-0006su-T6 Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, Eric Lombrozo <eric@ciphrex.com> Subject: Re: [Bitcoin-development] Serialised P2SH HD chains X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Thu, 04 Dec 2014 18:04:46 -0000 --f46d0418257c22c5f4050967ca49 Content-Type: text/plain; charset=UTF-8 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 > --f46d0418257c22c5f4050967ca49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I wrote <a href=3D"https://github.com/bitcoinj/bitcoinj/bl= ob/master/examples/src/main/javascript/payprotocol.js">a little Javascript = program</a> to print some minimal protobufs to base64.<div><br></div><div>R= esult for a multisig output:</div><div> <p class=3D""><span class=3D"">Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfa= awdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf26HEINeUq4YAA</span></p><p= class=3D""><span class=3D"">Result for a regular pay to address output:</s= pan></p><p class=3D""><span class=3D""> </span></p><p class=3D""><span class=3D"">Ih8SGxIZdqkU4nFAzWDBp6LEi4uXgddL6= 5H11nGIrBgA</span></p><p class=3D""><span class=3D"">That is without any ex= piry time, which you'd want in practice. For an HD-iterating payment re= quest you'd also need a few flags and fields, but a well designed proto= col should only add a handful of bytes. The above strings are, I think, sho= rt enough to set as a username in a mining program so the general UX of Eli= gius can be maintained.</span></p><p class=3D""><span class=3D"">How to gen= erate them? That's not too hard. Building specialised one-off SPV walle= ts is quite easy these days with bitcoinj, there's a template app and a= video tutorial on how to customise it available here:</span></p><p class= =3D""><span class=3D""><a href=3D"https://bitcoinj.github.io/simple-gui-wal= let">https://bitcoinj.github.io/simple-gui-wallet</a><br></span></p><p clas= s=3D""><span class=3D"">You can just copy/paste the code into a new directo= ry 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).=C2=A0</span></p>= <p class=3D""><span class=3D"">So producing a little GUI that lets you buil= d a base64 encoded payment protocol request that supports HD iteration for = one or more keys, along with a little BIP70 extension that says "altho= ugh this output is a multisig output, please actually create a p2sh output&= quot;, would make a nice starter project for someone. It could also then ac= t as a watching wallet and plot a graph of mining payouts over time, for ex= ample.</span></p><p class=3D"">If anyone wants to take this on let me know.= I can help out with the final code signing steps to make Gatekeeper/Intern= et Explorer happy so don't worry about distribution.<br></p></div></div= ><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 4, 2= 014 at 6:25 PM, William Swanson <span dir=3D"ltr"><<a href=3D"mailto:swa= nsontec@gmail.com" target=3D"_blank">swansontec@gmail.com</a>></span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex">Yes. A few of us over here in San Di= ego actually started working on a<br> format like this a few months ago, but it's been on the back burner<br> for a while.<br> <br> Our motivation was to come up with a shared HD wallet format. Say I<br> would like create a 2-of-3 multisig wallet using my phone, PC, and<br> hardware key fob. All three devices would presumably be running<br> different wallet software, so we need some sort of standardized HD<br> multisig chain-description format that all three wallets can<br> understand. That way, regardless of their other differences, the<br> wallets can at least agree on how to generate new addresses.<br> <br> Of course, once you share this chain-description file with a third<br> party, they too can generate addresses out of the wallet. This can be<br> used for auditing (like for charities), for receive-only wallets (like<br> a merchant kiosk), and for recurring payments. The recurring payment<br> case is a little problematic, since you need to trust the payee with<br> your privacy. I imagine this would only be useful for payouts you<br> manage yourself, like a mining pool, and not something you share with<br> the general public.<br> <br> Our format is very similar to yours. We have a script template, just<br> like you do, but we describe the HD chains in a separate section<br> rather than in-line with the script. The script template only comes<br> into being once the chains have been gathered together into one place,<br> so the chain descriptions need to stand alone.<br> <br> Unfortunately, we still have a lot of details to work through before<br> we have a concrete proposal that's ready for this mailing list.<br> Perhaps we can work together to come up with something.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> -William<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr <<a href=3D"mailto:luke@dash= jr.org">luke@dashjr.org</a>> wrote:<br> > Is anyone working on a serialisation format to convey P2SH HD chains? = For<br> > example, to give someone who wants to make recurring payments a single= token<br> > that can be used to generate many P2SH addresses paying to a multisig = script.<br> ><br> > I'm thinking of something along the lines of a simple series of to= kens, each<br> > indicating either a HD chain or literal script content. For all HD cha= ins in<br> > the data, a child key would be generated based on the payment number, = and all<br> > tokens concatenated to form the P2SH serialised script. Eg, for a simp= le 2-<br> > of-2, you would do something like this:<br> >=C2=A0 =C2=A0 =C2=A0literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECK= MULTISIG)<br> > Does this sufficiently cover all reasonable use cases?<br> ><br> > Luke<br> <br> ---------------------------------------------------------------------------= ---<br> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br> from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br= > with Interactivity, Sharing, Native Excel Exports, App Integration & mo= re<br> Get technology previously reserved for billion-dollar corporations, FREE<br= > <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D164703151&iu= =3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= pad/clk?id=3D164703151&iu=3D/4140/ostg.clktrk</a><br> _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> </div></div></blockquote></div><br></div> --f46d0418257c22c5f4050967ca49--