pull down to refresh
You might find these Bitcoin Stackexchange topics interesting:
- What is the Lightning Network proposal? What problem is it trying to solve?
- How does the Lightning network work in simple terms?
(Disclosure: my own posts.)
Yo @sorukumar, I think this one will interest you.
Actually, I don’t think it’s hard. A payment transactions can move any amount of money in fairly small amount of weight. Spam transactions generally take more weight per operation and most of them don’t have an open ended value to their senders.
With the waning interest in inscriptions and runes, feerates of spam transactions are minuscule:
(from this dashboard: https://dune.com/murchandamus/inscription-brc20-weight-and-percentage)
E.g., yesterday, spam transactions paid 4.7% of fees for 47% of the blockspace. Payment transactions paid 95.3% of fees for 53% of the blockspace. So, payment transactions are currently paying about 18× higher feerates on average than spam. To me that sounds like spam transactions are only bidding on underdemanded blockspace at the very bottom of the mempool around 0.1 s/vB. As the mempool is clearing out, they finally are selected into blocks after sitting there for an indeterminate amount of time. There just seems too little demand for blockspace from payment transactions right now.
when inscription spam drives fees through the roof, regular people can’t afford to make on-chain transactions anymore
We must be living in different universes. The mempool cleared this week to 1.04 blocks worth of transactions waiting. The feerate necessary to be in the next block is currently 0.1033 s/vB. The spam transactions make up the absolute bottom of the mempool, their feerates are a fraction of those of payment transactions. So that “market failure” your son(?) is decrying seems to be insufficient demand for payment transactions. How is that supposed to be fixed by BIP 110?
BIP 322 basically creates a fake transaction and uses the signatures on that transaction to attest that the owner controls these UTXOs. For hash-based output scripts the inputs must reveal the corresponding input script for the signatures to be verifiable.
Personally, I’m still convinced that we will not see any CRQC in the next four decades, and therefore I don’t find it concerning to show public keys. Unless you assume that there are CRQC, public keys being public is not an issue.
My understanding is that BIP 322 is somewhat unfinished and would need someone to pick it up and address the outstanding issues. I haven’t asked Kalle, but I would assume that if someone offered, they’d be welcome to take the helm.
There are a few people that appear twice (just who jumped out to me):
- Boris Nagaev and Nagaev Boris
- rot13maxi and Rijndael
- waxwing/ AdamISZ and AdamISZ
I don’t think "admin" is supposed to actually be a bubble?
Generally, whatever this is doing seems to overvalue message count. I see a number of people that I would not consider particularly influential featured as larger than expected bubbles.
I haven’t looked at the transactions in question, but Runes are fairly compact (usually even fitting into 40 bytes or less) and Inscriptions have nothing to do with OP_RETURN outputs, so presumably it’s images, text, or other data embedding.
Mempool Policy limits some fields. For example transactions above 100,000 vB are considered non-standard and will not get admitted to nodes’ mempools.
Consensus Rules are very lenient to transactions, it has e.g., always been valid to fill the entire block with a single transaction, or even just a single output script (although output scripts over 10,000 bytes are unspendable).
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.
This is an often repeated claim. Could you please provide any evidence that actually supports this claim? Obviously the UTXO set has gotten bigger, and that will cause Bitcoin Core nodes to flush the dbcache more often. On the other hand, this appears to be offset by spam transactions having significantly fewer signature operations per weight. BitMEX Research found a positive correlation between inscriptions and verification speed.
There are many things that people can do wrong that would make IBD unbearably slow. For example running your box with the default 0.5 GB dbcache when you have more RAM, setting the dbcache higher than 75% of your RAM, using an external hard drive, a SD card or HDD hard drive to store the UTXO set, running an outdated version that is by default configured to cease assumevalid at the height of that release and performs full signature validation for years worth of blocks. There is a lot of really bad instructions out there. E.g., I saw a semi-prominent RDTS proponent once suggest that one should set the dbcache larger than the UTXO set size (which if you have less RAM than that would cause swapping and freeze up your computer).
So, if someone at some point would please provide any evidence that the effect you’re claiming to see a) exists, and b) is caused by the spam, instead of just the blockchain being bigger because there are 100k more blocks than two years ago?
As long as nobody actually substantiates this claim, I’m gonna continue to assume that it’s a rumor based on some people misconfiguring their nodes and experiencing issues.
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.
Larger UTXO set will translate to a graceful degradation, not a drastic slowdown. If you want to convince me of something else, please bring something more than repeating an unsubstantiated claim.
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?
Please explain in detail which problem is being caused by huge witnesses.
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?
People claim (without evidence) that the IBD is gotten significantly slower since the spam fad started. Validation is a big part of what takes time in IBD.
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.
Could you please explain how the UTXO set supposedly impacts nodes? Because the points you’re raising makes me think that we disagree how it does.
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.
I would recommend that they instead get a used laptop. New Raspberry Pis are not particularly cheap for their very limited capabilities. After buying the device itself plus a harddrive and a case, you could get a pretty decent used laptop instead.
Spammers are only buying blockspace nobody else is demanding at minimal feerates.they're "buying block space" at witness discount rates.
... doesn’t give you the right to tell other people what they are allowed to do with the blockspace they buy.
Blockspace is limited to 4,000,000 weight units. One byte of non-witness data takes as much blockspace as four bytes of witness data, so they also cost the same amount of fees. More witness data does not translate to displacing more other transactions. Witness data does not get blockspace at a discount, it gets a discount on its size. They increase the size of the block for the same cost. As explained, the blocksize is smaller than it was projected anyway and disk space is dirt cheap. Only the UTXO set has to be fairly quickly accessible, but that’s only about ~12 GB or so. So put those 12 GB on an SSD and put the blockchain on an HDD, if you’re running out of space?
tell me again why the witness discount was necessary?
The witness discount permitted segwit to increase the blocksize and it better aligned the costs of inputs and outputs with the burden they put on nodes.
(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)
Miners produce blockspace and they sell the blockspace by matching it to bids from the mempool. The mempool is a perpetual auction for blockspace. Not sure why that would even be controversial.
As foretold by the prophecy, this is the nth time that we have outlasted a data embedding fad — and we have become exceedingly efficient at it.
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.
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.
Thanks for sacrificing your time so we didn’t have to. From what you show, Carvalho’s description is completely untenable.