From: John Carvalho <john@synonym•to>
To: Bitcoin-Dev Mailing List <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] The Pinning & Replacement Problem Set
Date: Thu, 2 Nov 2023 08:58:36 +0000 [thread overview]
Message-ID: <CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com> (raw)
In-Reply-To: <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
Good morning,
All layers and technologies "on" Bitcoin will fail in situations where
miners misbehave or the blocks & mempool remain consistently, overly full.
Consider this as a "law" of Bitcoin/blockchains.
In hindsight (for you, not me) it was very unwise to start messing with
mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought
a fragile harmony and utility to Bitcoin, which we were lucky to have for
as long as we could.
The engineers intentionally broke this. Mempoofullrbf washes away the
ability for users to express their intent on whether to pin or replace a
transaction, and now Lightning has BOTH pinning and replacement problems.
You could argue this was inevitable. The point here is that layers have
mempool and miner problems.
Core has a few choices here, as I see it:
1. They can try to revert mempoolfullrbf and re-establish first-seen
policy. Hard to say whether this would work, or whether it would be
enough...
2. They can create additional policies that are enforced by default that
allow people to flag how they want their txn handled, as in, a "pin this"
vs "replace this" aspect to every txn. This is probably the best option, as
it allows miners to know what people want and give it to them. This is
utility, thus incentive-compatible.
3. Remove all policy and let the market evolve to deal with the chaos.
Which is similar to the next option: do nothing.
4. Do nothing and allow a fractured mempool environment to evolve where
large businesses form private contracts with miners and pools to support
their own unsupported policies, so they can provide better experiences to
customers and users.
5. Invent some miracle magical crypto cure that I am not capable of
imagining at this time.
I disclaim some ignorance to details of how other mempool research might
affect these options and problems, but I am skeptical the dynamics
discussed here can be removed entirely.
--John Carvalho
CEO, Synonym.to <http://synonym.to/>
[-- Attachment #2: Type: text/html, Size: 2960 bytes --]
next parent reply other threads:[~2023-11-02 8:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
2023-11-02 8:58 ` John Carvalho [this message]
2023-11-02 15:42 ` Peter Todd
2023-11-03 19:57 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com' \
--to=john@synonym$(echo .)to \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox