Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.80 as permitted sender)
	client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
	helo=outmail149080.authsmtp.com; 
User-Agent: K-9 Mail for Android
In-Reply-To: <F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com>
References: <201412041542.44207.luke@dashjr.org>
	<F904F6F8-BA2E-4B86-8C6C-B34A88D384BD@eeqj.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Thu, 04 Dec 2014 20:43:32 +0000
To: Jeffrey Paul <jp@eeqj.com>, Luke Dashjr <luke@dashjr.org>
Message-ID: <EDE19DB7-A029-47AB-8E34-B59F09B3320D@petertodd.org>
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Serialised P2SH HD chains
Precedence: list

-----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=E2=80=99s my impressio=
n that
>a single token that can be used to obtain many P2SH addresses paying to
>a multisig script looks something like
>
>bitcoin:?r=3Dhttps://payee.com/customer12345/recurring/paymentrequest/ne=
w
>
>As it=E2=80=99s impossible to actually transmit a tx without network acc=
ess,
>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=E2=80=99d 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 man=
y ways of authenticating payment addresses. This stuff isn't evident in t=
rivial consumer<->merchant use-cases, but is very common in anything else=
. For instance, consider the case of moving funds from a hot wallet or co=
ld, 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 avo=
id specifying scriptPubKey formats too explicitly. (though obcs k-anon se=
t 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
=3DAtvv
-----END PGP SIGNATURE-----