Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DADEEC000E for ; Tue, 22 Jun 2021 18:02:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B1F084053D for ; Tue, 22 Jun 2021 18:02:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKGMYL-1QEUq for ; Tue, 22 Jun 2021 18:02:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by smtp4.osuosl.org (Postfix) with ESMTPS id CF80F4052E for ; Tue, 22 Jun 2021 18:02:04 +0000 (UTC) Received: by mail-ed1-x52f.google.com with SMTP id i5so7454960eds.1 for ; Tue, 22 Jun 2021 11:02:04 -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; bh=ERrJz7GJD6jWwCS8QCbPIHIyTJ0rlsyVgEiNAT3Pvz4=; b=ksbumRm8i0ZuZVxmG71F8rzIn1+y5GMld1FmffOaakkXxLxCC6G1pIV8clooYU7SW8 XQnXPGqZsIi/UAZaBKppQF8Nthm5AZ0bxYNpuplv+ypUzVbFASf9+AD8eNnsDETQHUc1 kyDfmMbfk9mf41HoftLIDfnXOaF+XgemBWhN+9X2eh1q1JG2MmAqrYv6GwPGyh6rOEvh Kc2dn7DFVK/kTghc+cq5dYbSrCmyUNAle0qbN12kpBEOxGqM0Bcud5I35TH0lNR7YJRm TaO2ODYVyCWHrUsg4tEhnNjjOd7a03wkz/aA9bImH6N8942873OSWEfHMIF0jdCjHIhG DFJw== 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; bh=ERrJz7GJD6jWwCS8QCbPIHIyTJ0rlsyVgEiNAT3Pvz4=; b=fE9Mkkk+VVLFun5r5H8QTWQcYzDg99HX/3PZ//9nRqEGiTGYHxpjwjkEPOfNf1A+We 4v+210OCweTWvv6+xtvpNgU9J4Jb6e+TNbQcZuSrLbIfyz3V63CxF2i82TN/ohpkL/0Q OAvHc2Hzn0O03efH+HVjTd6gQXs57V3jW04qE6FMo05QmFBebBw8VYpLcKxbKCyYF9eE d5Mx/3nozgaaADAzOk4n7VDIBEOVFeIAkk6hkmJUKn8BYS3+Q+dhVpwlac/eSOYtF/Ny yiWqfl64XXUUMnOp/HlgNA8X4dj84SAnQEwXf4L8tglqDdsl+Q5fAT/P4WHkqXMpajVy AakQ== X-Gm-Message-State: AOAM530zAOa9sR/f2zh/wPFzyWz4YLy8ql0FslMcbv/uwDEcp7hvoKvH +b+XRL7NNkDwn5oXDW+slTZVtj8Kg0I2WK5TUek= X-Google-Smtp-Source: ABdhPJz6RxiopFdsq/Z4VaOV8q5+Y9A+QVKj/lvGrH12lLK8+QO6RiqEvDH0QCvG+und+/ECB8W8y3VositPertXxIc= X-Received: by 2002:a05:6402:1c1a:: with SMTP id ck26mr6776794edb.230.1624384923067; Tue, 22 Jun 2021 11:02:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 22 Jun 2021 11:01:46 -0700 Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000051670405c55e960d" X-Mailman-Approved-At: Wed, 23 Jun 2021 02:51:25 +0000 Subject: Re: [bitcoin-dev] =?utf-8?q?Tuesday=E2=80=99s_IRC_workshop_on_L2_onch?= =?utf-8?q?ain_support?= 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: Tue, 22 Jun 2021 18:02:07 -0000 --00000000000051670405c55e960d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the Summary Michael! It seems like fee-sensitive timelocks weren't discussed too much in the workshop, unless I'm missing something. I also don't see any downside to it discussed (other than that it needs a soft-fork). It seems like that would be a great way to substantially increase the resilience of the LN to temporary periods of fee congestion, even potentially long-running periods that last weeks. It might even help in non-temporary fee market increases by giving participants extra time to use some fee-bumping technique to close or restructure their channels to compensate for the elevated fee market. On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The workshop was previously announced by ariard on the bitcoin-dev > mailing list here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841= .html > > A reminder was posted to the bitcoin-dev mailing list here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.= html > > The conversation log for the workshop is here: > https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 > > I=E2=80=99ll summarize what was discussed during the meeting but please r= efer > to the L2 zoology repo ariard has set up for background context and > additional notes: https://github.com/ariard/L2-zoology > > General considerations > > I think it is worth first reiterating the obvious that there will > never be perfect security guarantees on network transaction fee rates > or transaction relay. Network fee rates can in theory go up to > anything (upper limit of infinity) and will always to some degree be > inherently unpredictable. In addition transaction acceptance can never > be guaranteed even if you attempt a direct connection to a miner. At > the same time L2 protocols (e.g. Lightning and DLCs) elevate > transaction propagation and inclusion in a time sensitive mined block > to a security assumption from what used to just be a usability > assumption (BlueMatt). Within those confines these workshops are > attempting to strengthen that security assumption knowing that > guaranteeing it is out of reach. > > There are considerations that blocked transaction propagation isn=E2=80= =99t > necessarily a problem for the victim if it is also blocked for the > attacker. In addition some successful attacks present an opportunity > for the victim to divert their funds to miner fees (e.g. scorched > earth) ensuring the attacker doesn=E2=80=99t financially benefit from the > attack (harding). Personally I would argue neither of these present > much assurance to the victim. Out of conservatism one should assume > that the attacker has greater resources than the victim (e.g. a direct > line to a miner) and knowing a victim=E2=80=99s lost funds went to the mi= ner > instead of the attacker isn=E2=80=99t of much comfort to the victim (othe= r > than potentially presenting a disincentive for the attack in the first > place). This is obviously further complicated if the miner is the > attacker. In addition any incentive for miners to not mine > transactions to wait for a potential pay-all-to-fee are troubling > (t-bast). > > New(ish) ideas > > RubenSomsen brought up the idea of fee sensitive timelocks, they would > need a soft fork. ariard briefly discussed the idea of a transaction > relay overlay network. harding stated his opinion that we should be > leaning more on miners=E2=80=99 profit incentive rather than attempting t= o > normalize mempool policy (e.g. > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/0026= 64.html > ). > t-bast raised the prospect of mining pools exposing public APIs to > push them transactions directly. > > The impact of changes to Bitcoin Core on L2 protocols > > Some changes to Core (e.g. some privacy improvements) can conflict > with the goal of minimizing transaction propagation times. > Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2 > developers a way to write regression tests against the latest builds > of bitcoind. He added that L2 devs should write automated regression > test suites against bitcoind exposed RPC commands. t-bast would like a > bitcoind =E2=80=9Cevicttx=E2=80=9D RPC to remove a transaction from the m= empool on > regtest. > > Full RBF > > In advance of the workshop ariard posted to the mailing list a > proposal for full RBF in a future version of Bitcoin Core: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.= html > > Progress in this direction has been attempted in the past (e.g. > https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out > that even with full RBF it is trivial to create mempool partitions. As > long as RBF has a fee rate increase minimum an attacker can trivially > split the mempool by broadcasting two conflicting transactions with > the same fee. > > ariard plans to contact businesses (e.g. Lightning onboarding services > relying on zero confirmations) to check that this possible eventual > move to full RBF doesn=E2=80=99t present a problem for them. There could = well > be engineering work required in advance of the possible change being > made. > > Next week=E2=80=99s meeting > > Next week=E2=80=99s meeting (Tuesday 22nd June, 19:00 UTC, > #l2-onchain-support, Libera) will be on fee bumping and package relay > that glozow has recently been working to advance in Bitcoin Core. > > -- > Michael Folkson > Email: michaelfolkson@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000051670405c55e960d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the Summary Michael!=C2=A0

I= t seems like fee-sensitive timelocks weren't discussed too much in the = workshop, unless I'm missing something. I also don't see any downsi= de to it discussed (other than that it needs a soft-fork). It seems like th= at would be a great way to substantially increase the resilience of the LN = to temporary periods of fee congestion, even potentially long-running perio= ds that last weeks. It might even help in non-temporary fee market increase= s by giving participants extra time to use some fee-bumping technique to cl= ose or restructure their channels to compensate for the=C2=A0elevated=C2=A0= fee market.=C2=A0

On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via = bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
The workshop was previously announced by= ariard on the bitcoin-dev
mailing list here:
https://lists.linuxfou= ndation.org/pipermail/bitcoin-dev/2021-April/018841.html

A reminder was posted to the bitcoin-dev mailing list here:
https://lists.linuxfoun= dation.org/pipermail/bitcoin-dev/2021-June/019068.html

The conversation log for the workshop is here:
https://gist.github.com/ariard/5f28df= fe82ddad763b346a2344092ba4

I=E2=80=99ll summarize what was discussed during the meeting but please ref= er
to the L2 zoology repo ariard has set up for background context and
additional notes: https://github.com/ariard/L2-zoology

General considerations

I think it is worth first reiterating the obvious that there will
never be perfect security guarantees on network transaction fee rates
or transaction relay. Network fee rates can in theory go up to
anything (upper limit of infinity) and will always to some degree be
inherently unpredictable. In addition transaction acceptance can never
be guaranteed even if you attempt a direct connection to a miner. At
the same time L2 protocols (e.g. Lightning and DLCs) elevate
transaction propagation and inclusion in a time sensitive mined block
to a security assumption from what used to just be a usability
assumption (BlueMatt). Within those confines these workshops are
attempting to strengthen that security assumption knowing that
guaranteeing it is out of reach.

There are considerations that blocked transaction propagation isn=E2=80=99t=
necessarily a problem for the victim if it is also blocked for the
attacker. In addition some successful attacks present an opportunity
for the victim to divert their funds to miner fees (e.g. scorched
earth) ensuring the attacker doesn=E2=80=99t financially benefit from the attack (harding). Personally I would argue neither of these present
much assurance to the victim. Out of conservatism one should assume
that the attacker has greater resources than the victim (e.g. a direct
line to a miner) and knowing a victim=E2=80=99s lost funds went to the mine= r
instead of the attacker isn=E2=80=99t of much comfort to the victim (other<= br> than potentially presenting a disincentive for the attack in the first
place). This is obviously further complicated if the miner is the
attacker. In addition any incentive for miners to not mine
transactions to wait for a potential pay-all-to-fee are troubling
(t-bast).

New(ish) ideas

RubenSomsen brought up the idea of fee sensitive timelocks, they would
need a soft fork. ariard briefly discussed the idea of a transaction
relay overlay network. harding stated his opinion that we should be
leaning more on miners=E2=80=99 profit incentive rather than attempting to<= br> normalize mempool policy (e.g.
https://lists.linuxf= oundation.org/pipermail/lightning-dev/2020-April/002664.html).
t-bast raised the prospect of mining pools exposing public APIs to
push them transactions directly.

The impact of changes to Bitcoin Core on L2 protocols

Some changes to Core (e.g. some privacy improvements) can conflict
with the goal of minimizing transaction propagation times.
Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2
developers a way to write regression tests against the latest builds
of bitcoind. He added that L2 devs should write automated regression
test suites against bitcoind exposed RPC commands. t-bast would like a
bitcoind =E2=80=9Cevicttx=E2=80=9D RPC to remove a transaction from the mem= pool on
regtest.

Full RBF

In advance of the workshop ariard posted to the mailing list a
proposal for full RBF in a future version of Bitcoin Core:
https://lists.linuxfoun= dation.org/pipermail/bitcoin-dev/2021-June/019074.html

Progress in this direction has been attempted in the past (e.g.
https://github.com/bitcoin/bitcoin/pull/10823) Blue= Matt pointed out
that even with full RBF it is trivial to create mempool partitions. As
long as RBF has a fee rate increase minimum an attacker can trivially
split the mempool by broadcasting two conflicting transactions with
the same fee.

ariard plans to contact businesses (e.g. Lightning onboarding services
relying on zero confirmations) to check that this possible eventual
move to full RBF doesn=E2=80=99t present a problem for them. There could we= ll
be engineering work required in advance of the possible change being
made.

Next week=E2=80=99s meeting

Next week=E2=80=99s meeting (Tuesday 22nd June, 19:00 UTC,
#l2-onchain-support, Libera) will be on fee bumping and package relay
that glozow has recently been working to advance in Bitcoin Core.

--
Michael Folkson
Email: michae= lfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000051670405c55e960d--