From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 42BA2C0177 for ; Sat, 28 Mar 2020 17:39:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 3A56D866AD for ; Sat, 28 Mar 2020 17:39:03 +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 x--yk0e37Bs5 for ; Sat, 28 Mar 2020 17:39:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D3B9E8654E for ; Sat, 28 Mar 2020 17:39:01 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id c21so5575582pfo.5 for ; Sat, 28 Mar 2020 10:39:01 -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=LAANrsf+MAu++0HwP81vm53nvCEJJ3qFaXQfMTq7jMo=; b=jmQ7bANLgKJUwJ1z5dQV5ZHobZAtqZeNKYrA2E5eRWUrJGc/06Euk3nDemKC8YuVIM CnryNcZ6knvWRAW0RRryAxKDwVgItX4omUFUTtXlBymwYJP5AetMejMpyvbNPWFT/uMu S76VXgLZOcEfSi+D4zt+M2G4LsgliRCL0+tSTKDeX6+1dYaqdFq2tHq3GfrWF2YCqkXh 1aQzwr3LXn62pDOgcIzilFkEi6jGu26RC3FtfzrWp9PgT8Uv3MTK/v6YLTRX0Bmsm3+k +BVPn2+Ndq+Ky7bdCdpsoAF6DyGnJfMZgizEpRE0uEmW6JhYpQxhIJQgyeTZtTVHzxNK MG1w== 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=LAANrsf+MAu++0HwP81vm53nvCEJJ3qFaXQfMTq7jMo=; b=C7BSjx0z47VXGZ13qrhxcRUj+R5Wf/mg3U08DliTFmuVacKrAEyfgswh5mrhXtUbEU jeAqn+ZKJVOLlCyrBvim3kfQNbnX02sV8baBxCwrD0wCFtAbGUC8Cuvupqgf2l+msM/N BqDTJpf3IRWKI2tPqx8v4Me2LSPdDknQ5JISJ1IRjyxFenkUu3zO9uR/fftpJP7AKLns 7s0Yi2yv0iQ5LXlptRngWgIYqm5p+kcDzCV1/2N9y95c9eoftj0VNjAtjGW0Ao1MtRQL 5lCCi+i+7gXK6jKCT6WCZF6J/LliO+YXjyc8OSzuh1ZU0g3s1A5U8YN8ue3O2P/rpN6C rjhA== X-Gm-Message-State: ANhLgQ33WqEac7yZpQWCfzOACwacQE2uqncQJ+2lUEWYD1ABrATtnhAA EybOfeGzFuzvfp+pUjko7u6Nb7NGm8wBQPbpRsE= X-Google-Smtp-Source: ADFU+vurDn/cO5P6mrHGaJmT27nfmQNP/m1uhUMZa5dBy/q8HfHZ3o9exYZmV7ggetRn177WRbBlxEqZu6SRF4Jo30w= X-Received: by 2002:aa7:96a6:: with SMTP id g6mr4868035pfk.88.1585417141387; Sat, 28 Mar 2020 10:39:01 -0700 (PDT) MIME-Version: 1.0 References: <20200327171017.GM28113@mcelrath.org> <6SFA-3YOsuEl4D3N5eA5G6q1B6ROWHmNefjCC5cRPpHg6iu9PVdG21PKjV28IMYXY_tOcmrSB60tnQRgm4pcHXB_MxOPaa9zZIbBeo0aHS4=@protonmail.com> In-Reply-To: <6SFA-3YOsuEl4D3N5eA5G6q1B6ROWHmNefjCC5cRPpHg6iu9PVdG21PKjV28IMYXY_tOcmrSB60tnQRgm4pcHXB_MxOPaa9zZIbBeo0aHS4=@protonmail.com> From: Ruben Somsen Date: Sat, 28 Mar 2020 18:38:47 +0100 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000088861505a1edb188" X-Mailman-Approved-At: Sat, 28 Mar 2020 17:44:48 +0000 Cc: Tom Trevethan 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 17:39:03 -0000 --00000000000088861505a1edb188 Content-Type: text/plain; charset="UTF-8" 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 > --00000000000088861505a1edb188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=C2=A0swapping UTXOs is atomic. All parties choose a se= cret, then they all make adaptor signatures, then they reveal their secret = to the statechain entity. The SE then publishes the signatures, causing eve= ryone to learn the secret. And if the SE doesn't publish, it simply mea= ns the transfer didn't occur.

But taking a ste= p back and thinking about an MVP, it may be easier to make it more like a f= ully 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 a= ren't needed.

The downside of that method is t= hat 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 o= f 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 add= s a lot of complexity (adaptor signatures, sparse merkle trees with non-inc= lusion 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 b= e used to pay the SE for its service through a different UTXO than the one = being transferred.=C2=A0=C2=A0

My conclusio= n was that opening a Lightning channel on top of a statechain makes more se= nse 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 sm= all enough to be used to pay for statechain fees.

= More on this in my Breaking Bitcoin 2019 talk (timestamped link):=C2=A0https://youtu.be/09HcYRjDkMA?t= =3D850

a logical enhancement would be to use some kind of single-use seal

Any kind of system where users transfer owner= ship 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 &l= t;bitcoin-dev@list= s.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 p= ath from
> sender -> receiver
>
>=C2=A0 =C2=A0 =C2=A03. (Optional) single-use seals to close old state >
>
> (1) It's unlikely that a party sending a UTXO to another party wil= l have a UTXO
> of exactly the right size that's needed, already locked into the s= tatechain. 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 r= eceiver
> 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 va= luable for
> small-value payments, and statechains will be more valuable for larger= values.
>
> The natural solution is to decompose your outputs in a binary decompos= ition,
> 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 bina= ry
> 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 lo= g(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 vi= able. 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 s= end.

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:

=C2=A0 =C2=A0 [funding tx]->1BTC(SE)-+=C2=A0 (onchain)
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |
=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+->[update mechanism]->1BTC(ZmnSCPxj)

Then I send to the statechain a transaction spending my 1BTC-on-statechain,= giving you 0.11568768 BTC:

=C2=A0 =C2=A0 [funding tx]->1BTC(SE)-+=C2=A0 (onchain)
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |
=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+->[update mechanism]->1BTC(ZmnSCPxj)->[tx= ]-+->0.11568768BTC(bsm117532)
=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+->0.88431232BTC(ZmnSCPxj)

The statechain verifies that the tx I sent is valid, then outputs the next = state as below:

=C2=A0 =C2=A0 [funding tx]->1BTC(SE)-+=C2=A0 (onchain)
=C2=A0 =C2=A0 _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (statechain) |
=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+->[update mechanism]-+->0.11568768BTC(bsm117= 532)
=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+->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 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).
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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000088861505a1edb188--