Date: Sat, 28 Mar 2020 02:42:27 +0000
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
Precedence: list

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