* [bitcoindev] Timewarp Attacks and Long-Term Timelocked Script Paths
@ 2024-04-09 21:40 Antoine Riard
0 siblings, 0 replies; only message in thread
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
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 6227 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2024-04-09 21:53 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-09 21:40 [bitcoindev] Timewarp Attacks and Long-Term Timelocked Script Paths Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox