Squeezed in one last blog post for 2023... Happy New Years! 🎊

“We as a community should ask how such an inefficient proposal, with significant potential harm to mining decentralization, has managed to progress as far as it has”.

As you’re asking the questions, my comments. Fundamentally, there is a cultural issue in Bitcoin FOSS development where devs are incentivized to ship code (grants and other financial compensations are mostly based on what you deliver) and as such most devs found themselves trapped to be “nice” with their peers to get review and social support for their own code projects, and better appreciation when it’s coming the time to re-new their grants.

Doing adversarial analysis and calling to cut technical complexity after months of development, at the price of slowing down some people agendas (e.g with v3 txn LSPs wishing to five the public image that LN is “safe”), might slow down your FOSS engineering career progress, so most of Bitcoin devs won’t do it.

No one is to blame specifically. That said current Bitcoin development culture is deeply concerning for a multi-billion dollar worldwide project :thinking_face:

(And personally I did call to better analysis and design process of policy changes for l2s as early as mid-2021 https://bitcoinops.org/en/newsletters/2021/05/19/).

"Since a typical anchor-output using Lightning channel takes 2x more block space, a large miner could easily offer out-of-band fee payments at, say, a 25% discount, giving them a substantial 25% premium over their smaller competitors. Given that mining pool fees are highly competitive, on the order of 1% or 2%, being able to earn a 25% premium over your competitors is an enormous advantage. With Lightning, offering this as a service in an automated, convenient, way would be quite easy to implement.”

To the best of my knowledge, this is the first time the potential impact of fee-bumping techniques on miner competitiveness has been raised as a limitation of V3 policy format (even if I did raised doubts on the full anti-pinning efficiency, as we as a community don’t understand enough pinning attacks in my opinion).

Fee-bumping techniques comparison have been done in the past (before V3 policy): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html

Zooming out, I think this discussion comes still as an aftermath of the conversation of last year on the design philosophy of policy changes in the context of full-rbf, where we never yield practical design goals that transaction-relay or mempool policy should ideally respect (e.g miner decentralization equilibrium, liquidity efficiency asymmetry among use-cases, L2s security risks): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html