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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VbgMy-0001ss-NF
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 00:44:16 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.98 as permitted sender)
client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
helo=outmail148098.authsmtp.com;
Received: from outmail148098.authsmtp.com ([62.13.148.98])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VbgMx-00079V-B5 for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 00:44:16 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id r9V0i71I001625;
Thu, 31 Oct 2013 00:44:07 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r9V0i24r055751
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 31 Oct 2013 00:44:05 GMT
Date: Wed, 30 Oct 2013 20:44:01 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20131031004401.GA22665@savin>
References: <CAAS2fgRRobkE2GdYomtJof7HCH-9ZczE9EBj7DBS-pCGscUSNQ@mail.gmail.com>
<CAPaL=UXxyKpWxG3qE=76B1HmbUXRCEWWRsCAceL6RfToDh01yg@mail.gmail.com>
<op.w5ojgsityldrnw@laptop-air>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
In-Reply-To: <op.w5ojgsityldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 8ba8705b-41c5-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdQMUF1YAAgsB AmUbW1ReVFl7WWY7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqCHoB XxwaEBl3cgJDeTBy YENmXj5TDhVyckZ4
EFNQFD4DeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4zFy85 ShYeVS01GlECTCI3
ZxIhMBYbGkcWNA0P C386HzoA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: blockchain.info]
X-Headers-End: 1VbgMx-00079V-B5
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
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, 31 Oct 2013 00:44:16 -0000
--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 28, 2013 at 12:37:30PM -0700, Jeremy Spilman wrote:
> Just an aside...
>=20
> The 1BTC bountry John references below is a 1BTC P2SH output, where the =
=20
> redeemScript he provided does hash to the expected value, and is itself a=
=20
> 2-of-3 multisig, with the following pubkeys, expressed as addresses:
>=20
> 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
> 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
> 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
>=20
> By comparison, the signatories for the 4BTC bountry are:
>=20
> 1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe
> 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
> 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
>=20
> On the one hand, the vanity address makes it easy to guess who one of the=
=20
> signatories is, on the other hand, is it bad form to reuse keys for =20
> signing?
It's a bit more risky from a cryptography perspective, but provided your
wallet implementation is done correctly the extra risk is pretty much
theoretical. However this has caused real-world coin loss in the past in
the case of the Android PRNG flaw - re-using nonces in ECC signing
causes the private key to be revealed.
I think the real issue here is that John doesn't appear to have asked
any of the people whose signatures can release the funds if they were
willing to take part. If he had done that, he could have, and should
have, gotten separate pubkeys for the purpose of the bounty like was
done for Gregory Maxwell's CoinJoin bounty. Instead by not asking he is
in reality if not in theory placing demands on people who haven't
consented, particularly for the 1BTC bounty where he doesn't control any
of the private keys required to release the funds. IMO this is rude and
I encourage people not to do this.
> John, you mentioned wanting to disambiguate bounties, perhaps through a =
=20
> bounty-specific pubkey. I'm not sure I follow, how is that better than =
=20
> just referencing the address of the output, or the TxID, in a 'Table of =
=20
> Bounties'? Or you want to embed a hash of your signed message announcing =
=20
> the bounty?
Well, the issue with not disambiguating bounties is that if further
funds are sent to the bounty address it's unclear how do you handle
those funds. Note how he specified a specific txout for the 1BTC bounty,
but specified an address for the 4BTC bounty.
> Out of curiosity, I suppose right now you just keep pubkeys for the =20
> signatories you want to appoint and reuse the same pubkey to create these=
=20
> multi-sigs, or you have to ask for a new one each time?
>=20
> From the signatories perspective, I imagine we're a long way off from a =
=20
> wallet receiving or importing the p2sh, tracking that these outputs as =
=20
> "yours", and even more, which contract/bounty they correspond to, and =20
> finally a usable way to accumulate signatures and ultimately spend the =
=20
> output to the bounty winner.
We're not that far off: I could cook up a Python script to do the
signature accumulation and signing in a few hours. There's just not all
that much demand yet to fully polish the UI's, and in any case, it'll
differ for every specific application.
FWIW blockchain.info added multisig escrow support ages ago, then
removed it not long after because usage was near zero.
--=20
'peter'[:-1]@petertodd.org
0000000000000001daf527009e07f452eee5dca920d3a9253b682d8bd26783ff
--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJScafRXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDVmYzBjZmZhMmYxYzYwMzYyYWQ5OThkMmE2ZGQ5MmFiNjlj
MzQyMzVhMGUwYjA2NGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsk3wgAvXrL+puR/65Wim1sbRvmXyZR
Up2vX36LzqnbxR6KzpBPVOVY0WBmmAlAto1jKzs4E16FFPNGGYZywu9JebdmSAdy
UkSi5JMzpz8/2SWmthuBcVKJLKFXNFvBFwqdtQyqq+ROsUclTCJTXY+WWlRH4QPu
1NTE/8jE7tWJUCiAXyYNGaEdiHh1nRNUOf2xz5TVckGTp8WwslHn1yRxHMI7R9Q6
XrpGcUysQZurGBUpUawMpoMYB+UBjHjaTw+DqzcGKDyfujJ5CUc18hQYCwYU6U1H
W47FSn7S6G43da12d8XLPYnl6Uh/Y1cHRonthkJcCnAO+0Be3DhnSzxqlHoINQ==
=kc0f
-----END PGP SIGNATURE-----
--5mCyUwZo2JvN/JJP--
|
