policy: Enable full-rbf by default #28132
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
FYI mempool.space has enabled full-rbf by default, among many others. |
|
When you say "by default", do you mean that full-rbf would come by default as part of IBD or when you update Bitcoin Core? When would full-rbf be "by default"? |
This pull-req has nothing to do with Initial Block Download (IBD). It simply changes the default for the A significant fraction of the P2P network has already chosen to enable full-rbf, so full-rbf replacements propagate reasonably well. Almost half of pools by hash power has enabled full-rbf, so full-rbf replacements that reach those miners are readily mined, as seen on https://mempool.space/rbf#fullrbf and https://fullrbf.mempool.observer/ |
|
On the first line of arguments, I think zero-conf business acceptance have the option to deploy additional full-nodes with good transaction-relay peering to obtain a reasonable view of network mempools, and therefore increase their odds of seeing a double-spend of a confirmation of interest. In practice, zero-conf applications have risk threshold, once those thresholds are reached they will deactivate zero-conf acceptance. On the second line or arguments, mempool consistency with miners is becoming a practical concern in my opinion with the appereance of so-called “transaction accelerators”, as now LSPs can use those out-of-band transaction-relay service to fee-bump their stuck multi-party transactions, and therefore provoke a divergence with the rest of the network. I raised this risk of “mining income asymmetries due to unequal access in to transaction flows bypassing policies” in Suhas proposal to remove the mempoolfullrbf option months ago. On the third line of arguments about the enhancement of multi-party funded transactions flows, the original motivation is explained in this post on the lightning dev mailing list. RBF opt-out allows a counterparty contributing an input to block the confirmation of a multi-party transaction at minimal cost, therefore enabling a liquidity griefing at low-cost (size of the pinning tx * mempool min fee). Since then, early Lightning Service Providers deploying dual-funding have raised again the concern on the mailing list during May of this year, and how sustained RBF signaling flag opt-out can be an annoying vector of pinning attack. While from my understanding the issue might be solved on the Lightning-side by upcoming deployment of nversion=3 (where full-rbf is implied by the policy regime), this won’t solve the pinning issue for coinjoin multi-party transactions which are concerned too (and this is not sure that we’re deploying nversion=3 for the dual-funding/splicing flows due to package limits size). With that context in mind, full-rbf by default is a welcome deployment for second-layers and multi-party applications. On the deployment schedule, we’re still mid-26.0 schedule, so I think it’s reasonable to land it now (feature freeze scheduled for 2023-10-01 as of today July 24th). This still gives a period of roughly 5 months to zero-conf business and other software that would need to tweak their software. 37% of the hash power sounds a reasonable demonstration of the Bitcoin mining ecosystem selecting the transaction-relay policy favoring maximization of their mining income strategy. So I’m Concept ACK on this change, I still think this change deserves announcement on the mailing list and usual technical communication channels to warn ecosystem stakeholders impacted by the proposed change. |
|
I queried the explorer like this Only 4 of 6 mentioned transactions seem to be full-rbf, or was it a wrong request? |
DrahtBot
changed the title
|
On July 24, 2023 12:41:10 PM GMT+03:00, Pavel Vasin ***@***.***> wrote:
I queried the explorer like this
```
~ $ curl -s https://mempool.space/api/v1/block/0000000000000000000153159d7b95debfb0dadcd1040aaf9dbeb0025a1ddeac/audit-summary | jq .fullrbfTxs
[
"53cec64b52989c531550ac4606bedf1ff83d5bfd90efdc4006f122ac6b1b7643",
"5bc64344c56f847e2d992fab241567075473eec9423776afadc187299352bce1",
"64ec51dedd1404a775d590f530a01bbdc4239c8eb6d33ce4b9217ec2f0b8ddae"
]
```
Only 4 of 6 mentioned transactions seem to be full-rbf, or was it a wrong request?
mempool.space doesn't keep information about replacements indefinitely; after a certain amount of time it's deleted from their databases. All those transactions were created by my OpenTimestamps calendars, and I can assure you they are full-rbf replacements.
Lots more too: https://alice.btc.calendar.opentimestamps.org/ https://bob.btc.calendar.opentimestamps.org/
|
There was a problem hiding this comment.
Concept nACK
That's 37% of total hash power regularly mining full-rbf transactions.
I think this decision is premature and that is not enough for the current value to be changed, honestly. Still prefer it as opt-in instead of enabled by default ATM
Let's get this merged and this silly debate over with. Miners and node operators who choose to disable full-rbf still can with a simple configuration change.
Let's get this not merged and this silly debate over with. Miners and node operators who choose to enable full-rbf still can with a simple configuration change.
|
Concept ACK, but the description has some issues:
It was always invalid.
This is backward. Miners are incentivised to match nodes. Nodes shouldn't try to match miners. |
Reworded it to say "even more clearly invalid"
That's probably true for consensus changes. But this isn't a consensus change. For full-rbf 1) miners can run their own nodes, 2) sufficient full-rbf nodes are running that miners can fairly reliably receive full-rbf replacements. The status quo is already that full-rbf replacements are regularly mined and can be propagated with a little bit of work. This change merely accepts that fact, and (marginally) improves the propagation situation for small miners, and makes full-rbf more convenient to use for everyone else. |
|
Concept ACK. |
|
What happened to: "It's just opt-in"? |
|
On July 29, 2023 11:08:33 PM GMT+02:00, "Marius Kjærstad" ***@***.***> wrote:
What happened to: "It's just opt-in"?
~40% of hash power decided to opt-in. You opting out is meaningless once that has happened, because unconfirmed transactions are well and truly insecure. So might as well enable it by default.
Miners can still opt out if they choose. Though there's no reason not to.
|
|
@petertodd Why didn't any hash power opt-in to RBF back in 2015? |
|
On July 30, 2023 1:00:32 AM GMT+02:00, "Marius Kjærstad" ***@***.***> wrote:
@petertodd Why didn't any hash power opt-in to RBF back in 2015?
They did. I created a full-rbf patch years ago that some miners were running.
See also: https://petertodd.org/2016/are-wallets-ready-for-rbf
|
|
@petertodd Why didn't any hash power opt-in to RBF before you made that patch? |
|
Concept ACK There are no answers for questions that do not make sense. Also there are no arguments left against full RBF as it's used regularly. |
|
Replace by fee makes double spending easier and harm's Bitcoin's ability to be used as a currency in my opinion |
|
Concept ACK Enabling full-RBF by default removes remaining false sense of security |
Someone had to actually write the code of course. AFAIK I was the first (though as far as I know, rbf was first suggested by Satoshi). |
|
The fact RBF is possible already undermines the security of the mempool, which was already low, so having it on by default or not, the fact it exists already killed zero-conf a long time ago. |
I've posted a notice on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021823.html Thanks for the Concept ACK! |
|
First-seen-safe is good enough for grocery shopping. But don't let me disturb you while you strip away the utility of BTC. |
I'm not aware of any second layer protocols that are improved by having full-rbf more broadly available. |
petertodd
force-pushed
the
2023-07-enable-full-rbf
branch
from
7a1289b to
c205461
Compare
petertodd
force-pushed
the
2023-07-enable-full-rbf
branch
from
c205461 to
512278e
Compare
This is good information to have. I’ll recall the original motivation which was behind introducing I’ll observe that since then collaborative transaction construction, the v2 open channel flow has been merged in lightning specification (bolt PR 851, so more and more multi-party application are at risk of being DoSed, if the associated full-node has a low-topology of Reviewed code change at 512278e. |
Yes, my Libre Relay implementation of replace-by-fee-rate always enables full-rbf as it's the other relevant transaction pinning vector. And while Core intends to ship V3 transactions, it's a very narrow transaction pinning mitigation. For example, it does nothing to help
Agreed.
Thanks! You might want to formally Tested ACK it so the bot picks it up. |
|
I saw also my previous comment was counted wrong. But this fixes it: Tested ACK |
There was a problem hiding this comment.
Tested ACK 512278e
Manual mutation testing with following diff:
diff --git a/src/kernel/mempool_options.h b/src/kernel/mempool_options.h
index 4e1e24a11d..0850b2e60e 100644
--- a/src/kernel/mempool_options.h
+++ b/src/kernel/mempool_options.h
@@ -22,7 +22,7 @@ static constexpr unsigned int DEFAULT_BLOCKSONLY_MAX_MEMPOOL_SIZE_MB{5};
/** Default for -mempoolexpiry, expiration time for mempool transactions in hours */
static constexpr unsigned int DEFAULT_MEMPOOL_EXPIRY_HOURS{336};
/** Default for -mempoolfullrbf, if the transaction replaceability signaling is ignored */
-static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{true};
+static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{false};
/** Whether to fall back to legacy V1 serialization when writing mempool.dat */
static constexpr bool DEFAULT_PERSIST_V1_DAT{false};
/** Default for -acceptnonstdtxn */
diff --git a/test/functional/mempool_accept_v3.py b/test/functional/mempool_accept_v3.py
index 5e722724b9..6f11683a9c 100755
--- a/test/functional/mempool_accept_v3.py
+++ b/test/functional/mempool_accept_v3.py
@@ -162,7 +162,6 @@ class MempoolAcceptV3(BitcoinTestFramework):
self.check_mempool([tx_v3_bip125_rbf_v2["txid"], tx_v3_parent["txid"], tx_v3_child["txid"]])
- @cleanup(extra_args=["-mempoolfullrbf=0"])
def test_v3_bip125(self):
node = self.nodes[0]
self.log.info("Test v3 transactions that don't signal BIP125 are replaceable")
On analyzing tangential mempool behaviors hypothetically affected by setting mempoolfullrbf=1 by default:
(a) Wtxid: nsequence signaling is encompassed both in txid and wtxid. After this change and assuming reboot a local mempool can re-accept a bip125 opt-out transaction previously rejected as identical non-witness data might not have change, yet the wtxid being different.
(b) Mempool.dat / persistence: the dump of mempool transaction. Dump of transactions are expected to be altered with mempoolfulrbf=1 as bip125 opt-out transactions are expected to be accepted with this change.
(c) Datacarrier: one op_return data carrying output. The data carriage is implemented in the scriptpubkey while the signaling rbf mechanism is implemented in one of the input. There is no effect expected on data carriage mempool acceptance, unless very exotic usage of sighash malleability, where the txid can be altered yet the hash of the op_return scriptpubkey stays identical.
(d) Dust: the dust satoshi threshold. The dust check is implemented on the output amounts while the signaling rbf mechanism is implemeted in one of the input. There is no effect expected on data carriage mempool acceptance, unless very exotic usage of sighash malleability, where the txid can be altered yet the hash of one of the output amount under the dust threshold stays identical.
(e) Mempool expiry: by default after 14 days transactions are sorted out. Transactions accepted under mempoolfullrbf=0 and still in the mempool until reaching expiration could be replaced by an opt-out transactions. I think this a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.
(f) Mempool limits / RBF carve-out. When mempool limits are reached out (25 descendants), there is an exemption to get one more child to be connected on the parent. As bip125 inheritance is not implemented in core, the one more opt-out child could be re-accepted in the mempool. I think this is a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.
(g) Package initial acceptance / RBF. In-mempool packages are submitted to descendants and ancestors limits. As bip125 inheritance is not implemented in core, a subset of child could be re-accepted in the mempool. I think this is a transient risk of double-spend during the deployment of mempoolfullrbf=1 as a default.
(h) Mempool Reorg. Signaling mechanism is implemented on the nSequence field. In case of chain reorgs, the pool of disconnected transactions can be re-added in mempool. There is no effect expected on disconnected transactions re-acceptance.
(i) Mempool sigops limits. Script sig ops limits are evaluated on the scriptSig / witness spend. This mempool limit check only happens once a transaction is good for acceptance and scripts have to be validated. An opt-out transaction can be accepted for the same sig ops budget, I think this a transient genuine risk of opportunistic full-node ressource consumption during the deployment of mempoolfullrbf=1 as a default.
(j). Mempool unbroadcast. Transaction delivery is ensured by re-broadcasting transactions until a GETDATA is received. After this change and assuming reboot a local mempool can re-accept a bip125 opt-out transaction previously rejected
and keep re-announcing this transaction to non-upgraded peers, provoking a free transaction relay bandwidth. I think this a transient minor risk of bandwidth ressource denial-of-service during the deployment of mempoolfullrbf=1 as a default.
petertodd
force-pushed
the
2023-07-enable-full-rbf
branch
from
512278e to
fbdc61e
Compare
|
Thank everyone for your participation in this discussion and review of this pull request so far. However the comments section here has become difficult to follow due to numerous off-topic comments, a few personal disagreements, and repetition of arguments. In the interest of having a more productive and focused technical and philosophical discussion we are going to close and lock this PR. @petertodd: We strongly encourage you to open a new pull request for this proposal, as the intention of closing this is not to close down the change request itself, but rather make the commentary easier to follow, and more on-topic, for fellow reviewers and contributors. In the new PR, please do link to this current PR (#28132) for historical context, this will ensure we do not lose the link between useful review and discussion which has already taken place here, in the new PR. Contributors: When the new PR is opened, please keep the discussion focused on technical aspects, avoid personal attacks, and refrain from repeating arguments without adding new information. This will help maintain a more constructive and efficient review process. This action is in line with our moderation guidelines, which aim to keep discussions on-topic, respectful, and constructive. |
The following pools are have enabled full-rbf:
...and others. The above list is 90%+ of total hash power.
Frankly, I can't think of another time in Bitcoin's history where a supermajority of hash power had chosen to change Bitcoin Core's default mempool policy in the same way.
Enabling full-RBF by default is well overdue. Miners have chosen to mine it on a large scale, it simplifies mempool logic, and it makes certain types of DoS attacks on multiparty protocols significantly more expensive so there's no reason to continue to try to prevent full-RBF replacements from getting to miners.