From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Tom Trevethan <tom@commerceblock•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Statechain implementations
Date: Thu, 26 Mar 2020 01:20:47 +0000 [thread overview]
Message-ID: <C9VNjBcLdS_tYiO3oZ-pwXjGV1ALjVxbLuS44u0Iscv0N4li1GTEjg0h63e9NBlTaG8iePiyhXhWlVkk1DzrRlPFvflF5sTIBipKu4L-oN0=@protonmail.com> (raw)
In-Reply-To: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
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
next prev parent reply other threads:[~2020-03-26 1:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 13:52 Tom Trevethan
2020-03-26 1:20 ` ZmnSCPxj [this message]
2020-03-26 3:55 ` Albert
2020-03-26 12:36 ` Ruben Somsen
2020-03-26 17:12 ` Christian Decker
2020-03-26 17:17 ` Greg Sanders
2020-03-26 18:53 ` Ruben Somsen
2020-03-27 1:46 ` ZmnSCPxj
2020-03-27 15:12 ` Ruben Somsen
2020-03-28 2:20 ` ZmnSCPxj
2020-03-26 14:52 ` Bob McElrath
2020-03-27 17:10 ` Bob McElrath
2020-03-28 2:42 ` ZmnSCPxj
2020-03-28 17:38 ` Ruben Somsen
2020-03-28 17:42 ` Ruben Somsen
2020-03-30 1:25 ` ZmnSCPxj
2020-03-31 10:35 ` David A. Harding
2020-03-31 11:41 ` Tom Trevethan
2020-04-02 22:56 ` Tom Trevethan
2020-04-03 16:37 ` Nadav Kohen
2020-04-04 12:07 ` ZmnSCPxj
2020-04-05 14:17 ` Bob McElrath
2020-04-05 18:24 ` ZmnSCPxj
2020-04-05 21:25 ` Tom Trevethan
2020-05-07 14:54 ` Tom Trevethan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='C9VNjBcLdS_tYiO3oZ-pwXjGV1ALjVxbLuS44u0Iscv0N4li1GTEjg0h63e9NBlTaG8iePiyhXhWlVkk1DzrRlPFvflF5sTIBipKu4L-oN0=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tom@commerceblock$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox