Topic: A different approach to Bitcoin's scalability issues? (Read 376 times)

It only remove financial incentive. Without upper limit, malicious party with few percent could bloat blockchain by claim they have very big mempool.


I never said increasing block size is scaling solution, that's why i used double quote and word "PR".

I agree, although

I couldn't have put this better! It will go in my list of bookmarks. This is what happens when people throw around words from a field they have no idea about.
It's clear that a block of twice the size has twice the space for transactions; so since the relation between size and transaction count stays the same, nothing was 'scaled'.

And not to forget the truly awful BIP 100, A.K.A. "Just let the miners pick the size.  What could possibly go wrong?"    

Glad that one never gained any traction.    

There was a time where I was an ardent supporter of BIP 106, or at least a somewhat curtailed version of it.  But people pointed out that it would be possible to manipulate or game the system.  As such, it's probably not safe.  If it's a major part of the foundations, it has to be solid.

Increasing max block size is not what "scaling" means. If you can process M transactions, and it takes N bytes, then processing 1000*M transactions by using 1000*N bytes is not "scaling". It is the simplest "linear growth" and has nothing to do with real scaling. The "real scaling" is called "compression". For example, where you can handle N-of-N multisig by using a single signature, instead of N signatures. Or where you can compress a chain of A->B->C->...->Z transactions into A->Z transaction, that is also scaling. And that is the right direction for the next soft-forks.

I think it is gone. Also because BCH and similar chains did it in a hard-fork way for no reason. They could create 1 GB blocks in a soft-fork way, and we can also do that, if it will turn out that no other way is possible. But as far as I know, there are better ways to scale things, so I think we won't need increasing the block size in the future. Another thing is that the max witness size is just a parameter that any node can set to anything, so from the code perspective, everything is ready, it is just a matter of reaching consensus if needed.

1. Lower max block size can have minimum size set to the current Bitcoin block max size so it cannot get worse than what it is now.
2. If it does increase Bitcoin price than I would not complain . If it does not then the incentive to claim big mempool for miners is gone.

In real life different miners would set mempool size to different values, there will be conflicting interests, and in the long run it will be close to what majority of nodes see.
But I am not in favor of increasing max block size as I believe it would affect decentralization. But theoretically it is an interesting topic.

I haven't yet read the replies, but my first thought is that you might be mixing up running a full node and running a miner.
If you come from crypto theory and mostly read papers like the Bitcoin whitepaper itself, you may rightfully assume so, since it was envisioned that people would do both. But today, this is not the case.

This means that a higher hashrate in the network doesn't gain node runners anything, so it makes no sense that they'd need to go buy larger SSDs, while miners are making more profit or something like that (if I understood your proposal correctly like that).

This is correct, since regular people (altruistic node operators) who run a low-cost, low-power node (like in my $50 guide) don't want to spend a lot of money on hardware and networking.


That's the issue: node operators are usually not miners at the same time.

Here you're speaking about mining blocks, again - while the issue with a larger block size (as you said in my first quote) is that it becomes hard for ordinary people to run a node. That's not due to mining difficulty or anything like this, but due to hardware and networking (infrastructure) costs. Node operators gain nothing in terms of money, from doing it.

Yeah, so the issue is that the 'new people joining the network' as miners, aren't the ones running the nodes. That's pretty much it.

It is completely different, because all blocks have to be the same for all miners, so difficulty is based on a situation, where all miners have the same chain, so they get the same difficulty. On the other hand, each node has a different mempool. For example, my node allows accepting and broadcasting free transactions, and they are included only if there is a space for them (if you want to see them, you have to find my node in the wild, and set your node to allow free transactions, because they are sent only to nodes that declare to accept them). So that means my mempool is always bigger, because you can send some free transaction, and it will be later dropped if not picked by other nodes (which is usually the case).

Why not? Any miner can create a lot of dust, just to get rid of the competition. For example, some evil miner could use some 256-bit number as a source of entropy, then use that to generate a lot of transactions, moving coins to himself. That miner could always fill the whole mempool, up to the 300 MB default limit. Then, that miner can pretend that its mempool is always full of transactions. But it does not matter, because even if some miner is sending coins to himself, then it can be done at zero cost (also if everything is precomputed, then that miner does not have to store all of that, but only be aware of the correct UTXO set). In this way, a single miner can create a lot of dust, that will take a few kilobytes, but others will process a lot of data, because others will have no idea, which algorithm was used to generate them.

So, there are things that may be profitable from a single miner's perspective, but can be considered harmful from the network's perspective.

Using average mempool size is no different than using average difficulty. Some blocks mined in much less than 10 minutes, some in more than 10 minutes but the average value comes out fine. In addition there is no financial incentive for miners to attack blockchain.

There is no point in having a requirement that does not have to be followed.

You can't even measure the mempool size of older blocks for it to be close to the size or not, because as I said in my post above mempool is not stored anywhere. Even if you could, when calculating target we aren't looking for a number that is close to correct one, but we are looking for exact values.

There is no need to validate any precise value that will change anyway. When averaging over 2016 blocks the result will get close to average mempool size that other nodes see.

A node cannot validate the size of the miner's mempool, and if the miner can choose any size, then there is no point.

Of course every miner will set mempool size to a different value before mining the next block. That is why I said the mempool as miner (who will produce the next block) sees it. Once block is mined that value becomes the mempool size for blockchain at that block index.

Simply stated, there is no "the mempool". Every node has a mempool and every mempool is assumed to be different.

Why not make the block size simply depend on some fraction of mempool size, say 1/10? Add a field to each block to record what miner sees as memory pool size then average it for the last 2 weeks. Then approximately each transaction in the mempool will get included in the next 10 blocks.

Try multiplying blocksize by the base-10 logarithm of difficulty.

i.e. log10(difficulty)

That way, difficulty can be in the exahashes range as it is now and the factor still be no higher than 15-18 i.e. 15MB-18MB final size for that difficulty.

But, how is this better than just raising the block size? It's more complicated and, therefore, leaves room for possible failures. If your approach to solve scalability has to do with the block size, simply increase it. Don't mess with variables such as difficulty, which exist solely for determining another thing.

As said by pooya above, there are more factors that determine difficulty. There have been times in the past when the price was dropping while the difficulty was increasing.

Lightning Network is another peer to peer network that is running on top of bitcoin. It is not centralized nor controlled by any company.

There are ways to not be online and receive payment but ignoring that, LN still provides a good utility. Imagine you wanted to pay your bills, deposit/withdraw bitcoin to/from your exchange, purchase something from a merchant, etc. in all these cases the receiver is already online and has an open channel, you too are also online and have an open channel. All you have to do is to make your payment.

In other words a lot of transactions that were happening on chain could happen on LN, freeing up on-chain space.

While your approach have some flaws which already mentioned, i appreciate your effort to think new approach and writing it neatly.


Definitely not Segwit2x, but i think you refer to BIP 104, 106 and 107.


CPU and RAM would be bigger concern than internet speed/price.


1. Correlation doesn't necessary imply causation.
2. Have you used other data to compare it with bitcoin transaction/day? IIRC big Bitcoin price swing have bigger correlation with Bitcoin transaction/day since holder would either buy and withdraw from exchange or deposit to exchange and sell.

Thanks for the reply.
I agree with most of the things that you said.


I totally agree with the China example. I mentioned it as well as a problem to be solved. Conceptually speaking, we don't need the block size to change every 2016 block (roughly 2 weeks). It can be changed once a month or even more (this should be picked more carefully of course). If so, the algorithm can get many calculations from different nodes throughout let's say a month, and make some sort of an average in order to represent a general trend in the network.
Now this is all based on the say that there is a good enough relation between the has rate and the transaction amount.
I went to check some data to see something more visual.
I checked these 2 tables:
https://ycharts.com/indicators/bitcoin_transactions_per_day
https://www.blockchain.com/charts/hash-rate

I have seen 2 significant things:
     1) It appears that there is no linear relation between the hashing rate and the transactions per day.
         One thing that I think should be taken into account, is that today we are already facing the scalability issue's consequences. Meaning that I think it's possible to say with just a little of confidence, that if
         transaction fees weren't as high - we would see much more transactions occurring. So basically saying that it might be possible that the data we are seeing today is "manipulated" by the problem itself.
      2) When major changes in trends occur, it is seen in both the hashing rate and the transaction 'demand'. You can look at the end of June 2021, end of April 2021, end of October 2020, end of May 2020,
          end of March 2020. Although not identical, the downwards trend is similar. It should be said that it's possible that there a 3rd factor I didn't take into account that is effecting both of these rates.

So to sum this one up - I don't believe that the relation between the two factors should be linear. It could be inverted, divided, and etc.
For example, there can be a constant factor added to the formula, let's name is for fun the BS factor (block size). This factor will be used to show the relation we agree on, between the two indicators. This factor could be negative, a fraction and etc.
The role of this factor is to moderate or extend the calculation's value, to whichever the network decides represents it's needs the best. The factor also can be changed if needed throughout time.

I also agree that the hash rate indicator might not be the perfect one to use - I chose it because it was the most logic one I knew and thought that can work. There might be another indicator that will work better.
But overall, I am optimistic about the ability to find a relation that will be good enough, and will enable us to change block size according to need.



I agree and disagree with you on this one. The 'theoretical' infinite transaction cap is also valid with changing block sizes (because you can keep them growing as much as you need). Like the LN, the only limitations are those we and the technology put.
Another deal breaker for me, is that the LN is off-chain. The bitcoin network is some kind of miracle. I believe we should only move to layer-2 solutions after we are 100000% sure that there is nothing else we can do on-chain.
The LN is operated by a company, which is prone to failure, as we all know and suffer even from big corporations such as facebook. What if someone hacks the company? What if it fails? Hacked? Or anything disastrous that might happen. The beauty of bitcoin is that it operates without anything needed except a few nodes.
This can be an issue for the LN. For example, if I am from the US and I wanna pay someone from Japan, I need one of two scenarios: Either we open a direct channel (but then it would not be efficient since you are paying double fees) or either a long long link of people on the LN are active and if one of these links closes - I might not be able to perform the transaction.
Another thing is that on the bitcoin network, I can even send the coins to a wallet, when the other party isn't online. He will just see the coins next time he connects to the internet.
On the LN, both parties have to be always online in order to make and receive the transactions (they have to have the channel active). This might not be a huge deal, but we already have a system that works seamlessly. So why downgrade ourselves?

I am curios to hear your thoughts about these things. 






The adjustment takes place every 2016 blocks.

This is not the most correct assumption.
First of all the hashrate increase could be because someone made a much more efficient hardware to mine bitcoin (in simple terms a better ASIC). That doesn't have to mean more adoption.
Another reason could be that a very cheap source of electricity were found and more miners got on board in that place. For example the electricity price for home users is ridiculously low where I live ($0.002) but people generally don't know or care about bitcoin mining not to mention that the government regulation that forces any bitcoin miner to register and pay a higher electricity price (equal to export price which is about $0.05 I believe).
Imagine if that changed, and the ASIC production wasn't a bottleneck. The hashrate would shoot up to the moon.

On the other hand we saw how the price crash accompanied with China banning mining and more price crash could lead to hashrate dropping a lot.

In both of these 2 cases everything else about the network remains the same. It takes the same amount of time for nodes to download and verify each block. The number of nodes remain the same, etc. while hashrate jumps up or down.
So, as you can see hashrate is not a good characteristic to use in order to determine the block size.

Generally speaking any dynamic way of computing block size cap is a bad idea.

Bottom line is that we can never reach the desired scalability using block size ever simply because there is always a cap and the block could be filled whether with legitimate transactions or spam ones. But with a second layer that does't have the same limits, we can achieve a lot of scaling.

Fees have to be low for people to use LN otherwise it would make very little sense to even open a channel if you have to pay for example $100.
[/quote]