…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.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Conflicts
Reviewers, this pull request conflicts with the following ones:
#28676 ([WIP] Cluster mempool implementation by sdaftuar)
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.
petertodd
commented at 3:49 pm on July 23, 2023:
contributor
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”?
petertodd
commented at 9:44 pm on July 23, 2023:
contributor
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 -mempoolfullrbf option to true/enabled. Previously the default was false/disabled. Users who update Bitcoin Core to a version containing this change would by default propagate and mine full-rbf replacements unless they had chosen to disable full-rbf.
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/
ariard
commented at 11:51 pm on July 23, 2023:
member
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.
recursive-rat4
commented at 9:40 am on July 24, 2023:
none
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.
jaonoctus
commented at 6:41 pm on July 24, 2023:
none
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.
luke-jr
commented at 6:53 pm on July 25, 2023:
member
Concept ACK, but the description has some issues:
Obviously, with this much support of full-rbf, arguments against it on the basis that unconfirmed transactions are safe are now invalid.
It was always invalid.
Secondly, on the basis of mempool consistency with miners, since full-rbf is the compatible policy in almost all cases, we should be supporting it by default if you take the position that we want to optimize for consistency with miners.
This is backward. Miners are incentivised to match nodes. Nodes shouldn’t try to match miners.
petertodd
commented at 10:14 am on July 26, 2023:
contributor
Concept ACK, but the description has some issues:
Obviously, with this much support of full-rbf, arguments against it on the basis that unconfirmed transactions are safe are now invalid.
It was always invalid.
Reworded it to say “even more clearly invalid”
Secondly, on the basis of mempool consistency with miners, since full-rbf is the compatible policy in almost all cases, we should be supporting it by default if you take the position that we want to optimize for consistency with miners.
This is backward. Miners are incentivised to match nodes. Nodes shouldn’t try to match miners.
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.
DrahtBot added the label
CI failed
on Jul 29, 2023
hsjoberg
commented at 11:02 am on July 29, 2023:
contributor
Concept ACK.
This is helpful for second layer protocols, including Lightning.
sandakersmann
commented at 9:08 pm on July 29, 2023:
contributor
What happened to: “It’s just opt-in”?
petertodd
commented at 9:44 pm on July 29, 2023:
contributor
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.
sandakersmann
commented at 11:00 pm on July 29, 2023:
contributor
@petertodd Why didn’t any hash power opt-in to RBF back in 2015?
petertodd
commented at 11:50 pm on July 29, 2023:
contributor
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.
@petertodd Why didn’t any hash power opt-in to RBF before you made that patch?
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).
SparK-Cruz
commented at 2:09 pm on July 30, 2023:
none
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.
petertodd
commented at 3:52 pm on July 30, 2023:
contributor
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.
Replace by fee makes double spending easier and harm’s Bitcoin’s ability to be used as a currency in my opinion
RBF also allows people to be more frugal with their fee estimates as they can bump more easily if necessary - this certainly helps bitcoin’s ability to be used a currency.
Moreover, it has never been appropriate to rely on unconfirmed transactions. Maintaining an illusion (that transactions that aren’t in the blockchain can be relied upon) is not something worth attempting by frustrating RBF.
pokkst
commented at 1:22 am on July 31, 2023:
none
This entire discussion is pointless since Core won’t listen to any feedback and will proceed with their centralized development and decision making process.
ajtowns
commented at 5:44 am on July 31, 2023:
contributor
This replaced 87f20bf4a8b71a255e47876ca7563cdcab1a830490a1b130bbe71c28d8da3884 which had a 3.14sat/vb feerate. statoshi reported minfees up to 3.09sat/vb in the period between the original propagating and the replacement being mined.
This replaced e17630b903e9fb5bd4c6083297c25572417c0261e9a0c55ef2cde2b2a7be6523 at 3.14sat/vb; during the time between the original propagating and the replacement being mined, statoshi’s minfee was dropping from 3.1sat/vb to 1.2sat/vb.
This replaced 844a0d2caf3488e20a4befcb7e581e5d849f2eb3581d5dddbfe2ac2412a9631f which had a 3.14sat/vb feerate. statoshi reported a minfee of 3.09sat/vb around the time the original tx propogated.
This replaced 0075cfc555ac5431438c72b616af69a27496fb71e5dbdfa40f3d4520df19e97e also at 3.81sat/vb; statoshi reports a minfee reaching 3.9sat/vb over the period between the original tx propagating and the replacement being mined.
This replaced 353be845e9019ac975981433672e8ff56032f599fe48ec1bd4ed968ea95949cc at 3.14sat/vb; statoshi’s minfee over the 80 minutes between the original propagating and the replacement being mined was dropping from 3.4sat/vb to 2.2sat/vb then immediately rose again to 3.2sat/vb.
This replaced 6b59ab3d86b5110565faff8d1ae2e263c4b873e406f73a0ec92988f0d587f204 at 4.76sat/vb; statoshi reports a minfee of 4.5sat/vb dropping to 3.0sat/vb then rising back to 4.0sat/vb around this period.
As far as I can see, miners evicting the original txs from their mempool due to variations across the network in minfee values is a plausible explanation for all these replacements.
petertodd
commented at 7:53 am on July 31, 2023:
contributor
This replaced 87f20bf4a8b71a255e47876ca7563cdcab1a830490a1b130bbe71c28d8da3884 which had a 3.14sat/vb feerate. statoshi reported minfees up to 3.09sat/vb in the period between the original propagating and the replacement being mined.
This replaced e17630b903e9fb5bd4c6083297c25572417c0261e9a0c55ef2cde2b2a7be6523 at 3.14sat/vb; during the time between the original propagating and the replacement being mined, statoshi’s minfee was dropping from 3.1sat/vb to 1.2sat/vb.
This replaced 844a0d2caf3488e20a4befcb7e581e5d849f2eb3581d5dddbfe2ac2412a9631f which had a 3.14sat/vb feerate. statoshi reported a minfee of 3.09sat/vb around the time the original tx propogated.
This replaced 0075cfc555ac5431438c72b616af69a27496fb71e5dbdfa40f3d4520df19e97e also at 3.81sat/vb; statoshi reports a minfee reaching 3.9sat/vb over the period between the original tx propagating and the replacement being mined.
This replaced 353be845e9019ac975981433672e8ff56032f599fe48ec1bd4ed968ea95949cc at 3.14sat/vb; statoshi’s minfee over the 80 minutes between the original propagating and the replacement being mined was dropping from 3.4sat/vb to 2.2sat/vb then immediately rose again to 3.2sat/vb.
This replaced 6b59ab3d86b5110565faff8d1ae2e263c4b873e406f73a0ec92988f0d587f204 at 4.76sat/vb; statoshi reports a minfee of 4.5sat/vb dropping to 3.0sat/vb then rising back to 4.0sat/vb around this period.
As far as I can see, miners evicting the original txs from their mempool due to variations across the network in minfee values is a plausible explanation for all these replacements.
All of those transactions are taken from my OpenTimestamps calendars. My OTS calendars bump fees repeatedly, increasing the feerate by 1sat/vb with each replacement, starting at approximately the minimum relay fee. Every single one of those replacements is actually a long string of multiple replacements. mempool.space does not maintain replacement data beyond 24 hours or so; if you want to see live replacement data you can do to https://alice.btc.calendar.opentimestamps.org/ or https://bob.btc.calendar.opentimestamps.org/ and just click on any of the recently mined transactions to see mempool.space’s replacement history data on them. You can also see full-rbf replacements at https://mempool.space/rbf#fullrbf, which I linked above as well.
Please delete your comment as it is factually incorrect and misleading. Frankly I’m surprised that you are so unaware of current mempool policies in use by miners that you were unaware of the fact that full-rbf has been widely adopted.
Sjors
commented at 9:30 am on July 31, 2023:
member
The main benefit of this PR would be to undo the split in policy caused by adding this flag and widely advocating for it. I don’t think that’s just a fad at this point. However I’m inclined to wait a little bit longer, e.g. after the v26 release, to see if your observations are maintained and reproduced outside of OTS. The new mempool.space tracking is helpful here.
In the release notes we should remind wallet users to not (yet) stop using the RBF flag, because their peers may not reliably relay it.
Daniel600
commented at 10:13 am on July 31, 2023:
none
This would unnecessarily and extremely negatively impact merchants and users who choose to accept 0-conf while using mitigation tools like GAP600. This negative impact could be avoided by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs.
At GAP600 we continue to see strong use of our service for BTC we have seen circa 350k unique trx hash per month (over the last 3 months) requested to our platform. Our clients include - Coinpayments, Coinspaid and Changelly. Given the period of Mempool being full we have seen an increase a fee required in order to be approved by our platform for trx. This is not an insignificant use case and one which can be easily maintained as is.
We have not seen any impact of full RBF on double spend rates for our trxs which seems to put in large question the stated figure of 40% adoption by miners at such a rate of adoption we would expect to see a large increase in double spends. We expect once this setting become default this will greatly change the adoption of this service.
GAP600 model targets not to get it wrong and as such we are very sensitive to any double spend which we get wrong in predicting as we reimburse our clients. GAP600 is not a payment processor rather services payment processors, merchants and non custodial liquidity providers which service non-custodial wallets.
Sjors
commented at 10:45 am on July 31, 2023:
member
by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs.
Including the original outputs is not part of BIP 125. It’s not realistic to expect an entirely new complex RBF proposal, especially one that’s not incentive compatible for miners. It’s also something for the mailinglist.
We have not seen any impact of full RBF on double spend rates for our trxs
This does seem relevant. But it can be interpreted both ways: it could also mean your customers have no intention to double-spend you even though it became technically easier.
Opportunity makes a thief, but this default won’t change the opportunity by much. A thief needs software that will perform a double-spend without the RBF flag. Anyone making such software will know they need to either use preferential peering or publish it via a block explorer that supports full RBF.
Daniel600
commented at 11:16 am on July 31, 2023:
none
We have not seen any impact of full RBF on double spend rates for our trxs
This does seem relevant. But it can be interpreted both ways: it could also mean your customers have no intention to double-spend you even though it became technically easier.
Opportunity makes a thief, but this default won’t change the opportunity by much. A thief needs software that will perform a double-spend without the RBF flag. Anyone making such software will know they need to either use [preferential peering]or publish it via a block explorer that supports full RBF.
With FullRBF the risk factor increases significantly - currently 0-conf acceptance relies heavily on first seen rule, reasonable fee, and no ongoing attempt at a double spend - with FullRBF significantly adopted by miners non of those hold anymore and an attacker can double spend at any stage pre block inclusion
Sjors
commented at 11:31 am on July 31, 2023:
member
with FullRBF significantly adopted by miners
If @petertodd’s analysis above is correct, that’s already the case and this PR won’t change that.
This would unnecessarily and extremely negatively impact merchants and users who choose to accept 0-conf while using mitigation tools like GAP600. This negative impact could be avoided by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs.
At GAP600 we continue to see strong use of our service for BTC we have seen circa 350k unique trx hash per month (over the last 3 months) requested to our platform. Our clients include - Coinpayments, Coinspaid and Changelly. Given the period of Mempool being full we have seen an increase a fee required in order to be approved by our platform for trx. This is not an insignificant use case and one which can be easily maintained as is.
We have not seen any impact of full RBF on double spend rates for our trxs which seems to put in large question the stated figure of 40% adoption by miners at such a rate of adoption we would expect to see a large increase in double spends. We expect once this setting become default this will greatly change the adoption of this service.
GAP600 model targets not to get it wrong and as such we are very sensitive to any double spend which we get wrong in predicting as we reimburse our clients. GAP600 is not a payment processor rather services payment processors, merchants and non custodial liquidity providers which service non-custodial wallets
“first seen” isn’t ever safe, this is why bitcoin needs a blockchain in the first place. Relying on heuristics to make assumptions about safety outside of that perverts incentives horribly, some business being able to afford to purchase/generate the relevant data giving them an advantage over those just waiting for confirmations and using bitcoin itself for which there is as low a barrier of entry as possible.
Bitcoin is not obligated to follow a development path that maintains your business model and indeed would do well to make it unviable just as it would chain-anal companies.
jonathanbier
commented at 3:11 pm on July 31, 2023:
none
When I first read this, I did not understand what those links to https://mempool.space/ were, as I did not know, but they seem to have a new RBF feature. This RBF information then seems to go after a few days. Therefore I have provided some screenshots below so people can see the feature and it wont disappear. It shows that the transactions were replaced and that there was no RBF flag. I hope this helps.
Antpool
Binance Pool
kristapsk
commented at 5:35 pm on July 31, 2023:
contributor
2. Users who do care and want full-RBF to be off and rely on defaults not changing.
Users should check release notes before upgrading Bitcoin node. Various defaults changes from time to time, this won’t be the first time.
petertodd
commented at 3:05 pm on August 1, 2023:
contributor
Reposting my reply to this identical message on the mailing list:
On Mon, Jul 31, 2023 at 03:13:19AM -0700, Daniel Lipshitz wrote:
This would unnecessarily and extremely negatively impact merchants and users who choose to accept 0-conf while using mitigation tools like GAP600. This negative impact could be avoided by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs.
At GAP600 we continue to see strong use of our service for BTC we have seen circa 350k unique trx hash per month (over the last 3 months) requested to our platform. Our clients include - Coinpayments, Coinspaid and Changelly.
I checked, and Coinpayments and Coinspaid are both merchant processors. I could
not find any example of actual merchants using their platform accepting
unconfirmed payments. I also could not find any documentation on their websites
indicating unconfirmed transaction acceptance.
As for Changelly, their website says right on the front that “With an average
transaction speed of 5–40 minutes, we ensure you can swiftly take advantage of
market opportunities.” Obivously, 5 minutes is not an unconfirmed payment.
Additionally, I verified myself by doing test transactions with BIP125 disabled
and an adequate fee: unconfirmed payments are not accepted by Changelly. As
their exchange flow clearly says “Once BTC is confirmed in the blockchain,
we’ll start exchanging it to .”
You need to provide an genuine example of an actual merchant who accepts
unconfirmed transactions as payment, and actually relies on first-seen
behavior.
We have not seen any impact of full RBF on double spend rates for our trxs
Based on the above findings, this appears to be because you don’t actually have
any clients who rely on unconfirmed payments.
petertodd
commented at 3:10 pm on August 1, 2023:
contributor
On Sun, Jul 30, 2023 at 02:18:25PM -0700, Matt Corallo wrote:
This is helpful for second layer protocols, including Lightning.
I’m not aware of any second layer protocols that are improved by having full-rbf more broadly available.
@ariard provided an example above.
fjahr
commented at 8:03 pm on August 1, 2023:
contributor
Concept ACK
Daniel600
commented at 10:28 pm on August 1, 2023:
none
Your research is not thorough and reaches an incorrect conclusion.
As stated many times - we service payment processors and some merchants directly - Coinspaid services multiple merchants and process a significant amount of BTC they are a well known and active in the space - as I provided back in December 2022 a email from Max the CEO of Coinspaid confirming their use of 0-conf as well as providing there cluster addresses to validate there deposit flows see here again - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html - if this is not sufficient then please email support@coinspaid.com and ask to be connected to Max or someone from the team who can confirm Conspaid is clients of GAP600. Max also at the time was open to do a call, I can check again now and see if this is still the case and connect you.
That on its own is enough of a sample to validate our statistics.
I have also spoken to Changelly earlier today and they offered to email pro @ changelly.com and they will be able to confirm GAP600 as a service provider. Also please send me the 1 trx hash you tested and I can see if it was queried to our system and if so offer some info as to why it wasnt approved. Also if you can elaborate how you integrated with Changelly - I can check with them if that area is not integrated with GAP600.
As the architect of such a major change to the status of 0-conf transactions I would think you would welcome the opportunity to speak to business and users who actual activities will be impacted by full RBF becoming dominant.
Are you able to provide the same i.e emails and contacts of people at the mining pools who can confirm they have adopted FULL RBF ?
Reposting my reply to this identical message on the mailing list:
On Mon, Jul 31, 2023 at 03:13:19AM -0700, Daniel Lipshitz wrote: This would unnecessarily and extremely negatively impact merchants and users who choose to accept 0-conf while using mitigation tools like GAP600. This negative impact could be avoided by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs. At GAP600 we continue to see strong use of our service for BTC we have seen circa 350k unique trx hash per month (over the last 3 months) requested to our platform. Our clients include - Coinpayments, Coinspaid and Changelly.
I checked, and Coinpayments and Coinspaid are both merchant processors. I could not find any example of actual merchants using their platform accepting unconfirmed payments. I also could not find any documentation on their websites indicating unconfirmed transaction acceptance. As for Changelly, their website says right on the front that “With an average transaction speed of 5–40 minutes, we ensure you can swiftly take advantage of market opportunities.” Obivously, 5 minutes is not an unconfirmed payment. Additionally, I verified myself by doing test transactions with BIP125 disabled and an adequate fee: unconfirmed payments are not accepted by Changelly. As their exchange flow clearly says “Once BTC is confirmed in the blockchain, we’ll start exchanging it to .” You need to provide an genuine example of an actual merchant who accepts unconfirmed transactions as payment, and actually relies on first-seen behavior.
We have not seen any impact of full RBF on double spend rates for our trxs
Based on the above findings, this appears to be because you don’t actually have any clients who rely on unconfirmed payments.
petertodd
commented at 1:29 am on August 2, 2023:
contributor
On Tue, Aug 01, 2023 at 03:28:31PM -0700, Daniel Lipshitz wrote:
Your research is not thorough and reaches an incorrect conclusion.
As stated many times - we service payment processors and some merchants directly - Coinspaid services multiple merchants and process a significant amount of BTC they are a well known and active in the space - as I provided back in December 2022 a email from Max the CEO of Coinspaid confirming their use of 0-conf as well as providing there cluster addresses to validate there deposit flows see here again - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html - if this is not sufficient then please email @.*** and ask to be connected to Max or someone from the team who can confirm Conspaid is clients of GAP600. Max also at the time was open to do a call, I can check again now and see if this is still the case and connect you.
That on its own is enough of a sample to validate our statistics.
I have also spoken to Changelly earlier today and they offered to email pro @ changelly.com and they will be able to confirm GAP600 as a service provider. Also please send me the 1 trx hash you tested and I can see if it was queried to our system and if so offer some info as to why it wasnt approved. Also if you can elaborate how you integrated with Changelly - I can check with them if that area is not integrated with GAP600.
As the architect of such a major change to the status of 0-conf transactions I would think you would welcome the opportunity to speak to business and users who actual activities will be impacted by full RBF becoming dominant.
Are you able to provide the same i.e emails and contacts of people at the mining pools who can confirm they have adopted FULL RBF ?
FYI I replied to this on the mailing list. It’s rather silly to duplicate this
entire conversation both here and the bitcoin-dev mailing list.
0xB10C referenced this in commit
42aa269f6f
on Aug 2, 2023
Daniel600
commented at 10:29 am on August 2, 2023:
none
A clear and open method to research the adoption of full RBF would look something like this and could easily be done -
Create 20 trxs (larger numbers better) in between every block and after 30 seconds try replace them.
Run this test for at least a few hours preferably more than 24 hours or even a few days.
See results of how many were replaced.
Ignore trx results if trx are included in blocks before replace trxs are published.
Have other Bitcoin Core developers independently implement and review the test results
Based on a test like this or something similar it would be reliable to get to an assessment of the adoption of full RBF.
in
test/functional/feature_rbf.py:32
in
024403e95doutdated
brandonblack
commented at 3:40 pm on August 2, 2023:
Might be better to add a comment above line 29 a la
0# both nodes disable full-rbf to test BIP125 signaling
and then change the comment on line 38 to
0# second node has default mempool limits
petertodd
commented at 12:04 pm on August 3, 2023:
Thanks! Good idea; fixed.
brandonblack
commented at 3:43 pm on August 2, 2023:
none
utACK024403e95d76f824c58851d84468c693bf0cbeae
petertodd force-pushed
on Aug 3, 2023
YellowRoseCx
commented at 5:06 pm on August 3, 2023:
none
What’s the root cause that makes a transaction need Replace-by-fee in the first place? Can we fix that?
RBF is a feature for consenting adults. If you don’t want to participate in it, you don’t need to.
Your passion for it isn’t a reason to force others into using it in transactions by default that don’t involve you.
ariard
commented at 11:14 pm on August 3, 2023:
member
MajesticBank
commented at 4:41 pm on August 4, 2023:
none
With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
Maybe that’s the thing we don’t like in this proposal?
Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
YellowRoseCx
commented at 5:08 pm on August 4, 2023:
none
With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
Maybe that’s the thing we don’t like in this proposal?
Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceries?
To quote the whitepaper:
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
Making miners ignore the “chronological order of transactions” by default converts them all into dishonest attackers, which would break the system completely.
“If a miner sees a broadcast double spend of a confirmed transaction that would result in fees higher than the expected cost of forking the chain, miners implementing the RBF policy completely would then start work on forking the chain from that point. And as they would all do it simultaneously, this would then incentivise broadcasts of yet more double spends against already confirmed transactions that have only tiny fee increases — but as miners are working on a rewrite of the timeline anyway, it costs them nothing to go back and include other double spends as well.” -Mike Hearn
“It’s OK to accept 0-conf transactions if you can reverse whatever it is you’re doing for the buyer, or if you know the buyer’s identity and can therefore legally attack them for fraud if they reverse the transaction. " - Theymos
petertodd
commented at 5:14 pm on August 4, 2023:
contributor
With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
That is correct. The BIP125 flag is a way to distinguish transactions from different wallets, and Chainanalysis certainly makes use of this. Deployment of Full-RBF would eliminate the need for any wallet to set BIP125 flags, allowing all wallets to eventually transition to having identical characteristics.
Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.
FYI I still have not been able to find a single example of an online service that actually accepts unconfirmed transactions in exchange for something of value, relying on first-seen behavior.
If someone knows of such a service, they should reply in this thread with the URL.
ekzyis
commented at 7:53 pm on August 4, 2023:
none
How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceries?
Why is there no mention of the Lightning Network in this thread? Users should use the Lightning Network for instant payments which are also cheaper than onchain.
To quote the whitepaper:
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
“Computational proof of the chronological order of transaction” just means that computational proof is required to generate consensus which transactions happened before others hence the term timechain. This is enough to solve the double-spend problem. Everyone just needs to agree in which order transactions happened. It does not mean that the first-seen transaction has to be included in the blockchain.
“If a miner sees a broadcast double spend of a confirmed transaction that would result in fees higher than the expected cost of forking the chain, miners implementing the RBF policy completely would then start work on forking the chain from that point. And as they would all do it simultaneously, this would then incentivise broadcasts of yet more double spends against already confirmed transactions that have only tiny fee increases — but as miners are working on a rewrite of the timeline anyway, it costs them nothing to go back and include other double spends as well.” -Mike Hearn
Every miner would mine their own block simultaneously in that case. So every miner would be on their own. Hence it makes more sense to keep mining the longest chain since that’s the only way to generate consensus. If you fork the chain because you think that makes you more money, the same reasoning applies to other miners. Why would they accept your chain? They would just also mine their own chain.
At the end, bitcoin wouldn’t work like this so any miner which attempts this would quickly realize they are actually losing money, not making more money.
YellowRoseCx
commented at 3:23 am on August 5, 2023:
none
Those are good points but as for the first, my honest answer is because I
think it’s complicated to use unless you use centralized or trust based
services which is completely against the Bitcoin ethos imo. Even though LN
uses the same currency/coin(bitcoin) as the Bitcoin Network, using it is
not actually using Bitcoin unless you’re opening or closing channel. I’ve
been using bitcoin for over a decade and imo unless I can look up my
transaction on the Bitcoin blockchain connected to my BTC node, then I
don’t consider it a Bitcoin transaction. It’s like using a wrapped bitcoin
on a different network.
I had asked this question a little further up, but instead of focusing on
transaction recovery from the mempool, why not focus efforts on reducing
the need for Replace by Fee to begin with? If the root cause of what’s
causing some transactions to need to be replaced is addressed, then
wouldn’t that be better long-term?
On Fri, Aug 4, 2023, 2:53 PM ekzyis @.***> wrote:
How long do you want Bitcoin users to stand waiting in a store before they
can leave with their groceries?
Why is there no mention of the Lightning Network in this thread? Users
should use the Lightning Network for instant payments which are also
cheaper than onchain.
To quote the whitepaper:
In this paper, we propose a solution to the double-spending problem using
a peer-to-peer distributed timestamp server to generate computational proof
of the chronological order of transactions. The system is secure as long as
honest nodes collectively control more CPU power than any cooperating group
of attacker nodes.
“Computational proof of the chronological order of transaction” just means
that computational proof is required to generate consensus which
transactions happened before others hence the term timechain. This is
enough to solve the double-spend problem. Everyone just needs to agree in
which order transactions happened. It does not mean that the first-seen
transaction has to be included in the blockchain.
“If a miner sees a broadcast double spend of a confirmed transaction that
would result in fees higher than the expected cost of forking the chain,
miners implementing the RBF policy completely would then start work on
forking the chain from that point. And as they would all do it
simultaneously, this would then incentivise broadcasts of yet more double
spends against already confirmed transactions that have only tiny fee
increases — but as miners are working on a rewrite of the timeline anyway,
it costs them nothing to go back and include other double spends as well.”
-Mike Hearn
Every miner would mine their own block simultaneously in that case. So
every miner would be on their own. Hence it makes more sense to keep mining
the longest chain since that’s the only way to generate consensus. If you
fork the chain because you think that makes you more money, the same
reasoning applies to other miners. Why would they accept your chain? They
would just also mine their own chain.
At the end, bitcoin wouldn’t work like this so any miner which attempts
this would quickly realize they are actually losing money, not making more
money.
After reading your blog posts and thinking about it for the day, I’ve got some questions about it if you don’t mind.
One of the issues you write about is when a CoinJoin input is spent before the round is complete causing nodes to see the non-coinjoin transaction first. When this happens, why wouldn’t nodes then reject that second transaction with spent inputs instead of letting it sit in the mempool? Or if nodes can do this, remove the spent input and associated output from the transaction so the rest of the unspent inputs go through as fast as the CoinJoin multiparty Tx fee lets them. Has there ever been discussion of using cryptographic proofs of transactions sent between nodes/wallets to determine if a coin input has already been submitted to the blockchain and using that to reject “double-spends” of that coin(unless the transactions are marked for with ability to be replaced)? I’d think that would stop the issue of double spent coins in CoinJoins/multiparty transactions causing it to be stuck in the mempool for a long time
After reading your blog posts and thinking about it for the day, I’ve got some questions about it if you don’t mind. One of the issues you write about is when a CoinJoin input is spent before the round is complete causing nodes to see the non-coinjoin transaction first. When this happens, why wouldn’t nodes then reject that second transaction with spent inputs instead of letting it sit in the mempool?
In a decentralized system there is no way to reliably know which transaction is in fact the second.
Or if nodes can do this, remove the spent input and associated output from the transaction so the rest of the unspent inputs go through as fast as the CoinJoin multiparty Tx fee lets them. Has there ever been discussion of using cryptographic proofs of transactions sent between nodes/wallets to determine if a coin input has already been submitted to the blockchain and using that to reject “double-spends” of that coin(unless the transactions are marked for with ability to be replaced)? I’d think that would stop the issue of double spent coins in CoinJoins/multiparty transactions causing it to be stuck in the mempool for a long time
Look, given that no-one can provide actual examples of services accepting unconfirmed transactions, there is no reason to waste engineering effort for a totally broken, insecure, “feature” that essentially no-one is actually using. Especially when it causes harm to other use-cases like coinjoins that are very widely used. It’s a fact that double-spending unconfirmed transactions is very easy. That’s not going to change.
petertodd
commented at 10:22 am on August 8, 2023:
contributor
NACK
Clearly, some are going to be adversely affected by this PR if it gets merged.
Citation needed.
You need to provide actual examples of services that are going to be negatively affected. Simply claiming that is not enough. No-one has provided such examples in this pull-req or on the bitcoin-dev mailing list.
Daniel600
commented at 12:25 pm on August 8, 2023:
none
For accuracy purposes GAP600 supports a range of clients who use 0-conf for their end users in a range of applications - including gaming/gambling, instant crypto swops, and Forex. All industries which take their privacy very seriously. GAP600 has provided email quotes and root addresses (here and in the mailing list) in order to validate this claim for this signifiant market.
You have accused GAP600 and myself of outright lying, based on your perceived understanding of how GAP600 should run its business, and based on your assumed understanding of how our clients should choose to share their data (in public forums which are not known for civil discourse or action). That is your prerogative.
I have asked some of our clients to share direct feedback, up to their comfort level. I am not sure if they will choose to do so.
Your mistake here, is the mistake of all central planners who assume they are able to understand and plan the market. This proposal will result in a major protocol change as to how Bitcoin has always run since genesis, and a major negative impact on a market sector which actually uses Bitcoin for commerce.
With this market impact being waved away based on your assumptions.
NACK
Clearly, some are going to be adversely affected by this PR if it gets merged.
Citation needed.
You need to provide actual examples of services that are going to be negatively affected. Simply claiming that is not enough. No-one has provided such examples in this pull-req or on the bitcoin-dev mailing list.
MajesticBank
commented at 4:43 pm on August 8, 2023:
none
#1 At this point I will assume Daniel600 is not just spreading lies but obviously pressured / paid to promote lower privacy on bitcoin blockchain.
There is no service on internet that accept 0-conf bitcoin transaction, end.
I have 10 years experience in this industry and running crypto-instant swap exchange for 2+ years https://majesticbank.sc/
Made over 500,000+ transactions using Coinpayments, Coinspaid and Changelly + fixedfloat, changenow and many more instant-swap sites, no service ever accepted 0-conf payments, his claims are so much full of FUD, it’s unbearable.
Maybe there is a different reason he doesn’t like this, so better be honest man, because this is non-sense.
#2 Pseudonymity (at first was anonymity) for bitcoin is a lie.
Your addresses might not interact on blockchain at all, but the software, wallet you use to make them can tell a lot about you and link them together. Version of transaction, which address type are you using, your average(usual) fee and in this case LockTime.
Having so many address type is obvious bummer for privacy, which we can’t affect that but obviously locktime is something we can do about.
(not considering pool thing as I don’t deeply )
#3 Users can’t make decision on their own, when they don’t understand technology and blockchain, if they understood what are we discussing here they would definitely want rbf by default.
It’s more comfortable for them, so they can later increase fee, specially when bitcoin congestion happens every few days.
Like it happened today, better bitcoin-core picking of estimate fee to follow and services should update to automatically update to higher fee in case end-user is waiting more then hour.
Bitcoin is coin that’s widely and this is improvement not a feature.
YellowRoseCx
commented at 6:04 pm on August 8, 2023:
none
You’d likely have to go back to 2016 or before , when RBF wasn’t added, to find the lists of merchants who accepted 0-conf transactions for smaller IRL transactions. A lot of merchants stopped accepting 0- conf when it was made easier to fraudulently cancel a transaction which has overall likely slowed down IRL merchant adoption and use, if not reversed it.
Users can’t make decision on their own
are you serious? “Bitcoin users are dumb and us devs know what’s best for them” is a real thought you believe?
ajtowns
commented at 6:46 am on August 9, 2023:
contributor
All of those transactions are taken from my OpenTimestamps calendars. My OTS calendars bump fees repeatedly, increasing the feerate by 1sat/vb with each replacement, starting at approximately the minimum relay fee.
Yes, that is a pretty perfect mechanism if you want to create a false positive for “full rbf” when all you’re actually triggering is eviction from the mempool due to a change in minfee. For nodes that don’t run “full rbf”, they’ll see one of the early transactions, add it to the mempool, then ignore any replacements for a while, until their local minfee drops below the original transaction, at which point they’ll accept the first replacement they see. Presuming that takes a while, that replacement will then have a high fee, and be included in their templates. That matches all the examples you gave.
It does not match some recent txs mined by antpool, though: eg b4a8d9… at 17.1sat/vb seems to have been mined in the first block that any of its alternatives paid sufficiently for, and there doesn’t seem to be any indication that the minfee should have risen above even the fee of the initial alternative (a6f344845e58d6ef288870b37674942d0505d9ee64f0d289164c3f401be8c086) at 5.98sat/vb (statoshi’s graphs indicate a max minfee around that time of 5.6sat/vb).
All of the data being linked here (the OTS webpages, fullrbf.mempool.observer and mempool.space) remove that data after at most a couple of weeks which makes it pretty difficult to review. I’ve made some custom patches to bitcoind to make it easier for me to double check your claims, but that’s not convenient or easily reproducible by others either.
Please delete your comment as it is factually incorrect and misleading. Frankly I’m surprised that you are so unaware of current mempool policies in use by miners that you were unaware of the fact that full-rbf has been widely adopted.
Insults and “delete your comment” don’t make for either scientific or constructive discussion.
ghost
commented at 8:35 pm on August 9, 2023:
none
Some full RBF transactions are being mined.
Who cares about origin?
OpenTimestamps
Even if opentimestamps full RBF transactions are mined
Do you even think for a moment that it doesn’t matter if have it default or not?
Or is it just about emotional drama?
Full RBF transactions are being relayed and miners include them in blocks.
If making it default affects your security, I want to know your project. I won’t exploit.
petertodd
commented at 9:41 pm on August 10, 2023:
contributor
All of those transactions are taken from my OpenTimestamps calendars. My OTS calendars bump fees repeatedly, increasing the feerate by 1sat/vb with each replacement, starting at approximately the minimum relay fee.
Yes, that is a pretty perfect mechanism if you want to create a false positive for “full rbf” when all you’re actually triggering is eviction from the mempool due to a change in minfee. For nodes that don’t run “full rbf”, they’ll see one of the early transactions, add it to the mempool, then ignore any replacements for a while, until their local minfee drops below the original transaction, at which point they’ll accept the first replacement they see. Presuming that takes a while, that replacement will then have a high fee, and be included in their templates. That matches all the examples you gave.
Those example are just examples: my belief is based on far larger numbers of transactions getting mined by those pools. Notably, OTS sets nLockTime freshly on each transaction, and the nLockTime’s of the observed, mined, transactions are all up to date. For example, here’s a recent OTS tx mined by Foundry USA, showing that they are not mining full-rbf as the transaction mined was broadcast multiple blocks prior: https://mempool.space/tx/585810a208f2141a730f7589ce8484d8bd11a3c3607c471fecf3354d30e6c2cf
Anyway, for even better examples, on Aug 2nd I updated both calendars to send their initial transactions at significantly above minfee.
It does not match some recent txs mined by antpool, though: eg b4a8d9… at 17.1sat/vb seems to have been mined in the first block that any of its alternatives paid sufficiently for, and there doesn’t seem to be any indication that the minfee should have risen above even the fee of the initial alternative (a6f344845e58d6ef288870b37674942d0505d9ee64f0d289164c3f401be8c086) at 5.98sat/vb (statoshi’s graphs indicate a max minfee around that time of 5.6sat/vb).
Yes, AntPool has very clearly been mining full-rbf for some time now. The supermajority of OTS full-rbf txs are mined by them, which is what you’d expect given their 20% hash power. I haven’t tried to measure what % of their hash power has full-rbf turned on. But it’s likely high or even 100% as mempool.space shows reasonably close to optimal fees for most txs that do get mined.
AntPool + Binance Pool already represents 33% of hash power.
All of the data being linked here (the OTS webpages, fullrbf.mempool.observer and mempool.space) remove that data after at most a couple of weeks which makes it pretty difficult to review. I’ve made some custom patches to bitcoind to make it easier for me to double check your claims, but that’s not convenient or easily reproducible by others either.
All you have to do to double check these claims is to run a well-connected Bitcoin node with full-rbf enabled, and debug=mempool set. You can easily see what transactions have been accepted and when via this method by simply grepping your debug.log file. To be sure you’re seeing all full-rbf replacements, you can use my full-rbf peering fork: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
Please delete your comment as it is factually incorrect and misleading. Frankly I’m surprised that you are so unaware of current mempool policies in use by miners that you were unaware of the fact that full-rbf has been widely adopted.
Insults and “delete your comment” don’t make for either scientific or constructive discussion.
It is productive to delete incorrect and misleading comments once notified, especially in the case where the misinformation is encouraging people to use Bitcoin in a dangerous and insecure way. Your comment was clearly incorrect, and not in a subtle way, and showed a lack of investigation. And as you can easily see in the above discussion, we have a company - GAP600 - denying the reality that a large % of hash power mines full-rbf, while trying to sell a clearly broken service.
Symphonic3
commented at 7:51 am on August 11, 2023:
none
Concept ACK
BitcoinErrorLog
commented at 9:56 am on August 11, 2023:
none
NACK.
The preceding mempoolfullrbf debate resulted in a Bitcoin Core where mempool policy is a minority voting system.
While I acknowledge that mempool policy is local and any consistency we have across policies is a phenomenon of incentives, AND that the likely proper solution is to REMOVE mempool policy steering from both the Core community and software, here we are nonetheless.
The default config for Core is a dangerous space to design, and we should hold the user space, and status quo utility as sacred.
It is my belief that continued mempool manipulation will result in less and less stability and utility. Maybe this is inevitable or necessary for future situations, but, right now, no one actually needs mempoolfullrbf, and I personally value onchain payment use cases more than any of the mempoolfullrbf arguments presented.
petertodd
commented at 12:55 pm on August 11, 2023:
contributor
On Fri, Aug 11, 2023 at 02:56:55AM -0700, John Carvalho wrote:
NACK.
The preceding mempoolfullrbf debate resulted in a Bitcoin Core where mempool policy is a minority voting system.
While I acknowledge that mempool policy is local and any consistency we have across policies is a phenomenon of incentives, AND that the likely proper solution is to REMOVE mempool policy steering from both the Core community and software, here we are nonetheless.
The default config for Core is a dangerous space to design, and we should hold the user space, and status quo utility as sacred.
It is my belief that continued mempool manipulation will result in less and less stability and utility. Maybe this is inevitable or necessary for future situations, but, right now, no one actually needs mempoolfullrbf, and I personally value onchain payment use cases more than any of the fullmempoolrbf arguments presented.
Do you have an actual example of a real-world online merchant that accepts
unconfirmed transactions for something of value immediately? Please provide a
URL so we can check.
I still have not found such an example. GAP600 has claimed to have such
customers. But so far their claims have not checked out.
Without such an example your claim that you “personally value onchain payment
use cases” is not relevant.
ariard
commented at 5:26 am on August 12, 2023:
member
More than 2 years ago, the liquidity griefing provoked by RBF opt-out of a counterparty contributing to a multi-party transaction (splicing / dual-funding) was brought on the mailing list in a post intitled “On Mempool Funny Games against Multi-Party Funded Transactions” and it was the main motivation behind the introduction of mempoolfullrbf with #25353.
Since then the liquidity griefing concern in the context of multi-party transaction has been brought by another Lightning developer in the mailing list post “Liquidity griefing for 0-conf dual-funded txs” and such use-case patterns is in early deployment phase, and start to have more and more economic volume, it turns out it’s a good tool to address the liquidity management issues Lightning is so often blamed with.
Since then, and during all the last year conversation about mempoolfullrbf, if it should be turned by default, activated at some block-height-encoded flag or remove as an option, to the best of my knowledge no counter-reply has been technically argued on this liquidity griefing concern. That said, if doubts persist, I’m very open to do a real-world exploitation if someone takes the burden of setting a “blue” Lightning infrastructure and communicate back the learnings to the community.
According to this public data-collection dashboard, the Lightning Network is a network of 4,713 BTC, 16,313 self-announcing nodes and 68,739 publics channels. Quantitative results than anyone running a Lightning node is able to independently verify thanks to the gossip network.
With a goal to conciliate multiple use-cases, a technical philosophy has been sketched out “to each use-case its set of policy rules” (iiuc) in a reply to the mailing list post entitled “On mempool policy consistency” by a Bitcoin Core developer. I don’t think this philosophy is practical as this is not solving the liquidity griefing issue, even with proposed nversion=3 changes codes as non-rbf signaling nversion=2 are not made replaceable by nversion=3 transactions.
There is definitely an ongoing effort to make the mempool policy rules more modular (see #25584) and documented (see #22806) though they have been started years ago, and the main bottleneck is code and review by skilled hands and eyes. I think most of the GH comments from the 28 participants so far (and the 55 ones in #26438 and the 66 ones in #26525) have been “cheap talks”. I don’t think comments like “I feel the mempool policy rules should be X" have convincing weight in the technical discussion of a +500$ B decentralized network.
From my viewpoint and communication channels, there is no really steering (in the IETF sense) of mempool policy rules by the Bitcoin Core community, rather dealing with legacy technical debt. mempoolfullrbf was not even a subject at the last CoreDev meeting if my memory works well, which is the most “closed-yet-invitation-based-on-technical-proof-of-work” communication channel we have in the Bitcoin development community.
Aiming to roll the ball forward I do have few technical questions for the users running zero-conf in an economic fashion:
do you have already deployed “fire cut” thresholds if more than X of your incoming on-chain transaction traffic is double-spend ?
would you consider batch CPFP of incoming zero-conf transaction as enabled by package-relay to deter double-spend ?
have you privacy-preserving cryptographic proofs (see the taproot-ringsig proof-of-concept) of the business statements you’re claiming for the past periods ?
would you consider monitoring miners mempools for double-spend of a given UTXO, think “reverse transaction-accelerator” ?
The measurement method of the PR author to justify the change have been called out as “dubious” in the latest Bitcoin Optech newsletter. In fact I think in a decentralized community where the decision-making process has to be decentralized and auditable, it’s a good methodological advance to see a PR author coming with real-world numbers, even if the methodology is imperfect. I would rather invite the Bitcoin Optech newsletter to inform how someone could re-do the claimed measurement “at home”.
Ultimately, I think the conversation is still a lack of consensus on the mempool policy rules design philosophy in a growing ecosystem of use-cases underpinned by a matrix of incentives and host of different performances. On this very issue, I’m to blame as I’ve never replied to the author of the mailing list thread “On mempool policy consistency” here.
I think the PR can be put as a draft for now by the maintainers as there is no technical consensus on enabling full-rbf by default.
bitcoin deleted a comment
on Aug 13, 2023
achow101
commented at 10:04 am on August 13, 2023:
member
Please keep discussion here civil and on topic. Ad hominems are neither useful nor productive.
ariard
commented at 11:41 pm on August 13, 2023:
member
@zkfrio Thanks for your thoughts and I’m staying available to explain any technical concepts laid out on a public communication channels such as the Bitcoin mailing list or IRC, and offer my time in a true FOSS spirit.
In matters of ad hominems and personal threats, I’m following the personal policy to process the ones coming from pseudonymous GH users (minding all the practice GH is following to bind users to a social persona) as “cheap talk”, as there is no track records on your statements. Though if you estimate that my Bitcoin scientific or engineering statements are damaging your professional or personal interests, you’re always free to sue me in the competent jurisdiction (you can use the default antoine.riard@gmail.com for the letters of actions).
If it’s more a question of you not finding the corrects words to express your thoughts on a delicate and complex technical subject such as full-rbf, and here I understand how sometimes it can hard to articulate a reasoning being native french-speaking and non-english, I’m happy to offer you a beer at the next technical Bitcoin conference. Sincerely from a human being, to another one.
BitcoinErrorLog
commented at 6:33 am on August 14, 2023:
none
Do you have an actual example of a real-world online merchant that accepts unconfirmed transactions for something of value immediately? Please provide a URL so we can check. I still have not found such an example. GAP600 has claimed to have such customers. But so far their claims have not checked out. Without such an example your claim that you “personally value onchain payment use cases” is not relevant.
Many examples of 0conf acceptance have been provided, with consistency across years. The examples I am the most familiar and confident in are Bitrefill, where I worked for a few years and witnessed the benefits first-hand for both users and the merchant, and Blocktank LSP, where we try to provide as much of an instant LN channel user experience as possible. These are all demonstrated at their respective websites (bitrefill.com, blocktank.to (which is also represented within Bitkit wallet, bitkit.to).
There is also a community of other LSP-affiliated engineers creating specifications that include assumptions for optional 0conf flows, meaning there are many existing projects and businesses that hope to incorporate risk-managed 0conf acceptance into their products and services.
There is also data and testimony from several other people in the mailing list in recent years.
There is no question that the 0conf use case is present, and certainly no question it is more utilized and potentially useful than any use case served by this PR.
Nodes should not be ignoring or redefining user-intent via mempool policy in the first place. If I want RBF, I will flag it in my txn. If I want users of my app to be able to RBF, I will default that setting in my own client.
petertodd
commented at 10:57 am on August 14, 2023:
contributor
On Sun, Aug 13, 2023 at 11:33:19PM -0700, John Carvalho wrote:
Do you have an actual example of a real-world online merchant that accepts unconfirmed transactions for something of value immediately? Please provide a URL so we can check. I still have not found such an example. GAP600 has claimed to have such customers. But so far their claims have not checked out. Without such an example your claim that you “personally value onchain payment use cases” is not relevant.
Many examples of 0conf acceptance have been provided, with consistency across years. The examples I am the most familiar and confident in are Bitrefill, where I worked for a few years and witnessed the benefits first-hand for both users and the merchant, and Blocktank LSP, where we try to provide as much of an instant LN channel user experience as possible. These are all demonstrated at their respective websites (bitrefill.com, blocktank.to (which is also represented within Bitkit wallet, bitkit.to).
Bitrefill does not accept unconfirmed transactions, and as far as I can tell,
has not accepted them for many months. While their order page claims otherwise
under the advanced tab, even if you send a transaction with sufficient fee it
will not be accepted without a confirmation. I and friends of mine have tested
this multiple times, including with logged in, well-used accounts. If you
believe otherwise, tell me exactly how to get it to accept an unconfirmed
transaction.
As for Blocktank LSP and Bitkit, tell me, exactly how do I get it to accept an
unconfirmed transaction in exchange for something of value?
petertodd
commented at 11:14 am on August 14, 2023:
contributor
On Sun, Aug 13, 2023 at 11:33:19PM -0700, John Carvalho wrote:
There is also a community of other LSP-affiliated engineers creating specifications that include assumptions for optional 0conf flows, meaning there are many existing projects and businesses that hope to incorporate risk-managed 0conf acceptance into their products and services.
I should point out that if what you are claiming is true, we should be merging
this change now rather than later. We have clear technical consensus that
acceptance of unconfirmed transactions is dangerous, and businesses trying to
do that pose a risk towards the Bitcoin ecosystem as a whole. Ensuring a new
round of such reckless businesses doesn’t develop is in the interests of
everyone but those businesses. Merging this pull-req now helps prevent that
outcome, and we have an opportunity to do so at a time when the evidence has
clearly shown that no or essentially no actual businesses are relying on
unconfirmed transactions.
petertodd
commented at 11:28 am on August 14, 2023:
contributor
On Fri, Aug 11, 2023 at 10:27:10PM -0700, Antoine Riard wrote:
Aiming to roll the ball forward I do have few technical questions for the users running zero-conf in an economic fashion:
do you have already deployed “fire cut” thresholds if more than X of your incoming on-chain transaction traffic is double-spend ?
would you consider batch CPFP of incoming zero-conf transaction as enabled by package-relay to deter double-spend ?
have you privacy-preserving cryptographic proofs (see the taproot-ringsig proof-of-concept) of the business statements you’re claiming for the past periods ?
would you consider monitoring miners mempools for double-spend of a given UTXO, think “reverse transaction-accelerator” ?
I think you asking these questions inappropriately gives readers the impression
that there actually are non-trivial examples of real businesses who are relying
on unconfirmed transactions. The fact is in this entire thread no-one has been
able to provide clear, convincing, evidence that this is true.
We have a lot of claims. But claims are not evidence of use. If anything, the
claims so far are suggestive of fraud. For example it’s plausible that the lack
of usage of GAP600 is because they offer a service that doesn’t actually work,
so businesses use them briefly - paying them money - and then quit. GAP600 has
even said that they don’t even test their own service with real double-spends.
Notably, in the example of Changelly given above, they did respond to be and
confirmed that they do NOT use GAP600’s service for any real
customer-to-business use-case. Changelly also confirmed to me that they have
never even tested it with a real double spend.
The measurement method of the PR author to justify the change have been called out as “dubious” in the latest Bitcoin Optech newsletter.
First of all, the word “dubious” doesn’t even appear in the Bitcoin Optech
newsletter. Quoting it in such a way is not accurate. Second, all Bitocin
Optech actually did was link Andrew Chow’s initial comment, which even he
admitted was clearly not correct with respect to Antpool.
ayesaac
commented at 3:23 pm on August 14, 2023:
none
Secondly, on the basis of mempool consistency with miners, since full-rbf is the compatible policy in almost all cases, we should be supporting it by default if you take the position that we want to optimize for consistency with miners.
If 37% of hash rate is mining full RBF, enabling full RBF is (currently) a move away from mempool consistency with majority hash rate.
Thirdly, all previous arguments in favor of full-rbf, such as multiparty transactions, wallets, user-expectations, etc. still apply.
Full RBF is already possible, and these arguments are not a convincing reason for changing default policy.
This simplification of mempool policy is well overdue. 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.
A change to a default does not meaningfully simplify mempool policy, which is arbitrary and controlled by individual nodes and as such cannot be meaningfully simplified.
The arguments for and against throughout this PR still seem to be about full RBF as a concept. Full RBF as a concept is out of the bag and usable. So:
What is the benefit (or drawback) to changing the default policy for users’ own mempool for them?
That’s all this PR does.
As far as I can tell its currently a tradeoff between fee efficiency and priority; if I have full RBF enabled, I see higher bids which 37% of hashrate might mine. Bidding against full RBF transactions is less fee efficient, but increases the odds of my being included in the next block. I might lean slightly toward full RBF true because I see a more complete picture of awaiting transactions (if my mempool isn’t full and evicting, in which case which txs I’d rather have in my mempool is entirely based on what I’m using my mempool for), but that’s not a great argument for making that decision for others.
petertodd
commented at 6:08 pm on August 14, 2023:
contributor
If 37% of hash rate is mining full RBF, enabling full RBF is (currently) a move away from mempool consistency with majority hash rate.
You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
Full-RBF miners want to learn about full-RBF replacements. Non-full-RBF miners don’t care about full-RBF replacements. But it does them no harm to receive that information: they just ignore it.
Full-RBF nodes distribute the same information as non-full-RBF nodes: transactions and blocks. But in addition, they also distribute information about full-RBF replacements. So a full-RBF node is compatible with both full-RBF and non-full-RBF miners. While a non-full-RBF node is only compatible with non-full-RBF miners.
If 0% hashing power was mining full-RBF you could argue that the full-RBF replacement information was irrelevant. But the fact is, a significant % of hashing power is mining full-RBF, so it makes sense to adopt the mempool policy of maximum compatibility: Full-RBF.
This simplification of mempool policy is well overdue. 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.
A change to a default does not meaningfully simplify mempool policy, which is arbitrary and controlled by individual nodes and as such cannot be meaningfully simplified.
In the future it will. As I mentioned above, wallets have been moving to taking away the ability to set or unset BIP125, simplifying the user experience. As more miners mine full-RBF, the need for that code diminishes, eventually allowing us to remove it entirely from both nodes and wallets.
We do not need to support irrelevant options that no-one actually uses. The fact is, no-one in this thread has been able to come up with a real-world example of a business that actually depends on unconfirmed transactions. The distinction between replaceable and “non-replaceable” transactions that BIP125 introduced is thus irrelevant, and we can phase it out.
ayesaac
commented at 6:31 pm on August 14, 2023:
none
You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
That’s one potential goal of a node runner, but not all node runners, and not the only goal.
In fact, as far as I’m aware, all estimates point to an overwhelming majority of nodes not relaying.
Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Running a node is the only way to validate that the chain you’re on is following the rules you want. Running a node is a requirement of many services. At least in the Bitcoin circles I travel in, these are the primary reasons people run nodes.
There are certainly people who run nodes with the aim of ‘supporting the network’. To an extent, this is why I run a node. But running a node is primarily a selfish endeavour; to exercise your own self-sovereignty, at least with the node runners I know.
If people want to relay as much as possible, they can set this flag. Assuming that is the goal of the majority is just that: an assumption.
In the future it will.
Maybe. That’s what you’d hope, and I can empathize with that goal; less code makes things easier to maintain, and less likely to go wrong. But that’s not a reason to make a decision for noderunners when there are clearly people who don’t want the first-seen option to disappear. At least for now. That is steering policy with defaults. I’m extremely uncomfortable with that, and I know that many other Bitcoiners are.
petertodd
commented at 6:44 pm on August 14, 2023:
contributor
That’s one potential goal of a node runner, but not all node runners, and not the only goal.
In fact, as far as I’m aware, all estimates point to an overwhelming majority of nodes not relaying.
Citation needed.
The default behavior of Bitcoin Core is to relay transactions, whether or not the node is a listening node. If you believe that the overwhelming majority of nodes have disabled transaction relay (eg via -blocksonly), you need to cite that claim. That is definitely not true with respect to listening nodes, as if the “overwhelming majority” of listening nodes had disabled transaction relay, transaction relay for non-listening nodes would not work. It works fine.
Anyway, full-RBF is only relevant to nodes that relay. Even if your claim was true, it would be irrelevant to this discussion.
Maybe. That’s what you’d hope, and I can empathize with that goal; less code makes things easier to maintain, and less likely to go wrong. But that’s not a reason to make a decision for noderunners when there are clearly people who don’t want the first-seen option to disappear. That is steering policy with defaults. I’m extremely uncomfortable with that, and I know that many other Bitcoiners are.
That same kind of logic was used to argue for increasing the block size, and it’s no surprise that many big blockers have argued against full-rbf. The fact is we make technical trade offs all the time. This happens to be a tradeoff between an essentially non-existent class of users, and a much larger group of actual, real world, users who benefit from full-RBF: https://petertodd.org/2023/why-you-should-run-mempoolfullrbf#the-controversy
ayesaac
commented at 7:09 pm on August 14, 2023:
none
The default behavior of Bitcoin Core is to relay transactions
Yes, bad (incorrect) wording. The majority are (/appear to be) non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
Anyway, full-RBF is only relevant to nodes that relay. Even if your claim was true, it would be irrelevant to this discussion.
Full RBF is relevant to anybody who has a mempool whose state they care about or rely on, and anyone who has any opinion or need beyond ‘maximum’ when it comes to relay.
For those, for example, using their mempool to decide transaction fees, there is a difference they may or may not be aware of while full RBF transactions are mined by a (large) minority of hashrate.
That same kind of logic was used to argue for increasing the block size, and it’s no surprise that many big blockers have argued against full-rbf.
What logic, exactly?
Re: complexity? You’re the one who brought up complexity and maintenance.
Re: core steering non-consensus policy? Given blocksize is consensus layer, no, they didn’t.
This is borderline ad hominem by association. Sorry, I’m not a big blocker. Were the topic of blocksize to become relevant again, I’d be arguing to shrink it short of something big changing. While we’re at it, I agree zero conf is a terrible idea.
This happens to be a tradeoff between an essentially non-existent class of users, and a much larger group of actual, real world, users who benefit from full-RBF: https://petertodd.org/2023/why-you-should-run-mempoolfullrbf#the-controversy
Users can already benefit from full RBF. Again: I am not arguing for or against full RBF as a concept. It’s fine. I am asking for a justification for changing default policy. That we need defaults at all is an unfortunate fact. To change them is to make a decision for everyone running defaults you have no right to make. You need a good reason to justify that, and ‘maximum relay’ for full RBF replacements which are already being relayed fine with people opting in isn’t a particularly good reason.
YellowRoseCx
commented at 7:10 pm on August 14, 2023:
none
You are mistaken. Think about this in terms of information: the purpose of a Bitcoin node is to widely distribute information in the form of transactions and blocks.
That’s one potential goal of a node runner, but not all node runners, and not the only goal.
In fact, as far as I’m aware, all estimates point to an overwhelming majority of nodes not relaying.
Running a node is an absolute necessity to interact with Bitcoin without any trust or dependence on third parties. Running a node is the only way to validate that the chain you’re on is following the rules you want. Running a node is a requirement of many services. At least in the Bitcoin circles I travel in, these are the primary reasons people run nodes.
There are certainly people who run nodes with the aim of ‘supporting the network’. To an extent, this is why I run a node. But running a node is primarily a selfish endeavour; to exercise your own self-soverignty.
Satoshi Nakamoto said having all users of a network run their own node doesn’t scale and is similar to every Usenet user running their own NNTP server.
And he recommended “users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.”
Non-mining nodes have no network power unless you’re accepting payments through that node, otherwise they can only watch the rules, not enforce them. Miners in consensus create the rules and enforce them. The power comes from voting ability from hashrate.
“A fully validating node running on a RaspPi does nothing to enforce consensus because miners don’t care if you follow their chain or not.
The economic nodes that matter are exchanges, vendors, etc. because their choices dictate default consumer behavior, which overall has a far greater impact on the consensus ecosystem than a non-mining user node.
Fully validating nodes that process no transactions/have no economic activity have no input on the consensus of Bitcoin.”
petertodd
commented at 7:54 pm on August 14, 2023:
contributor
The default behavior of Bitcoin Core is to relay transactions
Yes, bad (incorrect) wording. The majority are (/appear to be) non-listening. Point being that those whose primary goal is maximum relay of blocks and transactions would be listening to achieve that.
You’re arguing a logical fallacy here. You might as well argue that the vast majority of people don’t even run nodes, so there’s no reason for any node to distribute any transactions or blocks at all.
The fact is, nodes that choose to propagate transactions are spreading information around. Spreading the maximal amount of useful information - all replacements, full-rbf or not - is maximally compatible with both full-rbf and non-full-rbf miners.
Full RBF is relevant to anybody who has a mempool whose state they care about or rely on, and anyone who has any opinion or need beyond ‘maximum’ when it comes to relay.
For those, for example, using their mempool to decide transaction fees, there is a difference they may or may not be aware of while full RBF transactions are mined by a (large) minority of hashrate.
Again, for the purpose of transaction fees since miners are mining full-rbf, knowing about full-rbf replacements (and thus their contribution to fees) gives you the maximum information.
Of course, in practice replacements are only a small % of overall fees, so the difference is small. But that difference is in favor of defaulting to full-rbf.
That same kind of logic was used to argue for increasing the block size, and it’s no surprise that many big blockers have argued against full-rbf.
What logic, exactly?
The logic that a small minority simply wanting a broken feature to exist forever is reason to keep it.
This is borderline ad hominem by association. Sorry, I’m not a big blocker. Were the topic of blocksize to become relevant again, I’d be arguing to shrink it short of something big changing. While we’re at it, I agree zero conf is a terrible idea.
Yes, it is a terrible idea. BIP125 bends over backwards to support essentially non-existent “zero conf” usecases. Getting rid of BIP125 - adopting full-rbf - fixes that mistake. The only reason why you’d want the BIP125 flag is for the sake of zero-conf. There’s no other reason to have a distinction between replaceable and “non-replaceable” transactions.
Yes. And adopting it by default makes it easier for all users to benefit from it. The fact that a limited version of a good thing exists is not grounds to stop all improvement.
Daniel600
commented at 8:59 pm on August 14, 2023:
none
On Fri, Aug 11, 2023 at 10:27:10PM -0700, Antoine Riard wrote: Aiming to roll the ball forward I do have few technical questions for the users running zero-conf in an economic fashion: - do you have already deployed “fire cut” thresholds if more than X of your incoming on-chain transaction traffic is double-spend ? - would you consider batch CPFP of incoming zero-conf transaction as enabled by package-relay to deter double-spend ? - have you privacy-preserving cryptographic proofs (see the taproot-ringsig proof-of-concept) of the business statements you’re claiming for the past periods ? - would you consider monitoring miners mempools for double-spend of a given UTXO, think “reverse transaction-accelerator” ?
I think you asking these questions inappropriately gives readers the impression that there actually are non-trivial examples of real businesses who are relying on unconfirmed transactions. The fact is in this entire thread no-one has been able to provide clear, convincing, evidence that this is true. We have a lot of claims. But claims are not evidence of use. If anything, the claims so far are suggestive of fraud. For example it’s plausible that the lack of usage of GAP600 is because they offer a service that doesn’t actually work, so businesses use them briefly - paying them money - and then quit. GAP600 has even said that they don’t even test their own service with real double-spends. Notably, in the example of Changelly given above, they did respond to be and confirmed that they do NOT use GAP600’s service for any real customer-to-business use-case. Changelly also confirmed to me that they have never even tested it with a real double spend.
The measurement method of the PR author to justify the change have been called out as “dubious” in the latest Bitcoin Optech newsletter.
First of all, the word “dubious” doesn’t even appear in the Bitcoin Optech newsletter. Quoting it in such a way is not accurate. Second, all Bitocin Optech actually did was link Andrew Chow’s initial comment, which even he admitted was clearly not correct with respect to Antpool.
Should anyone here (except the author) wish to have a test account of GAP600 please reach out via our site, would be happy to provide. I am also open to have a public call to show and discuss our offering and possibly show live transactions being scored and queried.
It is clear from the authors commentary this PR is not about full RBF it is about stopping 0-conf.
The onerous is not on 0-conf or first seen rule proponents to justify their use cases. The onerous is on the author to show and justify that this PR is so important and value adding that it should be adopted despite 0-conf use cases and adoption. This has not been remotely shown.
The methodology of 37% assessment above is not thorough - a simple test of representative trx count with a time gap followed by a replace trxs would give an initial assessment. A feature which has 37% natural adoption with in less than a year indicates viral adoption and wouldn’t require any lobbying, or default setting to become dominant with in a very short time.
The author continues to repeat baseless accusations - these have been responded to #28132 (comment)
GAP600 is active business with ongoing clients who value their privacy just like the miners the author quotes above - July 2023 GAP600 serviced circa 350k unique transaction hashes. I will check directly with Changelly on their feedback, as well as look to asses further information which can be shared publicly. The author does not and can not know all use cases of Bitcoin.
ayesaac
commented at 10:09 pm on August 14, 2023:
none
You’re arguing a logical fallacy here. You might as well argue that the vast majority of people don’t even run nodes, so there’s no reason for any node to distribute any transactions or blocks at all.
Not at all. I’m arguing that
the purpose of a Bitcoin node is to widely distribute transactions and blocks
Is false. It’s one purpose of some nodes (that they mostly do by default doesn’t mean that’s a major goal of the people running them), but it’s optional, and which transactions get relayed is dependent on all kinds of things, including whether your mempool is currently full. I could shrink my mempool to the minimum size to have a reasonable fee estimate, and stop relaying transactions which are below its floor, but which are absolutely relevant to the rest of the network, for example.
‘Maximum relay’ doesn’t seem to matter anywhere else.
There are a cohort of Bitcoiners who actively don’t want to maximally relay for different reasons. Some are the zeroconf people. Some are people who don’t want to relay ordinals. Whether or not you agree with them, it’s not the place of core to dictate what their node relays.
The fact is, nodes that choose to propagate transactions are spreading information around. Spreading the maximal amount of useful information - all replacements, full-rbf or not - is maximally compatible with both full-rbf and non-full-rbf miners.
No. Nodes relay transactions by default. That is not a choice, and relaying transactions is tightly coupled with having a mempool. Afaict, which transactions get relayed is almost entirely the same decision as which transactions get added to my mempool in core.
Given my node is my node first, regardless of whether it reduces some ideal (the ideal you are arguing is ‘maximum relay’), my node will be configured for my purposes, and mempool configuration, again, is a part of that.
Again, for the purpose of transaction fees since miners are mining full-rbf, knowing about full-rbf replacements (and thus their contribution to fees) gives you the maximum information.
No, replacements drop the replaced tx out of the mempool. It gives you different information. In the case of full RBF, it presents a transaction which 37% of hash rate might mine in lieu of a transaction which the other 63% might mine.
Of course, in practice replacements are only a small % of overall fees, so the difference is small. But that difference is in favor of defaulting to full-rbf.
I agree the difference is currently small, but its ‘being in favour of default full RBF’ is entirely arbitrary. You don’t know which is preferable for users, yet you want to change default policy and pick your preferred option.
The logic that a small minority simply wanting a broken feature to exist forever is reason to keep it.
This is a massive stretch. Big blockers wanted to increase block size, a consensus change, to not have to think about actual scaling solutions. They wanted to push the cost of ‘scaling’ onto node runners.
First seen is not broken. Of the two available options, it is the one which currently better reflects majority hashrate policy. It can coexist with full RBF indefinitely, and sure, if full RBF sees large scale adoption, first at mining, and then by node runners, a default change might make sense. We aren’t there yet. I actually expected us to get there a lot faster; my concern when the flag was merged was that we’d see very quick, very broad miner adoption (given leaving money on the table otherwise), but little user awareness/adoption at which point there’s an exploitable information asymmetry in publishing a low fee non-RBF-flagging transaction, waiting a little for propagation, then publishing a competitive fee full RBF replacement to invisibly (to those with no full RBF) outbid others in the fee market. Maybe that’s still a valid concern, but given it doesn’t seem to have materialised, maybe I’m missing something.
Yes, it is a terrible idea. BIP125 bends over backwards to support essentially non-existent “zero conf” usecases. Getting rid of BIP125 - adopting full-rbf - fixes that mistake. The only reason why you’d want the BIP125 flag is for the sake of zero-conf. There’s no other reason to have a distinction between replaceable and “non-replaceable” transactions.
The issue is we have that flag, we have untold numbers of nodes running unknown local policy for unknown reasons. This PR makes a decision for them. I don’t think such decisions should be taken lightly, and I simply don’t see much real utility in this change.
Full RBF works. It’s already accessible. The only potential benefits of this change, as far as I can tell, are:
Maybe in the future being able to remove an option node runners currently have without too much fuss.
People who want full RBF not needing to configure it.
The first is a nice-if-it-happens, but actively seeking to reduce options, even options you don’t agree with, which have no actual impact on others, doesn’t sit right with me.
The second is honestly a loss, to me. I want people to configure their nodes. I want them to make those decisions themselves. Admittedly that’s not a great argument either, but I don’t think that minor convenience is any more a compelling reason to change a default, and it’s the one being used to justify a change from the status quo without any real evidence for or against that being what users at large actually want.
Yes. And adopting it by default makes it easier for all users to benefit from it. The fact that a limited version of a good thing exists is not grounds to stop all improvement.
I don’t agree it makes things much easier, besides by pretending there are absolutely no trade offs and just making the decision about those trade offs for the user. Which, with the current state of the network, is false.
If it was just relay, I would probably have already acked. But it does impact your local view of the mempool, and some decisions you might make based on it, in non-obvious ways and I don’t like that decision being made for users without good (in my view) justification.
Anyone who really wants full RBF will have enabled it already. This PR gets basically (I suppose it’s possible someone could have manually set false in their config) everyone else, whether that’s the local policy they would want, if informed and made to pick, or not.
Symphonic3
commented at 1:01 am on August 15, 2023:
none
@iBeizsley@Daniel600 I think it’s worth noting that what’s being argued here is NOT any less of a choice for users than disabling full-rbf by default. The decision is made for the user no matter what the default is. Inaction does not equate to not making a decision. It is not possible for a setting to be “unset” by default, it must either be off or on.
Bitcoin Core’s policy has been against transaction censorship; there is a reason why tools like ordisrespector will not and should not make it into the base bitcoin client, no matter how much I or any other bitcoiner supports them. From this perspective, consistent policy that reduces capacity for censorship is the norm, and thus this change which relaxes mempool policy allowing more transactions through should be supported by Core.
The ignoring of non-rbf-flagging replacements has never been economically aligned for miners. At any point in time, a sufficiently expensive transaction can and will be mined by miners. This is evident in the presence of numerous “transaction accelerators” (direct inputs to their mempools) provided by miners.
You are indirectly advocating for a form of transaction censorship, which I personally see as extremely dangerous behaviour.
@YellowRoseCx
Satoshi Nakamoto said having all users of a network run their own node doesn’t scale and is similar to every Usenet user running their own NNTP server.
And he recommended “users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.”
If Satoshi Nakamoto says something and you fall into that appeal to authority, what is to stop you from following any grifter or authoritarian ruler? Bitcoin does not operate based on what someone or someone else says, this assumption is silly. Regardless, most opinions of Satoshi are wildly outdated and frankly come from a place of unfamiliarity with bitcoin. Just because they created it doesn’t mean it wasn’t still an extremely new technology.
Non-mining nodes have no network power unless you’re accepting payments through that node, otherwise they can only watch the rules, not enforce them. Miners in consensus create the rules and enforce them. The power comes from voting ability from hashrate.
“A fully validating node running on a RaspPi does nothing to enforce consensus because miners don’t care if you follow their chain or not.
Sure, miners don’t care if you follow their chain. In addition, nodes don’t care if miners don’t follow their rules. There is absolutely no behavior within bitcoin that is going to cause anyone to follow a miner that invents new consensus rules. Believe it or not, when a miner does that, we call these ‘shitcoins’.
The economic nodes that matter are exchanges, vendors, etc. because their choices dictate default consumer behavior, which overall has a far greater impact on the consensus ecosystem than a non-mining user node.
Fully validating nodes that process no transactions/have no economic activity have no input on the consensus of Bitcoin.”
This is untrue. One’s status as a business is entirely irrelevant if they begin running on a fork that is incompatible with bitcoin. How is any of this relevant to this discussion?
ayesaac
commented at 1:36 am on August 15, 2023:
none
I think it’s worth noting that what’s being argued here is NOT any less of a choice for users than disabling full-rbf by default. The decision is made for the user no matter what the default is. Inaction does not equate to not making a decision.
First seen is the existing default. I’m of the personal opinion it’s probably a worse default in a vacuum, but the decision isn’t being made in a vacuum, and changing defaults to influence policy toward personal preference, even if I’m confident in that preference, is quite different in my view to something being the default because there was not previously another option.
It is not possible for a setting to be “unset” by default, it must either be off or on.
It absolutely is possible, that’s just not how Core has operated. I would immediately ack a PR which prompted the user to select a policy in the absence of a defined setting in their config for this, and any other policy, but I don’t imagine it would get merged.
Bitcoin Core’s policy has been against transaction censorship… You are indirectly advocating for a form of transaction censorship, which I personally see as extremely dangerous behaviour.
Am I censoring your transactions if I run blocks only? Am I censoring your transaction if I set my mempool limit to 10mb, it fills up, and your transaction has a fee rate below my mempool’s current floor? I won’t relay your transaction in either of those cases, and plenty of other scenarios I don’t think people would consider to be censorship.
By your own admission, and I completely agree, full RBF seems highly incentive aligned for miners. A relatively low percentage of nodes relaying these transactions allows them to reach miners, and be mined. Not changing the default isn’t censorship; these transactions are reaching miners despite the default being to not relay them.
I’m not completely against changing the default, and I’m absolutely not against full RBF as a concept. But I’ve yet to hear a good justification for making a change from the status quo on behalf of users.
Symphonic3
commented at 2:50 am on August 15, 2023:
none
First seen is the existing default. I’m of the personal opinion it’s probably a worse default in a vacuum, but the decision isn’t being made in a vacuum, and changing defaults to influence policy toward personal preference, even if I’m confident in that preference, is quite different in my view to something being the default because there was not previously another option.
This philosophy is antithetical to any kind of development at all.
It is not possible for a setting to be “unset” by default, it must either be off or on.
It absolutely is possible, that’s just not how Core has operated. I would immediately ack a PR which prompted the user to select a policy in the absence of a defined setting in their config for this, and any other policy, but I don’t imagine it would get merged.
How do you propose the default state of the checkbox presented to the user be set?
Am I censoring your transactions if I run blocks only? Am I censoring your transaction if I set my mempool limit to 10mb, it fills up, and your transaction has a fee rate below my mempool’s current floor? I won’t relay your transaction in either of those cases, and plenty of other scenarios I don’t think people would consider to be censorship.
You are engaging in transaction censorship whether you like it or not by running a mempool policy that doesn’t relay every consensus valid transaction. Leech nodes are a mild form of censorship on the network.
By your own admission, and I completely agree, full RBF seems highly incentive aligned for miners. A relatively low percentage of nodes relaying these transactions allows them to reach miners, and be mined. Not changing the default isn’t censorship; these transactions are reaching miners despite the default being to not relay them.
I’m not completely against changing the default, and I’m absolutely not against full RBF as a concept. But I’ve yet to hear a good justification for making a change from the status quo on behalf of users.
Because if it’s assumed that Full-RBF is now occurring pervasively, it is unhealthy for the network to have a 60%+ disagreement on certain txs. This leads to bad assumptions, e.g. thinking that 0-conf is safe, and leads to degraded health of transaction relay if it continues, especially if the same were to happen with other kinds of transactions.
petertodd
commented at 10:38 am on August 16, 2023:
contributor
The methodology of 37% assessment above is not thorough - a simple test of representative trx count with a time gap followed by a replace trxs would give an initial assessment. A feature which has 37% natural adoption with in less than a year indicates viral adoption and wouldn’t require any lobbying, or default setting to become dominant with in a very short time.
As you can see, I’ve reconfirmed my OTS findings with test transactions, showing many examples of 4 different pools mining full-RBF. Re: “wouldn’t require any lobbying”, this pull-req isn’t about lobbying. It’s acknowledging the fact that miners have adopted full-RBF in significant numbers, and since they have, there is every reason to take advantage of that capability by setting an appropriate default for transaction relaying nodes. Miners who want to continue not mining full-RBF replacements are of course able to do so, and it’s quite possible that some will, at least initially. Full-RBF relaying nodes are of course compatible with non-full-RBF miners.
ariard
commented at 2:36 am on August 17, 2023:
member
I think you asking these questions inappropriately gives readers the impression
that there actually are non-trivial examples of real businesses who are relying
on unconfirmed transactions. The fact is in this entire thread no-one has been
able to provide clear, convincing, evidence that this is true.
I think you have two layers of reasoning: a) browsing the matrix of alternatives solutions for unconfirmed transactions and b) the economics traffic of the use-cases which justifies to design and deploy such alternatives solutions. a) is interesting for single-party 0-conf channels LSPs.
First of all, the word “dubious” doesn’t even appear in the Bitcoin Optech
newsletter.
“Peter Todd argues that the change is warranted because (according to his measurements, which have been called into doubt),”. (newsletter #263) and “dubious” definition, see wiktionary entry: https://en.wiktionary.org/wiki/dubious So I think my statement on your statement as represented by Optech was correct.
Seen the post. I think it could be interesting to re-do a coordinated full-RBF tests with full-nodes run by a set of independents participants, with debug=mempool enabled to corroborate the observations. Akin to astronomical observatories to watch volcanology or meteorology phenoma. Maybe with a longer delay than 30 seconds between replacements.
Personally I don’t have time to participate in such observation during the coming weeks, though if there is a mailing list announcement ahead, I’ll do my best to have a well-connected full-node running with debug=mempool to participate in such coordinated and distributed observations of full-rbf double-spends.
petertodd
commented at 2:34 pm on August 17, 2023:
contributor
I think you asking these questions inappropriately gives readers the impression
that there actually are non-trivial examples of real businesses who are relying
on unconfirmed transactions. The fact is in this entire thread no-one has been
able to provide clear, convincing, evidence that this is true.
I think you have two layers of reasoning: a) browsing the matrix of alternatives solutions for unconfirmed transactions and b) the economics traffic of the use-cases which justifies to design and deploy such alternatives solutions. a) is interesting for single-party 0-conf channels LSPs.
It’s pretty simple. What you said was “I do have few technical questions for the users running zero-conf in an economic fashion”. (emphasis mine) That statement gives the clear impression that you think those users actually exist in non-trivial numbers. Since no-one has provided any hard evidence they do, that’s misleading.
As for 0-conf channels, none of the actual deployed ones (eg Phoenix) rely on first-seen. Phoenix even sets the BIP125 flag on their LN-related on-chain transactions, and they do not accept on-chain payments without confirmation. If you are aware of another deployed in production LN implementation that does, I’d like to know, because that’s clearly dangerous and they should stop.
First of all, the word “dubious” doesn’t even appear in the Bitcoin Optech
newsletter.
“Peter Todd argues that the change is warranted because (according to his measurements, which have been called into doubt),”. (newsletter #263) and “dubious” definition, see wiktionary entry: https://en.wiktionary.org/wiki/dubious So I think my statement on your statement as represented by Optech was correct.
Maybe you’re missing this because of english not being a first language, but the word “dubious” in this context has significantly different connotations, particularly as you were implying that Bitcoin Optech themselves had characterized my research as such.
Seen the post. I think it could be interesting to re-do a coordinated full-RBF tests with full-nodes run by a set of independents participants, with debug=mempool enabled to corroborate the observations. Akin to astronomical observatories to watch volcanology or meteorology phenoma. Maybe with a longer delay than 30 seconds between replacements.
My OTS research was done with transactions that were usually much more than 30 seconds between replacements. That research has already been done and clearly shows full-RBF mining. After all, in addition to my transactons, there’s plenty of other sources of full-RBF replacements, and plenty of services such as https://mempool.space/rbf and https://fullrbf.mempool.observer/ observing those replacements happening. This isn’t an occasional propagation glitch. At this point I believe denying the obvious is harmful, as it misleads people about the risks of unconfirmed transactions.
Personally I don’t have time to participate in such observation during the coming weeks, though if there is a mailing list announcement ahead, I’ll do my best to have a well-connected full-node running with debug=mempool to participate in such coordinated and distributed observations of full-rbf double-spends.
I’ll ask you a simple question: do you think any miners are mining full-RBF at the moment?
nerd2ninja
commented at 4:32 pm on August 17, 2023:
none
Concept Ack. To quote moonsettler from a different mempool policy discussion
evil mempool is among the largest existential threats to bitcoin and we absolutely have no way to stop it from coming into existence. in fact unnecessarily restrictive mempool policy naturally incentivizes it’s emergence.
people attempting to effectively filter economically motivated, paying market for block space will most likely result in perverse outcomes that may hurt the security assumptions badly. basically opens the door for reorg markets because it solves the whole coordination problem.
Now, do I agree with this line of logic in full? Not necessarily, but if an “evil mempool” concerns you, it certainly applies to full rbf. Every “stuck” transaction in the mempool that wasn’t marked with RBF has to go to a “transaction accelerator” which is certainly an evil mempool if there ever was one. Lets allow all miners the incentives of higher paying transactions and not just the ones that are part of pools that have transaction acceleration services.
Repeatedly seeking “citations” for 0-conf use cases is not the way to convince people that your PR should be merged. You made the PR, seeking to change a long-standing default value. The onus in on you to show us that your PR will not break existing use cases. Forcefully demanding users and supporters of 0-conf/FSS policies to show their data is fallacious shifting of burden of proof. If you don’t think these use cases exist, go ahead and prove it.
Your own views on mempool policies are not infallible. Users of 0-conf/FSS have their own reasons and that itself should be respected. Being dismissive and browbeating others into submission does nothing to support your cause.
fjahr
commented at 1:04 pm on August 18, 2023:
contributor
The onus in on you to show us that your PR will not break existing use cases.
His argument is, of course, that the use cases are already broken and thus the setting may as well be changed to reflect reality and help the network. I find the evidence presented convincing enough.
If you don’t think these use cases exist, go ahead and prove it.
Proving a negative in this context seems nearly impossible. How should he do that? Visit every website on the web and check if they accept 0-conf? Asking others to prove him wrong seems the only viable course of action in this regard. And there is also precedent for this in previous changes on the implementation and protocol level. There have been many mailing list posts over the years asking “does it break anything for you if we do this?” and if people didn’t speak up and laid out their use case in a convincing manner the plans usually went ahead if the change was otherwise viewed as positive.
If you don’t like it just give a NACK and lay out an argument strong enough that he can not convince people otherwise.
ChrisMartl
commented at 2:46 pm on August 18, 2023:
none
Let’s get this merged and this silly debate over with.
From this developer, his way to communicate his ideas is inappropriate.
Never a discussion with the goal to make a decision is “silly”. It signals more or less arrogance. Furthermore, it shows where his preference is being focused; and it is on popular mining-pool entities. On the other hand, undermines the opt-in nature of the already implemented behavior.
Taking the “powerful” and less effort way to enforce his idea, rather than advocating regular Bitcoin node operators for changing the proper parameter in the configuration file is not a desired praxis.
ChrisMartl
commented at 3:39 pm on August 18, 2023:
none
Concept NACK
No the desired way/method to get “features” activated on regular Bitcoin nodes operators. This disrespects their sovereignty.
If a “feature” has value, then it should be activated on the field by their demanders; given that it’s being offered already by the software.
petertodd
commented at 9:34 am on August 19, 2023:
contributor
Repeatedly seeking “citations” for 0-conf use cases is not the way to convince people that your PR should be merged. You made the PR, seeking to change a long-standing default value. The onus in on you to show us that your PR will not break existing use cases. Forcefully demanding users and supporters of 0-conf/FSS policies to show their data is fallacious shifting of burden of proof. If you don’t think these use cases exist, go ahead and prove it.
Proving it is is exactly what I am doing, in multiple ways. For example:
Challenging people to demonstrate actual production use-cases that rely on first-seen mempool policy. People have failed to do that, even companies claiming to offer such services.
Proving that over 31% of hash power is mining full-rbf. Relying on first-seen is obviously nuts when so many miners ignore it. So it’s no wonder that people continually fail to provide examples of such use-cases: those use-cases are broken and people have stopped doing that.
Demonstrating that services that previously relied on first-seen have stopped doing so.
It used to be the case that lots of BTC<->altcoin exchange services would accept Bitcoin with zero confirmations and no KYC. Those services have all stopped doing that because doing so gets you exploited, over and over again. People have lost literally hundreds of thousands of dollars unsuccessfully trying to accept unconfirmed transactions.
Similarly, Bitrefill used to accept unconfirmed transactions. They’ve stopped doing that. No doubt because it’s just too easy to exploit.
Your own views on mempool policies are not infallible. Users of 0-conf/FSS have their own reasons and that itself should be respected. Being dismissive and browbeating others into submission does nothing to support your cause.
We are quite willing to discuss mempool policies that attempt to prevent actual use of Bitcoin: #28217 (note ACKS by active Core devs) and we have merged similar policies in the past (eg the dust rule).
Eliminating a broken policy that people don’t actually use, in exchange for many other benefits, makes a lot of sense.
russeree
commented at 10:02 pm on August 20, 2023:
contributor
Concept ACK : RBF is a larp.
ChrisMartl
commented at 5:43 am on August 21, 2023:
none
Concept ACK : RBF is a larp.
Expected a high quality rationale from someone advocating for logic and rationally.
We are still in the struggle of two vision for the Bitcoin system:
One controlled by every node operator and highly decentralized. (nobody alone controls)
One controlled by a few very highly capitalized entity node operators and highly centralized.
(a committee controls)
Kruwed
commented at 12:08 pm on August 21, 2023:
none
ACK. mempoolfullrbf=0 incentivizes the formation of an “Evil Mempool/Private Mempool” since the most economical transactions are censored instead of broadcast. This would harm the underlying security of the network and make fee estimation less accurate.
ChrisMartl
commented at 12:27 pm on August 21, 2023:
none
formation of an “Evil Mempool/Private Mempool”
What is an “evil” or private mempool?
since the most economical transactions are censored instead of broadcast
What is your source or rationale to base that opinion?
This would harm the underlying security of the network
What do you mean with “security” in this context?
make fee estimation less accurate.
By whom or how is a fee estimation made less accurate? What is “the” fee reference?
DrahtBot added the label
Needs rebase
on Aug 29, 2023
ariard
commented at 3:12 pm on August 29, 2023:
member
It’s pretty simple. What you said was “I do have few technical questions for the users running zero-conf in an economic
fashion”. (emphasis mine) That statement gives the clear impression that you think those users actually exist in non-trivial > numbers. Since no-one has provided any hard evidence they do, that’s misleading.
My statement was only an invitation to those users, if their actually exist in non-trivial numbers, to give provide relevant technical and economic information to the present discussion. From my experience of last year initial mempoolfullrbf deployment and some users showing up to defend the status quo (cf. Muun’s mail) more than I expected I think the good communication practice is to give the opportunity and relative time for such potential users to give their say. In matters of Bitcoin protocol upgrades, you never know if the lack of opposition is the lack of opposing users, or the lack of awareness of such existing opposing users.
As for 0-conf channels, none of the actual deployed ones (eg Phoenix) rely on first-seen. Phoenix even sets the BIP125
flag on their LN-related on-chain transactions, and they do not accept on-chain payments without confirmation. If you are > aware of another deployed in production LN implementation that does, I’d like to know, because that’s clearly dangerous
and they should stop.
I’m not ware of another deployed in production LN implementation / services that does 0-conf channels, though for your awareness zero-conf dual-funding / splicing can be expected to become a real-world usage (cf. Phoenix dev mail), where mempool pinning becomes a liquidity griefing. Even if this real-world usage brings risks, I think it’s a reasonable trade-off on the liquidity management dimension.
Maybe you’re missing this because of english not being a first language, but the word “dubious” in this context has
significantly different connotations, particularly as you were implying that Bitcoin Optech themselves had characterized
my research as such.
For sure it was unclear to me if in this context what was called dubious by Optech, either the measurement methodology, or the outcome of the measurement themselves. I think debating a measurement methodology is always a good conversation to have, history of science is sparked with epistemology controversies.
My OTS research was done with transactions that were usually much more than 30 seconds between replacements. That > research has already been done and clearly shows full-RBF mining. After all, in addition to my transactons, there’s plenty
of other sources of full-RBF replacements, and plenty of services such as https://mempool.space/rbf and
https://fullrbf.mempool.observer/ observing those replacements happening. This isn’t an occasional propagation glitch. At > this point I believe denying the obvious is harmful, as it misleads people about the risks of unconfirmed transactions.
To be fair I’ve looked on myself on few of those observation devices showing some hints of full-RBF mining after last year initial mempoolfullrbf deployment. I don’t think at that stage it’s an occasional propagation glitch, though to clarify my intent I think it’s valuable to spend time discussing what we think is a proven method to demonstrate phenomena on the transaction-relay network. I don’t think it will be the last time we’ll have as an ecosystem a controversy on policy rules deployment. While I agree on misleaded people not understanding the risks of unconfirmed transactions there will always a trade-off to appreciate between moving forward with a protocol upgrade deployment lacking enough consensus and as such raising more discussion and taking time to build more technical ground and understanding of said protocol upgrade.
I’ll ask you a simple question: do you think any miners are mining full-RBF at the moment?
Yes and I think from my memory of last year full-rbf transactions propagations simulations, if 10% of the transaction-relay nodes (not mining nodes) are running the flags with true, in practice it might be logically equivalent to the majority of nodes running full-rbf.
petertodd force-pushed
on Aug 31, 2023
petertodd force-pushed
on Aug 31, 2023
DrahtBot removed the label
Needs rebase
on Aug 31, 2023
cryptoquick
commented at 5:34 am on September 7, 2023:
none
As for whether double-spending is easier because of RBF, replacing payments in an open global network protocol with adversarial untrusted distributed consensus cannot be guaranteed until a transaction is mined. Anyone pretending the case is anything to the contrary is making promises Bitcoin can’t keep and has technically never been able to keep. Zeroconf is peddling snake oil.
Or, to put it even more succinctly: RBF is a larp.
petertodd
commented at 1:57 pm on September 7, 2023:
contributor
On Wed, Sep 06, 2023 at 10:34:22PM -0700, Hunter Beast wrote:
That’s not a one-off event. According to mempool’s data at the moment there’s
dozens of full-RBF spends getting mined, with significant fees associated with
them.
DrahtBot added the label
CI failed
on Oct 24, 2023
DrahtBot removed the label
CI failed
on Oct 25, 2023
hashbender
commented at 6:43 pm on November 3, 2023:
none
It would be nice if it was on by default
ariard
commented at 8:12 pm on November 3, 2023:
member
I think it’s good to communicate on the mailing list in which version (27.0 or 28.0) full-rbf might be turn on by default. I advocated such setting in the past as early as 0.24, though at the time some 0-conf transactions applications and services were migrating their stuff in consequence.
petertodd
commented at 8:40 pm on November 3, 2023:
contributor
Well it’s certainly not going to be in 26, as we’re releasing it now.
If we actually merge this soonish I’ll make a post saying it will come out in 27.0. I can also write some release notes if people want them.
Right now Antpool is the largest pool, and it’s still mining full-rbf, along with all the others mentioned above. (Luxor recently turned it back on; as Nick alluded to, looks like they unintentionally had it turned off) So IIRC we’re at ~40% of hash power mining it.
On November 3, 2023 5:12:32 PM GMT-03:00, Antoine Riard @.***> wrote:
I think it’s good to communicate on the mailing list in which version (27.0 or 28.0) full-rbf might be turn on by default. I advocated such setting in the past as early as 0.24, though at the time some 0-conf transactions applications and services were migrating their stuff in consequence.
petertodd
commented at 8:42 pm on November 3, 2023:
contributor
On November 3, 2023 5:12:32 PM GMT-03:00, Antoine Riard @.***> wrote:
I think it’s good to communicate on the mailing list in which version (27.0 or 28.0) full-rbf might be turn on by default. I advocated such setting in the past as early as 0.24, though at the time some 0-conf transactions applications and services were migrating their stuff in consequence.
Daniel600
commented at 6:53 am on November 6, 2023:
none
I think it’s good to communicate on the mailing list in which version (27.0 or 28.0) full-rbf might be turn on by default. I advocated such setting in the past as early as 0.24, though at the time some 0-conf transactions applications and services were migrating their stuff in consequence.
HI @ariard - has this PR been decided to be merged already? What would the timeline to expect if it will be released with 27.0 or 28.0? (i.e When should we expect 27.0 or 28.0 to released?)
At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023. If you wish to discuss with Changelly or Coinspaid to get further feedback on our service to them - please let me know and I am happy to connect you.
This major Bitcoin protocol change will most likely result in services wanting to offer 0-conf to
Only be able to offer 0-conf to trxs originating from know custodial wallets - a common service block analytics companies provide. (Major drop in privacy)
Pushing and encouraging users to move away from use with BTC. (May be viewed as a type of censuring)
A significant drop in the max trx size these services will be able to recognise on 0-conf - estimated to be below 50USD per trx. (May be viewed as type of censuring)
The 0-conf use case and original first seen protocol design can be retained very easily by just adding first seen protection to FULLRBF.
I believe the above information is highly pertinent when considering wether to merge this PR or not.
YellowRoseCx
commented at 8:09 am on November 6, 2023:
none
I think it’s good to communicate on the mailing list in which version (27.0 or 28.0) full-rbf might be turn on by default. I advocated such setting in the past as early as 0.24, though at the time some 0-conf transactions applications and services were migrating their stuff in consequence.
HI @ariard - has this PR been decided to be merged already? What would the timeline to expect if it will be released with 27.0 or 28.0? (i.e When should we expect 27.0 or 28.0 to released?)
At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023. If you wish to discuss with Changelly or Coinspaid to get further feedback on our service to them - please let me know and I am happy to connect you.
This major Bitcoin protocol change will most likely result in services wanting to offer 0-conf to
Only be able to offer 0-conf to trxs originating from know custodial wallets - a common service block analytics companies provide. (Major drop in privacy)
Pushing and encouraging users to move away from use with BTC. (May be viewed as a type of censuring)
A significant drop in the max trx size these services will be able to recognise on 0-conf - estimated to be below 50USD per trx. (May be viewed as type of censuring)
The 0-conf use case and original first seen protocol design can be retained very easily by just adding first seen protection to FULLRBF.
I believe the above information is highly pertinent when considering wether to merge this PR or not.
0-conf transaction protections wouldn’t necessarily work with BTC (they would technically), but realistically if the block weight can stays as limited as it is, then there will be transactions that stay forever in the unless there’s a significant drop in network usage allowing 1sat/b transactions to confirm. If a service accepts 0-conf, they’re never realistically guaranteed to get the coins confirmed even if the double spend protections are put in place. The reason why 0-conf transactions with double spend protections are acceptable on “contentious forks” is because they’re guaranteed to always be included in the next block and don’t have an easy way to double spend the coin like RBF allows
The problem that RBF is trying to solve could simply be solved by increasing the acceptable blockweight. This is especially significant with another halvening to occur soon. It would lower the transaction fees, guarantee next-block-confirmation, and allow a scalable income to miners by allowing more transactions and usage rather instead of continuously rising transaction fees that in turn, prevent normal people from using Bitcoin and turning Bitcoin into something only companies and wealthy individuals can afford to use.
Even if Core’s plan is to funnel users away from Bitcoin’s network to the Lightning Network, the LN whitepaper states for the BTC network to accommodate the 2016 world population with only 2 transactions per year(opening LN channel and closing LN channel), it would need the equivalent of a 133mb block size. That’s not even considering that there will always be individuals or companies who want to make more than 2 transactions per year and are able to pay a higher fee than everyone else, which in turn would cause some people to never have their LN channels open or close, pushing them towards centralized services. Even if we look at 1% of the population making 20 transactions per year, that would need at least the equivalent of a 13mb blocksize per year (not considering those who would pay more to bump some of the people’s transactions down)
Replace by fee is simply a bandaid on a much bigger issue and causes Bitcoin to stray further away from a simple to use, cheap to transact, decentralized electronic cash it was created to be.
achow101
commented at 3:49 pm on November 6, 2023:
member
has this PR been decided to be merged already?
No. No decision has been made as to whether this PR will or will not be merged.
ariard
commented at 8:02 pm on November 6, 2023:
member
HI @ariard - has this PR been decided to be merged already? What would the timeline to expect if it will be released with 27.0 or 28.0? (i.e When should we expect 27.0 or 28.0 to released?)
For your clarity and wider transparency, to the best of my understanding, we don’t have a decision process among the community about mempool policy changes affecting Bitcoin applications in a wide scale fashion, as mempoolfullrbf is I believe one of them. I think the best process we might have when such changes are proposed is to dicuss them on the mailing list and other bitcoin public development forum. By experience, it’s always a matter of trade-offs.
Personally, my position is still the same since 2021, I’m still advocating to turn on RBF by default to simplify multi-party transaction flows as I explained here on the mailing list or it is explained on the PR author blog’s here.
I thkn we’re still stuck on building technical consensus among the community on a transaction-relay policy design philosophy, something I’m still a bit to blame for as I never answered AJ mail of 2022 here on this very subject. I think the same conceptual divergences as showed up again with #28220.
I’ll do my best to draft an in-depth answer to AJ, notably to integrate some recent discovery in matters of policy design trade-offs (cf. “The Pinning & Replacement Problem Set” discussion on the mailing list) during the coming years, though if someone else wanna carry on the technical design philosophy discussion to move forward faster, please feel free to do so.
edited: to add missing hyperlink to AJ post “On mempool policy consistency"
nerd2ninja
commented at 9:03 pm on November 6, 2023:
none
This major Bitcoin protocol change will most likely result in services wanting to offer 0-conf to
Only be able to offer 0-conf to trxs originating from know custodial wallets - a common service block analytics companies provide. (Major drop in privacy)
Pushing and encouraging users to move away from use with BTC. (May be viewed as a type of censuring)
A significant drop in the max trx size these services will be able to recognise on 0-conf - estimated to be below 50USD per trx. (May be viewed as type of censuring)
There is a limited bandwidth to relay blocks between nodes you can’t scale on blocksize alone and that’s why thus far the consensus on how to scale Bitcoin has been through layer 2 solutions. So this entire block is out of touch with the current design philosophy which is to accept payments on second layers and use the first layer to manage and resolve disputes within that second layer.
DrahtBot added the label
Needs rebase
on Nov 13, 2023
petertodd force-pushed
on Nov 13, 2023
petertodd
commented at 8:18 pm on November 13, 2023:
contributor
At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023.
Have you actually tested full-RBF double spends against your service? Because at the moment, about 40% of hash power is mining with full-RBF enabled. So the chance of a full-RBF double-spend succeeding is approximately 40%.
As an example, here in El Salvador the Chivo ATMs accept transactions with BIP125 RBF enabled about half the time in my testing, immediately giving cash USD in exchange for a transaction that can be trivially replaced by 100% of miners. Since Chivo ATMs have AML/KYC by virtue of the fact that they require a phone number, which in turn requires AML/KYC to obtain in El Salvador, they are in fact relying on AML/KYC for double spend protection rather than mempool policies.
It would not be surprising if you’re claimed low rate of double-spends is purely because the services involved are not vulnerable. As I mentioned before, in my discussions with (IIRC) Changelly, they confirmed that they do not use GAP600 to secure transactions coming from untrusted sources.
DrahtBot removed the label
Needs rebase
on Nov 13, 2023
hf5pro
commented at 9:55 am on November 16, 2023:
none
The problem that RBF is trying to solve could simply be solved by increasing the acceptable blockweight.
At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023.
Have you actually tested full-RBF double spends against your service? Because at the moment, about 40% of hash power is mining with full-RBF enabled. So the chance of a full-RBF double-spend succeeding is approximately 40%.
As an example, here in El Salvador the Chivo ATMs accept transactions with BIP125 RBF enabled about half the time in my testing, immediately giving cash USD in exchange for a transaction that can be trivially replaced by 100% of miners. Since Chivo ATMs have AML/KYC by virtue of the fact that they require a phone number, which in turn requires AML/KYC to obtain in El Salvador, they are in fact relying on AML/KYC for double spend protection rather than mempool policies.
It would not be surprising if you’re claimed low rate of double-spends is purely because the services involved are not vulnerable. As I mentioned before, in my discussions with (IIRC) Changelly, they confirmed that they do not use GAP600 to secure transactions coming from untrusted sources.
Its not a requirement that our clients perform KYC and in general we dont inquire about it. GAP600 services customers who in most cases do not perform KYC for the trxs they are sending us - these include direct merchants, payment processors and non-custodial liquidity providers.
In general non custodial liquidity providers only perform KYC on high risk or on trx above a certain threshold. This is based on recent discussions I have had with some of them. Non custodial liquidity providers partner with non custodial wallets providers and have commercial relationships with them. So I would think that is the above feedback from Changelly is referencing.
We have seen double spends on our platform which have been caused by FullRBF and our system has obviously not been able to detect them beforehand - not a significant amount but we have seen them.
Our service rests on the first seen rule. Based on our experience a trx with confirmed inputs, reasonable fee, not seen conflicting trx for 5-7 seconds - is reliable. Also the trxs do not happen in a vacuum but rather in commercial exchanges with expected characteristics.
Why would first seen safe FullRBF i.e requiring at least same outputs as replaced transactions - not be able to achieve the goals of this PR?
petertodd
commented at 10:31 am on November 24, 2023:
contributor
Our service rests on the first seen rule. Based on our experience a trx with confirmed inputs, reasonable fee, not seen conflicting trx for 5-7 seconds - is reliable. Also the trxs do not happen in a vacuum but rather in commercial exchanges with expected characteristics.
Again, you still have refused to answer my question: Have you actually tested full-RBF double spends against your service?
kilrau
commented at 6:43 pm on December 5, 2023:
none
Is there another source for up-to-date full-rbf pool adoption?
petertodd
commented at 7:09 pm on December 5, 2023:
contributor
On December 5, 2023 1:43:28 PM EST, Kilian @.***> wrote:
Is there another source for up-to-date full-rbf pool adoption?
nvk
commented at 1:38 pm on December 19, 2023:
none
ACK
The current high fee environment is giving a good example as to why is so important to make this behaviour default.
michaelfolkson
commented at 2:04 pm on December 19, 2023:
contributor
Concept ACK. I always saw this as inevitable as it reduces mempool reasoning complexity and the supposed merits of zero conf discussion has been done to death.
EthnTuttle
commented at 3:28 pm on December 19, 2023:
none
Ack.
brandonblack
commented at 5:15 pm on December 19, 2023:
none
ACK
(Re-upping)
pox
commented at 6:07 pm on January 1, 2024:
contributor
ACK
DrahtBot added the label
CI failed
on Jan 12, 2024
petertodd force-pushed
on Feb 3, 2024
petertodd
commented at 8:58 am on February 3, 2024:
contributor
I updated the numbers and rebased the pull-req.
We should get this merged for the next release. It’s pretty silly to have a default mempool policy that only 30% of hash power is following.
DrahtBot removed the label
CI failed
on Feb 3, 2024
YellowRoseCx
commented at 7:14 pm on February 10, 2024:
none
I updated the numbers and rebased the pull-req.
We should get this merged for the next release. It’s pretty silly to have a default mempool policy that only 30% of hash power is following.
Over 80% of the network’s hashpower was once signalling for SegWit2x, but that much hashrate approval didn’t matter regarding implementations of changes then. Plus, a default Replace-By-Fee will just make BTC harder to use as a transactional currency without having to go through a medium, “and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads…the earliest transaction is the one that counts.”
kristapsk
commented at 7:21 pm on February 10, 2024:
contributor
Over 80% of the network’s hashpower was once signalling for SegWit2x, but that much hashrate approval didn’t matter
Segwit2x was change in consensus rules, a hardfork, full-RBF is not, it’s mempool policy, which isn’t part of consensus.
kilrau
commented at 11:02 am on February 12, 2024:
none
Plus, a default Replace-By-Fee will just make BTC harder to use as a transactional currency
That’s part of the goal. (Micro-) transactional use cases should use Layer 2.
Anyhow, it doesn’t matter. I can only speak for Boltz, but for us this train has left the station. Only one pool accepting fullrbf and it’s not safe to accept 0-conf anymore. Game over. It took a while to grow on me, give it some time.
ACK
DrahtBot added the label
CI failed
on Feb 12, 2024
petertodd force-pushed
on Mar 10, 2024
petertodd force-pushed
on Mar 10, 2024
petertodd force-pushed
on Mar 10, 2024
DrahtBot removed the label
CI failed
on Mar 10, 2024
MaxHillebrand
commented at 11:27 am on March 15, 2024:
none
cACK, this would be helpful for Wasabi Wallet.
orangesurf
commented at 1:39 pm on April 16, 2024:
none
An update to @petertodd’s stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF’d transactions from within the past 24 hours.
petertodd
commented at 5:56 pm on April 16, 2024:
contributor
Thanks for the update! I noticed you didn’t include Ocean. While they aren’t of significant hash power, they do in fact do full-rbf for some of their hash power as they give miners an option of picking Knots (full-rbf) or Core (defaults) templates.
tl;dr: their coordinator assumes that if a double spend is detected of lower fee-rate, the coinjoin will most likely win anyway regardless of BIP-125, so the round should be continued. This improves their resistance against the DoS attack of double spending your output to get a coinjoin round cancelled. They’re also running their nodes with full-rbf enabled. Of course, this would all work more reliably if full-rbf was enabled by default.
On April 16, 2024 9:40:01 AM EDT, orangesurf @.***> wrote:
An update to @petertodd’s stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF’d transactions from within the past 24 hours.
ariard
commented at 6:23 pm on April 18, 2024:
member
An update to @petertodd’s stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF’d transactions from within the past 24 hours.
97.7 % of hashrate is just overwhelming in matters of hashrate support for mempoolfullrbf. I’m still curious if anyone has data on the additional accumulated absolute fee traffic yielded by non-opting replacement that would have not propagated under lack of mempoolfullrbf support, since we introduced it in Bitcoin Core 24.0. I’m assuming mostly wallet developers have not changed lack of opt-in signaling RBF since mempoolfullrbf was introduced.
I think the quantitative information can be interesting for future transaction-relay policy changes and characterizing the “incentives susceptibility” of miners (i.e % of average block template income motivating the adoption of new software / custom settings by miners).
petertodd
commented at 0:20 am on April 19, 2024:
contributor
On Thu, Apr 18, 2024 at 11:24:20AM -0700, Antoine Riard wrote:
An update to @petertodd’s stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF’d transactions from within the past 24 hours.
97.7 % of hashrate is just overwhelming in matters of hashrate support for mempoolfullrbf. I’m still curious if anyone has data on the additional accumulated absolute fee traffic yielded by non-opting replacement that would have not propagated under lack of mempoolfullrbf support, since we introduced it in Bitcoin Core 24.0. I’m assuming mostly wallet developers have not changed lack of opt-in signaling RBF since mempoolfullrbf was introduced.
Possibly the best estimate we can get for that is to look at full-RBF
replacements that do not get mined. It’s not too uncommon to see, for example,
OpenTimestamp’s full-RBF replacements mysteriously get mined at the second or
third highest fee-rate they were propagated at even though multiple minutes
have passed since the higher fee-rate txs were broadcast. I believe that is
evidence of poor propagation to miners on occasion.
Anyway, at this point the better argument is that full-RBF is clearly what
miners have chosen to run, and by rejecting those transactions by default,
we’re pointlessly harming block propagation and fee estimation, among other
use-cases.
There’s also an argument that full-RBF mitigates miner-extractable-value
issues: since anyone can broadcast a full-RBF replacement, it reduces the need
for miners to actually invest in the software necessary to find the optimal
transations, as others can do it for them and simply pay fees. This is exactly
what we’re regularly seeing in full-RBF bidding wars right now.
levantah
commented at 12:30 pm on April 19, 2024:
none
Possibly the best estimate we can get for that is to look at full-RBF replacements that do not get mined. It’s not too uncommon to see, for example, OpenTimestamp’s full-RBF replacements mysteriously get mined at the second or third highest fee-rate they were propagated at even though multiple minutes have passed since the higher fee-rate txs were broadcast. I believe that is evidence of poor propagation to miners on occasion.
Just a reminder that there is still this “too many replacements” and I think it can play a part here:
0~/src/bitcoin$ git grep "too many potential replacements"1src/policy/rbf.cpp: return strprintf("rejecting replacement %s; too many potential replacements (%d > %d)\n",
2src/validation.cpp: strprintf("too many potential replacements%s", ws.m_sibling_eviction ? " (including sibling eviction)" : ""), *err_string);
3test/functional/feature_rbf.py: assert_raises_rpc_error(-26, "too many potential replacements", self.nodes[0].sendrawtransaction, dbl_tx_hex, 0)4test/functional/feature_rbf.py: assert_raises_rpc_error(-26, "too many potential replacements", self.nodes[0].sendrawtransaction, double_tx_hex, 0)5test/functional/feature_rbf.py: -26, "too many potential replacements", normal_node.sendrawtransaction, tx_hex, 0)6test/functional/mempool_accept_v3.py: rule5_str= f"too many potential replacements (including sibling eviction), rejecting replacement {tx_v3_child_2_rule5['txid']}; too many potential replacements (101 > 100)"
petertodd
commented at 5:09 pm on April 19, 2024:
contributor
The “two many replacements” condition is only triggered when a large number of transactions are replaced at once. OpenTimestamps doesn’t do that.
On April 19, 2024 8:31:20 AM EDT, levantah @.***> wrote:
Possibly the best estimate we can get for that is to look at full-RBF replacements that do not get mined. It’s not too uncommon to see, for example, OpenTimestamp’s full-RBF replacements mysteriously get mined at the second or third highest fee-rate they were propagated at even though multiple minutes have passed since the higher fee-rate txs were broadcast. I believe that is evidence of poor propagation to miners on occasion.
Just a reminder that there is still this “too many replacements” and I think it can play a part here:
0~/src/bitcoin$ git grep "too many potential replacements"1src/policy/rbf.cpp: return strprintf("rejecting replacement %s; too many potential replacements (%d > %d)\n",
2src/validation.cpp: strprintf("too many potential replacements%s", ws.m_sibling_eviction ? " (including sibling eviction)" : ""), *err_string);
3test/functional/feature_rbf.py: assert_raises_rpc_error(-26, "too many potential replacements", self.nodes[0].sendrawtransaction, dbl_tx_hex, 0)4test/functional/feature_rbf.py: assert_raises_rpc_error(-26, "too many potential replacements", self.nodes[0].sendrawtransaction, double_tx_hex, 0)5test/functional/feature_rbf.py: -26, "too many potential replacements", normal_node.sendrawtransaction, tx_hex, 0)6test/functional/mempool_accept_v3.py: rule5_str= f"too many potential replacements (including sibling eviction), rejecting replacement {tx_v3_child_2_rule5['txid']}; too many potential replacements (101 > 100)"
knocte
commented at 6:08 am on April 23, 2024:
contributor
cACK
DrahtBot added the label
CI failed
on May 13, 2024
DrahtBot removed the label
CI failed
on May 13, 2024
DrahtBot added the label
Needs rebase
on May 20, 2024
petertodd force-pushed
on May 21, 2024
DrahtBot removed the label
Needs rebase
on May 21, 2024
DrahtBot added the label
Needs rebase
on Jun 7, 2024
petertodd force-pushed
on Jun 14, 2024
DrahtBot removed the label
Needs rebase
on Jun 14, 2024
ariard
commented at 11:24 pm on June 20, 2024:
member
Possibly the best estimate we can get for that is to look at full-RBF
replacements that do not get mined. It’s not too uncommon to see, for example,
OpenTimestamp’s full-RBF replacements mysteriously get mined at the second or
third highest fee-rate they were propagated at even though multiple minutes
have passed since the higher fee-rate txs were broadcast. I believe that is
evidence of poor propagation to miners on occasion.
This is good information to have. I’ll recall the original motivation which was behind introducing mempoolfullrbf was removing a zero-cost transaction-relay jamming affecting multi-party transaction broadcast (cf. “On Mempool Funny Games against Multi-Party Funded Transactions”).
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 mempoolfullrbf=true nodes.
Reviewed code change at 512278e.
petertodd
commented at 0:58 am on June 21, 2024:
contributor
Possibly the best estimate we can get for that is to look at full-RBF
replacements that do not get mined. It’s not too uncommon to see, for example,
OpenTimestamp’s full-RBF replacements mysteriously get mined at the second or
third highest fee-rate they were propagated at even though multiple minutes
have passed since the higher fee-rate txs were broadcast. I believe that is
evidence of poor propagation to miners on occasion.
This is good information to have. I’ll recall the original motivation which was behind introducing mempoolfullrbf was removing a zero-cost transaction-relay jamming affecting multi-party transaction broadcast (cf. “On Mempool Funny Games against Multi-Party Funded Transactions”).
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 SIGHASH_ANYONECANPAY transactions or coinjoins. Enabling full-RBF in Core would at least be a start to mitigating these issues.
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 mempoolfullrbf=true nodes.
Thanks! You might want to formally Tested ACK it so the bot picks it up.
levantah
commented at 6:09 am on June 21, 2024:
none
I would just like to note that @fjahr is counted as NACK by mistake (read fully his comment which is just mentioning that the other he is replying to can “give a NACK”).
Tested ACK as I run fullrbf nodes aver since the configuration option appeared and this change just chenges the default.
levantah
commented at 6:10 am on June 21, 2024:
none
I saw also my previous comment was counted wrong. But this fixes it:
Tested ACK
fjahr
commented at 8:28 am on June 21, 2024:
contributor
I would just like to note that @fjahr is counted as NACK by mistake (read fully his comment which is just mentioning that the other he is replying to can “give a NACK”).
I didn’t notice, I gave @DrahtBot a 👎 so it should be removed.
ariard
commented at 9:51 pm on June 25, 2024:
member
Tested ACK512278e
Manual mutation testing with following diff:
0diff --git a/src/kernel/mempool_options.h b/src/kernel/mempool_options.h
1index 4e1e24a11d..0850b2e60e 100644 2--- a/src/kernel/mempool_options.h
3+++ b/src/kernel/mempool_options.h
4@@-22,7+22,7@@static constexpr unsigned int DEFAULT_BLOCKSONLY_MAX_MEMPOOL_SIZE_MB{5};
5/** Default for-mempoolexpiry, expiration time for mempool transactions in hours */ 6static constexpr unsigned int DEFAULT_MEMPOOL_EXPIRY_HOURS{336};
7/** Default for-mempoolfullrbf, if the transaction replaceability signaling is ignored */ 8-static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{true};
9+static constexpr bool DEFAULT_MEMPOOL_FULL_RBF{false};
10/** Whether to fall back to legacy V1 serialization when writing mempool.dat */11static constexpr bool DEFAULT_PERSIST_V1_DAT{false};
12/** Default for-acceptnonstdtxn */13diff --git a/test/functional/mempool_accept_v3.py b/test/functional/mempool_accept_v3.py
14index 5e722724b9..6f11683a9c 10075515--- a/test/functional/mempool_accept_v3.py
16+++ b/test/functional/mempool_accept_v3.py
17@@-162,7+162,6@@class MempoolAcceptV3(BitcoinTestFramework):
18 self.check_mempool([tx_v3_bip125_rbf_v2["txid"], tx_v3_parent["txid"], tx_v3_child["txid"]])
192021- [@cleanup](/bitcoin-bitcoin/contributor/cleanup/)(extra_args=["-mempoolfullrbf=0"])
22deftest_v3_bip125(self):
23 node = self.nodes[0]
24 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.
DrahtBot requested review from jaonoctus
on Jun 25, 2024
DrahtBot requested review from brandonblack
on Jun 25, 2024
DrahtBot requested review from luke-jr
on Jun 25, 2024
DrahtBot added the label
Needs rebase
on Jul 3, 2024
Enable full-rbf by defaultc57a4a8573
Add release notes for full-RBF.fbdc61ed54
petertodd force-pushed
on Jul 5, 2024
DrahtBot removed the label
Needs rebase
on Jul 5, 2024
levantah
commented at 3:55 pm on July 5, 2024:
none
ACKfbdc61e
DrahtBot requested review from ariard
on Jul 5, 2024
levantah approved
willcl-ark
commented at 11:26 am on July 12, 2024:
member
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.
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-12-21 15:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me
