path: root/ef/ab3e76d8fe470384bcbd85a19e39cd75dc6ef5

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&#39;d want in practice. For an HD-iterating payment re=
quest you&#39;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&#39;s not too hard. Building specialised one-off SPV walle=
ts is quite easy these days with bitcoinj, there&#39;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 &quot;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&#39;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">&lt;<a href=3D"mailto:swa=
nsontec@gmail.com" target=3D"_blank">swansontec@gmail.com</a>&gt;</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&#39;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&#39;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 &lt;<a href=3D"mailto:luke@dash=
jr.org">luke@dashjr.org</a>&gt; wrote:<br>
&gt; Is anyone working on a serialisation format to convey P2SH HD chains? =
For<br>
&gt; example, to give someone who wants to make recurring payments a single=
 token<br>
&gt; that can be used to generate many P2SH addresses paying to a multisig =
script.<br>
&gt;<br>
&gt; I&#39;m thinking of something along the lines of a simple series of to=
kens, each<br>
&gt; indicating either a HD chain or literal script content. For all HD cha=
ins in<br>
&gt; the data, a child key would be generated based on the payment number, =
and all<br>
&gt; tokens concatenated to form the P2SH serialised script. Eg, for a simp=
le 2-<br>
&gt; of-2, you would do something like this:<br>
&gt;=C2=A0 =C2=A0 =C2=A0literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECK=
MULTISIG)<br>
&gt; Does this sufficiently cover all reasonable use cases?<br>
&gt;<br>
&gt; 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 &amp; 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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D164703151&amp;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--