diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2024-04-09 14:40:26 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-04-09 14:53:00 -0700 |
commit | 5e26e1bc1b8f16a94398eba802904af9b403f1ea (patch) | |
tree | 871f2744e60d3b72f128bca7d25a3ac477fa843e | |
parent | 40fa569c6699f75a82dab2f72295d35bc1fa1892 (diff) | |
download | pi-bitcoindev-5e26e1bc1b8f16a94398eba802904af9b403f1ea.tar.gz pi-bitcoindev-5e26e1bc1b8f16a94398eba802904af9b403f1ea.zip |
[bitcoindev] Timewarp Attacks and Long-Term Timelocked Script Paths
-rw-r--r-- | 89/9f353900c00b83f70fec586bd7e9638438233f | 303 |
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>> 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">> 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">> 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">> 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">> 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">> 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">>= + 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">> 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">> Miners= + might be able to speed up the chain, but they can=E2=80=99t sign with keys= + they > don=E2=80=99t have, so I don=E2=80=99t think the timewarp attack= + represents some kind of new > 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" 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-- + |