Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E826B22A1; Fri, 6 Sep 2019 13:23:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED240831; Fri, 6 Sep 2019 13:23:37 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id i1so6306392edv.4; Fri, 06 Sep 2019 06:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:mime-version; bh=EOcaEuS/DzeX+REKHfXEhOTJXjuMmfZzVeTqOfQzFiA=; b=JIeaNN8iumjsjdABJJJjeoEWVVPRLWnjoCsp1NdH36y5igZouCX6b3YDTWG7GAeIti 28mDVfM3p5vNyB+C01s6m9IZB7yPsHwUuQqry5zB8sS4ED7yPGOqUFHjtA8Kz0zmgxkm PrG3ic9OdbfP0v37NJf0Qw8N8GbH6gJnjJpEYC5K3LWPc5YAx9ts9dAJUHQ9Ffkm3hoL P8SNWsOyIKsRHLZl8BQHzPe8+T+O+kTRM+m0w0c841MEJ52PSWyfY+KfPCtyb0eAUxvv /XD6OjozE+aAL9prkCkQ+yQw+hPHg9ow23mW0PMuFaP69KHSsFaoE6gZdBirbLDYpNpH Z+vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:mime-version; bh=EOcaEuS/DzeX+REKHfXEhOTJXjuMmfZzVeTqOfQzFiA=; b=MinhJG3p+Vbgs1lwleIqZjbSGo5IyfTXv+0yIFlkhGAwZc8NvJwtf65RH7U2xjzgnb jkEixpRD5p2HO3pn1aBe7BoL6HegMA0weceVuCFaBEyJboffrqjZZguvamM+jsV3iy3h v37eWvagN1HExpp3HTTHfzTlzyZwuJCPVYMuSru6sHfm/4r9DVQL6I+bG700XJcShNLd AeTayMtwakZ7RcJ3KmjXO0tyxwuqzu8AKw8Ymjyn30zJ4Uez7LpD8MJyUn/PCAFd4hdU 9C36/map12hqvTi3jLWP0bi+Tf9g0rJdRqxTGuVNv2l6cQfaPbZnPNvY/KSo4C8MGT0f VZ5w== X-Gm-Message-State: APjAAAWwr3QlRP8UQtoUpLzcpGNzsspAFRvecf4TZNgl1lljQbnqxBpb lHD/Mv4I5ICw0RbiWVZYy4iexAv9jdI= X-Google-Smtp-Source: APXvYqzEo31nSIoCCTybRh+P0F9TibfrOO5lhS5aTwQGGVyfwoEDAE81/bOgVvCGUq559dIfbtk/fg== X-Received: by 2002:a17:907:10c2:: with SMTP id rv2mr7080198ejb.305.1567776215856; Fri, 06 Sep 2019 06:23:35 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:151b:6955:e30b:9bb2]) by smtp.gmail.com with ESMTPSA id bm1sm937335edb.29.2019.09.06.06.23.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Sep 2019 06:23:35 -0700 (PDT) From: Christian Decker To: lightning-dev@lists.linuxfoundation.org Date: Fri, 06 Sep 2019 15:18:03 +0200 Message-ID: <87mufhva0k.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: [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 13:23:39 -0000 With the recently published proof-of-concept of eltoo on signet by Richard, I thought it might a good time to share some thoughts on ho I think we can build this system. I think there are a few properties of eltoo that allow us to build a nicely layered protocol stack, which improves flexibility and simplifies the reasoning about their relative security. Since I don't like huge e-mails myself and I'm about to write one, here's a quick TL;DR: > Using the clean separation of protocol layers provided by eltoo we can > reconcile many on-chain and off-chain concepts, and simplify the > reasoning to build more complex functionality beyond simple > HTLCs. Bitcoin transactions are a natural fit to represent proposed > off-chain state-changes while they are being negotiated. ### Clean separation of protocol layers One of te big advantages of eltoo over other off-chain update mechanisms is that it provides strong guarantees regarding the state that will eventually end up confirmed on-chain. If parties in an eltoo off-chain contract agree on an update, we can be certain (within eltoo's security assumptions) that this is the state that will eventually confirm on-chain, if no newer states are agreed. In particular it means that we are guaranteed no earlier state can leak onto the chain, keeping anything we build on top of the update layer unencumbered since it doesn't have to deal with this case. This is in stark contrast to the penalty update mechanism, where old/revoked states can leak on-chain, resulting in anything built on top of the penalty mechanism having to deal with that eventuality. For example if we look at HTLCs as specified [1] we see that it needs an additional revokation path for the case the commitment transaction that created this HTLC output is confirmed: ```btcscript # To remote node with revocation key OP_DUP OP_HASH160 OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE OP_SWAP OP_SIZE 32 OP_EQUAL OP_IF # To local node via HTLC-success transaction. OP_HASH160 OP_EQUALVERIFY 2 OP_SWAP 2 OP_CHECKMULTISIG OP_ELSE # To remote node after timeout. OP_DROP OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF OP_ENDIF ``` The update mechanism bleeding into the other layers is rather cumbersome if you ask me, and complicates the reasoning about security. Having to thread the penalty through outputs created by the off-chain contract may also not work if we deal with more than 2 parties, since penalties always steal all the funds, regardless of whether the output belonged to the cheater or not (see asymmetry vs symmetry argument from the paper [2]). With the clean separation we get from eltoo we can concentrate on building the output scripts we'd like to have without having to thread penalties through them. This reduces the complexity and our on-chain footprint. The update layer now exposes only two very simple operations: `add_output` and `remove_output` (this should sound very familiar :-p). ### Ownership and atomic update model Now that we have a solid update layer, which ensures that agreed upon states will eventually be reflected on-chain, we can turn our attention to the next layer up: the negotiation layer. Each output in our agreed-upon state needs to be assigned one or more owners. The owners are the participants that need to sign off on removal of an output and the creation of new outputs which redistribute the funds contained in the removed outputs to newly created outputs. In addition we need to ensure that multiple `remove_output` and `add_output` are guaranteed to be applied atomically. By creating a datastructure that lists a number of operations that are to either be applied to the current state or discarded, we can have arbitrary complex changes of ownership, and the newly created outputs can have arbitrary scripts. If all of this sounds familiar that's because this is exactly the UTXO model and the transaction structure we have in Bitcoin. We collaboratively manage funds bound to some outputs (UTXO) and can change their ownership and allocation over time (transactions). This means that a subset of the participants in an off-chain contract can negotiate among themselves how to redistribute funds, join and split them in an arbitrary fashion, without the rest of the contract being involved. The end result is a valid Bitcoin transaction that spends some outputs of the current state, and is signed by the owners. The transaction can then be presented to the entire group, and applied to the state. Applying the transaction flattens multiple transactions built on top of the current state into a new state (similar to transaction cut-through in mimblewimble). Using transactions as a means to represent off-chain negotiations, and then applying them to the off-chain state via cut-through has a number of advantages over similar schemes: - Even if we failed to update the off-chain state, the transactions building on top of it are valid transactions, so once we tear down the channel, our negotiated new state can still be reached by broadcasting the transaction after settlement (this is basically what the channel factory paper [3] was using). - We can reuse a lot of tools that we have already built for on-chain transactions, including things like miniscript and hardware wallets, without explicitly requiring them in our own specification. The Bitcoin object model is our interface here. - It allows for experimentation even inside a running eltoo instance. If you can find another participant that supports a fancy new protocol, you can use that protocol even though some of the other participants may not know anything about it. As long as you can understand the Bitcoin transaction model you can participate in a multi-party channel. I think this reconciliation between the off-chain model and the on-chain model, with many concepts cleanly mapping from one context to another (state outputs = UTXO, off-chain update = on-chain transactions, cut-through = confirmation, operation batching = block creation) is rather nice :-) That should be enough rambling on my side. I'm interested in what others think about this. Is it completely off, does it make no sense at all, or is this something we should be looking into going forward? Cheers, Christian [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#received-htlc-outputs [2] https://blockstream.com/eltoo.pdf [3] https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable%5FFunding%5FOf%5FBlockchain%5FMicropayment%5FNetworks.pdf