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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id E6150C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 09:00:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id D22D24047B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 09:00:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id L0Lh-CCOf1O0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 09:00:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp2.osuosl.org (Postfix) with ESMTPS id 5958140474
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 09:00:24 +0000 (UTC)
Date: Tue, 31 Aug 2021 09:00:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1630400421;
bh=kqDksoeqC0NhzEmlWhH/xucgy196RwKlaViLLcTKY0s=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=gEH74gp9CcDnH0YYC6lRPDSWiH8alyhHVrWJ554cJCAqPVaWRU2jgY83w/8yldMiN
0hruKXS6MpvhwbDtN6/KjcqwCZy4vdpWO5tNu6Avzeds4rkEJeT98j3jtcGyqB49Ll
c9LskHkr0NdZOq+VETTPY4Q5Sc6Srv9XazqJfHMs=
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <RrFU9zB125CEEua75KWb6IfANybTVN9AGfvjxE65Ysa1zOIgM-h48HmdBcfynW7HEd6kOaA5G-FhAVbmrq5DJXJJYHNArJDORGJklnBCU_I=@protonmail.com>
In-Reply-To: <CAJ4-pECwGfrrB15oS0t-+vsjn11sC=9Bz6JGsGsicUorCjuYpA@mail.gmail.com>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com>
<CAJ4-pEAT8Rrf7dN9A+F2SUvaRz0-DqgDw45whtZcWCTPeQ+uxA@mail.gmail.com>
<T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
<CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
<1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
<CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com>
<wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com>
<CAJ4-pECwGfrrB15oS0t-+vsjn11sC=9Bz6JGsGsicUorCjuYpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as
a function of total input value
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, 31 Aug 2021 09:00:29 -0000
Good morning Zac,
> Perhaps you could help me understand what would be required to implement =
the *unmodified* proposal. That way, the community will be able to better a=
ssess the cost (in terms of effort and risk) and weigh it against the perce=
ived benefits. Perhaps *then* we find that the cost could be significantly =
reduced without any significant reduction of the benefits, for instance by =
slightly compromising on the functionality such that no changes to consensu=
s would be required for its implementation. (I am skeptical that this would=
be possible though). The cost reduction must be carefully weighed against =
the functional gaps it creates.
For one, such output need to be explicitly visible, to implement the "chang=
e outputs must also be rate-limited".
A tx spending a rate-limited output has to know that one of the outputs is =
also a rate-limited output.
This flagging needs to be done by either allocating a new SegWit version --=
- a resource that is not lightly allocated, there being only 30 versions le=
ft if my understanding is correct --- or blessing yet another anyone-can-sp=
end `scriptPubKey` template, something we want to avoid which is why SegWit=
has versions (i.e. we want SegWit to be the last anyone-can-spend `scriptP=
ubKey` template we bless for a **long** time).
Explicit flagging is bad as well for privacy, which is another mark against=
it.
Notice how Taproot improves privacy by making n-of-n indistinguishable from=
1-of-1 (and with proper design or a setup ritual, k-of-n can be made indis=
tinguishable from 1-of-1).
Notice as well that my first counterproposal is significantly more private =
than explicit flagging, and my second coutnerproposal is also more private =
if wallets change their anti-fee-sniping mitigation.
This privacy loss represented by explicit flagging will be resisted by some=
people, especially those that use a bunch of random letters as a pseudonym=
(because duh, privacy).
(Yes, people can just decide not to use the privacy-leaking explicitly-flag=
ged outputs, but that reduces the anonymity set of people who *are* interes=
ted in privacy, so people who are interested in privacy will prefer that ot=
her people do not leak their privacy so they can hide among *those* people =
as well.)
You also probably need to keep some data with each output.
This can be done by explicitly storing that data in the output directly, ra=
ther than a commitment to that data --- again, the "change outputs must als=
o be rate-limited" requirement needs to check those data.
The larger data stored with the output is undesirable, ideally we want each=
output to just be a commitment rather than contain any actual data, becaus=
e often a 20-byte commitment is smaller than the data that needs to be stor=
ed.
For example, I imagine that your original proposal requires, for change out=
puts, to store:
* The actual rate limit.
* The time frame of the rate limit.
* The reduced rate limit, since we spent an amount within a specific time f=
rame (i.e. residual limit) which is why this is a change output.
* How long that time frame lasts.
* A commitment to the keys that can spend this.
Basically, until the residual limit expires, we impose the residual limit, =
then after the expiry of the residual limit we go back to the original rate=
limit.
The commitment to the keys itself takes at least 20 bytes, and if you are p=
lanning a to support k-of-n then that takes at least 32 bytes.
If this was not explicitly tagged, then a 32 byte commitment to all the nec=
essary data would have been enough, but you do need the explicit tagging fo=
r the "change outputs must be rate-limited too".
Note as well that the residual needs to be kept with the output.
Bitcoin Core does not store transactions in a lookup table, it stores indiv=
idual *outputs*.
While the residual can be derived from the transaction, we do not have a tr=
ansaction table.
Thus, we need to explicitly put it on the output itself, directly, since we=
only have a lookup table for the unspent outputs, not individual transacti=
ons.
(well there is `txindex` but that is an option for each node, not something=
consensus code can rely on)
So yes, that "change outputs must also be rate-limited" is the big sticking=
point, and a lot of the "gaps" you worry about occur when we drop this bit=
.
Drop this bit and you can implement it today without any consensus code cha=
nge, and with privacy good enough to prevent people with random letters as =
pseudonym from trying to stop you.
Regards,
ZmnSCPxj
|
