From michaelfolkson at gmail.com Thu Jul 29 11:36:25 2021 From: michaelfolkson at gmail.com (Michael Folkson) Date: Thu, 29 Jul 2021 12:36:25 +0100 Subject: [Lightning-dev] Last week's second IRC workshop on L2 onchain support and wrap up In-Reply-To: References: Message-ID: There was some additional discussion on L2 onchain support at the recent online Sydney Socratic Seminar. It wasn't recorded but a transcript is below. Transcript: https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/ The discussion focused partly on the rules [1] of BIP 125 RBF and the rationale for these rules (which isn't clear from the BIP). Proposed ideas such as SIGHASH_IOMAP, fee sponsorship and transaction mutation were also discussed that weren't covered during the IRC workshops. [1] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details On Tue, Jun 29, 2021 at 10:44 AM Michael Folkson wrote: > > 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: michaelfolkson at gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: michaelfolkson at gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3