path: root/2f/351c0529c22553ca210f0b6d8b539b87408f75

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DADEEC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:02:04 +0000 (UTC)
Received: by mail-ed1-x52f.google.com with SMTP id i5so7454960eds.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAFvNmHSYD0yZhMJC=ceBZw86+-HyZ3mj19Tx3svfZ7Gxn3FiRg@mail.gmail.com>
In-Reply-To: <CAFvNmHSYD0yZhMJC=ceBZw86+-HyZ3mj19Tx3svfZ7Gxn3FiRg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 22 Jun 2021 11:01:46 -0700
Message-ID: <CAGpPWDYi0Cqm7JjM5CuNOutA4UpDsQS_3Nta+SmVSPxe3jaOog@mail.gmail.com>
To: Michael Folkson <michaelfolkson@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr">Thanks for the Summary Michael!=C2=A0<div><br></div><div>I=
t seems like fee-sensitive timelocks weren&#39;t discussed too much in the =
workshop, unless I&#39;m missing something. I also don&#39;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</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">The workshop was previously announced by=
 ariard on the bitcoin-dev<br>
mailing list here:<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Apr=
il/018841.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2021-April/018841.html</a><br>
<br>
A reminder was posted to the bitcoin-dev mailing list here:<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Jun=
e/019068.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2021-June/019068.html</a><br>
<br>
The conversation log for the workshop is here:<br>
<a href=3D"https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4"=
 rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/ariard/5f28df=
fe82ddad763b346a2344092ba4</a><br>
<br>
I=E2=80=99ll summarize what was discussed during the meeting but please ref=
er<br>
to the L2 zoology repo ariard has set up for background context and<br>
additional notes: <a href=3D"https://github.com/ariard/L2-zoology" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/ariard/L2-zoology</a><br>
<br>
General considerations<br>
<br>
I think it is worth first reiterating the obvious that there will<br>
never be perfect security guarantees on network transaction fee rates<br>
or transaction relay. Network fee rates can in theory go up to<br>
anything (upper limit of infinity) and will always to some degree be<br>
inherently unpredictable. In addition transaction acceptance can never<br>
be guaranteed even if you attempt a direct connection to a miner. At<br>
the same time L2 protocols (e.g. Lightning and DLCs) elevate<br>
transaction propagation and inclusion in a time sensitive mined block<br>
to a security assumption from what used to just be a usability<br>
assumption (BlueMatt). Within those confines these workshops are<br>
attempting to strengthen that security assumption knowing that<br>
guaranteeing it is out of reach.<br>
<br>
There are considerations that blocked transaction propagation isn=E2=80=99t=
<br>
necessarily a problem for the victim if it is also blocked for the<br>
attacker. In addition some successful attacks present an opportunity<br>
for the victim to divert their funds to miner fees (e.g. scorched<br>
earth) ensuring the attacker doesn=E2=80=99t financially benefit from the<b=
r>
attack (harding). Personally I would argue neither of these present<br>
much assurance to the victim. Out of conservatism one should assume<br>
that the attacker has greater resources than the victim (e.g. a direct<br>
line to a miner) and knowing a victim=E2=80=99s lost funds went to the mine=
r<br>
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<br>
place). This is obviously further complicated if the miner is the<br>
attacker. In addition any incentive for miners to not mine<br>
transactions to wait for a potential pay-all-to-fee are troubling<br>
(t-bast).<br>
<br>
New(ish) ideas<br>
<br>
RubenSomsen brought up the idea of fee sensitive timelocks, they would<br>
need a soft fork. ariard briefly discussed the idea of a transaction<br>
relay overlay network. harding stated his opinion that we should be<br>
leaning more on miners=E2=80=99 profit incentive rather than attempting to<=
br>
normalize mempool policy (e.g.<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-A=
pril/002664.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2020-April/002664.html</a>).<br>
t-bast raised the prospect of mining pools exposing public APIs to<br>
push them transactions directly.<br>
<br>
The impact of changes to Bitcoin Core on L2 protocols<br>
<br>
Some changes to Core (e.g. some privacy improvements) can conflict<br>
with the goal of minimizing transaction propagation times.<br>
Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2<br>
developers a way to write regression tests against the latest builds<br>
of bitcoind. He added that L2 devs should write automated regression<br>
test suites against bitcoind exposed RPC commands. t-bast would like a<br>
bitcoind =E2=80=9Cevicttx=E2=80=9D RPC to remove a transaction from the mem=
pool on<br>
regtest.<br>
<br>
Full RBF<br>
<br>
In advance of the workshop ariard posted to the mailing list a<br>
proposal for full RBF in a future version of Bitcoin Core:<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Jun=
e/019074.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2021-June/019074.html</a><br>
<br>
Progress in this direction has been attempted in the past (e.g.<br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/10823" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/10823</a>) Blue=
Matt pointed out<br>
that even with full RBF it is trivial to create mempool partitions. As<br>
long as RBF has a fee rate increase minimum an attacker can trivially<br>
split the mempool by broadcasting two conflicting transactions with<br>
the same fee.<br>
<br>
ariard plans to contact businesses (e.g. Lightning onboarding services<br>
relying on zero confirmations) to check that this possible eventual<br>
move to full RBF doesn=E2=80=99t present a problem for them. There could we=
ll<br>
be engineering work required in advance of the possible change being<br>
made.<br>
<br>
Next week=E2=80=99s meeting<br>
<br>
Next week=E2=80=99s meeting (Tuesday 22nd June, 19:00 UTC,<br>
#l2-onchain-support, Libera) will be on fee bumping and package relay<br>
that glozow has recently been working to advance in Bitcoin Core.<br>
<br>
-- <br>
Michael Folkson<br>
Email: <a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blank">michae=
lfolkson@gmail.com</a><br>
Keybase: michaelfolkson<br>
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000051670405c55e960d--