From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E4EFFC000E; Thu, 29 Jul 2021 11:36:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id CCDD3401F0; Thu, 29 Jul 2021 11:36:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BoRv2n7CK2j; Thu, 29 Jul 2021 11:36:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by smtp2.osuosl.org (Postfix) with ESMTPS id C4109401BD; Thu, 29 Jul 2021 11:36:37 +0000 (UTC) Received: by mail-yb1-xb2c.google.com with SMTP id f26so9687106ybj.5; Thu, 29 Jul 2021 04:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=4pM0//AFPsZNNOT7F8PEphJe7xUhU+JsmZMs5S1LolU=; b=vNVoPF3teYB3tvro77wSZfyuEw7+Jq//vm5buW+iSzTgsc/THoiE8YMxObn7bgRtJE juFzHpAW4sxeqDtESjkjBOEa9hFCrV+NCQsuGSfe4u+gJDvMddZquCHuzVhrMBgaDeVJ 3OAJUQBU4l2WoelHJds02FcWc1I9jJQyuKrn+nH7mcUTxtIEUl9Tl1rpdfRipcjgWsQl aoXX35yHs8x3CZc+aWQC8+6GdxwpPgan1LNFc8ta4gQ+jPqt0Ep7stodBZUtUp2FGCM+ V2swnvYq866WUmYBozCJLXGk0TTKgHcpjay73sabWnsLtchJfpZG9WqmZ07AyssUy1KD G9/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=4pM0//AFPsZNNOT7F8PEphJe7xUhU+JsmZMs5S1LolU=; b=irRDhlGz8S3z0J9ImXoCTCv3i4vKFIy3qbxjw5/agD1r+y2N4J5Aw81g6XtJQI3iOT AmubiTuFpGzu5Jt7osL+/M8l7dypxwEbBvD5Ll2S1EzamxGckyElWXH++amrI7svouAp 3GUT+tzNcGbqddIWuLPf85g6xMVmTxInponNXOs5gwXNhUxGFoHWDPZUtYcQYdl5Dq5r s99/wQC6V9bw9z3Q4aE5MtFUzOlVW40q9EmRGk97ohgU3cI0ntBs9X6EHh7W50x8tP9U /k30gGWucXMzod922ct9m4VbEqqZEaqejvUcTBrhZZUUaLEzZf81gh6W23WrEVf4i9j8 aweQ== X-Gm-Message-State: AOAM532PqSGA1+yuRXtgIaqg8U5ZOLgS8hLT1eeAHeZ9gcfWnxNJwKSh n0bQBuO7RFWwmnsuvXe+71EUPZtJA5Peffdt2v89TKuohmZfvQ== X-Google-Smtp-Source: ABdhPJxd9G7No9wKVHvKVe4w+V1riFlakiC+/ao1fwxp25KgNtoYtKxr3Kx+Yj7B2DjYnf1d7tuUSuOGNG/K4QLSq6Q= X-Received: by 2002:a25:fc5:: with SMTP id 188mr5933085ybp.51.1627558596313; Thu, 29 Jul 2021 04:36:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Folkson Date: Thu, 29 Jul 2021 12:36:25 +0100 Message-ID: To: Bitcoin Protocol Discussion , "lightning-dev\\@lists.linuxfoundation.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 30 Jul 2021 20:01:02 +0000 Subject: Re: [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 11:36:41 -0000 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-soc= ratic-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#implemen= tation-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=E2=80=99s case, w= ith 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 =E2=80=9Cpackaging=E2=80=9D the parent and the child the initia= tor of the > transaction(s) can ensure the miner=E2=80=99s mempool doesn=E2=80=99t ini= tially 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/8756699bfcad4d3806ba9f3396d4e= 66a > > 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=E2=80=99t introduce material implement= ation > 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=E2=80=99t 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=E2=80=99t 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=E2=80=99s > 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=E2=80=99s > witness for her branch is say 1,000 vbytes and Bob=E2=80=99s witness is o= nly > say 250 vbytes. Replacing Alice=E2=80=99s larger witness with Bob=E2=80= =99s 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/0030= 02.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@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --=20 Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3