Timewarp Attacks and Long-Term Timelocked Script Paths

Timewarp Attacks and Long-Term Timelocked Script Paths
From: Antoine Riard @ 2024-04-09 21:40 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3987 bytes --]

Hi all,

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

> No vault schemes that I’m aware of - and certainly none of the concrete

> examples I’ve done with OP_VAULT - automatically transfer coins after some

> height, relative or otherwise.

> As far as I can tell, the summary of this post is “using timewarp, miners 
are

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

> associated with automatic vault recoveries.” But I haven’t actually ever 
seen a

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

> scheme I’ve seen) consists of both a relative timelock *and* a recovery 
key.

> Miners might be able to speed up the chain, but they can’t sign with keys 
they > don’t have, so I don’t think the timewarp attack represents some 
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 
has been a subject of discussions since at least 2012 from looking on bitcoin 
talk.org archive [0]. I think multiple designs have been proposed 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.

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

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

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 you can have a wide range of scripting conditions, including 
n-of-m or hash-lock. In the context of multi-stakeholders deployment, which 
is my understanding of one of the use-case target of OP_VAULT, n-of-m or 
hash-lock witnesses can be owned by a subset of stakeholders, including 
after some relative or absolute timelocks.

There is no documentation of the operational key model for basic OP_VAULT 
use-cases, including "key-ceremony" (i.e under which computing environment 
the OP_VAULT tree of transactions and scriptpubkeys endpoints are generated 
and validated), neither recovery response policy (i.e under which basic set 
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 
don't have, without breaking the discreet log problem backing up ECC 
schemes we're using. I still think, they have wide margin 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 selection, and 
reduced on a single temporal dimension for exploitation).

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

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

-- 
2: Type: text/html, Size: 6227 bytes --]

 permalink raw reply	[|nested]