Timewarp Attacks and Long-Term Timelocked Script Paths
Antoine Riard
> 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.