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
|
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 45F52C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Aug 2021 01:51:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2DF05400E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Aug 2021 01:51:01 +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_DNSWL_NONE=-0.0001,
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 LllGtbhA84i2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Aug 2021 01:50:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
by smtp2.osuosl.org (Postfix) with ESMTPS id E499E400B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Aug 2021 01:50:56 +0000 (UTC)
Date: Sat, 14 Aug 2021 01:50:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1628905853;
bh=BBak5x0bEWpOThbpmW5g1DxLrsrBBoOCYMWAogjpGY0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=Z0JFRuiLzIsQVuGjc7ozcxL/p3Rf/Z6RdLkZHPXJxpzhXN5S1nSvlf1N805GWquPN
aS9SrZpG2+B8IYeohFzgCPtabh5LbmJNa7jwBZWQ5LdZ5utxfvqFO6dpqdN18ejUWf
W3GkqTo6ZvdgGrweeFhYAzbKXtAUWPpM9Egn8Vug=
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
In-Reply-To: <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
<CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@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>
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: Sat, 14 Aug 2021 01:51:01 -0000
Good morning Zac,
> Hi=C2=A0ZmnSCPxj,
>
> Thank you for your insightful response.
>
> Perhaps I should take a step back and take a strictly functional angle. P=
erhaps the list could help me to establish whether=C2=A0the proposed functi=
onality is:
>
> Desirable;
> Not already possible;
> Feasible to implement.
>
> The proposed functionality is as follows:
>
> The ability to control some coin with two private keys (or two sets of pr=
ivate keys) such that spending is limited over time for one private key (i.=
e., it is for instance not possible to spend all coin in a single transacti=
on) while spending is unrestricted for the other private key (no limits app=
ly). No limits must apply to coin transacted to a third party.
>
> Also, it must be possible never having to bring the unrestricted private =
key online unless more than the limit imposed on the restrictive private ke=
y is desired to be spent.
>
> Less generally, taking the perspective of a hodler: the user must be able=
to keep one key offline and one key online. The offline key allows unrestr=
icted spending, the online key is limited in how much it is allowed to spen=
d over time.
>
> Furthermore, the spending limit must be intuitive. Best candidate I belie=
ve would be a maximum spend per some fixed number of blocks. For instance, =
the restrictive key may allow a maximum of 100k sats per any window of 144 =
blocks. Ofcourse the user must be able to set these parameters freely.
My proposal does not *quite* implement a window.
However, that is because it uses `nLockTime`.
With the use of `nSequence` in relative-locktime mode, however, it *does* i=
mplement a window, sort of.
More specifically, it implements a timeout on spending --- if you spend usi=
ng a presigned transaction (which creates an unencumbered specific-valued T=
XO that can be arbitrarily spent with your online keyset) then you cannot g=
et another "batch" of funds until the `nSequence` relative locktime passes.
However, this *does* implement a window that limits a maximum value spendab=
le per any window of the relative timelock you select.
The disadvantage is that `nSequence` use is a lot more obvious and discerni=
ble than `nLockTime` use.
Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that =
is a good cover for `nLockTime` transactions.
I believe Dave Harding proposed that wallets should also use, at random, (s=
ay 50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sn=
iping mechanism.
This alternate anti-fee-sniping would help cover `nSequence` use.
Note that my proposal does impose a maximum limit on the number of windows.
With `nSequence`-in-relative-locktime-mode the limit is the number of times=
that the online keyset can spend.
After spending that many windows, the offline keyset has to be put back onl=
ine to generate a new set of transactions.
It has the massive massive advantage that you can implement it today withou=
t any consensus change, and I think you can expect that consensus change wi=
ll take a LONG time (xref SegWit, Taproot).
Certainly the functionality is desirable.
But it seems it can be implemented with Bitcoin today.
Regards,
ZmnSCPxj
|
