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 9C80B3EE for ; Thu, 19 Sep 2019 07:52:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6281A76D for ; Thu, 19 Sep 2019 07:52:21 +0000 (UTC) Date: Thu, 19 Sep 2019 07:52:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568879535; bh=WNvRejzvMv0uxJOlNPsOA60GvjbGcHeNPUE8PyPWZcY=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=OE8dTaHHIjdN26OXd8y4FEDXj7kEzrXdEFejJTI6MYFe71AhYELJ/fJL+ycUV8Djv zYpzKdQt12k37bg/5j+Fsn/p4rFOZFyPbuer+aErXh+5/FgPxOOWixjmk4NkyRyZ8P RtQ8d6OsFpDEilpNO4jdqqvR48z3n4pm9wR+A7yM= To: bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <7e7SBK5tLdpzTkgh-sNrAZR7qnPfu_i0tHY5ia4pk3Mjdw3dSZx3kcKiIMC9Hmu_lp8Y3mBFqlqsA_iHobJo58MSiW8NW1zKHUQKOWuuw4c=@protonmail.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 Subject: [bitcoin-dev] Timelocks and Lightning on MimbleWimble 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: Thu, 19 Sep 2019 07:52:22 -0000 Good morning list, I was reading transcript of recent talk: https://diyhpl.us/wiki/transcripts= /scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/ And in section "Taproot: main idea": > Q: Can you do timelocks iwth adaptor signatures? > > ... > > A: This is one way it's being proposed by mimblewimble; but this requires= the ability to aggregate signatures across transactions. > > Q: No, there's two transactions already existing. Before locktime, you ca= n spend wit hthe adaptor signature one like atomic swaps. After locktime, t= he other one becomes valid and you can spend with that. They just double sp= end each other. > > A: You'd have to diagram that out for me. There's a few ways to do this, = some that I know, but yours isn't one of them. I believe what is being referred to here is to simply have an `nLockTime` t= ransaction that is signed by all participants first, and serves as the "tim= elock" path. Then, another transaction is created, for which adaptor signatures are give= n, before completing the ritual to create a "hashlock" path. I find it surprising that this is not well-known. I describe it here tangentially, for instance: https://lists.linuxfoundatio= n.org/pipermail/bitcoin-dev/2019-April/016888.html The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction" a= nd "pre-swap backout transaction", which are `nLockTime`d transactions. Later transactions then use a Scriptless Script-like construction to transf= er information about a secret scalar x. My understanding of MimbleWimble is that: * There must exist a proof-of-knowledge of the sum of blinding factors used= . This can be trivially had by using a signature of this sum, signing an em= pty message or "kernel". * I believe I have seen at least one proposal (I cannot find it again now) = where the "kernel" is replaced with an `nLockTime`-equivalent. Basically, the `nLockTime` would have to be explicitly published, and it = would be rejected for a block if the `nLockTime` was less than the block he= ight. * There may or may not exist some kind of proof where the message being s= igned is an integer that is known to be no greater than a particular value,= and multiple signatures that signed a lower value can somehow be aggregate= d to a higher value, which serves this purpose as well, but is compressible= . My understanding is thus that the above `nLockTime` technique is what is in= deed intended for MimbleWimble cross-system atomic swaps. -------- However, I believe that Lightning and similar offchain protocols are **not = possible** on MimbleWimble, at least if we want to retain its "magical shri= nking blockchain" property. All practical channel constructions with indefinite lifetime require the us= e of *relative* locktime. Of note is that `nLockTime` represents an *absolute* lifetime. The only practical channel constructions I know of that do not require *rel= ative* locktime (mostly various variants of Spilman channels) have a fixed = lifetime, i.e. the channel will have to be closed before the lifetime arriv= es. This is impractical for a scaling network. It seems to me that some kind of "timeout" is always necessary, similar to = the timeout used in SPV-proof sidechains, in order to allow an existing cla= imed-latest-state to be proven as not-actually-latest. * In Poon-Dryja, knowledge of the revocation key by the other side proves t= he published claimed-latest-state is not-actually-latest and awards the ent= ire amount to the other party. * This key can only be presented during the timeout, a security parameter= . * In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff starts= this timeout, and only the smallest-timeout state gets onchain, due to it = having a time advantage over all other versions. * In indefinite-lifetime Spilman channels (also described in the Decker-Wat= tenhofer paper), the absolute-timelock initial backoff transaction is repla= ced with a kickoff + relative-locktime transaction. * In Decker-Russell-Osuntokun, each update transaction has an imposed `nSeq= uence` that forces a state transaction to be delayed compared to the update= transaction it is paired with. It seems that all practical offchain updateable cryptocurrency systems, som= e kind of "timeout" is needed during which participants have an opportunity= to claim an alternative version of some previous claim of correct state. This timeout could be implemented as either relative or absolute lock time,= but obviously an absolute locktime would create a limit on the lifetime of= the channel. Thus, if we were to target an indefinite-lifetime channel, we must use rela= tive lock times, with the timeout starting only when the unilateral close i= s initiated by one participant. Now, let us turn back to the MimbleWimble. As it happens, we do *not* actually need SCRIPT to implement these offchain= updateable cryptocurrency systems. 2-of-2 is often enough (and with Schnorr and other homomorphic signatures, = this is possible without explicit script, only pubkeys and signatures, whic= h MimbleWimble supports). * Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed = this was the original formulation). * Since we have shown that, by use of two transaction alternatives, one t= imelocked and the other hashlocked, we can implement an HTLC-like construct= on MimbleWimble, that is enough. * Relative locktimes in Decker-Wattenhofer are imposed by simple `nSequence= `, not by `OP_CSV`. HTLCs hosted inside such constructions can again use the two-transactions= construct in MimbleWimble. * Ditto with indefinite-lifetime Spilman. * Ditto with Decker-Russell-Osuntokun. * The paper shows the use of `OP_CSV`, but aj notes it is redundant, and = I agree: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Mar= ch/001933.html Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from b= eing deployed on MimbleWimble. Instead, it is the "nonexistence of **relative** locktime" that prevents Li= ghtning over MimbleWimble. Why would **relative** locktimes not possibly exist? In order to **validate** a relative locktime, we need to know the blockheig= ht that the output we are spending was confirmed in. But the entire point of the "magical shrinking blockchain" is that already-= spent outputs can be removed completely and all that needs to be validated = by a new node is: * The coin-creation events. * The current UTXO set (plus attached rangeproofs). * The blinding keys. * Signatures of the blinding keys, and the kernels they sign (if we use the= "kernels encode `nLockTime`" technique in some way, they should not exceed= the current supposed blockheight). The problem is that an output that exists in the UTXO set might be invalid,= if it appears "too near" to an `nSequence` minimum spend of a previous out= put that was spent in its creation. That is, the above does not allow validation of **relative** locktimes, onl= y **absolute locktimes**. (At least as far as I understand: there may be special cryptographic constr= ucts that allow signatures to reliably commit to some relative locktime). This means that relative locktimes need to be implemented by showing the tr= ansactions that spend previous UTXOS and create the current UTXOs, and so n= o backwards to coin-creation events. This forces us back to the old "validate all transactions" model of startin= g a new node (and seriously damaging the entire point of using MimbleWimble= anyway). I do not believe it is the lack of SCRIPT that prevents Lightning-over-Mimb= leWimble, but rather the lack of relative locktime, which seems difficult t= o validate without knowing the individual transactions and when they were c= onfirmed. Regards, ZmnSCPxj