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
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
