summaryrefslogtreecommitdiff
path: root/52/f8682133594fab72172d5cb223743f199830c9
blob: 6ae19676ea78efdd9cc9180a96e95c612101cc33 (plain)
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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
Return-Path: <rsomsen@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B8CFBC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 28 Mar 2020 17:43:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id A22D486A56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 28 Mar 2020 17:43:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lB2H8lTdKM69
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 28 Mar 2020 17:43:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com
 [209.85.216.66])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 491A486A37
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 28 Mar 2020 17:43:12 +0000 (UTC)
Received: by mail-pj1-f66.google.com with SMTP id v13so5388921pjb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 28 Mar 2020 10:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=4pBHQw2gQNmoD/f4XALcWroOGjIa1dpi+A2tiCooIZs=;
 b=PqUHQfdsFrmNksoZ8d3vTFOVr5uld9jiOGIxEKv4NKenF2fV0MaROgvj66Tdc1Akuw
 1KL73nOLBQ0pARchCWIuwx9GqdCD6wPdcPOWkNZgLCfGkhu86hGjf9T294UtDmjSDOTM
 nWyOmhNCxQw0iNNN9mk8v/Jtjk4VvErk3iABk0RyC97EipqOADK1K4mCaqqSJ2zFCbpd
 LSDF10V83YzzNC+i5SlU2erdXU4eAi8gL4SFkKTHN7rmqZPsEWcU3wYg9odQ3CbMVbBF
 iPfe/FJ/8xdIELODRKxYG8hrEltZJ2BdpR2EP+pRzRLrshHijW7sDd7R642RMzsZXwEK
 ktPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=4pBHQw2gQNmoD/f4XALcWroOGjIa1dpi+A2tiCooIZs=;
 b=GS9WGwPASzRaV+hPmNQh4TDlCcvNs4h1zR3Cql/Qg4oMX+qvvP2bvpvgLYknTzUUZE
 pzOjrJinK+4exKX9ynGADL7oNth0cRrKNAl5Kxmjl5DVXmUE5m3XNcQQD94/yUz+Rjqp
 Rjm0+QxXgTLh8O5ZgzbDam5JkKNPk5nVWgPmzDi5nmG2jeQVC/zUzyDfQpfg98VS7RkJ
 fhtXNVFOKwrAqK4UXZ1F6s6JrwQuzQej4Ak7Ubk+kky9+gAFBrFbRhqvP7ptvKUGA76S
 SL7lIrhiV1d+JdjUrgzfOdeP9yBFILXDDOL7m+uE22nIvV8so7kU5lWOU2F+xE2whGst
 fhpg==
X-Gm-Message-State: ANhLgQ06Bw2J4hO7sgrGV/ZSUc5UZc43hekG5BqFJlz3tp4SKp56lSp1
 J1JVT51Jzha6vwn7BOTa7v+beaZ0Zrnre9d3nhw=
X-Google-Smtp-Source: ADFU+vsbpIoj4M0FfRSYJnJ5yE5XAerpE/wdy4+HBq8r01KdiReko/8KwWICYe5UZl+IWw+OvEJoa77fcDeqh2xUpO8=
X-Received: by 2002:a17:902:9a98:: with SMTP id
 w24mr4849944plp.40.1585417391846; 
 Sat, 28 Mar 2020 10:43:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200327171017.GM28113@mcelrath.org>
 <6SFA-3YOsuEl4D3N5eA5G6q1B6ROWHmNefjCC5cRPpHg6iu9PVdG21PKjV28IMYXY_tOcmrSB60tnQRgm4pcHXB_MxOPaa9zZIbBeo0aHS4=@protonmail.com>
 <CAPv7TjYs8j=rKWPVzfFbtznjFQfpKTBGr4AnCXrDcU64Cb8S9Q@mail.gmail.com>
In-Reply-To: <CAPv7TjYs8j=rKWPVzfFbtznjFQfpKTBGr4AnCXrDcU64Cb8S9Q@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sat, 28 Mar 2020 18:42:58 +0100
Message-ID: <CAPv7Tjb5a5RbXH802m8qHoUKw-5rZV6nOw01z9+hx4yTJYV3Cw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000076385305a1edc01c"
X-Mailman-Approved-At: Sat, 28 Mar 2020 17:44:48 +0000
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 17:43:13 -0000

--00000000000076385305a1edc01c
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

the current owner can ask the statechain entity to sign an alternative to
> the first stage, with 0 relative locktime


Unless I am misunderstanding something, this seems to run into the problem
that the original first stage transaction is already out there (and its
relative timelock started ticking). There is no mechanism ensuring that the
new tx will have precedence. And even if it did work, I doubt it's cleaner
than doing a cooperative peg-out that simultaneously happens to peg back
in, creating a brand new statechain UTXO with no history.

Cheers,
Ruben

On Sat, Mar 28, 2020 at 6:38 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi Bob,
>
> Looks like we're largely thinking along the same lines.
>
> It's unlikely that a party sending a UTXO to another party will have a
>> UTXO of exactly the right size that's needed
>
>
> My original proposal uses adaptor signatures to ensure swapping UTXOs is
> atomic. All parties choose a secret, then they all make adaptor signatures,
> then they reveal their secret to the statechain entity. The SE then
> publishes the signatures, causing everyone to learn the secret. And if the
> SE doesn't publish, it simply means the transfer didn't occur.
>
> But taking a step back and thinking about an MVP, it may be easier to make
> it more like a fully audited transparent blockchain where multiple users
> create a combined transaction of all the UTXOs they want to swap, which is
> published together with all the corresponding Bitcoin transactions. Then
> adaptor signatures aren't needed.
>
> The downside of that method is that you lose the ability to only validate
> the history of the coins you hold (scalability win). For this to be
> possible, you need to keep the history of every individual UTXO completely
> separate. I still think that is where we eventually want to end up (as well
> as having blind signatures), but it adds a lot of complexity (adaptor
> signatures, sparse merkle trees with non-inclusion proofs...).
>
> The natural solution is to decompose your outputs in a binary decomposition
>
>
> I fully agree, but on top of that I think we also need Lightning,
> because....
>
> This same mechanism can also be used to pay the SE for its service through
>> a different UTXO than the one being transferred.
>
>
> My conclusion was that opening a Lightning channel on top of a statechain
> makes more sense for this (as ZmnSCPxj explained in his reply to you). If
> we expect BTC fees to go up, we can't expect the statechain to hold UTXOs
> that are small enough to be used to pay for statechain fees.
>
> More on this in my Breaking Bitcoin 2019 talk (timestamped link):
> https://youtu.be/09HcYRjDkMA?t=850
>
> a logical enhancement would be to use some kind of single-use seal
>
>
> Any kind of system where users transfer ownership through signatures will
> resemble single-use seals, so I'd say that's inevitable! :)
>
> Cheers,
> Ruben
>
>
> On Sat, Mar 28, 2020 at 3:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>> lots
>> > 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
>> statechain. 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
>> receiver
>> > has the UTXO, it's unlikely that he will want to send exactly that same
>> amount
>> > to another receiver later. This isn't a problem in Lightning where
>> amounts can
>> > be arbitrarily updated. As a consequence, I think Lightning is more
>> valuable for
>> > small-value payments, and statechains will be more valuable for larger
>> values.
>> >
>> > The natural solution is to decompose your outputs in a binary
>> decomposition,
>> > having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis,
>> and 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
>> viable. The
>> > statechain could also assist in dividing a UTXO into two utxos of the
>> next 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
>> from internally having multiple UTXOs divided from a single large onchain
>> UTXO.
>>
>> Indeed, a statechain can act much like a federated blockchain, and the
>> interface to the statechain could be for its clients to send a Bitcoin
>> transaction to it spending 1 or more of the UTXOs currently instantiated
>> inside the statechain.
>> Then the statechain validates the client Bitcoin transaction, updates its
>> state and republishes it to its clients, removing the
>> (internal-to-statechain-only) UTXOs spent, and inserting the new UTXOs of
>> the incoming transaction.
>>
>> 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-cutthrough system.
>>
>> This prevents the onchain UTXO from having a single logical owner, of
>> course, 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 sufficient to ensure that nobody (other than the trusted statechain) can
>> prevent the publication of the latest accepted state.
>>
>> This is probably significantly more efficient than splitting up the 1BTC
>> value to multiple lots.
>>
>> I think this framework will work for all offchain mechanisms (CoinSwap,
>> Lightning, statechains), by the way --- you can always view the offchain
>> update mechanism as logically implementing a "new" cryptocurrency system
>> that maintains UTXO sets and allows removal and insertion of UTXO sets
>> according to the same rules (sans relative-locktime) as the hosting
>> cryptocurrency system (i.e. the blockchain).
>> The same realization is what underlies channel factories as well --- the
>> hosting cryptocurrency system need not be a blockchain, it can be just
>> another cryptocurrency system (of which a blockchain is just one kind).
>>
>> My understanding is that the original description, which describes
>> transferring the entire value inside the statechain to a new owner, was
>> only for exposition and that it was an exercise for the reader to consider
>> how a statechain can internally split the total value among multiple UTXOs.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--00000000000076385305a1edc01c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">the current owner can ask the statechain enti=
ty to sign an alternative to the first stage, with 0 relative locktime</blo=
ckquote><div><br></div><div>Unless I am misunderstanding something, this se=
ems to run into the problem that the original first stage transaction is al=
ready out there (and its relative timelock started ticking). There is no me=
chanism ensuring that the new tx will have precedence. And even if it did w=
ork, I doubt it&#39;s cleaner than doing a cooperative peg-out that simulta=
neously happens to peg back in, creating a brand new statechain UTXO with n=
o history.</div><div><br></div><div>Cheers,</div><div>Ruben</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Ma=
r 28, 2020 at 6:38 PM Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.com"=
>rsomsen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>Hi Bob,</div><div><br></div><div>Lo=
oks like we&#39;re largely thinking along the same lines.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">It&#39;s unlikely that=
 a party sending a UTXO to another party will have a UTXO of exactly the ri=
ght size that&#39;s needed</blockquote><div><br></div><div>My original prop=
osal uses adaptor signatures to ensure=C2=A0swapping UTXOs is atomic. All p=
arties choose a secret, then they all make adaptor signatures, then they re=
veal their secret to the statechain entity. The SE then publishes the signa=
tures, causing everyone to learn the secret. And if the SE doesn&#39;t publ=
ish, it simply means the transfer didn&#39;t occur.</div><div><br></div><di=
v>But taking a step back and thinking about an MVP, it may be easier to mak=
e it more like a fully audited transparent blockchain where multiple users =
create a combined transaction of all the UTXOs they want to swap, which is =
published together with all the corresponding Bitcoin transactions. Then ad=
aptor signatures aren&#39;t needed.</div><div><br></div><div>The downside o=
f that method is that you lose the ability to only validate the history of =
the coins you hold (scalability win). For this to be possible, you need to =
keep the history of every individual UTXO completely separate. I still thin=
k that is where we eventually want to end up (as well as having blind signa=
tures), but it adds a lot of complexity (adaptor signatures, sparse merkle =
trees with non-inclusion proofs...).</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">The natural solution is to decompose your =
outputs in a binary decomposition</blockquote><div><br></div><div>I fully a=
gree, but on top of that I think we also need Lightning, because....</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This same m=
echanism can also be used to pay the SE for its service through a different=
 UTXO than the one being transferred.=C2=A0=C2=A0</blockquote><div><br></di=
v><div>My conclusion was that opening a Lightning channel on top of a state=
chain makes more sense for this (as ZmnSCPxj explained in his reply to you)=
. If we expect BTC fees to go up, we can&#39;t expect the statechain to hol=
d UTXOs that are small enough to be used to pay for statechain fees.</div><=
div><br></div><div>More on this in my Breaking Bitcoin 2019 talk (timestamp=
ed link):=C2=A0<a href=3D"https://youtu.be/09HcYRjDkMA?t=3D850" target=3D"_=
blank">https://youtu.be/09HcYRjDkMA?t=3D850</a></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">a logical enhancement would be t=
o use some kind of single-use seal</blockquote><div><br></div><div>Any kind=
 of system where users transfer ownership through signatures will resemble =
single-use seals, so I&#39;d say that&#39;s inevitable! :)</div><div><br></=
div><div>Cheers,</div><div>Ruben</div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 28, 2020=
 at 3:42 AM ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Good morning Bob,<br>
<br>
&gt; Big picture, it seems to me this idea is workable and very interesting=
. I see<br>
&gt; three likely enhancements that will be necessary or desirable:<br>
&gt; 1. Atomic swap of multiple UTXOs, and binary decomposition of value in=
 lots<br>
&gt; 2. Key exchange (&quot;addresses&quot;) to facilitate a secure comms p=
ath from<br>
&gt; sender -&gt; receiver<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A03. (Optional) single-use seals to close old state<b=
r>
&gt;<br>
&gt;<br>
&gt; (1) It&#39;s unlikely that a party sending a UTXO to another party wil=
l have a UTXO<br>
&gt; of exactly the right size that&#39;s needed, already locked into the s=
tatechain. If<br>
&gt; he has to create the UTXO first and then lock it into the statechain, =
the<br>
&gt; statechain solution is no better than an on-chain send. And once the r=
eceiver<br>
&gt; has the UTXO, it&#39;s unlikely that he will want to send exactly that=
 same amount<br>
&gt; to another receiver later. This isn&#39;t a problem in Lightning where=
 amounts can<br>
&gt; be arbitrarily updated. As a consequence, I think Lightning is more va=
luable for<br>
&gt; small-value payments, and statechains will be more valuable for larger=
 values.<br>
&gt;<br>
&gt; The natural solution is to decompose your outputs in a binary decompos=
ition,<br>
&gt; having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis=
, and so<br>
&gt; on. Then when I want to send, I select the appropriate UTXOs as a bina=
ry<br>
&gt; decomposition of the value I want to send, with a &quot;lot size&quot;=
 of 1048576<br>
&gt; satoshis, or the dust limit. The notion of &quot;lots&quot; like this =
is common in<br>
&gt; traditional markets...many stocks are bought and sold in lots of 100, =
and forex<br>
&gt; is traded in lots of $100,000. Users of a statechain therefore need lo=
g(V)<br>
&gt; available UTXOs locked into the statechain, where V is their value in =
BTC.<br>
&gt; Having fixed lot sizes like this also makes coinjoin-type uses more vi=
able. The<br>
&gt; statechain could also assist in dividing a UTXO into two utxos of the =
next lot<br>
&gt; size down, so that I have the right UTXOs to hit the value I want to s=
end.<br>
<br>
My understanding of statechains is that nothing prevents the statechain fro=
m internally having multiple UTXOs divided from a single large onchain UTXO=
.<br>
<br>
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.<br>
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.<br>
<br>
For example, suppose I have a 1BTC onchain UTXO that I use to create a new =
statechain:<br>
<br>
=C2=A0 =C2=A0 [funding tx]-&gt;1BTC(SE)-+=C2=A0 (onchain)<br>
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0+-&gt;[update mechanism]-&gt;1BTC(ZmnSCPxj)<br>
<br>
Then I send to the statechain a transaction spending my 1BTC-on-statechain,=
 giving you 0.11568768 BTC:<br>
<br>
=C2=A0 =C2=A0 [funding tx]-&gt;1BTC(SE)-+=C2=A0 (onchain)<br>
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0+-&gt;[update mechanism]-&gt;1BTC(ZmnSCPxj)-&gt;[tx=
]-+-&gt;0.11568768BTC(bsm117532)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-&gt;0.88431232BTC(ZmnSCPxj)<br>
<br>
The statechain verifies that the tx I sent is valid, then outputs the next =
state as below:<br>
<br>
=C2=A0 =C2=A0 [funding tx]-&gt;1BTC(SE)-+=C2=A0 (onchain)<br>
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0+-&gt;[update mechanism]-+-&gt;0.11568768BTC(bsm117=
532)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0+-&gt;0.88431232BTC(ZmnSCPxj)<br>
<br>
In short, statechains can be implemented as a sort of super-transaction-cut=
through system.<br>
<br>
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.<br>
<br>
This is probably significantly more efficient than splitting up the 1BTC va=
lue to multiple lots.<br>
<br>
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 &quot;new&quot; cryptocurrency syst=
em that maintains UTXO sets and allows removal and insertion of UTXO sets a=
ccording to the same rules (sans relative-locktime) as the hosting cryptocu=
rrency system (i.e. the blockchain).<br>
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).<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--00000000000076385305a1edc01c--