pull down to refresh

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.
144 sats \ 0 replies \ @sedited 20h

It is all vibes, and the vibes will never be pure enough on a censorship resistant public bulletin board.

reply

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.

reply

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?

reply

Maybe this is where I’m confused. Are they seeking to ban valid transactions or change the criteria for being a valid transaction?

reply

Via the BIP

reply

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.

reply
The argument should be about whether the new rules would be better or worse.

I think that this is exactly the frame of BIP110 (and maybe that's your point too?)

We all agree that:

  • arbitrary data accumulation in the finance ledger is a cost we don't want to bear
  • it is hard to coordinate a solution, no matter what
  • we don't want to make another dumb, permanent mistake
  • this is an acute problem, currently impacting decentralization (reducing supply of nodes which can functionally perform the IBD)
  • the relatively few individuals facilitating this SPAM situation are not going to have to pay the for it
  • the network is a very significant part of the value proposition of bitcoin
  • the relatively few individuals making money this way are imposing a significant cost on the network and its node operators,

The author(s?) of BIP110 assert:

  • Inputs spending UTXOs that were created before the activation height are exempt from the new rules.
  • The new rules expire, returning us to the original state without committing to anything other than a single coordinated action against these relatively few individuals creating this data bloat
  • It's important to act, and quickly, to impact the business interest of these individuals
  • This is a temporary change, with real risks if miners play a strategy of not working with the users
  • Any solution will require significant coordination, this requires the minimal level of coordination, while still significantly disincentivizes the embedding of contiguous arbitrary data larger than 256 bytes

see also, the ideal solutions to the iterated prisoner's dilemma.

reply
289 sats \ 4 replies \ @Murch 10h
We all agree that:

No, we don’t all agree on those.

  • arbitrary data accumulation in the finance ledger is a cost we don't want to bear

Agreed

  • it is hard to coordinate a solution, no matter what

Agreed

  • we don't want to make another dumb, permanent mistake

Disagree with witness discount and Taproot being mistakes

  • this is an acute problem, currently impacting decentralization (reducing supply of nodes which can functionally perform the IBD)

It’s not an acute problem. It’s not a big surprise that microcomputers that were barely able of keeping up five years ago are pushing their limit.

Before segwit, people were expecting blocks to land at 1.7–2.3 MB with full segwit adoption. The average blocksize has been about 1.6 MB in the last year. That means that the blockchain grows merely about 80 GiB per year without the segwit blocksize increase it would have been 50 GiB. Still, it doesn’t come as a surprise that the blockchain is nearing 1 TB (= 0.909 TiB) when Bitcoin is now 17 years old.
Did these people assume that they’d only have to buy one device to last them for their lifetime? If they bought a 1 TB hard drive a year or two ago, and didn’t anticipate that it would be too small in a couple years, I cannot commend them for their basic arithmetic skills.

  • the relatively few individuals facilitating this SPAM situation are not going to have to pay the for it

They pay the very high cost of purchasing blockspace, the same as everyone else does for their transaction data. People are running nodes for themselves. Either the cost is worth it, or its not. Just because you decide to run a node for yourself doesn’t give you the right to tell other people what they are allowed to do with the blockspace they buy.

  • the network is a very significant part of the value proposition of bitcoin

The network is totally fine even with a minor portion of node runners misconfiguring their nodes to make them less useful peers.

  • the relatively few individuals making money this way are imposing a significant cost on the network and its node operators,

This gets repeated over and over, but somehow nobody has any statistics or data to support that the spam had a significant impact on IBD. Facts are that fees for spam transactions are about 2–5% of all fees in the past weeks, while blockspace usage of spam has been 20–40%. Anti-spam pundits keep only showing the latter number, but the way I interpret these charts is:

Spammers are only buying blockspace nobody else is demanding at minimal feerates. The spam isn’t even trying to compete with payment transactions anymore, so how could it drive up the cost of payment transactions? If people want less spam, they should send more payment transactions. Additionally, it is a fact that inscriptions and OP_RETURN outputs are cheaper to validate than payment transactions, and most of the additional UTXOs created are spendable no different from any other payment output.

So what we are looking at is a movement fueled by resentment over a feerate spike two years ago and by people daring to do with their blockspace something that these purists don’t like. The movement is very effectively splitting the community because their arguments are technically untenable and emotionally loaded, which most other bitcoiners reject rightfully.

The author(s?) of BIP110 assert:
  • Inputs spending UTXOs that were created before the activation height are exempt from the new rules.
  • The new rules expire, returning us to the original state without committing to anything other than a single coordinated action against these relatively few individuals creating this data bloat
  • It's important to act, and quickly, to impact the business interest of these individuals

No, it’s not. It’s fake urgency over a nothing burger, deliberately fabricating and perpetuated by pushing people’s buttons.

  • This is a temporary change, with real risks if miners play a strategy of not working with the users
  • Any solution will require significant coordination, this requires the minimal level of coordination, while still significantly disincentivizes the embedding of contiguous arbitrary data larger than 256 bytes
see also, the ideal solutions to the iterated prisoner's dilemma.

It’s just a regular con: isolate a gullible crowd, create tension between the in-crowd and out-crowd, raise your profile and profit from the outrage.

reply
It’s not a big surprise that microcomputers that were barely able of keeping up five years ago are pushing their limit.

it's a big surprise that the team of brilliant software engineers dedicating (a subset of) their careers to protecting the worlds most important financial technology from idiocy were dumb enough to let these perfectly functional microcomputers get swamped by memory constraints when they were working perfectly just a handful of years ago.

note that it's not the storage getting swamped, it's the ram.

Before segwit, people were expecting blocks to land at 1.7–2.3 MB with full segwit adoption. The average blocksize has been about 1.6 MB in the last year.

it's the footprint of the UTXO set, not the size of blocks, not the drive size.

fee rates facilitating the creation UTXOs with huge witness is the problem. you don't want to un-discount the witness, and you don't want to solve for contiguous data. what would you like to solve for?

Additionally, it is a fact that inscriptions and OP_RETURN outputs are cheaper to validate than payment transactions, and most of the additional UTXOs created are spendable no different from any other payment output.

why mention validation?

their spendability is exactly the issue. UTXOs in the memory are what's constraining the decentralization onto weaker machines. the dominant cost on constrained hardware is UTXO set, not validation.

put another way, which sufficiently powerful computer would you recommend for some poor user outside of the 1st world to save up for in order to run a node for their community with the preferred permissionless blockchain, hmm? certainly not a fairly common and inexpensive raspi4.

Spammers are only buying blockspace nobody else is demanding at minimal feerates.
... doesn’t give you the right to tell other people what they are allowed to do with the blockspace they buy.

they're "buying block space" at witness discount rates.

tell me again why the witness discount was necessary?

(for the record, I don't agree that they're buying block space. miners sell placement priority in their templates not block-space... they can't sell something they don't own)

isolate a gullible crowd

isolation... by whom exactly? certainly not the people calling these invested individuals "rednecks"?

I have no idea what the answer to this is, but how do the 2-5% of fees paid by "spam" compare to the extra costs from transmitting and storing all that data?

Obviously, you're right that people either think it's worth running a node or they don't, but if it's more costly to do so than it needs to be, fewer people will do it than otherwise would.

That seems like a fair summary

reply

Same thing, isn't it?

reply

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.

reply

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?

reply

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?

reply

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?

That’s different because it introduces a new party to the validation process who is outside of the network.

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.

And the moment you let someone decide which valid transactions are "spam" you've introduced the exact central authority Bitcoin was built to eliminate.

100%.

reply

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.

reply

I think this wouldn't have happened if the changes in core were not pushed so agressively.

reply

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.

reply

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).

reply

What's done is done.

reply
144 sats \ 1 reply \ @aljaz 23h

the most monumental threat to bitcoin is this whole fucktard conflict manufactured by god knows who to split the community that is already incapable to agree on anything even further.

People who's intellectual capacity doesn't reach further than being able to spell BIP110 on their best day all of the sudden have opinions on things that have have more layers and 2rd, 3rd... n-th order consequence because a deepshit podcaster they happen to be listen to in an attempt to get some personality into the empty shell of their existence.

I hope this entire conflict is a psyop because otherwise this community is more retarded than anyone could imagine in their worst nightmare.

reply

"Bitcoin is for retards" is not a bad slogan.

reply
central authority Bitcoin was built to eliminate.

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.

reply
spam is spam. there's nothing wrong with coordinating among peers to disincentivize it.

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.

reply
531 sats \ 5 replies \ @itsrealfake 10 Feb -1000 sats

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:

https://m.stacker.news/129741

Secondly (of all)Secondly (of all)

I'll be honest that when I read this, it felt like you hadn't yet read the https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki#user-content-Motivation:

get used to the idea of "bad" valid transactions

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:

"I have zero confidence that we stop with spam" is specifically addressed in the BIP:

This is specifically addressed in the BIP.

No. It is impossible to solve spam completely, and typically spam is best fought with policy/filters, not consensus. What this softfork does is require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushes.

Lastly (for now)Lastly (for now)

Specifically, this proposal invalidates all methods of embedding contiguous arbitrary data larger than 256 bytes; it also invalidates large scriptPubKey and Tapleaf formats that are abused almost exclusively for data embedding; and finally, it restores, in consensus, the long-established 83-byte policy limit on OP_RETURN outputs.

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.

... the fee for a data storage transaction still goes only to the miner who includes the data in a block, but the burden of storing the data falls on all node operators, who never received even a part of the fee, yet are forced to continue downloading, storing, and serving the data forever.
In this case, the miner accepts a one-time fee, and in exchange, the priceless service of highly-available, uncensorable data storage is provided in perpetuity for free by node operators.

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 https://www.todayonchain.com/news/article/01K8NA96KBQ0SDSTPK0NCG64SK/ 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.

https://m.stacker.news/129749

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.

https://m.stacker.news/129747

Closing this down for real nowClosing this down for real now

Anyway, thanks for the opportunity to put my thoughts together a bit better.

0 sats \ 0 replies \ @MaximumSats 10 Feb -165 sats

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.