1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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 <pete@petertodd.org>) id 1XwdHM-0008HX-Ol
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Dec 2014 20:45:36 +0000
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;
Received: from outmail149080.authsmtp.com ([62.13.149.80])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XwdHL-0004RG-Cm for bitcoin-development@lists.sourceforge.net;
Thu, 04 Dec 2014 20:45:36 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sB4KjP4O051210;
Thu, 4 Dec 2014 20:45:25 GMT
Received: from [10.32.64.79] (no-dns-yet.sleek.net [37.205.56.238] (may be
forged)) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sB4KjOir080953
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 4 Dec 2014 20:45:25 GMT
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>
X-Server-Quench: 791af9f2-7bf6-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUHFAXAgsB AmIbWVReVFh7W2Y7 aA1PbwVYfE9IQQdp
WFdNRFdNFUsrcxh6 XGFHEBl6dwxDezBx ZkZiWj5cVUUrI08r
QFNTRzsAeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4wEyQ9 ThQDBjgjVXVffAV7
DzBuIV4VHUAKWgAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 37.205.56.238/465
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by punt17.authsmtp.com id
sB4KjP4O051210
X-Spam-Score: -0.9 (/)
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 SPF_PASS SPF: sender matches SPF record
0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist
[URIs: dashjr.org]
X-Headers-End: 1XwdHL-0004RG-Cm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 20:45:37 -0000
-----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-----
|
