Would you say the same of distributed key generation schemes like FROST?
There's DKG/MPC schemes which can obviate the issue to a degree in contexts like Nostr, and I think Frostr is pretty handy... something i'd like to implement in Sanctum at some point...
With Bitcoin though it's not a simple matter of a shared key, there's validation of any off-chain behavior. The "setup" of that future validation is therefore trusted.
Don't the existing timelocks in bitcoin come a little close to application logic?
If they were using some external clock then yes, you'd need some kind of time oracle, but since block height is inherent part of Bitcoin validation then there's no external application hook to validate, block height is already validated with or without them.
Timelock is really colloquial, not literal, a timelock is really a blocklock. The Satoshi team used the term Timechain in the earliest code due to the chronological nature of blocks.
There's DKG/MPC schemes which can obviate the issue to a degree in contexts like Nostr, and I think Frostr is pretty handy... something i'd like to implement in Sanctum at some point...
With Bitcoin though it's not a simple matter of a shared key, there's validation of any off-chain behavior. The "setup" of that future validation is therefore trusted.
If they were using some external clock then yes, you'd need some kind of time oracle, but since block height is inherent part of Bitcoin validation then there's no external application hook to validate, block height is already validated with or without them.
Timelock is really colloquial, not literal, a timelock is really a blocklock. The Satoshi team used the term Timechain in the earliest code due to the chronological nature of blocks.