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
|
Return-Path: <sebastian@gnet.me>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9D60AC0052
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 19:14:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 8B85B87670
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 19:14:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0-s8gQx1bS7U
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 19:14:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by hemlock.osuosl.org (Postfix) with ESMTPS id CEB8B8766C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 19:14:38 +0000 (UTC)
Date: Tue, 01 Dec 2020 19:14:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnet.me;
s=protonmail; t=1606850076;
bh=ca2+6oj3AGdrUA4NAlkH0T+Vc/3EZ0j4e3u73zLs4fk=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=CEPYZNlP1irFROlN0jgpdA3chrJzksni65ID4IQYL6jyeY8oCYzl9+KCq9gdtPzvP
Zx0WqYyORC06GYFrUoE6BO9jo5ENrUP/NEUXA5U0gyFeBjoJlAyf9h9/23RVj3lNLy
Oz9nkAINjqiAAfpVf0SJxuU7QS3uLqALFS/FPMbY=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Sebastian Geisler <sebastian@gnet.me>
Reply-To: Sebastian Geisler <sebastian@gnet.me>
Message-ID: <d7f827f2-b56d-f439-6c27-f22b46306e36@gnet.me>
In-Reply-To: <OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com>
References: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>
<00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org>
<3f172428-fb03-755f-3020-43817fdb1897@gnet.me>
<a_ytmG7wahHYE15SU_JER_s2dLFVpI8fRLBZTuV32QuXVOoOq2r7Dyof1tugJUFoE1bDAbYMffJ21HGNPVhh2dLGIWPkIPfEryT2Jk_sg3Y=@protonmail.com>
<OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 01 Dec 2020 20:04:23 +0000
Subject: Re: [bitcoin-dev] Out-of-band transaction fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 01 Dec 2020 19:14:41 -0000
Hi ZmnSCPxj,
thank you for your detailed comments. I agree that the centralization
risk is a big problem. I didn't fully take into account how hard it
might be to distinguish honest service providers, which makes that
problem so much worse. I think I'll not pursue this approach for that
reason. While such a system can't be prevented I don't need to encourage it=
.
I might look into the "pay someone to add their UTXO to a tx for fees
and give them back the remainder" approach though, it doesn't seem as
hazardous and might even be possible to do in a decentralized fashion.
> Now, you have mentioned a number of times that you believe Bitcoin will e=
ventually be a settlement layer, and somehow link this with standardized UT=
XO sizes.
> But I think the end goal should be:
>=20
> * To improve Bitcoin blockchain layer privacy.
>=20
> It should not matter how we achieve this, whether it involves standardize=
d UTXO sizes or not; if you want to use this solution, you need to present =
a good reason why this is the best solution for Bitcoin privacy, and better=
than other solutions.
I completely agree.
> For example, the JoinMarket way of CoinJoining does not require any parti=
cular standardized UTXO size.
> The upcoming SwapMarket that Chris Belcher is working on, also does not r=
equire such a standardized UTXO size, as it is based as well on the JoinMar=
ket technique, where the client can select whatever sizes it wants.
> Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes fo=
r privacy, if apparently JoinMarket and SwapMarket can improve privacy with=
out this?
These efforts are great! Yet all CoinJoin based protocols I have seen
(mostly academic ones tbh, that provide strong guarantees) have some
amount of overhead in the form of creating more UTXOs and bigger
transactions than minimally possible or even "toxic waste" we don't know
what to do with. As far as I understand it there's now way around that
without relaxing anonymity guarantees. Maybe I'm not up to date in that
regard.
I also think that the privacy properties/the actual anonymity set of
unequal output size CoinJoins (i.e. knapsack mixing) is not as well
understood as for evenly-sized output CoinJoins. If we are only talking
about user-defined CoinJoin output sizes it comes down to efficiency
again. This will nearly always lead to change and not many parties will
be interested in the particular output size so you even need to pay them
to participate.
Please bear with me as the following part is _very_ speculative:
I believe that if Bitcoin becomes mainstream (I take no stance whether
this is good or not, but consider it a possibility) transaction prices
are bound to increase dramatically, which would make such protocols
uneconomical. This also means most people will rely on some L2
technology. But the fees might even make Lightning nodes uneconomical
for the majority of people. So if we are lucky federated L2 systems, or
if we are unlucky centralized ones, will play an important role imo.
In such an environment, where on-chain transactions are mostly used as
settlements between somewhat big players, having (multiple tiers of)
evenly sized UTXOs makes a lot of sense. You don't need exact valued
transfers and get free/cheaper than free and effective mixing on spends
if you just combine your transactions.
So imo the pros of this technique are:
* as simple as possible (easy to assess exact anonymity set)
* cheap, so it could be made a default, leading to a large anon set
while the cons are:
* only makes sense when exact values aren't important (e.g. L2 funding)
* needs fee hacks
I don't want to derail this any further. I agree that my initial idea
bears too great risks of regulatory capture. While I find the
evenly-sized UTXO idea intriguing I'd be even happier about a
arbitrary-amount scheme that gives the same strong assurances in an
_efficient_ manner, I just haven't seen a way to achieve this so far.
Best,
Sebastian
|
