path: root/89/9f353900c00b83f70fec586bd7e9638438233f

Delivery-date: Tue, 09 Apr 2024 14:53:01 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBNHR22YAMGQE7FLSNPA@googlegroups.com>)
	id 1ruJOm-0005QJ-Cj
	for bitcoindev@gnusha.org; Tue, 09 Apr 2024 14:53:00 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-617d0580378sf90839317b3.3
        for <bitcoindev@gnusha.org>; Tue, 09 Apr 2024 14:52:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1712699573; x=1713304373; 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:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=67e0RWJR73sNTvp9iNERA0964k1VK28PVL9jbRpwsWE=;
        b=QuGVQsH3FOnCJ9mIZadqD3LlZ/921rBxcrLCeexX+njCq11x1tfSFyY48taUkv+WDS
         bHyPVVI/idiELzwx+deVtmxUPH35D1Wlx+D47VYcsDjiKdLIeJDyW7jKaitRDLdXz/W8
         GQWi8Y6Wdad2zrKUmK0if0AmqsSj0lKhqV2sz10JXbcwVa3m+o6M4xZoYTevXoiq19dF
         CmBrCXecOGJ1SZH/6AhjUKAhK9y10THOADmXb2mJH9H04AItqmS+3p1MVPswszShUho8
         OXHPpYwn192AkBw8ZuZUJIWqWAvzqQKdgXKTYDRziEjrwqdQ4RbwCVxzOZbaO9p0emeM
         4Bbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1712699573; x=1713304373; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=67e0RWJR73sNTvp9iNERA0964k1VK28PVL9jbRpwsWE=;
        b=YXPj+1q5jXbnfXcvavQBHQGentq3uTZoZPFCnweveljXChfUzwU57ft4AJ4/WMxzEI
         SIhYOyoXZG56bdZqi5HpdWHwZeyg0QW5b7WiGDIZcppdJqzXFcG92Ob6VLW3rHMA5GCb
         HXm8U9goipY0M/27nJ6RwqgrqpVa4yh1M7Qknde54aOQkoRjBe7g5xCbHQvqyu0u5o93
         MB3/zGJrzInWqvkH/Bb6+TGrK1yvuFRMDEhvnAxHXgqMa1BfHFeezRIj0cxUK06EAQ0N
         zOid34UoUWONZ4uERUTF0djQ4a2KLQokihOckS0RyR0FKhfGNk/ADuZ8piZz5ZHW7HNd
         sGNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712699573; x=1713304373;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=67e0RWJR73sNTvp9iNERA0964k1VK28PVL9jbRpwsWE=;
        b=MzD12AMFMlmgrgz63a3gJMtoA1JIycw47HeeoLgXu+kvQEDa716N13MXM+5bflggHe
         R1nQbmLWrtozaym390Itvj46E4fx2A6OeJRGkfl9ZZMoO3pOl3drfZv3gR7LmqcfJP+y
         lW1ZkZWpO2LH8SR4TvEU2PdyNc5uyZJPKyuBW2IrHHpXL1g/18tuNbP4ykt5Pw0cv9QC
         tL8VsqbPdeCiJZaGD5Fx+HjlRhFTueeRfus9PbIiLoZjFy+dB7vR8MUWVLo1f5d7elrV
         bEcHGPBAo4t4pgKilln53NeBwAh2lF4GPPXzx93St/bE9+J4m9EpICnJEU7J7AOqTJN7
         weJw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUCWQruaBsBj0tloUUUxmo31v1GlvULyGty/jVqfQaELUFeRxlUIY3hPfTbfSg8tKqFSDIM6IdzQyl70GN7SaqvHLN/yYQ=
X-Gm-Message-State: AOJu0YwzvAlwpy10mvzzm+rPjgwakSajMjVlE2Gqq4fKWyAcLqTCDxf0
	e2DcDaEyJUg2uVpd8G3RndfJHpQCiMi9i27Co1qb7G5SmjMA53Kq
X-Google-Smtp-Source: AGHT+IHpuxIXx0GDDQpTDJmg0Xq6JCqQ95GRqoO6+9p3r2TSFYDCPCz+l7bpGCwLKF6iEoJrEptLLQ==
X-Received: by 2002:a25:b227:0:b0:dc7:4cb1:6817 with SMTP id i39-20020a25b227000000b00dc74cb16817mr1150106ybj.22.1712699573431;
        Tue, 09 Apr 2024 14:52:53 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:72c4:0:b0:dcc:4b24:c0dd with SMTP id n187-20020a2572c4000000b00dcc4b24c0ddls15149ybc.0.-pod-prod-08-us;
 Tue, 09 Apr 2024 14:52:52 -0700 (PDT)
X-Received: by 2002:a05:690c:6311:b0:614:ff0d:2c7b with SMTP id ho17-20020a05690c631100b00614ff0d2c7bmr235011ywb.10.1712699572226;
        Tue, 09 Apr 2024 14:52:52 -0700 (PDT)
Received: by 2002:a05:690c:dc6:b0:609:3e5d:63d0 with SMTP id 00721157ae682-61841304c15ms7b3;
        Tue, 9 Apr 2024 14:40:28 -0700 (PDT)
X-Received: by 2002:a05:6902:1148:b0:dc6:e1ed:bd1a with SMTP id p8-20020a056902114800b00dc6e1edbd1amr281284ybu.2.1712698827214;
        Tue, 09 Apr 2024 14:40:27 -0700 (PDT)
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"
X-Original-Sender: antoine.riard@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_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--