MIME-Version: 1.0
References: <CAFvNmHSYD0yZhMJC=ceBZw86+-HyZ3mj19Tx3svfZ7Gxn3FiRg@mail.gmail.com>
 <CAGpPWDYi0Cqm7JjM5CuNOutA4UpDsQS_3Nta+SmVSPxe3jaOog@mail.gmail.com>
 <CAFvNmHQjVs02AncYmGUipwt9cG+QvHpimmuMwYT1wRoQ4HiNiw@mail.gmail.com>
 <CAGpPWDaUDeNNwBUELnQ0xUDSkDTWv6vgEqVu1Sg7uNWOkKM+_g@mail.gmail.com>
In-Reply-To: <CAGpPWDaUDeNNwBUELnQ0xUDSkDTWv6vgEqVu1Sg7uNWOkKM+_g@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Tue, 22 Jun 2021 19:40:19 +0100
Message-ID: <CAFvNmHT96AHwgcQejF+5QLdPVvLPEXFbsG5vP7tF7=AA3CzMKA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
	=?utf-8?q?Tuesday=E2=80=99s_IRC_workshop_on_L2_onch?=
	=?utf-8?q?ain_support?=
Precedence: list

Sure, feel free to continue on this thread for discussion of fee
sensitive timelocks. I'll start a new thread for a summary of today's
second workshop.

On Tue, Jun 22, 2021 at 7:26 PM Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>
> >  where is the current network fee rate obtained from and how is it fed =
into the script?
>
> It could be obtained as something like the median transaction fee rate ov=
er a window of X blocks. Its something any full node could easily keep trac=
k of. And as long as hour-level or day-level granularity is acceptable, I w=
ouldn't think there'd be any need to incorporate mempool information (if th=
at were even possible without introducing new attack vectors). Let me know =
if this isn't an appropriate thread to discuss this in.
>
> On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson <michaelfolkson@gmail.co=
m> wrote:
>>
>> Hey Billy
>>
>> No, fee sensitive timelocks weren't discussed at any length in the
>> workshop. The workshops are obviously time limited but if they spur
>> future discussion and drafted proposals (whether they need soft forks
>> or not) outside of the workshops that would be great. This idea was
>> raised in the meeting by Ruben Somsen so maybe Ruben has given them
>> some thought. Making timelocks conditional on the current fee rate
>> seems challenging to me (where is the current network fee rate
>> obtained from and how is it fed into the script?) but I haven't
>> sketched out exactly how they would work.
>>
>> A reminder that the second workshop (on package relay and fee bumping)
>> starts at 19:00 UTC today (30 minutes after I've sent this, there may
>> be a delay before it is published to the mailing list).
>>
>> Thanks
>> Michael
>>
>> On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud <billy.tetrud@gmail.com> wr=
ote:
>> >
>> > Thanks for the Summary Michael!
>> >
>> > It seems like fee-sensitive timelocks weren't discussed too much in th=
e 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 wou=
ld be a great way to substantially increase the resilience of the LN to tem=
porary periods of fee congestion, even potentially long-running periods tha=
t last weeks. It might even help in non-temporary fee market increases by g=
iving 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 <bitco=
in-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/01=
8841.html
>> >>
>> >> A reminder was posted to the bitcoin-dev mailing list here:
>> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019=
068.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 plea=
se refer
>> >> 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 neve=
r
>> >> 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 direc=
t
>> >> line to a miner) and knowing a victim=E2=80=99s lost funds went to th=
e miner
>> >> instead of the attacker isn=E2=80=99t of much comfort to the victim (=
other
>> >> than potentially presenting a disincentive for the attack in the firs=
t
>> >> 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 woul=
d
>> >> 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 attempti=
ng to
>> >> normalize mempool policy (e.g.
>> >> https://lists.linuxfoundation.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 L=
2
>> >> 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 t=
he mempool 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/019=
074.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. A=
s
>> >> 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 service=
s
>> >> relying on zero confirmations) to check that this possible eventual
>> >> move to full RBF doesn=E2=80=99t present a problem for them. There co=
uld 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
>>
>>
>>
>> --
>> 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