Delivery-date: Tue, 09 Apr 2024 14:53:01 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 9 Apr 2024 14:40:26 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <e930eda7-da23-404f-811b-0072d8a35870n@googlegroups.com>
Subject: [bitcoindev] Timewarp Attacks and Long-Term Timelocked Script Paths
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_73836_989492713.1712698826852"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_73836_989492713.1712698826852
Content-Type: multipart/alternative; 
	boundary="----=_Part_73837_469554020.1712698826852"

------=_Part_73837_469554020.1712698826852
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

> https://delvingbitcoin.org/t/timewarp-miners-harvesting-and-vaults/218

> No vault schemes that I=E2=80=99m aware of - and certainly none of the co=
ncrete

> examples I=E2=80=99ve done with OP_VAULT - automatically transfer coins a=
fter some

> height, relative or otherwise.

> As far as I can tell, the summary of this post is =E2=80=9Cusing timewarp=
, miners=20
are

> incentivized to speed up block issuance to claim high fee transactions

> associated with automatic vault recoveries.=E2=80=9D But I haven=E2=80=99=
t actually ever=20
seen a

> vault scheme that is vulnerable to this, because the recovery path (in=20
every

> scheme I=E2=80=99ve seen) consists of both a relative timelock *and* a re=
covery=20
key.

> Miners might be able to speed up the chain, but they can=E2=80=99t sign w=
ith keys=20
they > don=E2=80=99t have, so I don=E2=80=99t think the timewarp attack rep=
resents some=20
kind of new > problem for vaults.

My original post scoped both vaults and time-locked wallets.

For time-locked wallets, dead's man switch with automatic transfer of coins=
=20
has been a subject of discussions since at least 2012 from looking on bitco=
in=20
talk.org archive [0]. I think multiple designs have been proposed along the=
=20
years by different wallet designers, though my understanding of one of the=
=20
plausible and simple design is a pre-signed absolute timelocked transaction=
=20
shared on one or more online hosts.

If no action is taken by the original owner of the coins, i.e transferring=
=20
the coins to a new address to re-set the dead's man switch timelock=20
duration, the timelocked transaction can be broadcast to transfer the coins=
=20
to a new owner (e.g in the context of inheritance scheme).

Under that setup, miners could trigger timewarp attacks to have early=20
broadcast of high-fee pre-signed transactions.

For vaults, from my understanding of OP_VAULT described in the paper, there=
=20
is a recovery path which is lock under a recovery-spk-hash. This isn't a=20
pure checksig operation and the proposal to have a scriptpubkey.=20
Scriptpubkey you can have a wide range of scripting conditions, including=
=20
n-of-m or hash-lock. In the context of multi-stakeholders deployment, which=
=20
is my understanding of one of the use-case target of OP_VAULT, n-of-m or=20
hash-lock witnesses can be owned by a subset of stakeholders, including=20
after some relative or absolute timelocks.

There is no documentation of the operational key model for basic OP_VAULT=
=20
use-cases, including "key-ceremony" (i.e under which computing environment=
=20
the OP_VAULT tree of transactions and scriptpubkeys endpoints are generated=
=20
and validated), neither recovery response policy (i.e under which basic set=
=20
of anomalies, a recovery server could broadcast a pre-signed transaction ?)=
.

This is correct, I'm not aware that miners can sign with private keys they=
=20
don't have, without breaking the discreet log problem backing up ECC=20
schemes we're using. I still think, they have wide margin of capabilities=
=20
to provoke a high absolute fee broadcast of a pre-signed transaction,=20
whatever hash-chain or signature-chain covenant, as soon as a temporal=20
dimension is introduced in the recovery response policy (relative timelock=
=20
can be probably guessed from recovery scriptpubkey templates selection, and=
=20
reduced on a single temporal dimension for exploitation).

I'll let as an exercise to the reader how miners minority coalition can=20
trigger timewarp attacks to target vaulting infrastructure, with owning far=
=20
less than 51% of network hashrate.

[0] https://bitcointalk.org/index.php?topic=3D110353.0

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/e930eda7-da23-404f-811b-0072d8a35870n%40googlegroups.com.

------=_Part_73837_469554020.1712698826852
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><font size=3D"2">Hi all,</font></div><div><br /></div>&gt; https://del=
vingbitcoin.org/t/timewarp-miners-harvesting-and-vaults/218<div><p style=3D=
"caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, =
sans-serif;"><font size=3D"3">&gt; No vault schemes that I=E2=80=99m aware =
of - and certainly none of the concrete</font></p><p style=3D"caret-color: =
rgb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, sans-serif;"><=
font size=3D"3">&gt; examples I=E2=80=99ve done with=C2=A0OP_VAULT=C2=A0- a=
utomatically transfer coins after some</font></p><p style=3D"caret-color: r=
gb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, sans-serif;"><f=
ont size=3D"3">&gt; height, relative or otherwise.</font></p><p style=3D"ca=
ret-color: rgb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, san=
s-serif;"><font size=3D"3">&gt; As far as I can tell, the summary of this p=
ost is =E2=80=9Cusing timewarp, miners are</font></p><p style=3D"caret-colo=
r: rgb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, sans-serif;=
"><font size=3D"3">&gt; incentivized to speed up block issuance to claim hi=
gh fee transactions</font></p><p style=3D"caret-color: rgb(34, 34, 34); col=
or: rgb(34, 34, 34); font-family: Arial, sans-serif;"><font size=3D"3">&gt;=
 associated with automatic vault recoveries.=E2=80=9D But I haven=E2=80=99t=
 actually ever seen a</font></p><p style=3D"caret-color: rgb(34, 34, 34); c=
olor: rgb(34, 34, 34); font-family: Arial, sans-serif;"><font size=3D"3">&g=
t; vault scheme that is vulnerable to this, because the recovery path (in e=
very</font></p><p style=3D"caret-color: rgb(34, 34, 34); color: rgb(34, 34,=
 34); font-family: Arial, sans-serif;"><font size=3D"3">&gt; scheme I=E2=80=
=99ve seen) consists of both a relative timelock=C2=A0<em>and</em>=C2=A0a r=
ecovery key.</font></p><p style=3D"caret-color: rgb(34, 34, 34); color: rgb=
(34, 34, 34); font-family: Arial, sans-serif;"><font size=3D"3">&gt; Miners=
 might be able to speed up the chain, but they can=E2=80=99t sign with keys=
 they &gt; don=E2=80=99t have, so I don=E2=80=99t think the timewarp attack=
 represents some kind of new &gt; problem for vaults.</font></p><p style=3D=
"caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34); font-family: Arial, =
sans-serif;"><font size=3D"2">My original post scoped both vaults and time-=
locked wallets.</font></p><p><font size=3D"2"><font color=3D"#222222" face=
=3D"Arial, sans-serif"><span style=3D"caret-color: rgb(34, 34, 34);">For ti=
me-locked wallets, dead's man switch with automatic transfer of coins has b=
een a subject of discussions since at least 2012 from looking on=C2=A0</spa=
n></font></font><font color=3D"#222222" face=3D"Arial, sans-serif" size=3D"=
2">bitcoin talk.org archive [0]. I think multiple designs have been propose=
d along the years by different wallet designers, though my understanding of=
 one of the plausible and simple design is a pre-signed absolute timelocked=
 transaction shared on one or more online hosts.</font></p><p><font color=
=3D"#222222" face=3D"Arial, sans-serif" size=3D"2">If no action is taken by=
 the original owner of the coins, i.e transferring the coins to a new addre=
ss to re-set the dead's man switch timelock duration, the timelocked transa=
ction can be broadcast to transfer the coins to a new owner (e.g in the con=
text of inheritance scheme).</font></p><p><font color=3D"#222222" face=3D"A=
rial, sans-serif" size=3D"2">Under that setup, miners could trigger timewar=
p attacks to have early broadcast of high-fee pre-signed transactions.</fon=
t></p><p><font color=3D"#222222" face=3D"Arial, sans-serif" size=3D"2">For =
vaults, from my understanding of OP_VAULT described in the paper, there is =
a recovery path which is lock under a recovery-spk-hash. This isn't a pure =
checksig operation and the proposal to have a scriptpubkey. Scriptpubkey yo=
u can have a wide range of scripting conditions, including n-of-m or hash-l=
ock. In the context of multi-stakeholders deployment, which is my understan=
ding of one of the use-case target of OP_VAULT, n-of-m or hash-lock witness=
es can be owned by a subset of stakeholders, including after some relative =
or absolute timelocks.</font></p><p><font color=3D"#222222" face=3D"Arial, =
sans-serif" size=3D"2">There is no documentation of the operational key mod=
el for basic OP_VAULT use-cases, including "key-ceremony" (i.e under which =
computing environment the OP_VAULT tree of transactions and scriptpubkeys e=
ndpoints are generated and validated), neither recovery response policy (i.=
e under which basic set of anomalies, a recovery server could broadcast a p=
re-signed transaction ?).</font></p><p><font color=3D"#222222" face=3D"Aria=
l, sans-serif" size=3D"2">This is correct, I'm not aware that miners can si=
gn with private keys they don't have, without breaking the discreet log pro=
blem backing up ECC schemes we're using. I still think, they have wide marg=
in of capabilities to provoke a high absolute fee broadcast of a pre-signed=
 transaction, whatever hash-chain or signature-chain covenant, as soon as a=
 temporal dimension is introduced in the recovery response policy (relative=
 timelock can be probably guessed from recovery scriptpubkey templates sele=
ction, and reduced on a single temporal dimension for exploitation).</font>=
</p><p><font color=3D"#222222" face=3D"Arial, sans-serif" size=3D"2"><span =
style=3D"caret-color: rgb(34, 34, 34);">I'll let as an exercise to the read=
er how miners minority coalition can trigger timewarp attacks to target vau=
lting infrastructure, with owning far less than 51% of network hashrate.</s=
pan></font></p><p><font color=3D"#222222" face=3D"Arial, sans-serif" size=
=3D"2"><span style=3D"caret-color: rgb(34, 34, 34);">[0]=C2=A0</span></font=
>https://bitcointalk.org/index.php?topic=3D110353.0</p></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/e930eda7-da23-404f-811b-0072d8a35870n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/e930eda7-da23-404f-811b-0072d8a35870n%40googlegroups.com</a>.=
<br />

------=_Part_73837_469554020.1712698826852--

------=_Part_73836_989492713.1712698826852--