pull down to refresh
Maybe this is where I’m confused. Are they seeking to ban valid transactions or change the criteria for being a valid transaction?
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.
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.
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.
see also, the ideal solutions to the iterated prisoner's dilemma.
- 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
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.
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.
Watching Netflix in HD is about 3 GB/h. The spam is less than 100 MB per day. So, the bandwidth is as much as watching a few minutes of Netflix per day.
After downloading a block and processing it in memory, we only read the blockchain data when we serve blocks to peers or when we rescan. That means that you can store the ~12 GB UTXO set on SSD, while you write the blockchain data to a HDD without much performance impact. A 2 TB HDD from Seagate or Western Digital is $80 today and will be enough to store the blockchain for another ten years. Also, most uses of full nodes at home are served perfectly fine with a pruned node that takes less than 50 GB of disk storage. So, the cost is a couple cups of coffee per year: negligible. If you live somewhere where that’s a lot of money, the calculus doesn’t change much: you run a node because it solves a problem for you. Either it’s worth it or not.
Besides, I have no clue why people are running nodes on microcomputers like Raspberry Pis. An old laptop is way more performant, costs the same, will use hardly any more power, and even comes with a built-in uninterruptible power supply.
It seems to me that most people who are complaining about the cost to run nodes are not running into a problem they can’t solve, but parroting talking points.
Thanks
That seems like a fair summary
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?
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.
If that last part is accurate then we are talking about more than just a change to one of the parameters.
Is this introducing a mechanism that allows a particular third party to veto transactions?
I would argue that the mechanism being introduced is this soft-fork-to-stop-spam pattern. It puts the decision of which transactions should be valid up to frequent and recurring debate.
I believe it is encapsulated in this exchange:
When BIP 110 expires, what do its advocates expect to happen? From my conversations with them, it seems that they expect either 1) another soft fork or 2) another soft fork.
In the case of 1) where they manage to get most bitcoiners and miners on board, they need another fork to make it all permanent, and then more forks when spammers embed data in new ways. In the case of 2) where they do not get support, they seem interested in trying again and floating a different fork to "fix the spam."
While this is not a mechanism in bitcoin's block validation rules that allows anyone to veto transactions, it creates a system where Bitcoiners must decide which transactions are "spammy" and to be stopped from happening and which ones are "real." Already, BIP 110 is setting up two such occasions in as many years (deciding whether to run BIP 110, and then deciding whether to run whatever comes next when it expires).
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?