From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <201412041542.44207.luke@dashjr.org> Date: Thu, 4 Dec 2014 19:04:21 +0100 X-Google-Sender-Auth: s7Gw3BgXvZDz2JrVKlYSGB7mrOQ Message-ID: From: Mike Hearn To: William Swanson 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 , Eric Lombrozo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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
I wrote a little Javascript = program to print some minimal protobufs to base64.

R= esult for a multisig output:

Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfa= awdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf26HEINeUq4YAA

Result for a regular pay to address output:

Ih8SGxIZdqkU4nFAzWDBp6LEi4uXgddL6= 5H11nGIrBgA

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.

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:

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

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

=

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.

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.


On Thu, Dec 4, 2= 014 at 6:25 PM, William Swanson <swansontec@gmail.com> wr= ote:
Yes. A few of us over here in San Di= ego 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 to= kens, each
> indicating either a HD chain or literal script content. For all HD cha= ins 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 simp= le 2-
> of-2, you would do something like this:
>=C2=A0 =C2=A0 =C2=A0literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECK= MULTISIG)
> 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 & mo= re
Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gam= pad/clk?id=3D164703151&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0418257c22c5f4050967ca49--