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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Delivery-date: Tue, 03 Jun 2025 11:29:34 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBD2IRYOX4AFRBA767TAQMGQEOG7RJEY@googlegroups.com>)
id 1uMWOD-0003pj-Gn
for bitcoindev@gnusha.org; Tue, 03 Jun 2025 11:29:34 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e812e064de6sf4207871276.3
for <bitcoindev@gnusha.org>; Tue, 03 Jun 2025 11:29:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1748975367; x=1749580167; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=vC+ws3VKMxVGYXAcUtrIHvW2fC3+wll1fsPESYXMZE0=;
b=a4oD/ZV1vAP01w7eKC/ElDV4uN4NYGinS36fu4iBlpuAajHSreNr1aZHA2zCnvVBGo
SL+/g1zL9J5iXY4i5sZ5lkOixm+MnE/wdS0+GGmXSYvFyvdg3He2Y3nsu762vdPoPLei
+Gi21/gCC6Q20SJDCltx5ecV2WgCkS/WXDggVGMY2HVX9zjL+l0IcXMyvWGMgPC4a5Jt
URLgti7c4xMGv3OWSSNNSbYOhH32T3zmU+7N4u6chqz4HpZxIG+Kdu3oqYC5rNbpFTE7
Kxy+7gECRSc4z7mdG+zMLLVlMQwSh0vCWKgPmRKepixc50JDHV8mXo8Sb8IUBw7IW/hq
UlKw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748975367; x=1749580167; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=vC+ws3VKMxVGYXAcUtrIHvW2fC3+wll1fsPESYXMZE0=;
b=mFLH9LJPPQRvNNMQnAX9fXcgfOWV0KpS6eUlybA8IRc40i3O7LlUcITz4F9MgN059T
/Af9FBHxMLEs19k8T4Buhq6XOz//0a6ezWzFzVjwUs+g3CSWIbzNOFYJhNUuHOhOneTi
NE/rBG71LL97napP99IrGudPSvyQKWF39nJyS/eEGq6wm4u0J42PYdDY11yC6I3vQICl
vO3YTpeAkR/dO8E7RXWZcgKh6Ol9HNKLO7CkGYRbN3W0pZ6cgseznEQvJ+rjMW9Idh/0
1MMm5rrOLkCX52XuMdh/3SYMUM2jq3sAlbEIrf5jsmcqR2ZP7Djq63RPexKYozEukmj4
AYKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748975367; x=1749580167;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=vC+ws3VKMxVGYXAcUtrIHvW2fC3+wll1fsPESYXMZE0=;
b=OYVmGT3Ua/98b8OU1+3rW6wrEqiq8mmiEcBUN6Nu1RgaY/MTs5+vX0M/+m+JrrfEpq
nIKt8VkL7F9a/+Zg4b06DNW3WJeuEUQ5DgAkbvnX9rwNlZWu1aiRAkwmkeRMTyWrGxW8
fJfV1DXja9p2CQzfB/81OBaJiq8gCbmtSSlmg8qteaSR3UJp/KR4Rv2vy/EfGmxONuY4
Aw4FjvbIhohWcO2w8CLe4sSGdZ6rUuPhIZIWtJFNZXXpo3vNX0o3pdi5fcWbM7cX4zva
nBiH0RSeOckCgZhBBRVn4mJDN1asxSn3JtRvDDo8jYpvKD8CbV4LnXKM2oOzRYORwM1c
scaw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVCOOZCWJuzSbVjm3l+BFsGZVD30ud+mlnDT2cm8/EJm5Z7w2sS63ArGS9sa6tv2/cIPUrDmYQWbpZh@gnusha.org
X-Gm-Message-State: AOJu0Yz5cp0SL11yjCB2ANnPEQ4fiekbC2kxdpM230wzWwlOT54vCntv
dBoIux+yBFrUtRXyjLc9MOwtrOjkWgiZExzignrtiniyXSz9vlbdI4b3
X-Google-Smtp-Source: AGHT+IGFw/gy/Kz8y6P6dIi3f7RixX9aYwjtV/w+4vCOcZ9ISDDLxa3wuGiOSF9YZrJWGxcm8vyg2Q==
X-Received: by 2002:a05:6902:4411:b0:e7d:7264:6bd5 with SMTP id 3f1490d57ef6-e7fec878b79mr19937809276.10.1748975367413;
Tue, 03 Jun 2025 11:29:27 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcs2Yx+0ytOOU2zTMhg1B/Hf/HqljKxm+XZx798FpaNxQ==
Received: by 2002:a25:b18c:0:b0:e7d:6611:588f with SMTP id 3f1490d57ef6-e7f6f6a937els5590405276.0.-pod-prod-00-us;
Tue, 03 Jun 2025 11:29:23 -0700 (PDT)
X-Received: by 2002:a05:690c:680b:b0:70e:39e:91c2 with SMTP id 00721157ae682-710c98bd179mr51216237b3.11.1748975363600;
Tue, 03 Jun 2025 11:29:23 -0700 (PDT)
Received: by 2002:a05:690c:360a:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-710d7084f23ms7b3;
Tue, 3 Jun 2025 10:26:43 -0700 (PDT)
X-Received: by 2002:a05:690c:6382:b0:70e:2173:6f98 with SMTP id 00721157ae682-710c9cdf120mr47169537b3.6.1748971602404;
Tue, 03 Jun 2025 10:26:42 -0700 (PDT)
Date: Tue, 3 Jun 2025 10:26:41 -0700 (PDT)
From: Leo Wandersleb <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5e393f57-ac87-40fd-93ef-e1006accdb55n@googlegroups.com>
In-Reply-To: <ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_SwlrooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg=@proton.me>
References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com>
<CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com>
<33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com>
<ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_SwlrooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg=@proton.me>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_477528_1713939525.1748971601858"
X-Original-Sender: LWandersleb@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_477528_1713939525.1748971601858
Content-Type: multipart/alternative;
boundary="----=_Part_477529_508156734.1748971601858"
------=_Part_477529_508156734.1748971601858
Content-Type: text/plain; charset="UTF-8"
Hi conduition,
Thanks for your careful analysis - excellent catches.
You're absolutely right about the txid vulnerability. The commitment must
be to the complete transaction including witness data (wTXID or equivalent)
to prevent an attacker from pre-committing to unsigned transactions. This
is essential - otherwise an attacker could indeed enumerate the UTXO set
and create commitments without knowing the private keys.
Regarding updates: You're correct that frequent updates would be needed as
wallets receive new UTXOs. However, I don't see this as a major issue -
users could batch their commitments periodically (say, monthly) rather than
after every transaction. The scheme is particularly important for existing
UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.).
For new UTXOs, wallets should ideally migrate to quantum-safe addresses
once available. OpenTimestamps aggregation would indeed help with scaling
and provide plausible deniability about the number of UTXOs being protected.
The time delay serves a different purpose than you might expect. It's not
about preventing commitment forgery after pubkey exposure, but rather about
allowing priority based on commitment age when multiple parties claim the
same UTXO:
1. Weak announcement starts the 144-block window
2. During this window, anyone with a strong commitment can reveal it
3. The oldest valid commitment wins
This creates the "poison pill" effect: an attacker might crack a key and
try to spend a UTXO, but if the original owner has an older commitment,
they can reclaim it during the window. The uncertainty about which UTXOs
have poison pills makes attacking large "lost" UTXOs risky - hence less
disruptive to the network.
The delay essentially allows a "commitment priority contest" where age
determines the winner, protecting users who prepared early while still
allowing these users to not move their funds.
Best,
Leo
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com.
------=_Part_477529_508156734.1748971601858
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi conduition,<br /><br />Thanks for your careful analysis - excellent catc=
hes.<br /><br />You're absolutely right about the txid vulnerability. The c=
ommitment must be to the complete transaction including witness data (wTXID=
or equivalent) to prevent an attacker from pre-committing to unsigned tran=
sactions. This is essential - otherwise an attacker could indeed enumerate =
the UTXO set and create commitments without knowing the private keys.<br />=
<br />Regarding updates: You're correct that frequent updates would be need=
ed as wallets receive new UTXOs. However, I don't see this as a major issue=
- users could batch their commitments periodically (say, monthly) rather t=
han after every transaction. The scheme is particularly important for exist=
ing UTXOs that already have exposed pubkeys (old P2PK, reused addresses, et=
c.). For new UTXOs, wallets should ideally migrate to quantum-safe addresse=
s once available. OpenTimestamps aggregation would indeed help with scaling=
and provide plausible deniability about the number of UTXOs being protecte=
d.<br /><br />The time delay serves a different purpose than you might expe=
ct. It's not about preventing commitment forgery after pubkey exposure, but=
rather about allowing priority based on commitment age when multiple parti=
es claim the same UTXO:<br /><br />1. Weak announcement starts the 144-bloc=
k window<br />2. During this window, anyone with a strong commitment can re=
veal it<br />3. The oldest valid commitment wins<br /><br />This creates th=
e "poison pill" effect: an attacker might crack a key and try to spend a UT=
XO, but if the original owner has an older commitment, they can reclaim it =
during the window. The uncertainty about which UTXOs have poison pills make=
s attacking large "lost" UTXOs risky - hence less disruptive to the network=
.<br /><br />The delay essentially allows a "commitment priority contest" w=
here age determines the winner, protecting users who prepared early while s=
till allowing these users to not move their funds.<br /><br />Best,<br /><b=
r />Leo<br />
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com</a>.<br />
------=_Part_477529_508156734.1748971601858--
------=_Part_477528_1713939525.1748971601858--
|
