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
Subject: Re: [bitcoin-dev] Last week's second IRC workshop on L2 onchain
	support and wrap up
Precedence: list

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