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
