[POLL] Is bigger block capacity still a taboo?

[oldkoin]

(even though 5.2 TB per year is quite too much).

What does a lot mean? That's ~$100 per year. When users pay $10 fees per transaction.

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

Or you did the math and realized that posting such calculations is somehow inconvenient.

And you decided to take 100MB at once. blocks. Only now an error occurred. These calculations don't scare anyone.

Why be modest? Others usually go straight to 1GB blocks. There the numbers will be more impressive.

We are now at 33% for, 33% undecided, and 33% against!  

Actually, who cares about this. That issue was solved a long time ago by splitting BCH and BTC.

Creating a fork with an increased block size did not solve the block size problem for Bitcoin. Absolutely not.

This problem was and remains the same. And this problem will have to be solved. There is no scenario in which Bitcoin with its current block size will be able to reach 1 billion users. What a billion. Bitcoin in its current form cannot handle even 100 million users.

[alani123]

lol at these numbers, the beast is calling 



I hear a lot about how big blocks will reduce decentralization and make things harder for I dividual miners.

Can somebody show me some data or a paper to support this?

I am genuinely curious, bitcoin's block size from 1 MB going to 4 MB didn't cause any such issues. Propagation time on Bitcoin is already pretty good. We are not talking about decreasing block times here.

Mining is already pretty centralized, almost no blocks are mined by miners outside of pools... The difficulty is so high it's hard to mine on your own. But even with bigger blocks, how would that prevent someone from mining like he does now? If someone is going to invest hundreds of thousands $ in mining equipment, are we to assume that they can't invest at an internet connection that is at least at ADSL or 3g speeds?

[philipma1957]

it is not a solution.

1mb 4bm 8mb 16mb 32mb 64mb all fail to solve why this occurs.

scrypt has 2 viable coins for merge mining and they make 12x the blocks per hour or day or week or month or year.

scrypt is the better design for small value frequent moves.

Oh but btc added LN
and Scrypt added LN for ltc and could do so for Doge.

oh a big block fixes things and scrypt can make a big block.

A  large freighter can carry more than 1 million barrels of oil

you do not use it to carry  a few cans of oil

Sha-256/BTC will not ever really win over scrypt/LTC/DOGE  if you are doing many 100 usd or less transactions.

If BTC users understood this they would

A) hodl large  BTC in self custody 10k or higher
B) small amounts of btc ltc and doge in an exchange like coinbase maybe 1k total
C) never pay small amount of BTC to anyone use LTC or Doge

all issues solved.

this fixes fees.

end of story.


If someone can show me a way for the 12x blocks an hour edge that scrypt has I would reconsider but frankly I do not see a way for btc to win by using a freight to move 5 dollars worth of oil

[el kaka22]

This is such a weird position to be in, the results are very close to each other. All sides have super reasonable explanation for why they are feeling that way, bigger blocks people like me want cheaper and faster transactions but the ones who are against it also wants to make sure security doesn't get lower because of it, which makes sense.

I understand not wanting something like this, because in the end we are talking about something that may hurt the blockchain all together. Remember all those alts with blockchain issues and hacks? We wouldn't want that in bitcoin. I am sure in an ideal situation everyone would want it, why would we be against it, why would anyone be? But people are fearing what could go wrong about it.

[franky1]

I hear a lot about how big blocks will reduce decentralization and make things harder for I dividual miners.

Mining is already pretty centralized, almost no blocks are mined by miners outside of pools... The difficulty is so high it's hard to mine on your own. But even with bigger blocks, how would that prevent someone from mining like he does now? If someone is going to invest hundreds of thousands $ in mining equipment, are we to assume that they can't invest at an internet connection that is at least at ADSL or 3g speeds?

mining has nothing to do with blocksize and blocksize has nothing to do with mining
mining hashes a blockheader.. blockheaders and hashes remain the same size no matter the blockdata part containing transactions becomes

people can still mine from home. they can buy their own full size asics or USB miners. the hashrate is linked to difficulty but difficulty is not related to blocksize. the reward amount of sats is related hashrate and to market price not blocksize directly

here is the thing if bitcoin transaction users have to pay more per fee.. less people want to use bitcoin, less want to buy bitcoin. less people want to transact with bitcoin.. this is a bad economic game like only having one table in a restaurant thinking the restaurant can stay profitable serving one customer a day by charging that one customer huge price for a meal..

however more transactions per block does not harm miners or break miners but does allow more transactions and more users and more opportunity to get profit from more people without charging people outrageous prices.. thus more sustainable economic model

Can somebody show me some data or a paper to support this?

I am genuinely curious, bitcoin's block size from 1 MB going to 4 MB didn't cause any such issues. Propagation time on Bitcoin is already pretty good. We are not talking about decreasing block times here.

the 6 trolls against blocksize increases are not thinking with their head about pros-cons for bitcoin. they instead are thinking using their training on how to promote that people should use other networks.
the fun part is their other network promotions/training admits that nodes can handle relay/verification of millions of transactions a second.. so there is no node problem for dozens of thousands per second reasonable request

[digaran]

Anyone who is against increasing the block size is either a shill for miners or has another agenda which benefits them as it benefits mining pools. I excluded ignorant opposition.

Every online application has plans to scale when userbase increases, can you imagine what would have happened if bitcointalk never upgraded it's servers?  Or what would have happened to instagram if they had the same server capacity for more than 4 years?  I can imagine what would have happened, they'd be dead by now, why Bitcoin isn't dead yet? Because it still has support from the community, if I were a mining pool, I'd think about that before including spam into my block, loyalty has it's limit.

[cryptosize]

Every online application has plans to scale when userbase increases, can you imagine what would have happened if bitcointalk never upgraded it's servers?  Or what would have happened to instagram if they had the same server capacity for more than 4 years?  I can imagine what would have happened, they'd be dead by now, why Bitcoin isn't dead yet? Because it still has support from the community, if I were a mining pool, I'd think about that before including spam into my block, loyalty has it's limit.

Care to explain why the internet still uses 32-bit addresses (IPv4) despite the fact we have around 15 billion devices connected online?

Why don't we ditch IPv4 in favor of IPv6 (128-bit)?

Why did we invent NAT/RFC 1918 (a solution that doesn't compromise backwards compatibility, SegWit-style)?

I'm still waiting for someone to answer these questions.

I thought this forum was IT-dominated. Nobody here is an expert in computer networks/internetworking?

[digaran]

You are asking the wrong people here, IP format is related to telecommunication companies controlled by governments, also I see no backward compatibility issues if we were to have for example 6 or 8MB blocks, even if we had 8MB blocks, the spammers would keep spamming, that's why other than blocksize, we need to consider increasing the fees for non-monetary transactions somehow.

[vjudeu]

What are your thoughts on increasing bitcoin's block capacity?

I'm against it

Think about the size of the block header. It takes only 80 bytes. Only that is really mined, the whole size of the block is just committed to it. Does it mean that we only have 80-byte blocks in practice? Of course not, because 32 bytes is all you need to form a valid commitment. Which means, you can have gigabyte-sized blocks, or even terabyte-sized blocks, if you just use commitments to make them. Just tweak your R-value in your signature, and then your terabyte-sized block will be connected with your signature. And it would cost you no additional on-chain bytes.

Which means, every time you move any coins with some standard transaction, and every time you use a single ECDSA signature, you can use random R-value, and not commit to any data, or tweak your random R-value by some non-random value, and commit to any data you want, without increasing the size of your transaction.

Technical details were also explained on mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022176.html

To be able to verify sign-to-contract, you reveal R0 and data, and the verification is just checking that R=R0+SHA256(R0, data)*G. That works with both ecdsa and schnorr signatures, so doesn't require any advance preparation.

[cryptosize]

You are asking the wrong people here

Really?

I thought at least some Bitcoiners were IT-savvy. Guess I was wrong. My bad!

IP format is related to telecommunication companies controlled by governments

That's not true.

RFC documents have nothing to do with ISPs/governments. Internet is decentralized, there is no central entity controlling the infrastructure (just like Bitcoin).

also I see no backward compatibility issues if we were to have for example 6 or 8MB blocks, even if we had 8MB blocks, the spammers would keep spamming

Sure, if you can invent something like SegWit... a soft fork.

that's why other than blocksize, we need to consider increasing the fees for non-monetary transactions somehow.

Possibly.

I was never a fan of storing arbitrary data in the blockchain, but that's how BTC was designed from the get-go.

Hell, some people want 4GB blocks to store video feeds from surveillance cameras.

I can understand why Satoshi wanted to store text messages (like the bank bailout one), but storing entire HD videos in the blockchain? That's absurd!

[vjudeu]

For example if it is a hard fork to increase block size in the future when the need arises, then my answer is a big fat YES. We definitely need to increase the on-chain capacity at some point but the important part is the "at some point" part.

Only time will tell, but I guess it will be much easier to convince people to include 1 GB commitment, as an addition to 4 MB witness, than to create a hard-fork, and include this 1 GB directly. It will simply not happen. If there would be some chances to get it, then Segwit would also be a hard-fork.

Which means, people could increase witness by adding "a second witness" called "commitments" or whatever. But I don't think it will be a regular hard-fork, because the longer that change needs to wait, the more ossified and "set in stone" everything is. And in the future, it will be even harder to convince BTC users to do any hard-fork, unless strictly needed (for example in 2038, because this bug can shutdown old nodes). If you create some unnecessary hard-fork on BTC, then users will call it an altcoin, and create a competing soft-fork or no-fork, and then your hard-fork will be "outside Bitcoin", just because of backward compatibility. The only chance to get a successful hard-fork, is when the old software crashes, and if there is no way to fix them without upgrading.

When it is used as "cloud storage" it is considered abuse and the transactions are spam. Meaning right now that the congestion is caused by abusing the protocol to perform an attack on bitcoin, this is not natural and the exploit should be fixed instead of increasing the capacity to let bigger spam in.

True. Even if someone supports big blocks, then other changes are more important. And if they won't be deployed first, then the final result will contain just Ordinals flood, UTXO flood, and a lot of other, not-yet-invented forms of spamming the chain.

P.S. I don't think increasing block capacity has ever been a "taboo" as some like to exaggerate it. HOW it is increased has been the source of a lot of disagreement.

Also true. We have soft-forks, because they are backward compatible. We could have a hard-fork, but then, there is a huge risk, that some people will call it "an altcoin", and release a competing soft-fork or no-fork. Which means, if you have all development power in your hands, and you release some hard-fork, then you risk losing it. Also, Ordinals can show you that too: Core developers didn't include Ordinals to their Bitcoin Core client, but they are still present on-chain. Which means, now people know, how to add new things, without asking Core. Which means, more people will start deploying their half-baked inventions, without asking for permission, or voting for a new soft-fork, so be ready for a huge spam of no-fork projects.

If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?

The role of OP_PUSHDATA is to push data (duh!). And why we have OP_PUSHDATA4? Well, because Satoshi released 32-bit version, and four bytes can be used to express some 32-bit number. Guess what: if the first version would be 64-bit, we could have OP_PUSHDATA8 as well.

But, I can ask you another question: if Satoshi wanted to fully use OP_PUSHDATA4, then why he limited MAX_SIZE of the P2P message into 32 MiB (0x02000000), and later limited block size into 1 MB (1000000)? Why November 2008 version was limited to only 32 MiB P2P message size? Yes, that November 2008 version, which contained quite huge Script support, what you can discover by exploring the Script of the coinbase transaction, used in that version (also note that it contained 100.00 BTC, expressed with 2-digit precision only as "10k satoshis", instead of 8-digit precision we have today, and that OP_CODESEPARATOR was mandatory at that time).

Seems that the creator had a different view than yours .

The whole Script is not necessary for Bitcoin to function. In the whitepaper, you have only P2PK, and nothing else. And it is still called Bitcoin, and people still check many coins if they implement everything from whitepaper, if they want to call something "the true Bitcoin" or not. Which means, your OP_PUSHDATA4 is not even mentioned there. We could start from P2PK-only system as well, and add commitments later, or even attach Schnorr signatures or TapScript later, directly into those public keys. Then, in such system, spending-by-pubkey would be always mandatory, but some keys (for example the private key equal to one) could require a commitment to some Script.

And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin?

For that reason, I think we should not try to measure that, but instead implement some way to compress pubkey-based transactions, while leaving non-standard use cases uncompressed. In this way, users could make cheap transactions, which could be combined into more expensive ones, while Ordinals users, and other spammers, would still need to pay the full price. In general, I think the price you pay for your transaction, should be relative to the level of compression you can achieve. Public keys can be compressed by Schnorr signatures. Arbitrary data pushes will usually stay uncompressed. The Hutter Prize record at the moment of writing allowed compressing 1 GB of Wikipedia into around 114 MB. But pubkey-based transactions could be compressed much further than that, you will hit a wall during compression, only if you push regular data, you won't have such problems with signatures, that could be just combined, because you can cover 1000-of-1000 multisig with a single signature.

Edit: Also, Satoshi explicitly said something about uploading videos:

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.

Seems that the creator had a different view than yours .

[franky1]

Edit: Also, Satoshi explicitly said something about uploading videos:

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.

emphasising.. some trolls that dont want junk to stop. think the only way is fee's
they also pretend the only way via fee's is everyone pays more equally..

there are many other ways to limit it. such as adding rules to opcodes to limit length(remove assumes and add conditions). and also penalise just certain opcodes for using certain opcodes. multiply base fee by 2000x much like the dev policis decision to multiply legacy by 4

[Wind_FURY]

That's because that's what you believe. In my personal opinion, it's probably better to maintain its current course of development and value decentralization and security more than the accomodation of a higher number of transactions through bigger blocks.

that is not your personal opinion. its plageurised script from a group of idiots that lulled you into repeating their narrative

just reciting the mantra of the party line.. without doing any math, or independent thought/analysis of what he is about to write

You're right, it's not my opinion, BUT in my personal opinion, I agree with the fact that the Core Developers have made the design decisions that value maintaining decentralization and security for the network MORE than increasing the transaction througput per block.

I know you're gaslighting everyone into believing I am wrong, and therefore you are right. BUT OK, they either DYOR and learn the truth, OR they listen to you and learn the truth the HARD WAY like I did.

Plus do you actually believe a single decentralized database could process all of the trillions of financial transactions per day? No? Then use Netflix's centralized/federated data centers with their very-low-latency, high-rate-of-data transfer. That would probably fix the problem. But that wouldn't be a protocol called Bitcoin.

you then double down by using nonsense exaggerations, exaggerations that are not even original or well thought out

there are 8 billion people on the entire planet. and not all of them use one currency..
but lets say they did.. for "trillions of transactions" requires each person to buy 12 items a days SEPARATELY for one trillion.. you used plural so multiply it by your magic plural amount you have in your head..

but becasue not everyone uses one currency naturally, lets take yours
250m mature people(toddlers dont shop for themselves) using the dollar. they do not even do 3 billion transactions per day

so stop with the exaggeration that one currency needs to do trillions.. let alone billions of transactions a day

you training of a discussion of reasonable adjustments at regular periods vs your stupid training of pretending the argument is about "gigabytes by next year" huge leaps, make you look foolish

get away from your training officer(forum-daddy) and think for yourself. he is not helping you
try to use actual data, real statistics, math and logic.. not some story some troll you call daddy tells you

Is that you trying to convince me again that "bigger blocks are better"? Pardon mer ser, but I have already learned the hard way that you're wrong.

Roger Ver and Jihan Wu had a thesis that if they hard fork to bigger blocks and call their shitcoin "Bitcoin", then the community would follow because "big blocks are what the community needs". How is Bitcoin Cash today, frankandbeans?

[franky1]

windfury
none of your replies are about REAL data, code, opcodes, limits.
none of your replies are about REAL maths related to the data/limits
none of your replies are even about technology limitations IN REALITY

try for once to make an ontopic reply that show some thinking about the subject, outside of idolising certain people and insulting others.

when even your idol god devs say nodes can handle the creating, signing, relaying co-signing and relaying again and then verifying "a million payments a second" pre confirm.. it shows nodes have no issues with just a few thousand transactions. especially if mempools of nods can verify and maintain 300mb-500mb pre confirm  transactions without blowing up

when 4mb blocks are 6kb/s internet speed
when 10mb blocks(your groups suggestion) are 15kb/s internet speed
when 100mb blocks(your groups exaggeration) are 150kb/s internet speed

so please tell me the real defined reason your against it... apart from dev god cult following and wanting to appease your mentor

[pooya87]

Since I have to dot all the eyes and cross all the tees: Legitimate use is anything that is not a spam attack, meaning where people use bitcoin to transfer money or in other words when Bitcoin is the "peer to peer digital cash system" that it was intended to.

If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?
Seems that the creator had a different view than yours .

Satoshi was not a god, he has made a lot of weird decisions when implementing Bitcoin. Unless he has explicitly expressed his intentions for a decision you can not make such conclusions like the one you just made here.

In this case if I had to guess I'd say there may be two reasons for this decision:
1- Scalability of the code.
As a developer, specially when you are creating a consensus critical code for a decentralized system, it is easier to have an functionality and never use it than not having it and wanting to add it in the future. Introduction of other functionality like interpretation of SegWit outputs, adding OP_SUCCESSx, etc. are doing exactly that.

2. Translating DER lengths.
I think this is the most possible reason. Since Satoshi was aware of DER encoding (used for signatures) and DER lengths have a similar approach to encoding data lengths and also support very large values, Satoshi might have adopted the same approach and implemented as big a size as he could.
BTW same approach is used to encode VarInt (used for script lengths) which is another way of encoding lengths some of which can never be used in Bitcoin but they can encode extremely large values nonetheless.

Otherwise I doubt that Satoshi ever intended to let anyone push 4+ GB data to the stack that only supports pushing data that is no bigger than 520 bytes.

The reason is pretty simple: the adoption hasn't grown enough for the current block capacity to not-be enough for the legitimate usage.

And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin? In my opinion, the adoption has grown a lot since the last time the Bitcoin community had had this debate.

It has definitely grown but considering how fee spikes have never been severe or long lasting without spam attacks we can say with a high degree of certainty that the adoption has not yet surpassed the capacity.

[Hamza2424]

try reading again

a miner does not even see full blockdata. a miner simply hashes a header (hashes a hash of a header to be more precise)
the header and hash which miners are involved in never change their length no matter how big a transaction or blocksize is

I think I've gone wrong somewhere while expressing it what I meant by this was it will directly increase the storage required by the minner to download the entire blockchain, and it will require a higher network bandwidth. So if the minner is not reading the entire block data still it's keeping a copy of the full data if the computation resources are not increasing but the network & storage resources are.

I was generally expressing my view on it and somehow mixed the nodes & minner at the same time. Anyway, there are some concerns for both miners and Nodes as well.

[stompix]

100mb blocks at your extreme is not 500GB... its actually 5.2GB a year

100 MB x 144 x 365 = 5,256,000 MB ~= 5.2TB per year. The 500 GB per year correspond to previously mentioned 10 MB block size.

Edit: You've corrected yourself. But, as I have said many times, it's not just the storage requirement (you can find HDD externals pretty inexpensive, even though 5.2 TB per year is quite too much).

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!
You are the only one that advanced this number, but just for this one time, no matter, let's play with it.

The last 24 hours' fees were 247.97 BTC
Fees for normal transactions, not ordinals represented 75% of the total, so at current price is $6.7 mill.
A Samsung EVO, so no your cheapest shit is $334.90 for 8TB on Amazon right now,  so $41 per TB.

Now, let's assume 20 000 nodes, split the $6.7mils, and you get, wow....$335, it's like god has spoken!  
So bottom line, users have paid in the last 24 hours on no ordinals transactions enough money so that 20,000 nodes would get an 8TB drive! In one F word day!

It's the verification process which takes most of the time, not the downloading. It already takes too much time, I can't fathom how much it'll take if we are to verify 100 MB.

Normally one would come with numbers on this...
So let's see what your average computer in 2009, like the core2duo could do and what your nowadays average desktop can,
So a CoreDuo E6600 vs Core i5-10600, intentionally middle processor 3 years old at the date of launch of now, ignoring the duo was $320 on launch and the i5 $210 so 50% cheaper, 18.2 gflops vs 482.3 gflops...lol!


Now let's move a bit further and do some really laughable math...

Let's assume we want everyone to hold some coins, just hold them nothing else.!!!!
We assume the blocks will be used just to distribute coins, so that would cram 25 000 outputs in a block (we need some spare space as not all inputs are already funded with that much), so that's 1,3 billion, so 6 years!!! LMAOOOOO...even if we would optimize transactions to the max, even if everyone would stop doing anything else and move a single coin on the blockchain, it will take 6 FUCKING YEARS for everyone to get coins in his wallet (you know the whole thing, not your keys, not your coins). Now assuming everyone would also want to open a LN channel, well..it's going to be 2040!
2040 till it will even be mathematically possible (impossible in real life) to get everyone on LN!

But we don't need everyone, I mean just 25% of the world, right...so 2027  
Seriously? Seriously? All because of a $300 drive? Common!

I'm pretty sure you'll have to trust some data center after the 100 MB proposal is accepted, unless you're willing to pay ~500 GB of space each year. Oh, and by the way, you'll have to upgrade to some better CPU in a couple of years, unless you're really patient with the initial block download.

You're talking to somebody who has 10KW of mining power actually securing the network as we speak in his basement.
So...you know... wrong path here

[Wind_FURY]

windfury
none of your replies are about REAL data, code, opcodes, limits.
none of your replies are about REAL maths related to the data/limits
none of your replies are even about technology limitations IN REALITY

try for once to make an ontopic reply that show some thinking about the subject, outside of idolising certain people and insulting others.

Probably not, that's because I'm a mere pleb. I'm not a coder, I'm not a very technical person although I try, BUT I understand enough to know who is LYING/spreading MISINFORMATION, and who are the trustworthy people in the community. It's NOT YOU frankandbeans, and it's there in your trust-ratings for everyone to see!

Plus who should the community listen to, to learn more about Bitcoin? Gregory Maxwell and Andrew Chow? Or a charlatan?

¯\_(ツ)_/¯

[cryptosize]

Every attempt to increase the block size limit via hard forks (BCH, BSV etc.) has produced blockchains with less security (aka shitcoins):

https://cointelegraph.com/news/bitcoin-sv-rocked-by-three-51-attacks-in-as-many-months
https://www.coindesk.com/tech/2019/05/24/bitcoin-cash-miners-undo-attackers-transactions-with-51-attack/

BCH and BSV aren't good example though. BSV doomed from start since it's associated with infamous faketoshi. BCH gain bad popularity due to community/developer action in past, especially claiming BCH as true Bitcoin while falsely say "BTC (Bitcoin Core)".

Sorry, that's not my problem.

You'll find people on this thread ferociously defending narcissists such as CSW and attacking/ignoring everyone who doesn't buy his BS (4GB Kool-Aid).

Satoshi never seeked fame, he didn't even spend his own coins...

[BlackHatCoiner]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!

What's the ideal block size according to you?

So bottom line, users have paid in the last 24 hours on no ordinals transactions enough money so that 20,000 nodes would get an 8TB drive! In one F word day!

Seriously? Seriously? All because of a $300 drive? Common!

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

So a CoreDuo E6600 vs Core i5-10600, intentionally middle processor 3 years old at the date of launch of now, ignoring the duo was $320 on launch and the i5 $210 so 50% cheaper, 18.2 gflops vs 482.3 gflops...lol!

I mean, yeah, if you dedicate a modern PC to running a full node, it will take a couple of days to reach the tip, but as per my experience goes, people don't use resource-intensive machines solely for that purpose. If you use a Raspberry Pi 4, it'll take a week to finish the first 500 GB.