A summary of the first workshop is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay. For more details on package relay see: https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md The conversation log for the second workshop is here: https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442 Package relay background Package relay is potentially useful for L2 protocols to address the inherent unpredictability of future fees. CPFP (child-pays-for-parent) seeks to ensure say a justice transaction, in Lightning’s case, with a lower fee, gets confirmed in a more timely manner because miners are incentivized to include the child transaction in a block. To do so they must include the parent transaction in that block or a preceding block. By “packaging” the parent and the child the initiator of the transaction(s) can ensure the miner’s mempool doesn’t initially reject the parent transaction for having a too low fee. There has been prior work done in previous years on package relay, mainly by Suhas Daftuar. Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a Package relay design questions: https://github.com/bitcoin/bitcoin/issues/14895 Recently Gloria Zhao has been advancing package relay in Bitcoin Core: https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add Package relay implementation Attendees seemed in agreement that enabling 2 transaction packages would be sufficient (at least for now) for Lightning and DLCs. A L2 protocol should always be able to design a two step process where the first transaction has an effective zero fee rate and the second transaction sets the fee. Restricting the size of the package to 2 may have the cost of slightly longer confirmation times and/or slightly higher fees (t-bast) but it compares well to the increased implementation complexity of larger package sizes. Two generation: multi parent, single child shouldn’t introduce material implementation complexity over two generation: single parent, single child (glozow). Package RBF (replace-by-fee) is possible where there are two competing packages with competing Lightning commitment transactions in them and the second package is given a higher fee to attempt to get it confirmed before the first package. However, supporting RBF within a package (ie replacing a transaction in a package with a higher fee transaction) increases implementation complexity and makes it harder to reason about (glozow). rgrant raised the possibility of using two packages {A,B} and {B,C} if three transaction packages e.g. {A,B,C} weren’t supported but it was suggested it is perhaps better to just broadcast a high fee CPFP transaction for the {A,B} package rather than creating two packages. If the first package has been evicted from the mempool the {B,C} package wouldn’t propagate because it would be an orphan package (t-bast). glozow suggested that only hints (wtxids of transactions you think should be package validated) could be communicated rather than relaying the transaction themselves but there were concerns from others on whether these hints would successfully propagate across the network. Instead fee rate hints could be sent to inform a peer’s decision on whether it makes sense to fetch the rest of the package (t-bast). darosior suggested the idea of a package based CBlockPolicyEstimator in Bitcoin Core if CPFP is going to be increasingly used on the network. Witness replacement and Taproot Tapscripts can be unlimited in size so with current Taproot rules you could in theory go from a 100,000 vbyte witness to an empty witness. L2 protocols may have a UTXO shared by two parties where Alice’s witness for her branch is say 1,000 vbytes and Bob’s witness is only say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller witness could reduce transaction fees. For Lightning the best case is a Taproot key path spend (16 vbyte witness) and the worst case is going to be a 150 vbyte witness. Miniscript can tell you your worst case transaction size and this can be used to assess the transaction pinning risk of a bloated witness (all harding). A future soft fork could give meaning to the annex in Taproot (darosior) which could be used for inflating the fee rate of a witness. Then you could have a same-txid-different-wtxid coming after with a lower fee rate but higher vbytes size to override package limits (ariard). But fee rate is purely a policy concept and the annex operates at the consensus level. In addition the annex can only increase the weight of a transaction, it cannot decrease it (harding). Wrap up and initial goals With regards to the goals of the workshops that were initially announced here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html 1) 2 transactions packages sounds enough to support currently deployed L2 protocols 2) There are ongoing discussions in the ecosystem regarding deprecation of opt in RBF and implementation of full RBF: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html 3) Generally status quo and ad hoc security incident response policy in the case of cross-layer security issues 4) Generally status quo on L2 security philosophy design. L2 protocol designers should seek to minimize assumptions on the base layer. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev