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 73A8AC0177 for ; Thu, 26 Mar 2020 01:20:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 6C14B87D6D for ; Thu, 26 Mar 2020 01:20:56 +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 fq6dvTvz7vYU for ; Thu, 26 Mar 2020 01:20:54 +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 E81B7876FF for ; Thu, 26 Mar 2020 01:20:53 +0000 (UTC) Date: Thu, 26 Mar 2020 01:20:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1585185650; bh=qr0NyDz+h8tCfrpzzs4AxyoQSYL0jIyZsfJvPLNMx5s=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=yFuq/rsm/jA2CiaxboSohhQRq9GdsKY7EkRyT3T3Qq6hqxh+2gl4ibf8ZHfhRgj+A AIrV52xUZ72ssckDV6iXLBylCDZ4eIivN5zdCzihQqa3wPAp7HHou7LFjqojcWM53P VgZ1END/8zPyT1cRITKfoW192a2UO3ULe1QTGfgo= To: Tom Trevethan , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 26 Mar 2020 01:20:56 -0000 Good morning Tom, > > We are starting to work on an implementation of the statechains concept (= https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin= -transfer-1ae4845a4a39), with particular interest in using the protocol ena= ble the change of ownership (novation) of an individual position in an acti= ve discreet log contract (DLC) without an on-chain transaction, and without= needing the cooperation of the counterparty. The protocol as outlined by R= uben requires features not currently available in Bitcoin (like SIGHASH_NOI= NPUT), and it is uncertain when (or even if) this will be added. So we are = looking at variants that would work with current Bitcoin functionality, and= it would be good to get some feedback on them. > > There are two main modifications we are looking at: > 1. Instead of an eltoo-based backup/refund transaction (enabling the curr= ent owner to claim the UTXO in case the statechain entity disappears) we pr= opose using a decrementing nLocktime for backup transactions as the output = changes hands. Here, the first owner gets a backup transaction with an nLoc= ktime at some future height (h0), then the next owner gets a backup transac= tion with nLocktime (h0-c) where c is a confirmation window. This approach = has the downside of limiting the lifetime of the UTXO, but it also doesn't = require the current owner to be always online. I believe I suggested this to Ruben Somsen as well in the past, but you can= replace the state update mechanism with, for example, Decker-Wattenhofer d= ecrementing-`nSequence`, which while it has a limit on the number of update= s, does not have a limit on the time that a UTXO is locked in this mechanis= m. You can even use the Decker-Wattenhofer trick of having a chain of decremen= ting-`nSequence` mechanisms to effectively multiply the number of updates t= hat the overall mechanism can have. The drawback is that in a unilateral close condition, the time to completel= y resolve the unilateral close is very large. For a quick reference for this technique: * The funding transaction is anchored onchain, but all succeeding transacti= ons are offchain. * This funding transaction has a particular funding transaction output. * There is a kickoff transaction, which is a 1-input 1-output transaction w= ithout any `nLockTime` or `nSequence` limits. * This spends the funding tx out. * The signer set of the output is the same as the signer set of the fundi= ng transaction output. * You could tweak keys or script to give a modicum of privacy. * There is one or more decrementing-`nSequence` transactions, which are 1-i= nput 1-output transactions. * Each one has a particular `nSequence` with a relative-locktime constrai= nt. * This spends the kickoff transaction output. * The signer set of the output is the same as the signer set of the fundi= ng transaction output. * There is one or more decrementing-`nSequence` transactions, which are 1-i= nput 1-output transactions. * Each one has a particular `nSequence` with a relative-locktime constrai= nt. * This spends the previous stage decrementing-`nSequence` transaction out= put. * The signer set of the output is the same as the signer set of the fundi= ng transaction output. * Repeat the above stage a few times. * There is one or more decrementing-`nSequence` transactions, which are 1-i= nput multi-output transactions. * Each one has a particular `nSequence` with a relative-locktime constrai= nt. * This spends the previous stage decrementing-`nSequence` transaction out= put. * The outputs of this transaction represent the current state inside the = statechain. The `nSequence` use means there is no time-based lifetime limit. The decrementing-`nSequence` stages mean that earlier states have higher `n= Sequence` limits, and newer states have lower `nSequence` limits. Chaining multiple such mechanisms allows you to "reset" a stage by making a= single update of the higher stage, which resets all further stages. So for example, we could have a multi-stage mechanism as below: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain | +->[kickoff tx]->[[14] stage]->[[14] stage]->[[14] sta= ge]-> state outputs The number in the brackets is the relative-locktime `nSequence` constraint = in that stage transaction. Let us suppose that we agree to decrement `nSequence` by 7 blocks at each u= pdate. Then the first update will have: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain | +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 7] sta= ge]-> state outputs The the second update: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain | +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 0] sta= ge]-> state outputs After this update, for the next update, we would also sign the second-to-th= e-last stage, and reset the last stage: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain | +->[kickoff tx]->[[14] stage]->[[ 7] stage]->[[14] sta= ge]-> state outputs And so on. Effectively it becomes a large counter, with the "least significant digit" = being the last stage. This multiplies the total number of updates your statechain can have, so fo= r example the above uses a total unilateral close delay of 42 blocks to all= ow creation of 27 updates, whereas if it were a single stage those 42 block= s would only allow 7 updates. As the first stage decrements, you can actually add more stages dependent o= n it, keeping a total maximum time that a unilateral close will resolve, bu= t increasing the number of transactions that would need to be published onc= hain in a unilateral close. This allows you to further extend the number of updates, possibly allowing = an indefinite number of updates (at the cost of greatly increased blockchai= n usage in the unilateral close, which might not be feasible). The original Decker-Wattenhofer paper "Duplex Micropayment Channels" has pr= ettier graphics. Regards, ZmnSCPxj