path: root/bf/fa4f4352ad00c698be5dd3372e2b4cf1868e39

Return-Path: <michaelfolkson@gmail.com>
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: <CAFvNmHSs0V8M8wjonoXKmBF6pgdtzQdgK-apsvd80+0k8WWZMg@mail.gmail.com>
In-Reply-To: <CAFvNmHSs0V8M8wjonoXKmBF6pgdtzQdgK-apsvd80+0k8WWZMg@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Thu, 29 Jul 2021 12:36:25 +0100
Message-ID: <CAFvNmHRw3j77ZrtY0bhDEom_0ZQ_7=31bzwDc0THzh07vze7XA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\@lists.linuxfoundation.org"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<michaelfolkson@gmail.com> 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