Hi *,
TLDR: Yes, this post is too long, and there's no TLDR. If it's any
consolation, it took longer to write than it does to read?
On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev wrote:
> Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
> If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> consistent deprecation process w.r.t to policy rules heavily relied-on by
> Bitcoin users, if we do so let sets a precedent satisfying as many folks as
> we can.
One precedent that seems to be being set here, which to me seems fairly
novel for bitcoin core, is that we're about to start supporting and
encouraging nodes to have meaningfully different mempool policies. From
what I've seen, the baseline expectation has always been that while
certainly mempools can and will differ, policies will be largely the same:
Firstly, there is no "the mempool". There is no global mempool. Rather
each node maintains its own mempool and accepts and rejects transaction
to that mempool using their own internal policies. Most nodes have
the same policies, but due to different start times, relay delays,
and other factors, not every node has the same mempool, although they
may be very similar.
-
https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
Up until now, the differences between node policies supported by different
nodes running core have been quite small, with essentially the following
options available:
-minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
-mempoolexpiry - how long to keep txs in the mempool
-datacarrier - reject txs creating OP_RETURN outputs
-datacarriersize - maximum size of OP_RETURN data
-permitbaremultisig - prevent relay of bare multisig
-bytespersigop - changes how SIGOP accounting works for relay and
mining prioritisation
as well as these, marked as "debug only" options (only shown with
-help-debug):
-incrementalrelayfee - make it easier/harder to spam txs by only
slightly bumping the fee; marked as a "debug only" option
-dustrelayfee - make it easier/harder to create uneconomic utxos;
marked as a "debug only" option
-limit{descendant,ancestor}{count,size} - changes how large the
transaction chains can be; marked as a "debug only" option
and in theory, but not available on mainnet:
-acceptnonstdtxn - relay/mine non standard transactions
There's also the "prioritisetransaction" rpc, which can cause you to keep
a low feerate transaction in your mempool longer than you might otherwise.
I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
ones of those options commonly set, and those only rarely result in any
differences in the txs at the top of the mempool.
There are also quite a few parameters that aren't even runtime
configurable:
- MAX_STANDARD_TX_WEIGHT
- MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
- MAX_P2SH_SIGOPS (see also #26348)
- MAX_STANDARD_TX_SIGOPS_COST
- MAX_STANDARD_P2WSH_STACK_ITEMS
- MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
- MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
- MAX_STANDARD_P2WSH_SCRIPT_SIZE
- MAX_STANDARD_SCRIPTSIG_SIZE
- EXTRA_DESCENDANT_TX_SIZE_LIMIT
- MAX_REPLACEMENT_CANDIDATES
And other plausible options aren't configurable even at compile time
-- eg, core doesn't implement BIP 125's inherited signalling rule so
there's no way to enable it; core doesn't allow opting out of BIP 125
rule 3 ratchet on absolute fee; core doesn't allow CPFP carveout with
more than 1 ancestor; core doesn't allow opting out of LOW_S checks
(even via -acceptnonstdtxn); etc.
We also naturally have different mempool policies between different
releases: eg, expansions of policy, such as allowing OP_RETURN or
expanding it from 40 to 80 bytes or new soft forks where old nodes won't
relay transactions that use the new; and also occassional restrictions
in policy, such as the LOW_S requirement.
While supporting and encouraging different mempool polices might be new
for core, it's not new for knots: knots changes some of these defaults
(-permitbaremultisig defaults to false, -datacarriersize is reduced to
42), allows the use of -acceptnonstdtxn on mainnet, and introduces new
options including -spkreuse and -mempoolreplacement (giving the latter
full rbf behaviour by default). Knots also includes a `-corepolicy`
option to make it easy to get a configuration matching core's defaults.
I think gmaxwell's take from Feb 2015 (in the context of how restrictive
policy on OP_RETURN data should be) was a reasonable description for
core's approach up until now:
There is also a matter of driving competent design rather than lazy
first thing that works. E.g. In stealth addresses the early proposals
use highly inefficient single ECDH point per output instead
