Page MenuHomePhabricator

change default -blockmintxfee to 0
AbandonedPublic

Authored by markblundeberg on Jan 11 2020, 14:48.

Details

Reviewers
deadalnix
Group Reviewers
Restricted Project
Summary

Under abnormal circumstances, it can happen that a transaction is accepted
into the mempool paying a feerate below 1 sat per byte (or below
1 sat per virtualbyte).

We want that these transactions can be eventually mined, since they may have
unconfirmed children which are being relied on (and the unconfirmed children
might not pay enough for CPFP). Unfortunately if the default is (as now)
-blockmintxfee= 1000 sat/kB then we can guess that no miner will mine them:
some miners increase -blockmintxfee above the default, but I haven't heard
of any that decrease it voluntarily.

Assuming such transactions are well distributed in the network, including
them won't introduce much orphan risk due to the fast block propagation
mechanisms and tx validation caching. And since the circumstances of
low-fee transactions are rare, this doesn't introduce significant damage
to miner profitability, but it can help the network function better.

Here are some possible circumstances why a lowfee tx could be in mempool:

  • When a reorg occurs all transactions get thrown back into the mempool, bypassing the normal fee limits. This may include some lowfee transactions.
  • Virtualsize may be introduced in a way that does not impact the relaying threshold (1 sat/byte). As a result, nodes may accept transactions below 1 sat/vbyte, provided they are at least 1 sat/byte. If -blockmintxfee refers to the sat/vbyte threshold, then they might not ever get mined.
  • Some kind of new mechanism may be introduced where < 1 sat/byte transactions can be pulled out of the orphan pool, provided their children pay enough fee. This does not exist right now, but if the children were later invalidated then the lowfee parent may be all alone in the mempool.
  • Mempool reconciliation algorithms may be introduced that result in a node accepting a low fee transaction just because of peer pressure, even though it wouldn't normally do so.
Test Plan

ninja check-all

Diff Detail

Repository
rABC Bitcoin ABC
Branch
blockmintxfee
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8859
Build 15693: Default Diff Build & Tests
Build 15692: arc lint + arc unit

Event Timeline

deadalnix requested changes to this revision.Jan 11 2020, 16:27

Over the 4 reasons given, 2 are vry clearly bogus:

When a reorg occurs all transactions get thrown back into the mempool, bypassing the normal fee limits. This may include some lowfee transactions.

That one is self defeating, because someone clearly mined that tx.

Mempool reconciliation algorithms may be introduced that result in a node accepting a low fee transaction just because of peer pressure, even though it wouldn't normally do so.

The whole pipeline would most likely have to be reworked to make that work, so this is irrelevent.

Other are not clear to me.

Virtualsize may be introduced in a way that does not impact the relaying threshold (1 sat/byte). As a result, nodes may accept transactions below 1 sat/vbyte, provided they are at least 1 sat/byte. If -blockmintxfee refers to the sat/vbyte threshold, then they might not ever get mined.

Using a mix a vbyte and bytes to charge is going to be bound to create a lot of problems down the road. It's complexity for little to no gain.

Some kind of new mechanism may be introduced where < 1 sat/byte transactions can be pulled out of the orphan pool, provided their children pay enough fee. This does not exist right now, but if the children were later invalidated then the lowfee parent may be all alone in the mempool.

That doesn't really seems like a big problem, considering the txns got in there because of the child to begin with.

In general, you'd want to patch to solve a problem. It is unclear here what that problem is.

This revision now requires changes to proceed.Jan 11 2020, 16:27

In general, you'd want to patch to solve a problem. It is unclear here what that problem is.

Yeah the immediate reason for coming up with this now was https://reviews.bitcoinabc.org/D4903?id=15339#inline-30002, however, it made me realize there is a general principle here that we should follow:

  • "If a transaction can end up in everyone's mempool under default settings, then it ought to be mineable under default settings".

In other words, phrasing the problem: "We don't want a situation where everyone has a tx in their mempools but nobody mines it". In the benign case (like now) this problem would mean that after a reorg, there might be a few stuck transactions that eventually expire. But alternatively, a bug in ATMP might happen where people can broadcast unlimited numbers of unmineable transactions, which would let them inflate the mempool.

Going to drop this from my queue for now, but I still think it's worth considering in future.