[bitcoin-dev] The Pinning & Replacement Problem Set

[bitcoin-dev] The Pinning & Replacement Problem Set

[John Carvalho]

[-- 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 --]

Re: [bitcoin-dev] The Pinning & Replacement Problem Set

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Thu, Nov 02, 2023 at 08:58:36AM +0000, John Carvalho via bitcoin-dev wrote:
> 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.

Replacement cycling has nothing to do with full-rbf. You are being disingenuous
by bringing up your pet topic in relation to this exploit.

In fact, in the anchor channels case, it isn't even possible for the relevant
transactions to turn BIP-125 RBF off, as the 1 block CSV delay forces RBF to be
enabled.

Note that at the moment, the largest pool - AntPool - has full-RBF enabled.
Thus we have at least 40.1% of hash power mining with full-RBF:

AntPool: 28%
Binance Pool: 7.8%
Luxor: 2.5%
BTC.com: 1.8%


Obviously, the sane thing to do is design protocols that are made secure by
clear incentives, rather than vague hopes. Thats why I proposed OP_Expire, a
solution that does not rely on any particular mempool behavior. Indeed, it's a
solution that unlike the current mitigations relying on mempools, has good
resistance to mempool sybil attacks.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] The Pinning & Replacement Problem Set

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 6157 bytes --]

Hi John,

I think lightning and other second time-sensitive layers being hit by
safety issues whenever the blocks are full is common knowledge as the issue
is being described in the paper under the "forced expiration spam" issues
arising spontaneously within an environment with high block space demand. I
believe you have known variants of those issues with the "flood & loot"
style scenarios.

What is coming as a new problem with the novel replacement issues lay in
the fact that your counterparty channel might always defer the confirmation
of your honest on-chain spend, in a way which is compatible with miners
incentives.

While this has been commonized by the wide deployment of bip-125-style RBF
over network mempools, this ability has been always available to any party
reaching out directly to miners out-of-band with consensus-valid
transactions. In a world where miners are pseudonymous (as we're mostly
seeing today, not considering pools) miners motivated by maximizing their
satoshi-denominated income is a reasonable assumption in my opinion.

As an ecosystem beyond core to fix sustainably pinning and replacement
problems, and I agree with you here, we are stuck with a "between Scylla
and Charybdis" serious safety issue, I'm seeing the following options.
Matching yours, rephrasing in my own words to ensure correct understanding.

1. We can revert to a static world with no replacement-by-fee mechanism as
a widely deployed network policy.

I think in a world where miners are in competition you can always reach out
to them with out-of-band higher fees packages than available in their local
mempool.

2. We can design, implement and deploy policies to better capture
transaction-issuer intent on the way future spend candidates are allowed
(or not) to replace the current in-mempool transaction.

Sadly, I think with lightning and other second time-sensitive layers, there
is no "single" transaction-issuer intent, though you might have as many
intents that you have counterparties within your off-chain states, all with
competing interests.

3. We can remove all policy and let the network of nodes and the economic
ecosystem evolve on its own.

I think a lot of mempool policy in place is actually anti-DoS measures
which are protecting at least the lowest-performance full-nodes, and those
measures are the source of issues for pinning. "Pure" RBF sounds to me only
to make adversarial replacement issues worse (at least nversion=3-style
policy introduces some assumptions on max package size if widely deployed).

4. We can do nothing and let a fragmented mempool environment, where every
large lightning and bitcoin business have out-of-band relationships with
miners and pools to support their packages, with some service-level safety
agreements.

I think this option was weighted as a way to solve pinning issues at the
commitment and second-state level years ago by the lightning community,
though it was brushed aside as bringing rampant centralization of the
lightning network, where small lightning nodes might not have privileged
access to miners [0].

5. We can design and implement some magical consensus-change or alter the
processing requirements (bandwidth, CPU perf, I/O disk) of full-nodes on
the peer-to-peer network to align incentives between miners and lightning
and time-sensitive second-layers.

I think this option represents more or less what are the trade-offs of what
is discussed by the "reverse locktime" new bitcoin script opcode idea or
replacement cache at the mempool-level in core [1].

Best,
Antoine

[0] https://github.com/lightning/bolts/issues/783
[1] https://github.com/bitcoin/bitcoin/issues/28699

Le jeu. 2 nov. 2023 à 11:38, John Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> 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/>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7856 bytes --]