Does it matter if every person from 10 people pay 100 sat/vByte as a fee or every person from 100 people pay 10 sat/vByte as a fee? It doesn't matter because the outcome is the same. Bitcoin can't grow with such a low block size, it will simply make it unattractive and people will actively start to look for alternatives.
Simply, there is no way that by increasing the block size, miners will lose the profit, no, that's not true.

Why is LN a solution? What if everyone moves on LN? Will miners still profit?

I can't agree with you, Bitcoin is meant for P2P transactions and that includes everything, starting from Coffee to Car and so on. The simple fact is that Bitcoin wasn't meant for massive usage and it's blocks size was 1 MB because it was enough for 2010 and for a few upcoming years. As time goes, number of Bitcoin users increase and the technology advances, so it's perfectly okay and to my mind, even necessary, to increase the block size.

As reminder, you need 2 Bitcoin on-chain TX when you use LN in order to open and close LN channel. That's where miner earn some income.


In addition, other scaling option (e.g. using LN or sidechain) needs on-chain TX to open LN channel or "peg" the coin on the sidechain. So very high TX fee would make those option not very attractive.

My bad. I must have counted the time it takes for a Raspberry Pi to do it, and I ignored batch verification, or other techniques Bitcoin Core implements to increase efficiency. I just multiplied the average total transactions times the time it takes to verify just one ECDSA signature. However, I do believe certain transaction types take more time to verify than typical, which can be used as an attack vector. I'll get back to it when I find the data to back this claim.

For the sake of the discussion, let's assume that the 16 MB limit is a harmless one. How do we enforce it in a softfork way? Segwit was enforced in a clever way, by separating the witness data from the transaction data. AFAIK, it's impossible to achieve it in softfork, unless you've figured out of another way to restructure the transaction data.

"Why shouldn't this be done in a hardfork way?". It's already history, called "Bitcoin Cash". There is no point in redoing the same thing.

Yeah, "wrapped" coin is definitely more popular. But either way, you still need one Bitcoin on-chain TX in order to send your Bitcoin to exchange/other service, to obtain the "wrapped" coin.


Most straightforward option would be increasing witness discount from 4 to 16. But without making Ordinal or other TX which use OP_FALSE OP_IF ... OP_ENDIF non-standard, it'll just make cost to spam on Bitcoin blockchain even cheaper.

That was a softfork. When you invalidate a currently valid rule, it's a softfork, and in this case, you invalidate blocks with size > 1 MB. However, a few years after this, a hardfork emerged.

Any decision taken by Satoshi was unquestionably followed, because... it was Satoshi. It's good that we don't have that source of influence anymore.

It still is surrounded by loads of controversy. First things first, what's the ideal block size increase? We're agreeing on the 16 MB limit, but stompix wants it to double on every halving. Another one might think 16 MB is still very small. I can already predict that the hardfork will end up just like Bitcoin Cash; uncertainty on the ideal adjustment will encourage people to stick with the tested, conservative 4 MB.

I want to remind you, at this point, that before Bitcoin Cash, there were Bitcoin developers who supported big blocks. The fact that they split a long time ago highlights how unlikely it is for the current small block developers to suddenly change their minds.

Miners are in charge of creating new blocks, every user is in charge of which consensus rules they accept. Of course, without miners that means there are no new blocks.
It's kinda sad the "one computer, one vote" thing can't work.

Note that mining pools can do so, without asking anyone for permission. And they didn't, for some reason. So, you can ask them, why they didn't put that kind of limit in the blocks they produce? Also, you can ask some node operators, why they collect and process transactions, which are below one satoshi per virtual byte? For example here, you can see some grey block of cheap transactions at the bottom of the chart: https://jochen-hoenicke.de/queue/#BTC,all,weight,0

Note that keeping the limit as it is, is the easiest thing to achieve, because it is about preserving "status quo". Which means, no matter if you want to increase or decrease some default values, related to the size of the block, or to the default fees, or to some other default rules, you need to reach consensus. And guess what: reaching consensus is hard, even in some topics like Segwit or Taproot, it took years. And convincing miners to set their max block size limit into 32 MiB (the default from the first version, used by Satoshi) is as hard, as convincing them to go for 10 kB (there were times, when the practical limit was lower than 1 MB, because of BDB locks, and stuff like that).

Also, increasing the size of the block makes this attack worse, than it currently is: https://bt.irlbtc.com/view/140078.msg1491085#msg1491085

There is one problem with that approach: verification. Sending the whole chain is not a problem. But verifying still is. And what is the bottleneck of verification? For example CPU speed, which depends on frequency:

2011-09-13: Maximum Speed | AMD FX Processor Takes Guinness World Record

2022-12-21: First 9 GHz CPU (overclocked Intel 13900K)

See? Humans are still struggling with reaching 8-9 GHz, and you need a liquid nitrogen to maintain that value. And more than a decade ago, the situation was pretty much the same. So, the CPU speed is not "doubled" every year. Instead, you have just more and more cores, and you have for example 64-core processor, instead of having 2-core or 4-core.

Which means that yes, you can download 100 GB, maybe even more. But is the whole system really trustless, if you have no chance of verifying that data, and you have to trust, that all of them are correct? Imagine that you can download the whole chain very quickly, but it is not verified. What then?

Also note, that if something can be done in parallel, then yes, you can use 64-core processor, and execute 64 different things at the same time. However, many steps during validation are sequential. The whole chain is a sequence of blocks. The whole block is a sequence of transactions (and their order does matter, if one output is an input in another transaction in the same block). The hashing of legacy transactions is sequential (also in cases like bare multisig, which has O(n^2) complexity for no reason).

So yes, you can have 64-core processor with 4 GHz each, but a single core with 256 GHz would allow much more scaling. And this is one of the reasons, why we don't have bigger blocks. The progress in validation time is just not sufficient to increase it much further.

That's the attack I was looking for but couldn't find. Thanks, garlonicon! As I understand it, this attack requires dedicating a little less than 1 MB of block space to execute. Currently, it is very expensive, but if the block size limit is 16 MB, a mining pool attacker could always fill a quarter of their block with these transactions. This would force the rest of the network to spend more than 12 minutes verifying them, effectively giving the attacker 12 minutes to mine alone.

Is that perhaps one of the best arguments in favor of a small block size? I see that it can practically only be resolved if we start implementing even more severe exclusions in the Script, but I'm not sure if it could be trivially resolved otherwise.

Different pools will do different things. The attacker will know in advance, that "yes, this block is correct" or "no, it abuses sigops limit, or any other quirky rule". And during those 12 minutes, different pools may apply different strategies. One strategy is to mine a block with just the coinbase transaction, and nothing else. But: on top of which block it should be mined?

An honest miner can decide to mine on top of what is already validated. But then, there is a risk, that this "12 minutes block" is not an attack. Maybe all of those transactions were flying in mempools, and some mining pool just included all of them, without having any evil plan in mind? But then, how to quickly check all rules, without performing full block validation?

It depends. Mining a block with some coinbase transaction, and nothing else, would be always valid, if the previous block is valid. Which means, that mining pools can mine on top of attacker's block, and then they will keep validating it.

Some example of sigops limit violation: https://bt.irlbtc.com/view/5447129.msg62014494#msg62014494

And then, imagine that you know in advance, that some mining pools use some kind of simplified block validation, and they don't check every rule (to get a better performace, because of using outdated custom software, or for whatever reason). Then, you may broadcast for example a lot of 1-of-3 multisig transactions into the network on purpose, and wait for other pools to grab them, and mine a new block. Then, you have 80k sigops limit, but some of their blocks may accidentally have 80,003. And there are more quirky rules to exploit.

Also, if you broadcast transactions, which are valid, but can become invalid in a particular context, then you can always say later: "See? Those transactions are valid, because they are included in other blocks, we did nothing wrong!".