Re: [Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)
On Thu, Sep 05, 2019 at 11:29:35AM +, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > I do not see much point in using miniscript for Lightning unless we > decide to support transporting arbitrary contracts, as here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html > > Otherwise, it would be far easier implementation-wise, to just have > carefully-coded SCRIPT to transport HTLCs. Something that has been impressed upon me is that using miniscript to create optimized Bitcoin scripts is perhaps not its primary use. Miniscript also makes it easy for any miniscript-aware wallet to figure out how to create a valid witness for the miniscript (if the wallet has the necessary private keys, hash pre-images, and a function to satisfy any timelocks). For example, right now Pieter Wuille is working on incorporating miniscript into Bitcoin Core. If there was then a miniscript for the current LN scripts and someone imported their keys and invoice pre-images[1] into their Bitcoin Core wallet, then Bitcoin Core could sign for their LN update and settlement transactions. E.g., the C-Lightning "HSM" module could become a thin wrapper around Bitcoin Core's wallet (or any other miniscript-aware wallet). Later, other wallets such as hardware wallets and exchange HSMs may add support for libminiscript, making it easy for LN nodes to delegate signing to outside devices without anyone having to change the code of those hard-to-change devices. Even later than that, y'all may change the LN script either slightly or dramatically If both the old script and the new script are miniscript based, then maybe none of the wallets that already supported miniscript will need to update their signing code---libminiscript will tell them what data they need to provide for the witness and, as long as they have functions capable of retrieving or generating that data, they'll automatically know how to create a witness for the new miniscript. Finally, someday consensus changes like taproot and SIGHASH_NOINPUT/ANYPREVOUT may be activated. If libminiscript is updated for that change, getting wallets to support those changes may be as easy as updating their bundled libminiscript version. In summary, miniscript does help you produce machine-optimized scripts and analyze them (and that's a pretty nifty feature by itself), but miniscript's true potential may come from allowing any wallet to sign for any miniscript-compatible script, freeing developers from having to write lots of sensitive signing code or heavily coordinating changes across different software (as is common in LN). -Dave [1] I don't think this is currently possible, but adding support for it using output script descriptors might not be difficult. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
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 an > 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 state txos to the participants in the update mechanism. Then the participants can agree that it is a valid spend of the specified state txos, and agree to sign a new state with the spent txos deleted and the 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 basically an invitation to close it unilaterally and enforce the contract on the blockchain. The "difficulty" in Poon-Dryja is not very onerous in my opinion; see the sketch 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 triggered 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 offchain 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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Reconciling the off-chain and on-chain models with eltoo
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
