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
|
Return-Path: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F4EE1A19
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jan 2019 19:24:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E48883A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jan 2019 19:24:16 +0000 (UTC)
Date: Sun, 27 Jan 2019 19:24:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1548617054;
bh=KvkiKRhc8Ux5BoUUPYMkZ/iqGIu2FwpIh81ob/fKk9M=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=Pr7SVOMHguKYlytZu9t0ltAeAz1slgliFlZZCRfV+WDN+3wyBnuYBY9M9qzh3O9y3
gHiavFStsK/gPz581SYdRNgGg9u2GOQOpRqgdrbdGh7pTn7zRvxQN39sfbdGLN5Niq
tzbhX4T1NAT7W34efsEtPO+eq9xTDdVgj8b//ntA=
To: Adam Gibson <ekaggata@gmail.com>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <vJMuB76ZLt0LrRQZKavdrbfJZOdlTF_cmt81c2Eu2jwvzZ3c2SYaBu5aI6lAP-gEDO1QQdUB-WMJE-XkEGEOpNdSWGFBA8ptWDFVihGHTc4=@protonmail.com>
In-Reply-To: <2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@gmail.com>
References: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com>
<e15c5dd7-6fe1-b253-e129-aeae6493acd1@gmail.com>
<-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com>
<2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@gmail.com>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Sun, 27 Jan 2019 22:06:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 27 Jan 2019 19:24:18 -0000
> Is there a missing word. "by giving a person.."? Not actually sure what
> you're getting at here but I suspect it's again tangential to this BIP
> discussion.
Correct on both points. I meant to say "giving a (txid:vout:privkey)" to a =
person as means of payment.
> So I think the limiting factor is in fact creating a standard that a reas=
onable number
> of people could agree with (and I like operational definitions, so
> subjective as it is, I like the goal of "good/clear enough that it could
> be incorporated into something like BtcPayServer")
The problem with BtcPayServer (and a lot of similar software), is that it's=
not very unsuitable for any sender/receiver coinjoin due to it not having =
its own wallet. As I understand the basic architecture is just a fancy wrap=
per around bip32 address generation and monitoring the payment to those add=
resses. This means that adding support is not only a large code change, but=
it also entails a substantial change for merchants (you can't just have yo=
ur payments flow into your trezor, but need to run a hot wallet)
But I strongly believe that bustapay is good enough _right now_ for BtcPayS=
erver integration (which I'd happily contribute myself, if it wasn't for my=
unfamiliarity of the project and c#)
> But this relates back to my first "generic" point that you haven't
> addressed here - protocol versioning and the possibility of more than
> one option. Perhaps more realistic (debatable): have the current version
> be non-PSBT but with a plan to have a version bump with PSBT in future.
> Stuff like that. It seems crazy to actually long term reject it.
Adding backwards-compatible versioning at a later stage would be pretty tri=
vial through either the URL or HTTP header (e.g version=3D2) and if break=
ing backwards compatible is desirable it can also easily been done (e.g. bu=
mp the bip21 or send an incompatible request/response). I don't see this as=
a problem at all, and I'm not rejecting it long-term, I just don't think i=
t's particularly helpful to bikeshed now, when adoption is pretty much zero=
.
> I don't want to be that guy, but this was a central part of the proposal
> that came of the meetup last summer and is in Haywood's blogpost. I mean
> if you came up it with separately, then cool :) But I was there, that
> was established immediately as the right way of doing this to avoid a
> trivial attack.
Oh wow. had no idea. I saw the part about the receiver spamming the sender =
with a bunch of transactions, where only 1 of them are real and thought "ew=
ww" and "came up" with the idea of a "template transaction" instead. I was =
always wondering why no one came up it, but now it makes sense. The transac=
tion-spam stage was just an _additional_ layer of protection.
Ok, now I feel like an idiot =3D) Thanks for letting me know.
> The counterargument is Laurent's statistics which I previously linked,
> suggesting that maybe 30% of txs violate this anyway, today. I'm not
> sure about that, will need more analysis; Core's SRD algo may be one
> reason, but anyway ... better to make things look like payments.
I think it's interesting, but I don't think it particularly matters. Avoidi=
ng UIH1 I think is pretty much irrelevant, as it'll likely just confuse any=
analysis into thinking the payment is the reverse of what it actually is. =
And wallets already don't care about violating UIH2(as a way to do implicit=
consolidation). If 30% of tx's are violating it, you can be pretty sure it=
means the _vast majority_ of wallets run coin selection in such a way that=
can violation UIH2. Most wallets use a coin selection algorithm that you =
can approximate with:
while !enoughMoney {
inputs +=3D getAnotherInput();
}
and don't run a final pass that would prune superfluous inputs. Even coins=
ayer (shill alert) which I believe runs the most advanced coin selection al=
gorithms, will routinely and intentionally violate UIH2 when it's ideal (e.=
g. most classic case: when `consolidationFeeRate >=3D minFeeRate`).
I'm not trying to dismiss your analysis, as I find it interesting. I'm just=
against increasing the cognitive burden on implementations by mentioning a=
ll this stuff, when the truth is it (barely) matters. If wallets routinely=
avoided UIH2 and making a UIH2 payment would "out" the transaction as much=
more likely to be a bustapay, then I'd definitely reconsider and provide a=
basic suggestion into how to try avoid it.
And like I said, I also think there's much more important things that go in=
to "picking a contributed input" than just this.
> A last point, you also don't see value in being more explicit about
> simple things like transaction version and locktime? Even if you think
> these things should not be controlled, e.g. the protocol should allow
> either transaction version, then it'd be better to explicitly say so.
My intention was that wallets create a transaction exactly like they normal=
ly would do, and use that as the template transaction. The only time I want=
ed to be prescriptive was when it would increase the implementation complex=
ity (e.g. being non-segwit compatible is a pain in the ass. So I'd rather j=
ust be "pure segwit only" transactions). But something like locktime makes =
no difference as long as the transaction is mempool eligible, so I'd rather=
just wallets do what they do anyway.
Although I think there should be a separate discussion on improving the uni=
formity of bitcoin transactions in general. The current state of affairs is=
really atrocious.
---
P.S. I know I come across as obstinate, but it's not really so. If you can =
come up with an alternative to bustapay with some traction, I'd love to get=
behind it and deprecate bustapay in favor of it. I just am pretty happy wi=
th the state of bustapay and it's status a sort of "MVP of pay2endpoint", a=
nd unless the argument is in the form: "We'd love to support it, but in ord=
er to do so we'd need X" I'm probably going to disagree.
|
