From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0E96223E0 for ; Fri, 6 Sep 2019 14:32:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03A5A89C for ; Fri, 6 Sep 2019 14:32:47 +0000 (UTC) Date: Fri, 06 Sep 2019 14:32:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1567780365; bh=zCpvj+1j0+y110OUR9o5CZiaSTg42a5lnpGEHR0c5n0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=I8iVICoIgG3bEDyUw7acqfKrw+f3RnS6Y1g+XAFjZB6AWc9hkVafybjbJwvRXwHsO 5Hx61u5Zft0U9dXy+iS7PSascku5znhTzwBbEe6nAvAv8nFHZ7y6Gr47fBeucQWeTK oLqmIP59cvAST2N0GrHc+gWKsKA6HK6T3Pbiq2AU= To: Christian Decker , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <87mufhva0k.fsf@gmail.com> References: <87mufhva0k.fsf@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 14:32:50 -0000 Good morning Christian, This is effectively transaction cut-through. I mention this in passing here: https://lists.linuxfoundation.org/pipermail= /lightning-dev/2019-April/001986.html > I observe that one may consider any offchain system a specialization of a= n offchain transaction cut-through system. > Thus, one may model changes to the offchain system state as the creation = of some transactions, followed by a cut-through of those transactions into = the new state. Basically, we can send a transaction that spends a subset of the current st= ate txos to the participants in the update mechanism. Then the participants can agree that it is a valid spend of the specified s= tate txos, and agree to sign a new state with the spent txos deleted and th= e new txos of the transaction inserted. Disagreement at this point is essentially a "if your tx is so valid why do = you not try it on the base blockchain layer huh?" challenge and is basicall= y an invitation to close it unilaterally and enforce the contract on the bl= ockchain. The "difficulty" in Poon-Dryja is not very onerous in my opinion; see the s= ketch here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-= August/001383.html Of note is that any contract with a relative locktime requirement would not= make sense to maintain offchain. If one wishes to select a relative locktime relative to the current moment,= one can quite easily compute an absolute timelock. Another note, is that contracts with timelocks need to be enforced onchain = on or before the timelock. Under Decker-Russell-Osuntokun the onchain enforcement needs to be triggere= d early according to the CSV security parameter; this is not an issue under= Poon-Dryja (as the CSV is in a later transaction). Under Decker-Russell-Osuntokun due to the use of `SIGHASH_NOINPUT` and the = non-stable txids involved, any transaction you wish to transport in the off= chain update mechanism needs to also be signed under `SIGHASH_NOINPUT`, but= again this is not onerous. In any case it is "only" a matter of tradeoffs one is willing to work under= anyway, and Decker-Russell-Osuntokun is very cool and uses `nLockTime` and= `OP_CHECKLOCKTIMEVERIFY` in a very clever way. Regards, ZmnSCPxj