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
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
Return-Path: <ekaggata@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CB0F1363
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Jan 2019 14:47:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com
[209.85.128.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B72D7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Jan 2019 14:47:40 +0000 (UTC)
Received: by mail-wm1-f46.google.com with SMTP id n190so7043354wmd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Jan 2019 06:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=to:references:from:openpgp:autocrypt:subject:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=IqzOXMcZdA+9r2c39anrJg4G7Z17gH3LjMH7ERO1/Fo=;
b=JLlK9OJ+QoGDVJozcogO1vmJmXdjbrmEhnofWnQFLrLUT4QTWIHratO5pBtSxKQwwI
kGGO/9eCosNzYZv8mmBVP9Dfr3WJf9sT4GZzuO4zj9GQmHPJwwAdUVo+5iRl40uoqvPe
foMKB3hD7oF+m3XKbGuN4SqK8HoWhxG4gc7xdzgMVhn8SBpH/9wggo8foWlrOimpqyb7
YOER62lDxgvDkPYVBHKPp2s9jEFSwsfeQuotB0SWH9UkHTIXAFfV3q4rO9sE5O4ePy7W
KsuaZRLeZsrU6hlQXIyIQPn225khX3lMq3lX7EM9E910wLTAVjBGdXe1XwNuYIT/f48u
t19Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:to:references:from:openpgp:autocrypt:subject
:message-id:date:user-agent:mime-version:in-reply-to
:content-language:content-transfer-encoding;
bh=IqzOXMcZdA+9r2c39anrJg4G7Z17gH3LjMH7ERO1/Fo=;
b=jsCDdUIfpybP0ZLVmlO7YhdOE2jD9ZrtDuQrUlcTnHJoNuLOHZZ8IC3Wn/MpM1Uo7u
+DIhvnyshgVVWsWE6d2NEi4XJlCuwSChhMW6OljowN1G6JJmXQ5BKZsXG6siqIdyJJ+H
gI2OF6C3FfWC/BCC6yzwjhmJksn41CXmWBlSpKi6QQ6atQAs3wHzD03y1lVOZuQzb2BS
z1m3zJPyBP4GNL8d4oV6IJqbuzRsiddwykfiukwMjiQl6zcbtfH0la2M12/7WNGQK2F5
MjFZlSERjrA3yi4kK3sZI/lYPqSRA/sGbHrT6xIJWNnPJfVxXVnjOxPgs6uxGcl7fOze
8G3g==
X-Gm-Message-State: AJcUukdL+JE9HrgYA7EgGpoARFxDRMH0jAN3pAPStkJeuS3moINXmmnS
YxshpIKIWOMvKliYT3WyxlbQjeRZ
X-Google-Smtp-Source: ALg8bN4B5MrFV9kM84IT7QUV3ci5QZTWH07meigy9cdmt4dEOBLpYslzYrLftwR9NKQSZv9qM/jPxg==
X-Received: by 2002:a1c:c60e:: with SMTP id w14mr7567183wmf.18.1548427657904;
Fri, 25 Jan 2019 06:47:37 -0800 (PST)
Received: from [10.5.0.5] ([77.243.183.203]) by smtp.gmail.com with ESMTPSA id
g16sm97235227wru.41.2019.01.25.06.47.36
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 25 Jan 2019 06:47:36 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com>
From: Adam Gibson <ekaggata@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=ekaggata@gmail.com; prefer-encrypt=mutual; keydata=
mQINBFv0DQgBEADhaaCIS7omfkdE11EuLtyhjHTFGANwsrAkhf1eKYBMdHpC5jbPi2MgJWMk
j5CMgvbKe+Y4vlUFzXW94uw8rMqH6Gd995+qs5EVqiA/8le80mTyuAG6JfpNqAo8ojHlPbr/
9errq8kYNVfH5HhEJB2WEsFKFCB3L7IjukhroNzpSWCl2t8oCdLFtAorZiIBDIVXjMrJRCIP
N4JhqV9O3PbXGiM2y+SIqwPemQF/qvwGfcSy+5OZ2TuDSPyGG7am8+a/kiq+s4prY/gJ2oxs
i0iVtOMG48VRCHlg/LD5t82DYsHUpuZAXT7Ubz+ZI051vDPPutxR/op/7r2zkkWqrQUSoluL
csUf+lb/3KSz8XkQwO9pLFC65qAqqBExKHAeh+uZnWDzn8E2JcpgDKYfW2eRZ4kL3PHozcZ6
1Ek9JbSBWTj2ghTkuwCi6eH+E8ybtiqWeB25LfLhqs2Qnk2IzC5NtqwyU+poYZD/ya0PPdoN
QVXsUB6F8j0M62bU25qqkkeUhW8aGDPVN0V/X4nCoyeUrOgU7oW9wCuFyg+eYn1q62iwCFrA
rjGvKSv3LzdzIqHeM8gaEs2sjUnvxwlcjJDVdiEW0nngcGU5+czH06hD0Nvu4nAgXeE5s4wv
d9FhGW9pjNb8TM2aQqMZzYJJDLNdVIZQNVycAtOwLKcCq0btFQARAQABtDNBZGFtIEdpYnNv
biAoQ09ERSBTSUdOSU5HIEtFWSkgPGVrYWdnYXRhQGdtYWlsLmNvbT6JAjcEEwECACECGwMC
HgECF4AFAlv0Dk0FCwkIBwMFFQoJCAsFFgIDAQAACgkQFBABoa938guczQ//f38lBKjg7c+U
t31x5ciX1LtxvLyfnmTIDQRq4pB2FWrl14utkK4afDRwcBR6zRlQx8PE52+M9Rg7+KYQ7hDY
y9c3IQonL2KdZgj+q2x99t5uUR9fj8b18U/2VDkVn1m8L//U3m596zZLwVBPr4OQ2Rd/rC6Y
GznMNXSN97nNr7SPGLXYH3rUEcmBf4VklneO6/M5y0PgNdTTM4DyKfrCk9ailWtev06G6gvT
kyLzjpHHZ5IyZvhpHua/oUHjeRzuS4VYUYQuuiATD7raJhXsxfL7g/NF/fOi3KwvRlAm4ns1
fOxOInLD2QK5hiEjdlPixwmuLMtTdHk5dAM+QX8Hr2Tis/cN+5J7vpvZoP7L0M7XxYo9J6wV
RMKOxNeFNa88W/n+pBDVCUdTqDOrVHP632zXt0sbaSKXa/KqznD+ReGOjaYsKKenEmyXgfv+
WoaUoqn9uZ8R2MywWyKojYguTP+RLHtzuiN3GPFPXQban27Ah+M5d6ruh/P/AXyuddtibq36
baD3iOXcGlmvfaAhYCVE59a3/AIAIZmkJr1DLJkfdF38BIqs+2/5jC05QyuGI94zmYy7Ivfj
w8ncqUUpir2M6X25YD00AzNruXDFVz8mpU3RcHEyVAhBtQeZuB+d8pZMzROoXpY0K+VwM4VD
3jiOJKQzYb+/kcaj20j9slS5Ag0EW/QNCAEQALueFahxEGALaZcBdBTYk5W32wdjdoZEjMUc
z7iWFyArDHeXjmxAis3+Q6TkFlAuJhGHL0NVpHjqDe0wg5B0V/c+Ew3WJTS6Or8UmKKg/OjU
b9gbRMmy+Jxm2Y7D8Lx7ikct3jo0aXJHApVzvFzQOUZUCO67/5PS9LY6RMqoyV97xnlaypsx
9CUF9Fc0eK7U/rliUJ0cSKoKm8kI1QTUfgRXkm33tn1qX5piAO8iyzPLZlJC0sVkI6tG0NMX
8d8/ifNmCZolBaYT8Y/J7tQgbdshMi7NSzpuPdZfeSo5JHIaQcBQCrjVPQvtWyQbVhbUKOFx
qLqIkaMEwOTVBNAMxuvwWLfr9sCiCpbPGTdu5ujyI4JsdxT+LkwgQSPPC0CZpxbNFeOdKcQM
o0f5la7zwNvEgXu0r9DGUAqM7cHPUUP0RQQl72vk1B2rr33gONeG8EzTYwYfuX5jjjyrd0Py
9XAgg3b9RFxRIsTmzTzsAmyxRRBJmwBsEJ/8A8mLlEWhgDDn/gl23YfTBlV/J/PBN0vVFrSe
IZtmWaDuxhiI07B/y1NKtttTkrU9R3K7GIinlIZ0/CR7LZRyP0F5NGLsDQwcrSNPLGoCeYLn
9cSYCtQjZjAXCBDbPFQqq8LV7INtGXHG8FUoclibHU13eK1SBiSY836lwt4PlZ/IiVsmvMBX
ABEBAAGJAh8EGAECAAkFAlv0DQgCGwwACgkQFBABoa938gsiOhAAtOQG/+Hh5vlk1r+AdFCO
kgLCFlNqGWk4pLlAhpxmE5NVJKfqjjb+0AA9u8WpEmJAudw0vUQNC/fBHQFT8czKy4u7QFSk
IPo2NtcGXYFjxMwzya5G87EgSgw8rekNHlC87r0lbcN/YZY3R0apcMCrbagjL7H4CGrc1oDl
YSRqiwekkItKLNpv3RocHI/SQDcGdJAtq/K5S3kKxwGPKLG+8Tdau4WkPWG+YnPj594mNGJv
5ZHUlma5r5hJHPSQregaDGJnq+ln3jDZ21rUEu1DROBP2UmS517WSiSZz+hQqgnRlXVql42f
vsggFpL3zdOXq0UbqPee1FVOuUidXaA8dGBfujJ/4MjCfCt5zyhr1+l3tKVjDiQhUkFbMaNp
fEUueW1gJuVgzofLmAhf3pTGiQQDpjKlijPLQxwAuQ4lM2KZObGSxDyw8Ffn8XX05DwU/s2h
/MKuRgYyp20UiVUmdnZ/+KrH/KhFgh9dn7fueWh//4AaDAZ8NJruondaLkmZ+D53V4qsbJE3
cpd1sXg5JL7eWE/8rwDsNWaJtM2p3viUujprCL7IMnXzv0dLfZm3fPGPWTg96/pdlWmpg4Ky
QjnH5SYgtHM+2GQnUD5nwsOGbXU27qQDMCpWU8aDvz2LPyD4qx9sS0gPpvOAYK5S3c0lWB5y
nl9Ca4x7aeV2qGM=
Message-ID: <e15c5dd7-6fe1-b253-e129-aeae6493acd1@gmail.com>
Date: Fri, 25 Jan 2019 15:47:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 26 Jan 2019 13:55:23 +0000
Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver
coinjoin protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jan 2019 14:47:42 -0000
Ryan and list,
I want to add some commentary to this (BIP79) to see if we can get
further in standardizing this idea.
When I first mulled it over I thought it too impractical, but its virtue
of steganographic hiding means only minimal uptake is still enormously
interesting and worth pursuing; that's my current feeling. I've offered
more detailed thoughts in my blog post[1] (def not required reading here).
Both Joinmarket and Samourai have started implementing this kind of
transaction. And while that's interesting experimentally, some kind of
cross-wallet standard would be helpful, albeit there some differences
between that and the merchant/centralized service use-case.
We might imagine as a concrete goal for this BIP to create something
that would be acceptable for inclusion into a project like BTCPayServer,
so that it could be used in a realistic use case by smaller bitcoin
accepting merchants.
Comments to the BIP[2] as follows, with generic comments first, and then
specific comments for existing points in the BIP:
[1] https://joinmarket.me/blog/blog/payjoin
[2] https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki
Generic comments
============
* Protocol versioning. Since inevitably (even if only merchants), this
must be implemented by multiple wallets to be useful, the communication
protocol will need versioning (for example i have in my
simple/experimental Joinmarket PayJoin that sender sends min and max
supported version and receiver responds with a chosen protocol version
so we can update). I do understand that as a client-server model can
apply here, we can ditch a lot of the complexities around network/p2p
interaction, but this much at least seems necessary.
* Although it has its logic, I don't think "Bustapay" is a good name for
this protocol. I prefer "PayJoin" which is neutral sounding and
self-descriptive. Needless to say this is not a hill I intend to die on.
* PSBT/BIP174. I realise this has already been discussed, but this is a
good example of what this standardisation was designed for, so I'd be
against not including it, even given the reality that, as you correctly
observe, it is not yet implemented in the majority of wallets and
libraries. One way round that is to make it optional (possibly combined
with above point about versioning). Note that for example you were
observing the necessity to check the sequence number was unchanged; that
would be encapsulated by checking equality of PSBT Input objects/fields.
While one can make such software architecture arguments, the really
fundamental point is the need for standards for x-wallet compatibility.
* Version, Locktime: Perhaps this is not needed; in a peer to peer
wallet scenario I think there might be logic in trying to get cover
traffic of (Core, Electrum, others), say, by using
last-block-locktime-mostly, as they do. Version should be 2 and sequence
is a function of your suggestion to use BIP125. Worth noting that BIP125
is *not* currently widely used on the network, though (see
https://p2sh.info/dashboard/db/replace-by-fee?orgId=1). For this reason
it should perhaps be explicitly only optional.
* Avoidance of non-payment "Unnecessary Input Heuristic" (1, 2). For
reference, see the definition here
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539
and some data here
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2800791
(whole comment thread may be of interest) - note this UIH name is afaik
Chris Belcher's invention, it seems useful as a categorisation.
So, it seems that UIH2 is more important to avoid; while some more
sophisticated wallet coin selection algorithms *may* occasionally pick
an input set where one input is larger than any output, most won't, and
some in particular never will. So I think the text here should indicate
that *the receiver's contributed input(s) SHOULD be chosen to avoid
triggering the UIH2 heuristic where possible, so that the final payjoin
transaction is maximally plausible as an ordinary payment" or similar.
UIH1 is a nice-to-have (meaning the plausibility extends to two
different (both wrong) payment amounts, but it may not be necessary to
mention it in the BIP.
Specific comments
=================
>> ====Step 4. Receiver validates, re-signs, and propagates on the
bitcoin network====
I believe this should say "Sender" not Receiver. Also for the next
sentence, s/receiver/sender/:
>> The receiver MUST validate the ''partial transaction'' was changed
correctly and non-maliciously (to allow using potentially untrusted
communication channels), re-sign its original inputs and propagate the
final transaction over the bitcoin network.
Your very correct highlighting of the attack vector of "receiver gives
sender other inputs belonging to sender to unwittingly sign (described
below), should be highlighted here, perhaps with the phrase "re-sign its
ORIGINAL inputs" (only!)".
>> When the sender is creating a "template transaction" it is done
almost identically to creating a normal send, with the exception that
*only* segwit inputs may be used. The sender is also encouraged to use a
slightly more aggressive feerate than usual as well as BIP125 (Opt-in
Full Replace-by-Fee Signaling), but neither is strictly required.
"slightly more aggressive feerate than usual" - this I understand is to
make up for receiver contributed utxo, OK.
"*only* segwit inputs" - it certainly makes things simpler. One can work
with non-segwit inputs but especially considering (as mentioned below)
we really ought to "MUST" the part about matching input types, I tend to
agree that non-segwit should be disallowed.
>> The receiver must add at least one input to the transaction (the
"contributed inputs"). If the receiver has no inputs, it should use a
500 internal server error, so the client can send the transaction as per
normal (or try again later).
Would it not be much simpler for the server to return a different
(non-error) response indicating that it will broadcast the template tx
in this case?
>> Its generally advised to only add a single contributed input, however
they are circumstances where adding more than a single input can be useful.
I don't see a good reason to advise the use of only 1 input? (but this
will also connect with the above generic comment about "UIH"). I guess
it's because of your approach to fees. I'd prefer not to create a
limitation here.
>> To prevent an attack where a receiver is continually sent variations
of the same transaction to enumerate the receivers utxo set, it is
essential that the receiver always returns the same contributed inputs
when it's seen the same inputs.
This is an approach to avoiding this problem which has the virtue of
simplicity, but it seems a little problematic. (1) You must keep a
mapping of proposed payment utxos to one's proposed contributed input
utxos, but (2) how should this be updated if you need to spend the
contribution mentioned in (1)? Ironically use of payjoin exacerbates
this issue, because it results in a smaller number of utxos being held
by the receiver at any one time :) All this considered, I still see the
value in your approach, but it might end up with a re-attempted payment
being rejected. Certainly the more complex suggested solutions coming
out of the summer 2018 coinjoin workshop aren't as practical as this,
and may be overkill for small merchants/receivers.
>> It is strongly preferable that the receiver makes an effort to pick a
contributed input of the same type as the other transaction inputs if
possible.
I have also thought about this and you could reasonably argue this
should be a MUST section in the BIP, that is, if the receiver cannot use
inputs of the same type, he should fall back to the template
transaction. A mixed-input payjoin/coinjoin is essentially
near-perfectly identifiable as such (there is almost zero other usage of
multi-type-input transactions), which is a very different thing than a
non-identifiable payjoin transaction. That may or may not be OK to the
sender. This is debatable though, for sure.
>> After adding inputs to the transaction, the receiver generally will
want to adjust the output that pays himself by increasing it by the sum
of the contributed input amounts (minus any fees he wants to
contribute). However the only strict requirement is that the receiver
*must never* add or remove inputs, and *must not* ever decrease any
output amount.
"*must never* add or remove inputs" - did you mean "must never remove
inputs"? he surely has to add one! Or, perhaps you mean he must not
alter the list of inputs provided by the sender (in which case it should
be clarified).
"must not decrease any output amount" - I initally disagreed with this
but it is a better option than the one I currently chose in Joinmarket
payjoin (sender pays all fee as long as receiver utxos are not too
much). So this means that the receiver either consciously chooses to not
increase the fee, meaning the fee rate may be a bit low (hence your
earlier comment about being generous, got it), or contributes via the
payout amount. I guess the latter might break merchant software
expecting to have amount output fixed and fees determined by change.
Regards,
Adam Gibson/waxwing
On 30. 08. 18 22:24, Ryan Havar via bitcoin-dev wrote:
> I've just finished writing an implementing of this, and extremely happy
> with how it turned out. So I'd like to go and try go down the path of
> more formally describing it and getting some comments and ultimately
> encourage its wide-spread use.
>
>
> ==Abstract==
>
> The way bitcoin transactions are overwhelming used is known to leak more
> information than desirable. This has lead to fungibility concerns in bitcoin
> and a raise of unreasonably effective blockchain analysis.
>
> Bustapay proposes a simple, practical way to bust these assumptions to
> immediate
> benefit of the sender and recievers. Furthermore it does so in such a
> way that
> helps recievers avoid utxo bloat, a constant problem for bitcoin merchants.
>
> ==Copyright==
>
> This BIP is in the public domain.
>
> ==Motivation==
>
> One of the most powerful heuristic's employed by those whose goal is to
> undermine
> bitcoin's fungiblity has been to assume all inputs of a transaction are
> signed by
> a single party. In the few cases this assumption does not hold, it is
> generally
> readibly recognizable (e.g. traditional coinjoins have a very obvious
> structure,
> or multisig outputs are most frequently validated onchain).
>
> Bustapay requires no changes to bitcoin and creates bitcoin transactions
> that are
> indistinguishable from normal ones.
>
> It is worth noting that this specification has been intentionally kept
> as simple
> as possible to encourage adoption. There are almost an endless amount of
> extensions
> possible but the harder the implementation of clients/server the less
> likely it
> will ever be done. Should bustapay enjoy widespread adoption, a "v2"
> specification
> will be created with desired extensions.
>
> ==Specification==
>
> A bustapay payment is made from a sender to a receiver.
>
> Step 1. Sender creates a bitcoin transaction paying the receiver
>
> This transaction must be fully valid, signed and all inputs must use
> segwit. This transaction is known as the "template transaction". This
> transaction must not be propagated on the bitcoin network.
>
> Step 2. Sender gives the "template transaction" to the receiver
>
> This would generally be done as an HTTP POST. The exact URL to submit it
> to could be specified with a bip21 encoded address. Such as
> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit
> and the HTTP body should be the raw transaction hex encoded as text.
>
> Step 3. Receiver processes the transaction and returns a partially
> signed coinjoin
>
> The receiver validates the transaction is valid, pays himself and is
> eligible for propation. The receiver then adds one of his own inputs
> (known as the "contributed input") and increase the output that pays
> himself by the contributed input amount. Doing so will invalidate the
> "template transaction"'s original input signatures, so the sender needs
> to return this "partial transaction" back to the receiver to sign. This
> is returned as a hex-encoded raw transaction a response to the original
> HTTP POST request.
>
> Step 4. Receiver validates, re-signs, and propagates on the bitcoin network
>
> The receiver is responsible in making sure the "partial transaction"
> returned by the sender was changed correctly (it should assume the
> connection has been MITM'd and act accordingly), resign its original
> inputs and propagates this transaction over the bitcoin network. The
> client must be aware that the server can reorder inputs and outputs.
>
> Step 5. Receiver observes the finalized transaction on the bitcoin network
>
> Once the receiver has seen the finalized transactions on the network
> (and has enough confirmations) it can process it like a normal payment
> for the sent amount (as opposed to the amount that it looks like on the
> network). If the receiver does not see the finalized transaction after a
> timeout will propagate the original "template transaction" to ensure the
> payment happens and function a strong anti-DoS mechanism.
>
>
> === Implementation Notes ===
> For anyone wanting to implement bustapay payments, here are some notes
> for receivers:
>
> * A transaction can easily be checked if it's suitable for the mempool
> with testmempoolaccept in bitcoin core 0.17
> * Tracking transactions by txid is precarious. To keep your sanity make
> sure all inputs are segwit. But remember segwit does not prevent txid
> malleability unless you validate the transaction. So really make sure
> you're using testmempoolaccept at the very least
> * Bustapay could be abused by a malicious party to query if you own a
> deposit address or not. So never accept a bustapay transaction that pays
> an already used deposit address
> * You will need to keep a mapping of which utxos people have showed you
> and which you revealed. So if you see them again, you can reveal the
> same one of your own
> * Check if the transaction was already sorted according to BIP69, if so
> ensure the result stays that way. Otherwise probably just shuffle the
> inputs/outpus
>
> Notes for sending applications:
>
> * The HTTP response must *not* be trusted. It should be fully validated
> that no unexpected changes have been made to the transaction.
> * The sender should be aware the original "template transaction" may be
> propagated at any time, and in fact can intentionally be
> done so for the purpose of RBF as it should have a slightly higher fee
> rate.
>
> == Credits ==
> The idea is obviously based upon Dr. Maxwell's seminal CoinJoin
> proposal, and reduced scope inspired by a simplification of the "pay 2
> endpoint" (now offline) blog post by blockstream.
>
>
> -Ryan
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|