From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 48464C0177 for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <6SFA-3YOsuEl4D3N5eA5G6q1B6ROWHmNefjCC5cRPpHg6iu9PVdG21PKjV28IMYXY_tOcmrSB60tnQRgm4pcHXB_MxOPaa9zZIbBeo0aHS4=@protonmail.com> In-Reply-To: <20200327171017.GM28113@mcelrath.org> References: <20200327171017.GM28113@mcelrath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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