Date: Thu, 26 Mar 2020 01:20:47 +0000
To: Tom Trevethan <tom@commerceblock.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <C9VNjBcLdS_tYiO3oZ-pwXjGV1ALjVxbLuS44u0Iscv0N4li1GTEjg0h63e9NBlTaG8iePiyhXhWlVkk1DzrRlPFvflF5sTIBipKu4L-oN0=@protonmail.com>
In-Reply-To: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Statechain implementations
Precedence: list

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 ena=
ble the change of ownership (novation) of an individual position in an acti=
ve discreet log contract (DLC) without an on-chain transaction, and without=
 needing the cooperation of the counterparty. The protocol as outlined by R=
uben requires features not currently available in Bitcoin (like SIGHASH_NOI=
NPUT), 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 curr=
ent owner to claim the UTXO in case the statechain entity disappears) we pr=
opose using a decrementing nLocktime for backup transactions as the output =
changes hands. Here, the first owner gets a backup transaction with an nLoc=
ktime at some future height (h0), then the next owner gets a backup transac=
tion 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 d=
ecrementing-`nSequence`, which while it has a limit on the number of update=
s, does not have a limit on the time that a UTXO is locked in this mechanis=
m.

You can even use the Decker-Wattenhofer trick of having a chain of decremen=
ting-`nSequence` mechanisms to effectively multiply the number of updates t=
hat the overall mechanism can have.

The drawback is that in a unilateral close condition, the time to completel=
y resolve the unilateral close is very large.

For a quick reference for this technique:

* The funding transaction is anchored onchain, but all succeeding transacti=
ons are offchain.
  * This funding transaction has a particular funding transaction output.
* There is a kickoff transaction, which is a 1-input 1-output transaction w=
ithout 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 fundi=
ng 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-i=
nput 1-output transactions.
  * Each one has a particular `nSequence` with a relative-locktime constrai=
nt.
  * This spends the kickoff transaction output.
  * The signer set of the output is the same as the signer set of the fundi=
ng transaction output.
* There is one or more decrementing-`nSequence` transactions, which are 1-i=
nput 1-output transactions.
  * Each one has a particular `nSequence` with a relative-locktime constrai=
nt.
  * This spends the previous stage decrementing-`nSequence` transaction out=
put.
  * The signer set of the output is the same as the signer set of the fundi=
ng transaction output.
* Repeat the above stage a few times.
* There is one or more decrementing-`nSequence` transactions, which are 1-i=
nput multi-output transactions.
  * Each one has a particular `nSequence` with a relative-locktime constrai=
nt.
  * This spends the previous stage decrementing-`nSequence` transaction out=
put.
  * 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 `n=
Sequence` 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] sta=
ge]-> 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 u=
pdate.

Then the first update will have:

    ***blockchain***
       [funding tx] -+
         _ _ _ _ _ _ | _ _ _ _ _ _ _
     offchain        |
                     +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 7] sta=
ge]-> state outputs

The the second update:

    ***blockchain***
       [funding tx] -+
         _ _ _ _ _ _ | _ _ _ _ _ _ _
     offchain        |
                     +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 0] sta=
ge]-> state outputs

After this update, for the next update, we would also sign the second-to-th=
e-last stage, and reset the last stage:

    ***blockchain***
       [funding tx] -+
         _ _ _ _ _ _ | _ _ _ _ _ _ _
     offchain        |
                     +->[kickoff tx]->[[14] stage]->[[ 7] stage]->[[14] sta=
ge]-> 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 fo=
r example the above uses a total unilateral close delay of 42 blocks to all=
ow creation of 27 updates, whereas if it were a single stage those 42 block=
s would only allow 7 updates.

As the first stage decrements, you can actually add more stages dependent o=
n it, keeping a total maximum time that a unilateral close will resolve, bu=
t increasing the number of transactions that would need to be published onc=
hain 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 blockchai=
n usage in the unilateral close, which might not be feasible).

The original Decker-Wattenhofer paper "Duplex Micropayment Channels" has pr=
ettier graphics.

Regards,
ZmnSCPxj