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
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1We0hh-0003IH-FX
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 11:23:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1We0hf-0006WB-T0 for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 11:23:33 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3QBNPDt029562;
Sat, 26 Apr 2014 12:23:25 +0100 (BST)
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 s3QBNLw1033235
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 26 Apr 2014 12:23:24 +0100 (BST)
Date: Sat, 26 Apr 2014 07:23:12 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Message-ID: <20140426112312.GA17949@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2e7a46df-cd35-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAQUGUUGAgsB AmIbWlZeUl57W2c7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAn1z eGJZUxlxdAdFfTBy ZEdrWz5ZCUMrcUAp
FFMHQW4DeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDFDleOyM+
FhMyOT95MTJCIiBY BxoVIFQeWg4UHyI8 DwwdGnA3FFcZVm0o
Ihgob1MHF1wWLQ08 NkFpWVMXM1cMAwlD EiMFHDVQIUIITDYq CgVBNQAA
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
X-Headers-End: 1We0hf-0006WB-T0
Cc: info@mycelium.com
Subject: [Bitcoin-development] Eliminating double-spends with two-party
self-escrow for high value transactions
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: Sat, 26 Apr 2014 11:23:33 -0000
--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In the majority of high-value transactions the fact that funds will be
sent is known prior to when they actually are. For instance, if Alice is
to meet Bob in person to buy a car or sell some Bitcoins, both parties
know the transaction will probably happen in the near future some time
before it actually does. Existing escrow solutions already take
advantage of this fact; for instance Localbitcoins provides sellers the
ability to escrow their funds with Localbitcoins prior to when the funds
are released to the buyer.
However with nLockTime a third-party escrow agent is *not* required.
Instead prior to Alice sending the funds to the escrow address, she has
Bob sign a refund transaction that unlocks at some time in the future.
Generally the transaction does go through, and Alice and Bob sign a
second transaction sending the funds to Bob. Sometimes it doesn't, and
Alice either gets Bob to sign a transaction sending the funds back to
her, or in the worst-case, just waits for the timeout to elapse.
Note that this technique can be used in addition to a third-party escrow
agent - the third-party then only plays a role in exceptional
circumstances.
Implementation sketch: Mycelium Local Trader
--------------------------------------------
The Mycelium Local Trader(1) is functionality built into the Mycelium
Android wallet that helps users trade cash for bitcoins by finding
traders in their local area. To attempt to prevent double-spends it uses
"transaction confidence", a technique that attempts to determine how
many nodes on the network a given transaction has propagated too. Of
course this technique is fragile and vulnerable to many attacks.
Local Trader already has pre-meetup buyer to seller communication built
in. Within the application the buyers and sellers communicate and
negotiate the amount and price of the Bitcoins prior to arranging a
meeting place. We can extend this to self-escrow as follows:
1) Alice publishes her offer to sell Bitcoins for cash.
2) Bob replies to the offer with an unused pubkey, B.
3) Alice creates tx1 paying a CHECKMULTISIG scriptPubKey spendable by
the co-operation of her pubkey, A, and Bob's pubkey, B. She signs tx1
but does not publish it.
4) Alice creates tx_refund which is nLockTime'd until some point in the
future and returns the output of tx1 to an address she controls. Note
how tx_refund depends on the signed tx1.
5) Alice sends Bob the hash of tx_refund for him to sign. As Bob does
not have the actual transaction Bob can't selectivly target tx1 for a
transaction mutability attack. Bob is free to sign the hash as the
pubkey has never been used before. Note that the tx_refund hash
Bob signs should be calculated with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
to allow Alice to, for instance, add fees.
6) Bob replies with the signature.
7) Alice checks the validity of the signature, and if satisfied,
publishes tx1 to the network.
8) Alice and/or Bob travel to actually meet in person. If this takes
time t the probability of a block being generated during that
time is P=3D1-e^(1/10mins*t) For instance, with a travel time of 30
minutes we get 95% success, 1 hour 99.75%, and 2 hours 99.999%
success.
9a) If the cash is handed over successfully Alice signs a
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY signature for the tx1 output
spending the funds to a scriptPubKey specified by Bob and gives that
signature to him.
10a) Bob creates a transaction spending the output, adds Alice's
signature to it, and finally signs it himself. He broadcasts this
transaction to the network, completing the transfer.
9b) If the cash is NOT handed over successfully Alice and Bob can either
co-operate to cancel the transaction immediately, sending the
escrowed funds back to Alice, or Alice can wait until the timeout to
use the signature she had Bob prepare in advance.
While the above is relatively complex, from the user's point of view the
process is quite similar to how Mycelium already works:
Alice: Publish offer -> Accept offer -> Travel -> Release funds
Bob: Browse ads -> Reserve funds -> Travel -> Accept
The chief difference being that the funds for the transaction have been
reserved, and if the transaction does not go through, will not be
unlocked without the co-operation of the other party, or the expiration
of the timeout.
Transaction Malleability
------------------------
While the above is fairly secure if transactions aren't being mutated
en-mass, better protections would be desirable. First of all adding a
third-party escrow to the two-party escrow is a prudent last ditch
measure to ensure that if malleability is an issue the third-party can
release locked funds manually; note how SIGHASH_SINGLE is used as
opposed to SIGHASH_NONE to prevent that third-party from having access
to the funds. Secondly a future soft-fork such as Pieter Wuille's
BIP62(2) can eliminate malleability. In particular, a soft-fork that
enabled the creation of signatures that did *not* include the txin txid
would be particularly valuable; in step 4 above Bob's refund signature
signed over the scriptPubKey and nLockTime only would cover all possible
cases whre a refund would be needed, such as accidental multiple
payments and previously unknown sources of malleability.
1) http://www.reddit.com/r/Bitcoin/comments/236k5d/mycelium_local_trader_is=
_now_available/
2) https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
--=20
'peter'[:-1]@petertodd.org
00000000000000009c143a1773a5dc24477ec151689bc78ffdd00a232bd533c8
--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTW5cXXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAyY2M2NGYzODFlYjRjMjc5ZmU3ODkyYTg0NTE3MjAzYTc2
NTkxNjk2YzZkNmExOGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftr0Af/eToQfrUhTk7HO2OoJYLOQSmL
ms6b49DHmq1TzHnqw19b9IElCv7sVA+9usa4PT/KcGrBCuXSGZRitPB/t7926uqr
AFv9eVjr+tjFPTapYC7owGxsX9V5Ckd4+sIzgAKgdg84wAdlZUeJewnv4SKOGidL
Wc2t5pHxxQD0Fd9xyyz8XD7YdveC2Zx43tanSJHWXG6vNMTYUGAS7IBvCa69lJJw
jGyXcuVtaR7jaXgwFxM3TXPBYVFEfw07rVlAoCkJMDkKaZEyX8EboK8/vKdK14Nj
sqQiHTbQbYin0dSRlLp72Z69bRv/1M4BZBvAyRWKLAjQDhFgCqyfVC7tOlnnpw==
=ib/f
-----END PGP SIGNATURE-----
--k+w/mQv8wyuph6w0--
|
