I don't agree with all the stuff Vortex says nor the way it is said, but this is a solid expression of why I disagree with bip 110 and the approach taken by the anti-spam side in general:
Consensus rules validate transaction structure and cryptographic correctness not content and that's not a "filter", that's protocol enforcement.
See there's a massive difference between "does this tx follow the rules" and "do I like what's in this tx."
A valid transaction that pays market-rate fees IS using Bitcoin as designed as the fee market is the spam filter so if someone pays to put data in a valid transaction, by what objective standard are you calling it spam?
"Not required for integrity" is subjective, the consensus rules already define what's required and if the tx passes them, it passed.
Again what you're actually proposing is adding a subjective content layer on top of objective consensus rules and again that's not maintaining Bitcoin that's changing its neutrality model.
Vortex ends with this, which strongly resonates:
And the moment you let someone decide which valid transactions are "spam" you've introduced the exact central authority Bitcoin was built to eliminate.
I’m not sure what the subjective part is. Aren’t they trying to reduce the cap on arbitrary data storage, regardless of the content of that data?
That seems like a change to the objective rules.
I see the subjective part being a decision to identify some valid transaction types as bad and to be banned while leaving other valid transaction types alone. How do we decide which transaction types are spammable and which are not?
If we treat Bitcoin as objective, a valid transaction would be a valid transaction.
Now, I've heard from BIP 110 supporters that I'm being too literal in my argument and that if I held this rule of never removing the validity of a transaction, we'd never be able to change any of Bitcoin's rules.
I don't find this very compelling, though. I think there is a significant difference between banning a transaction type that is in fairly widespread use and banning a transaction type that was purposefully left undefined for future upgrades.
No one is saying the people who make spam transactions don't care about them or are content to let them be frozen. The argument is that those valid transactions are bad, immoral, harmful to bitcoin, or just not what we like. This is subjective. People may use the let's fork and ban method now on spam, but who's to say they won't use it on transactions made by criminals next?
Maybe this is where I’m confused. Are they seeking to ban valid transactions or change the criteria for being a valid transaction?
Same thing, isn't it?
There’s nothing sacred about the current cap on arbitrary data storage, whatever it is.
I don’t see why it’s not just a practical question whether or not this different cap is functionally better.
Nothing here is about blocking who can make transactions or what they are allowed to purchase, afaik. That concern seems entirely unrelated.
This is how I think about it:
Everyone agreed that a certain set of transaction types could be included in a valid block.
One group of people has decided they don't like the transactions a different group is using, and are advocating a change to what can go in a valid block so that such transactions can no longer be included in a block.
My understanding of most changes to block validation rules is that they have been designed not to remove previous ways of transacting. BIP 110 is a significant departure from this philosophy in that it's only purpose is to remove previous ways of transacting.
How would this process look different if it was a government entity pushing for a rule change that made blocks with txs containing OFAC-banned addresses invalid?
That’s different because it introduces a new party to the validation process who is outside of the network.
I’m not anything like an expert on code improvements but when an upgrade includes things designed to remove vulnerabilities aren’t those reductions in what someone can do with bitcoin?
I will also admit to not being an expert on code improvements, but as far as I have learned, rule changes designed to address vulnerabilities (or upgrades in general) have never targeted things that were commonly being done with bitcoin transactions.
In the case of the inflation bug in 2010, someone clearly expected to be able to create more bitcoin than 21 million. The soft fork that changed this certainly was a reduction in what that person thought they could do with bitcoin.
However, I don't think such a case is very much like the case we are dealing with now regarding spam.
In general, I suspect (without much real evidence, I'll admit) that vulnerability fixes in Bitcoin have usually confined themselves to altering code to return to expected behavior.
This, I believe, is where BIP 110 proponents would say spam is not part of the expected behavior of bitcoin. I agree with this. However, I don't think spam is going to be pinned down to any one kind of transaction. And I think the transaction types they want to prevent are part of expected behavior.
Bitcoin has many kinds of transactions. How are we supposed to decide when one kind of transaction is being abused enough to warrant stopping everyone from using Bitcoin in that way?
As far as I can tell, introducing a new party to the validation process that is outside the network is exactly the plan: "spam" will be determined by some third party called "the community" or which only includes people who are "not spammers" and who are "good bitcoiners" -- all of which is entirely subjective.
Via the BIP
Fair enough. I’m trying to get at a different point though.
If there’s an exploit somewhere, pointing out that it’s within the rules is an odd critique because no one disagrees. The argument should be about whether the new rules would be better or worse.
I've never believed in the concept of spam on a network such as this with a fee market. I didn't think 2 or 4mb blocks were a good idea but if prunable then fine. I appreciate what LukeJr has always been trying to do but I think he's missing the cost that comes with pushing such a soft fork. I don't see it passing which is probably for the best.
100%.
appeal to emotion.
spam is spam. there's nothing wrong with coordinating among peers to disincentivize it.
this sort of shit is the result of the stupid block size wars where somebody wanted to make money quickly, and needed centralizing changes. compromises were made, after the "industry" pushed for 4mb blocks, and we wound up with 2mb blocks.
The BIP 110 approach is to go down a road of perpetual 51% attacks to root out spam. What make me nervous is that they want Bitcoiners to get used to the idea of "bad" valid transactions. If we go down this road, I have zero confidence that we stop with spam.
well...
First of allFirst of all
it's your node... so do what you want.
personally, I'm still running a version lower than 24. I respect your right to do whatever you want with your hardware (to the extent that your hardware will support it).
some years ago, I ran Core™️'s software on a raspberry pi 3... you might have noticed that's no longer an option, because that device can no longer process the UTXO set through IBD.
I like to take it slow with my savings and I hadn't formed an opinion about BIP110 until Feb 6th, just moments before sending a friend who's a bitcoin dev a message:
Secondly (of all)Secondly (of all)
I'll be honest that when I read this, it felt like you hadn't yet read the BIP:
Back in the days of the Captain Crunch whistle, it was possible to make the phone company's computer think a valid phone call was being made on the payphone network. That wasn't a valid phone call, it was an exploit. The p2p cash network is being exploited for data storage.
And then, your follow-up statement:
This is specifically addressed in the BIP.
Lastly (for now)Lastly (for now)
Until v30 you (and your ancestors, who I presume will also be node-operators) were getting hosed by some of the largest, financially aligned network participants leverage fiat financial engineering to make more fiat, in a high-time preference way. So, we pay them for it... but they're not our friends.
Now the developers who forced this mempool policy change through (despite considerable pushback from the community (before retiring from the project, evidently?!?)) have opened up every future user of the software to helping those least-aligned participants get paid to store somebody's backups on every raspberry pi 4 struggling to stand up under an overweight UTXO set, in every poor corner of the earth.
It's a good time to point out that... WE DON'T PAY CORE DEVELOPERS. They're getting paid by somebody tho :) And that's probably something the community should find a better way of addressing. Same is true for politicians in the US... low salary incentivizes influence peddling.
One last thingOne last thing
If you don't like the idea of BIP110 after 1 year, then you just don't adopt any further implementation of it. If the spammers continue to operate afterwards, then we know that style of change is ineffective.
And to this point, at the risk of damaging my own argument in favor of signaling BIP110 (especially since F2Pool refuses to), I think it's important to point out that the better arguments against BIP110 are:
a) Fork riska) Fork risk
Here, I'll add my friend's final remark about BIP110... I imagine I could get more details if I poke around for it, but I don't want to push the issue with somebody who's probably had plenty of talking about it already and might be over it for now.
b) Todd demonstrated BIP110 doesn't stop spamb) Todd demonstrated BIP110 doesn't stop spam
Todd actually demonstrated that BIP110 considerably reduces the impact of this kind of data-backup exploit.
I think this is particularly significant since it's got 2 possible fork points... but, also... the fork wars were also an airdrop, if you were running a node. I do think it's necessary for the community of node-runners to re-engage with the decisive nature of bitcoin. This is a continuous process of taking responsibility for custodianship of our currency from the moneylenders and fraudsters who have done us the honor of no less than a century of total war, destruction of whole societies in the name of laundering money, and doing so in way so as to leave us (the ones who work for our money) arguing amongst ourselves.
Closing this down for real nowClosing this down for real now
Anyway, thanks for the opportunity to put my thoughts together a bit better.
I appreciate your response here, and I agree with many of your points.
I, too, am running an old version of Core. Nor do I have any particular attachment to that project.
I've read the BIP, although I'll certainly admit that I am capable of misunderstanding things. The BIP's statements that "spam is best fought with policy/filters, not consensus" are given the lie by the very fact that RDTS is temporary. Additionally, if one listens to Luke or Dathon or Mechanic, it seems that continual forking is very much in line with the BIP 110 vision.
I think Bitcoin is quite a bit different than a telephone network. And we should be very careful about calling previously valid transaction types "exploits." It may even be the case that with Bitcoin once a transaction type is valid and widely-used, we're stuck with it.
I use bitcoin because it is the best chance I have to resist state control of my money. It achieves this by making it very hard for the state to prevent me from getting my utxos in a confirmed block.
BIP 110 claims to improve this censorship resistance of bitcoin by maintaining low burdens on node runners. But in doing so, it seems to me to sacrifice the confidence a utxo-holder has that they will be able to use Bitcoin the way they thought they could when they first bought in.
As far as I can tell, a user of bitcoin who bought bitcoin in 2011 can still use bitcoin in the same ways they did when they first started using it (plus in a bunch of new ways). And so on and so on until BIP 110. Now, there is a proposal to say all these people who used Bitcoin in a way that we don't like lose their guarantees. This seems like a very dangerous path to me.
Like I said at the top, I agree with many of your points, especially that we should be thinking about how we pay for bitcoin development. But I am entirely unconvinced by BIP 110.
https://twiiit.com/LukeDashjr/status/2021103707518017841
I think this wouldn't have happened if the changes in core were not pushed so agressively.
Agreed. But then again, the opposing side also turned their stance surprisingly quickly into a hill-to-die-on mode.
Vocal parties on either side acted like monumental dickheads (still are? Haven't been following the soap opera in a while.)
And I don't care who was the first dickhead.
It is strange that this became a thing that everybody is willing to make a stand on.
I think it comes down to each side feeling there is a threat to an essential aspect of bitcoin: the BIP 110 side sees spam as a threat to node runners, the Core side sees overly strong spam mitigation efforts as a threat to Bitcoin's incentive structure (hmm, that isn't quite right when I say it: what I mean is Bitcoin's" game theory" but that phrase gets used so widely as to be almost without meaning).
What's done is done.
https://twiiit.com/theonevortex/status/2021040410043482283
The tension here is real, but I think it's a false dichotomy. You don't need to modify consensus rules to address spam — you can build subjective filtering at the application layer, where it belongs.
This is exactly what Web of Trust scoring does on Nostr right now. No protocol changes needed. Each node/client/relay can independently choose to weight connections by trust scores derived from the social graph (PageRank, Sybil detection, etc). Valid messages still propagate — they just get ranked differently depending on who you trust.
The key distinction: consensus-layer filtering = central authority deciding what's valid. Application-layer trust scoring = each participant making their own subjective assessment. The first changes Bitcoin's neutrality model. The second is just users exercising judgment, which they've always done.
The fee market IS a spam filter for Bitcoin L1, and it works. For higher layers and protocols where fees don't create sufficient friction, decentralized trust scoring fills the gap without anyone having veto power over valid data.