[bitcoin-dev] Statechain implementations
ZmnSCPxj
ZmnSCPxj at protonmail.com
Mon Mar 30 01:25:36 UTC 2020
Good morning Ruben,
> Hi ZmnSCPxj,
>
> > the current owner can ask the statechain entity to sign an alternative to the first stage, with 0 relative locktime
>
> Unless I am misunderstanding something, this seems to run into the problem that the original first stage transaction is already out there (and its relative timelock started ticking). There is no mechanism ensuring that the new tx will have precedence. And even if it did work, I doubt it's cleaner than doing a cooperative peg-out that simultaneously happens to peg back in, creating a brand new statechain UTXO with no history.
If:
* You are sure the old first stage tx has > 0 relative locktime.
* The replacement tx (which replaces the old first stage) has a 0 relative locktime.
* The replacement tx redirects the funds to a new funding output for a (logically continuous, onchain new) statechain.
Then the replacement tx, having a smaller relative locktime than the old first stage, has precedence.
Indeed, having a *smaller* relative locktime is exactly the mechanism Decker-Wattenhofer uses.
So this is the state, with the kickoff having just been confirmed onchain:
***blockchain***
[funding tx]->[kickoff tx]-+
_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _
offchain |
+->[[ 7] stage]->[[ 0] stage]->[[14] stage]-> state outputs
Since the first stage is still "ticking" it is not yet confirmable onchain.
You ask the statechain to create an alternative, 0-relative-locktime, re-funding tx, and create a new mechanism:
***blockchain***
[funding tx]->[kickoff tx]-+
_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _
offchain |
+->[[ 7] stage]->[[ 0] stage]->[[14] stage]-> state outputs
(OR)
|
+->[[ 0] funding tx]->[kickoff tx]->[[14] stage]->[[14] stage]->[[14] stage]->state outputs
Because it has a time advantage, this new re-funding tx has higher priority (and is the same mechanism Decker-Wattenhofer has anyway).
Regards,
ZmnSCPxj
More information about the bitcoin-dev
mailing list