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’ll summarize what was discussed during the meeting but please 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 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’t
> 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’t 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’s lost funds went to the miner
> instead of the attacker isn’t of much comfort to the victim (other
> 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’ profit incentive rather than attempting 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 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 “evicttx” RPC to remove a transaction from the 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/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’t present a problem for them. There could well
> be engineering work required in advance of the possible change being
> made.
>
> Next week’s meeting
>
> Next week’s 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
>