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
|
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 48464C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:42:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 37AF1884EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:42:35 +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 NI-7mZMtKnpe
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:42:33 +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 EB4E2884E9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:42:32 +0000 (UTC)
Date: Sat, 28 Mar 2020 02:42:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1585363350;
bh=4cE4G+QmIPJ96qzHCXoO5XbbEAgrbXjVEI162VUKeCw=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=nJr1NVtJktSdoHEqUSnorQI5uQS3mdcPgOsRNnKLKssOGVaqvtsaxdmSgIvFtiuzR
wuDk69wKl0ixYmLwNgIfPocohjLBFbPTJz+f4L/Ur1Ia5xkulfzc+iboW2wFi6y3D+
kzP0pUSkZTMih4IyiEQHytmknWEQd/Qa0L+ByzUE=
To: Bob McElrath <bob@mcelrath.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6SFA-3YOsuEl4D3N5eA5G6q1B6ROWHmNefjCC5cRPpHg6iu9PVdG21PKjV28IMYXY_tOcmrSB60tnQRgm4pcHXB_MxOPaa9zZIbBeo0aHS4=@protonmail.com>
In-Reply-To: <20200327171017.GM28113@mcelrath.org>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<20200327171017.GM28113@mcelrath.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Tom Trevethan <tom@commerceblock.com>
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: Sat, 28 Mar 2020 02:42:35 -0000
Good morning Bob,
> Big picture, it seems to me this idea is workable and very interesting. I=
see
> three likely enhancements that will be necessary or desirable:
> 1. Atomic swap of multiple UTXOs, and binary decomposition of value in lo=
ts
> 2. Key exchange ("addresses") to facilitate a secure comms path from
> sender -> receiver
>
> 3. (Optional) single-use seals to close old state
>
>
> (1) It's unlikely that a party sending a UTXO to another party will have =
a UTXO
> of exactly the right size that's needed, already locked into the statecha=
in. If
> he has to create the UTXO first and then lock it into the statechain, the
> statechain solution is no better than an on-chain send. And once the rece=
iver
> has the UTXO, it's unlikely that he will want to send exactly that same a=
mount
> to another receiver later. This isn't a problem in Lightning where amount=
s can
> be arbitrarily updated. As a consequence, I think Lightning is more valua=
ble for
> small-value payments, and statechains will be more valuable for larger va=
lues.
>
> The natural solution is to decompose your outputs in a binary decompositi=
on,
> having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis, a=
nd so
> on. Then when I want to send, I select the appropriate UTXOs as a binary
> decomposition of the value I want to send, with a "lot size" of 1048576
> satoshis, or the dust limit. The notion of "lots" like this is common in
> traditional markets...many stocks are bought and sold in lots of 100, and=
forex
> is traded in lots of $100,000. Users of a statechain therefore need log(V=
)
> available UTXOs locked into the statechain, where V is their value in BTC=
.
> Having fixed lot sizes like this also makes coinjoin-type uses more viabl=
e. The
> statechain could also assist in dividing a UTXO into two utxos of the nex=
t lot
> size down, so that I have the right UTXOs to hit the value I want to send=
.
My understanding of statechains is that nothing prevents the statechain fro=
m internally having multiple UTXOs divided from a single large onchain UTXO=
.
Indeed, a statechain can act much like a federated blockchain, and the inte=
rface to the statechain could be for its clients to send a Bitcoin transact=
ion to it spending 1 or more of the UTXOs currently instantiated inside the=
statechain.
Then the statechain validates the client Bitcoin transaction, updates its s=
tate and republishes it to its clients, removing the (internal-to-statechai=
n-only) UTXOs spent, and inserting the new UTXOs of the incoming transactio=
n.
For example, suppose I have a 1BTC onchain UTXO that I use to create a new =
statechain:
[funding tx]->1BTC(SE)-+ (onchain)
_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
(statechain) |
+->[update mechanism]->1BTC(ZmnSCPxj)
Then I send to the statechain a transaction spending my 1BTC-on-statechain,=
giving you 0.11568768 BTC:
[funding tx]->1BTC(SE)-+ (onchain)
_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
(statechain) |
+->[update mechanism]->1BTC(ZmnSCPxj)->[tx]-+->0=
.11568768BTC(bsm117532)
+->0=
.88431232BTC(ZmnSCPxj)
The statechain verifies that the tx I sent is valid, then outputs the next =
state as below:
[funding tx]->1BTC(SE)-+ (onchain)
_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
(statechain) |
+->[update mechanism]-+->0.11568768BTC(bsm117532=
)
+->0.88431232BTC(ZmnSCPxj)
In short, statechains can be implemented as a sort of super-transaction-cut=
through system.
This prevents the onchain UTXO from having a single logical owner, of cours=
e, so onchain it is the statechain entity that owns the entire fund, but if=
you are trusting the statechain entity anyway, the update mechanism is suf=
ficient to ensure that nobody (other than the trusted statechain) can preve=
nt the publication of the latest accepted state.
This is probably significantly more efficient than splitting up the 1BTC va=
lue to multiple lots.
I think this framework will work for all offchain mechanisms (CoinSwap, Lig=
htning, statechains), by the way --- you can always view the offchain updat=
e mechanism as logically implementing a "new" cryptocurrency system that ma=
intains UTXO sets and allows removal and insertion of UTXO sets according t=
o the same rules (sans relative-locktime) as the hosting cryptocurrency sys=
tem (i.e. the blockchain).
The same realization is what underlies channel factories as well --- the ho=
sting cryptocurrency system need not be a blockchain, it can be just anothe=
r cryptocurrency system (of which a blockchain is just one kind).
My understanding is that the original description, which describes transfer=
ring the entire value inside the statechain to a new owner, was only for ex=
position and that it was an exercise for the reader to consider how a state=
chain can internally split the total value among multiple UTXOs.
Regards,
ZmnSCPxj
|
