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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id D01F9C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 02:18:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B853C6079F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 02:18:05 +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: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id XAVwKunemOtb
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 02:18:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp3.osuosl.org (Postfix) with ESMTPS id 6DD6A60632
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 02:18:01 +0000 (UTC)
Date: Tue, 10 Aug 2021 02:17:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1628561878;
bh=y9TZLLYSqccGqhnFoMD8szpDz0H7W50e8hT94/aiXdQ=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=fCiET2XxEZDdTHwYYxKubT9rBSkB/1WBpCwfhQPg3JLg6KBgtdNhkOo7+wszuk6dh
zL5rHJbxOTxpvrVwFX4pP7YDCOo91zr9MgaxrJ/Z84mQ9iylZix2l8Hsx+KmnH38ug
uZectVKL05+YsVD8q5CHhoLtlVEUOOut1s+FXKAs=
To: Zac Greenwood <zachgrw@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
In-Reply-To: <CAJ4-pEAT8Rrf7dN9A+F2SUvaRz0-DqgDw45whtZcWCTPeQ+uxA@mail.gmail.com>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<20210725053803.fnmd6etv3f7x3u3p@ganymede>
<CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
<CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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, 10 Aug 2021 02:18:05 -0000
fromGood morning Zac,
With some work, what you want can be implemented, to some extent, today, wi=
thout changes to consensus.
The point you want, I believe, is to have two sets of keys:
* A long-term-storage keyset, in "cold" storage.
* A short-term-spending keyset, in "warm" storage, controlling only a small=
amount of funds.
What you can do would be:
* Put all your funds in a single UTXO, with an k-of-n of your cold keys (id=
eally P2TR, or some P2WSH k-of-n).
* Put your cold keys online, and sign a transaction spending the above UTXO=
, and spending most of it to a new address that is a tweaked k-of-n of your=
cold keys, and a smaller output (up to the limit you want) controlled by t=
he k-of-n of your warm keys.
* Keep this transaction offchain, in your warm storage.
* Put your cold keys back offline.
* When you need to spend using your warm keys, bring the above transaction =
onchain, then spend from the budget as needed.
If you need to have some estimated amount of usable funds for every future =
unit of time, just create a chain of transactions with future `nLockTime`.
nLocktime +1day nLockTime +2day
+------------+ +------------+ +------------+
cold UTXO -->| cold TXO|-->| cold TXO|-->| cold TXO|--> etc.
| | | | | |
| warm TXO| | warm TXO| | warm TXO|
+------------+ +------------+ +------------+
Pre-sign the above transactions, store the pre-signed transactions in warm =
storage together with your warm keys.
Then put the cold keys back offline.
Then from today to tomorrow, you can spend only the first warm TXO.
From tomorrow to the day after, you can spend only the first two warm TXOs.
And so on.
If tomorrow your warm keys are stolen, you can bring the cold keys online t=
o claim the second cold TXO and limit your fund loss to only just the first=
two warm TXOs.
The above is bulky, but it has the advantage of not using any special opcod=
es or features (improving privacy, especially with P2TR which would in theo=
ry allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using just=
`nLockTime`, which is much easier to hide since most modern wallets will s=
et `nLockTime` to recent block heights.
Regards,
ZmnSCPxj
|
