Topic: How a floating blocksize limit inevitably leads towards centralization - page 7. (Read 71610 times)

+1 agree with you jgarzik

I don't understand why you didn't quote number 1, which is the most important part. The plan I outlined involves modeling the different options before the issue becomes a problem. Once it starts to become one, we have a better idea of which option to pursue further, and we can move on it fairly quickly.

Right now I find it hard to believe that a "clearly superior" solution emerges. If one does emerge and it still remains as "the solution" once the blocks become crowded, then so be it. I just think that the more data we have, the easier it is to choose a model that will work on the long run.

I made a similar suggestion, though it was based on hierarchy.  All chains would have a 1MB limit.

There would be a top-level parent chain.  Each chain would have 4 children chains.

Coins could be swapped internally in a chain.  In addition, there would be promote and demote transaction outputs.  This would send coins upwards and downwards.

The problem is that if you require "upward" coins to be verified by the parent chain, then you are effectively including the child chain in the parent chain, which defeats the purpose.

One way around it is to use the simplified payment system to move coins back to the parent chain.  This is where you assume the child chain blocks are valid, as long as there is a reasonable number of confirmations.

Miners on the toplevel chain would include the headers for the lower level chain in the parent chain somehow (say adding a merkle root to the coinbase code).

Once a header is included in the parent chain, then it becomes a "soft" checkpoint in the child chain and must be mined against, unless it is invalid.  Effectively, a child chain header in the parent chain has higher PoW than one that isn't in the header.  Validity checks are still needed so if an invalid child-block is included, it can still be orphaned.

As long as no reorg happens on the parent chain, this makes it much less likely that a re-org would happen on one of the child chains.

The parent chain would checkpoint the children every 1-2 blocks on average.

Downward payments are easy, a child chain needs to just monitor its parent and itself.

Upward payments could have a rule that they are accepted, as long as the transaction is buried at least N blocks deep in the child chain.  This can be checked without having to download the entire child chain.  N could be set to 120 or even higher.  

A balance would be maintained for each child chain.  The total sent upwards from a child chain could never exceed the total sent downwards.  Child chains might end up with reduced coin value.  This would happen if the chain confirmed a transaction that wasn't properly backed (and didn't orphan that transaction).  This protects the parent chain and maintains an incentive for child chains to keep proper track of things.

If a child chain has 5,123,456 coins in various balances (including grandchildren) but only 4,999,124 was actually demoted on net from the parent chain, then it would have to rescale all coins by 4999124/5123456.

Also, child chains would have to be tx fee supported, there would be no minting fee.

Huh? Let's see how bad it is first, how bad it destroys what bitcoin is.... then let's see what we should do about it?

I agree that simply raising the block size limit does not solve the scalability problem. That's why I posted in this thread:

https://bitcointalksearch.org/topic/m.1549439

hell i dont even really understand the proposal. its just process of elimination that leads me to this proposal (since everyone elses proposals have serious problems). But i imagine that blockchains would be regional. Since most trades would be with people in your area than most transactions would remain on the same blockchain. You are right though that if you wanted to send coins to someone on another blockchain you would need to pay 2 tx fees. Which would mean inorder to have the total fees cut in half we would need to ~ quad-ripple the total number of chains not double it.

this would also create a market for firms to store up large amounts of coins from each blockchain and make big transactions instead of a lot of little ones. This would really encourage people to use services like bitpay rather than sending the coins directly.

Unless there where reasons to fafour inner blockchain transactions more than others, this would on average increase the total size by ~50% for the same amount of transactions.

25% Chain A to Chain A transactions
25% Chain A to Chain B transactions
25% Chain B to Chain A transactions
25% Chain B to Chain B transactions

So 50% of all Transactions would have to be noted in two chains.

Unless I understand this proposal wrong.

What about multiple blockchains? And i dont mean competing blockchains, i mean other bitcoin blockchains that use the same bitcoins we use now. These blockchains wouldn't add any coins to the economy and would work entirely on transaction fees. Coins would be added to these blockchains by sending coins from the original blockchain to an address on the new blockchain and coins could be sent back to the original blockchain at any time.

The reason i suggest this is because eventually if bitcoin became a global phenomena, even while pushing the upper bounds of blocksize that the network could handle it could still be the case that transaction fees could be in the range of hundreds or thousands of dollars to get 1 tx included in a block. I dont really know what the solution to this is and admittedly i am grasping at straws here but who knows maybe you guys can take the idea and run with it.

There needs to be a clear idea of how some of the transactions that the blockchain can't handle, can be substituted. I've heard two versions of the story. The first one is that different blockchains, such as Ripple, start complementing Bitcoin. This idea is actually good, and I don't have a major problem with it. Ripple is an excellent complement to Bitcoin.

The second story however, is extremely undesirable. There is talk of people doing increasing amount of transactions within centralized services such as exchanges. That is a disaster which completely destroyes the central ideas behind Bitcoin. Bitcoin is a system without 3rd party trust (this would be destroyed), and it's also a system where using fractional reserve is very impractical (this would be destroyed as well). This second point would lead to the 21M coin limit meaning much less than it does now.

d'aniel had excellent points on this, which are exactly the arguments I'm most concerned about. It's real centralization, not some vague claims of a theoretical mining monopoly. Ripple as a complementary system is not that worrysome though.

That being said, here is how we need to proceed:

1) We come up with alternative models for what we're going to with the block size when this issue hits the fan. One of the options is clearly to do nothing.

2) We wait and see what happens when the current hard limit is pushed. We let the fees go up a bit. We study the reaction from Bitcoin users and see what kind of incentives and solutions higher fees encourage. This is when we start deciding which of the alternative models is actually best.

3) We decide a timetable for the change, if we decide to make a change, and put it in motion.

*We can also be substituted with "the dev team", however this issue is bigger than just the dev team. It's about which direction the users want to steer Bitcoin towards. It's a monumental decision.

I don't think making the Blocksize a function of a fixed BTC fee amount would be a good Idea.

1. We can impossible know how much 50 BTC will be at some point. This could mean (unlikely, but still) at some point that you would have to pay 1000st of Dollars to get a Transaction processed.

2. This directly contradicts that lost coins are not a problem.

3. Lets look at the 50 BTC total reward example. That would mean at some point that each Year 6.75% of all BTC to ever exist would have to be spend as fees.

As a slight tweak on the pay for space rule, what about making it exponential.

When difficulty is updated, update the max block size for the next period based on the total fees for the previous period.

MAX_BLOCK_SIZE (MB) = pow(2, ((tx + minting fees for the last period) / 50 / 2016) - 1)

This would allow reasonably fast growth, but still guarantee tx fees.

In fact, in the extreme, you could just remove the block size limit for any block that is has at least 50 total fees.

By averaging it over a period, it prevents combing lots of transactions into 1 block to bypass the rule.

-> -> -> -> ->

OTOH, maybe that is a good thing.  Most "small" miners could still mine the small fee txs.

The sizes would be

6.75:
12.5: 0.59MB
25: 0.7 MB
50: 1 MB
100: 2MB
150: 4MB
200: 8MB
250: 16MB
300: 32MB
350: 64MB
400: 128MB

To use up the entire bitcoin coinbase each year in fees requires around 400 BTC per block on average, so it is still hitting a hard limit.

The dynamic system could be that if the (tx + minting) fees are > T per block in the last period, then increase by 10% and if less than 0.5T, then decrease by 10%.