summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2024-04-09 14:40:26 -0700
committerbitcoindev <bitcoindev@googlegroups.com>2024-04-09 14:53:00 -0700
commit5e26e1bc1b8f16a94398eba802904af9b403f1ea (patch)
tree871f2744e60d3b72f128bca7d25a3ac477fa843e
parent40fa569c6699f75a82dab2f72295d35bc1fa1892 (diff)
downloadpi-bitcoindev-5e26e1bc1b8f16a94398eba802904af9b403f1ea.tar.gz
pi-bitcoindev-5e26e1bc1b8f16a94398eba802904af9b403f1ea.zip
[bitcoindev] Timewarp Attacks and Long-Term Timelocked Script Paths
-rw-r--r--89/9f353900c00b83f70fec586bd7e9638438233f303
1 files changed, 303 insertions, 0 deletions
diff --git a/89/9f353900c00b83f70fec586bd7e9638438233f b/89/9f353900c00b83f70fec586bd7e9638438233f
new file mode 100644
index 000000000..c68d787b5
--- /dev/null
+++ b/89/9f353900c00b83f70fec586bd7e9638438233f
@@ -0,0 +1,303 @@
+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--
+