Good morning Tom,
>
> We are starting to work on an implementation of the statechains concept
> (https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
> with particular interest in using the protocol enable the change of
> ownership (novation) of an individual position in an active discreet log
> contract (DLC) without an on-chain transaction, and without needing the
> cooperation of the counterparty. The protocol as outlined by Ruben requires
> features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is
> uncertain when (or even if) this will be added. So we are looking at variants
> that would work with current Bitcoin functionality, and it would be good to
> get some feedback on them.
>
> There are two main modifications we are looking at:
> 1. Instead of an eltoo-based backup/refund transaction (enabling the current
> owner to claim the UTXO in case the statechain entity disappears) we propose
> using a decrementing nLocktime for backup transactions as the output changes
> hands. Here, the first owner gets a backup transaction with an nLocktime at
> some future height (h0), then the next owner gets a backup transaction with
> nLocktime (h0-c) where c is a confirmation window. This approach has the
> downside of limiting the lifetime of the UTXO, but it also doesn't require
> the current owner to be always online.
I believe I suggested this to Ruben Somsen as well in the past, but you can
replace the state update mechanism with, for example, Decker-Wattenhofer
decrementing-`nSequence`, which while it has a limit on the number of updates,
does not have a limit on the time that a UTXO is locked in this mechanism.
You can even use the Decker-Wattenhofer trick of having a chain of
decrementing-`nSequence` mechanisms to effectively multiply the number of
updates that the overall mechanism can have.
The drawback is that in a unilateral close condition, the time to completely
resolve the unilateral close is very large.
For a quick reference for this technique:
* The funding transaction is anchored onchain, but all succeeding transactions
are offchain.
* This funding transaction has a particular funding transaction output.
* There is a kickoff transaction, which is a 1-input 1-output transaction
without any `nLockTime` or `nSequence` limits.
* This spends the funding tx out.
* The signer set of the output is the same as the signer set of the funding
transaction output.
* You could tweak keys or script to give a modicum of privacy.
* There is one or more decrementing-`nSequence` transactions, which are 1-input
1-output transactions.
* Each one has a particular `nSequence` with a relative-locktime constraint.
* This spends the kickoff transaction output.
* The signer set of the output is the same as the signer set of the funding
transaction output.
* There is one or more decrementing-`nSequence` transactions, which are 1-input
1-output transactions.
* Each one has a particular `nSequence` with a relative-locktime constraint.
* This spends the previous stage decrementing-`nSequence` transaction output.
* The signer set of the output is the same as the signer set of the funding
transaction output.
* Repeat the above stage a few times.
* There is one or more decrementing-`nSequence` transactions, which are 1-input
multi-output transactions.
* Each one has a particular `nSequence` with a relative-locktime constraint.
* This spends the previous stage decrementing-`nSequence` transaction output.
* The outputs of this transaction represent the current state inside the
statechain.
The `nSequence` use means there is no time-based lifetime limit.
The decrementing-`nSequence` stages mean that earlier states have higher
`nSequence` limits, and newer states have lower `nSequence` limits.
Chaining multiple such mechanisms allows you to "reset" a stage by making a
single update of the higher stage, which resets all further stages.
So for example, we could have a multi-stage mechanism as below:
***blockchain***
[funding tx] -+
_ _ _ _ _ _ | _ _ _ _ _ _ _
offchain |
+->[kickoff tx]->[[14] stage]->[[14] stage]->[[14]
stage]-> state outputs
The number in the brackets is the relative-locktime `nSequence` constraint in
that stage transaction.
Let us suppose that we agree to decrement `nSequence` by 7 blocks at each
update.
Then the first update will have:
***blockchain***
[funding tx] -+
_ _ _ _ _ _ | _ _ _ _ _ _ _
offchain |
+->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 7]
stage]-> state outputs
The the second update:
***blockchain***
[funding tx] -+
_ _ _ _ _ _ | _ _ _ _ _ _ _
offchain |
+->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 0]
stage]-> state outputs
After this update, for the next update, we would also sign the
second-to-the-last stage, and reset the last stage:
***blockchain***
[funding tx] -+
_ _ _ _ _ _ | _ _ _ _ _ _ _
offchain |
+->[kickoff tx]->[[14] stage]->[[ 7] stage]->[[14]
stage]-> state outputs
And so on.
Effectively it becomes a large counter, with the "least significant digit"
being the last stage.
This multiplies the total number of updates your statechain can have, so for
example the above uses a total unilateral close delay of 42 blocks to allow
creation of 27 updates, whereas if it were a single stage those 42 blocks would
only allow 7 updates.
As the first stage decrements, you can actually add more stages dependent on
it, keeping a total maximum time that a unilateral close will resolve, but
increasing the number of transactions that would need to be published onchain
in a unilateral close.
This allows you to further extend the number of updates, possibly allowing an
indefinite number of updates (at the cost of greatly increased blockchain usage
in the unilateral close, which might not be feasible).
The original Decker-Wattenhofer paper "Duplex Micropayment Channels" has
prettier graphics.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
