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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id A18BAC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:48:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 84904403C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:48:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.598
X-Spam-Level: *
X-Spam-Status: No, score=1.598 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, URI_NOVOWEL=0.5]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id H7XVhUvwtwnX
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:48:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp4.osuosl.org (Postfix) with ESMTPS id 9647A4039F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:48:54 +0000 (UTC)
Date: Mon, 16 Aug 2021 11:48:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1629114531;
bh=walDjUhuZHarxt5DPInACk9xYBSv7lPIi4ED46dBcn4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=u2p110BszejCuZjpTt9qg5LNqj8K02aVElItVFdvmRn3jabpPJhNrQDrPzjb1uvbP
4MAfTgrtGLoSniOamvwgjmImBrlYuHED9ZJj2lEDC53dDRTl8gUJ81ILAotoq8eyNa
6EO2zXgJ3Baf0U0j7QPq2SRxt9ZIr0Ge8z1mhZB8=
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com>
In-Reply-To: <CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<CAGpPWDZL6BpzoNa0Qgf-Ux60fyWPjZH=NESkgbhEQO_My=XiAg@mail.gmail.com>
<CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@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>
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: Mon, 16 Aug 2021 11:48:59 -0000
Good morning Zac,
> Thank you for your counterproposal. I fully agree that as a first step we=
must establish whether the proposed functionality can be implemented witho=
ut making any changes to consensus.
>
> Your counterproposal is understandably more technical in nature because i=
t explores an implementation on top of Bitcoin as-is. However I feel that f=
or a fair comparison of the functionality of both proposals a purely functi=
onal description of your proposal is essential.
>
> If I understand your proposal correctly, then I believe there are some ma=
jor gaps between yours and mine:
>
> Keys for unrestricted spending: in my proposal, they never have to come o=
nline unless spending more than the limit is desired. In your proposal, the=
se keys are required to come online in several situations.
Correct, that is indeed a weakness.
It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html
Basically: any quorum of signers can impose any rules that are not implemen=
table on the base layer, including the rules you desire.
That quorum is the "offline keyset" in my proposal.
>
> Presigning transactions: not required in my proposal. Wouldn=E2=80=99t su=
ch presigning requirement be detrimental for the usability of your proposal=
? Does it mean that for instance the amount and window in which the transac=
tion can be spent is determined at the time of signing? In my proposal, the=
re is no limit in the number of transactions per window.
No.
Remember, the output is a simple 1-of-1 or k-of-n of the online keyset.
The online keyset can spend that wherever and however, including paying it =
out to N parties, or paying part of the limit to 1 party and then paying th=
e remainder back to the same onchain keyset so it can access the funds in t=
he future.
Both cases are also available in your proposal, and the latter case (pay ou=
t part of the limit to a single output, then keep the rest back to the same=
onchain keyset) can be used to add an indefinite number of transactions pe=
r window.
>
> Number of windows: limited in your proposal, unlimited in mine.
Correct, though you can always have a fairly large number of windows ("640k=
B ought to be enough for anybody").
>
> There are probably additional gaps that I am currently not technically ab=
le to recognize.
It requires a fair amount of storage for the signatures at minimum, though =
that may be as small as 64 bytes per window.
1Mb of storage for signatures would allow 16,384 windows, assuming you use =
1-day windows that is about 44.88 years, probably more than enough that a o=
ne-time onlining of the offline keys (or just print out the signatures on p=
aper or display as a QR code, whatever) is acceptable.
> I feel that the above gaps are significant enough to state that your prop=
osal does not meet the basic requirements of my proposal.
>
> Next to consider is whether the gap is acceptable, weighing the effort to=
implement the required consensus changes against the effort and feasibilit=
y of implementing your counterproposal.
>
> I feel that your counterproposal has little chance of being implemented b=
ecause of the still considerable effort required and the poor result in fun=
ctional terms. I also wonder if your proposal is feasible considering walle=
t operability.
See above, particularly the gap that does not, in fact, exist.
>
> Considering all the above, I believe that implementing consensus changes =
in order to support the proposed functionality would preferable =C2=A0over =
your counterproposal.
>
> I acknowledge that a consensus change takes years and is difficult to ach=
ieve, but that should not be any reason to stop exploring the appetite for =
the proposed functionality and perhaps start looking at possible technical =
solutions.
You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, `OP_=
CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them listed=
somewhere, which may be used to implement something similar without requir=
ing presigning.
Since the basic "just use `nSequence`" scheme already implements what you n=
eed, what the covenant opcodes buy you is that you do not need the offline =
keyset to be onlined and there is no need to keep signatures, removing the =
remaining gaps you identified.
With a proper looping covenant opcode, there is also no limit on the number=
of windows.
The issue with the covenant opcodes is that there are several proposals wit=
h overlapping abilities and different tradeoffs.
This is the sort of thing that invites bikeshed-painting.
I suggest looking into the covenant opcodes and supporting those instead of=
your own proposal, as your application is very close to one of the motivat=
ing examples for covenants in the first place.
Regards,
ZmnSCPxj
|
