This is also how mempoolfullrbf got in. I had support from the author and some other core devs for a PR to remove it before release, but they said that because it was already scheduled for release in some weeks, it was me trying to change consensus. Since when his Core release schedule a method of consensus? The custom is that a clearly controversial change that disrupts the user space would at least be postponed, but no rational argument would be accepted.
reply
You had no business defending your broken business model and fundamental misunderstanding of fullrbf in the first place, so lets not pretend that these issues are at all related.
There is an issue here, but it's not your misunderstanding of the security of 0 conf transactions or node relay policy or the inclusion of settings and configuration option enabling users to configure their relay policies as they please - and as they already could with more effort or alternative clients. Lets not conflate your misunderstanding with the politics of Bitcoin Core development.
reply
He had every right to object to a disruption of existing and appropriately risk-managed 0conf use cases.
Especially so when core contributors were also projecting an explicit desire to turn the default to ON in a future release on the back of its introduction.
I disagree that this isn’t related. Both situations are examples of pushing aside well articulated critique to achieve a false sense of consensus.
reply
As a PR author I still think
mempoolfullrbf is a worthy technical change, especially to avoid discrepancies among network mempool states.Retrospectively this is correct the deployment could have been more smoothed and coordinated to let some use-cases adapt their software.
Overall, I still think the conversation should be zoomed out, it’s missing the point on the role of transaction-relay and mempool policy is playing in the security and operations of modern bitcoin use-cases (e.g Lightning or ordinals), and the de facto technical leverage that Core as a project can exercise on them. It’s not anyone responsibility though kinda the situation we’re in today.
Highlighted community awareness on this subject as early as 2021:
https://bitcoinops.org/en/newsletters/2021/05/19/
reply
Luke is also the developer who originally contributed the datacarrier and datacarriersize config options to Bitcoin Core back in 2014
Interesting, if he was planning on doing something akin to inscriptions back then, and was trying to keep the door open for them at the time. Perhaps even while convincing the devs to ACK based on their understanding the change in the way that it is now defined.
So, is it that devs are manipulating things now, or is it that Luke was manipulating things back then?
reply
To the best of my understanding, back then Luke was working to try to restrain OP_RETURN data blobs with the (still active) spam filter we all know and love (max 80 bytes).
This is basically what
datacarriersize is.Here are the revelant Pull Requests:
https://github.com/bitcoin/bitcoin/pull/3715
https://github.com/bitcoin/bitcoin/pull/5077
reply
See one of my underlying comments on the impact of transaction-relay and mempool policy on the operations of modern Bitcoin use-cases, such as inscriptions.
My technical position would be more to dry-up such policy in terms of consensus rules, i.e identically enforced by all peers of the Bitcoin network rather to keep multiplying the jungle of special policy rules, where a single change can break your whole use-case.
We’ll always have to deal with mempool policy, yet it might be more wise to keep it minimal and differentiating as less as we can among types of Bitcoin use-cases (unless for reasons on on-chain economic traffic ? even that proposal might be contentious).
reply
datacarriersizeconfig option from:datacarrierto also catch inscriptions. Then Gloria Zhao and Ava Chow (Bitcoin Core maintainers with commit access) used that new meaning ofdatacarriersizeas an argument to reject the fix (for non autists: inscriptions store they data in the input section of transactions, while "scriptPubKey" means output, so they narrowed the applicability ofdatacarriersizein its description text).datacarrieranddatacarriersizeconfig options to Bitcoin Core back in 2014. They redefined the meaning of his contribution in his face to be able to reject his new work more comfortably.datacarriersize: