1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 73A8AC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:20:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 6C14B87D6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:20:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fq6dvTvz7vYU
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:20:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by whitealder.osuosl.org (Postfix) with ESMTPS id E81B7876FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:20:53 +0000 (UTC)
Date: Thu, 26 Mar 2020 01:20:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1585185650;
bh=qr0NyDz+h8tCfrpzzs4AxyoQSYL0jIyZsfJvPLNMx5s=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=yFuq/rsm/jA2CiaxboSohhQRq9GdsKY7EkRyT3T3Qq6hqxh+2gl4ibf8ZHfhRgj+A
AIrV52xUZ72ssckDV6iXLBylCDZ4eIivN5zdCzihQqa3wPAp7HHou7LFjqojcWM53P
VgZ1END/8zPyT1cRITKfoW192a2UO3ULe1QTGfgo=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 01:20:56 -0000
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
|
