How a floating blocksize limit inevitably leads towards centralization

[Akka]

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.
...

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.

[1714056350]

1714056350

[1714056350]

1714056350

[1714056350]

1714056350

[Technomage]

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.

[Anon136]

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.

[Akka]

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.

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.

[Anon136]

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.

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.

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.

[justusranvier]

Increasing the size prematurely isn't scalability, its actual scaling. Heck even when it is time to do it (when it is no longer premature) it still will be actual scaling, not mere scalability. Get the difference? Scaling (actually increasing the size) awaits scalability (the mythical or vaporous or simply not quite yet ready to be merged-in optimsations).

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

https://bitcointalk.org/index.php?topic=93606.msg1549439#msg1549439

[hazek]

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.

What is this mystical "we" that you keep referring to? There is no "we". There are just peers in a peer to peer network. So I think when you say "we" you mean "Peers who agree with me and give their consent to my proposal".

Wanted clear that up so you don't get too confused when you're daydreaming how you would solve this problem for "us".  

[wtfvanity]

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

...
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.

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?

[TierNolan]

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.

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.

[Technomage]

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

...
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.

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 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.

[paraipan]

Isn't it possible to have a better happy medium though? Where transactions are say........ a dollar at most? Or maybe a few?  Just how big would they get? Maybe that's why all the devs are saying wait and see. :T
But yeah it would still be an achievement to actually need a greater block size

* "the devs" do not even agree amongst themselves

* There is no immediate need to change the block size (as you point out), only a perceived, debatable future need.

* Until that point happens, it is impossible to know what is a happy medium.  And how will we know that happy medium?  The free market and user choice will decide, not some cabal of miners or devs.

It is entirely within the realm of possibility that the userbase would refuse to change the block size.  It is inevitable that some users will indeed refuse to upgrade, thereby rejecting all (in their opinion) oversized blocks, thereby creating that most undesirable of outcomes, the long-lived chain fork.

Will a majority endorse the block size change, or refuse?  An unanswerable engineering question, for the moment.  And given the present lack of need for a hard forking change, there is not much point in speculation.

+1 agree with you jgarzik

[meowmeowbrowncow]

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.

Yep, the idea of turning to off chain transactions just implies that Bitcoin failed to meet demand.

[Anon136]

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.

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.

You know what would be almost functionally equivalent. Release bitcoin2 as soon as it becomes a problem. it could be literally exactly the same as bitcoin1 in every way except 2. The market would drive people to adopt bitcoin 2 and 3 and 4 when transaction fees became unresonable, but they would also have incentive not to addopt too early since the more established chains would be more marketable. Anyway if decentralized electronic exchanges eventually make the process of buying products from someone who only accepts payment from a chain that you dont use sufficiently seamless than it wouldnt really be all that different than what i originally described.

as a user you would need to decide on a trade off between how accepted your chain is (how often you would need to use an exchange) how high the fees were and how secure the chain was (higher tx fee chains being more secure)

now at this point you have something fairly similar to what i originally outlined, only instead of actully moving btc from one chain to the other, you could just use seamless electronic exchanges.

[TierNolan]

You know what would be almost functionally equivalent. Release bitcoin2 as soon as it becomes a problem. it could be literally exactly the same as bitcoin1 in every way except 2.

Not entirely, the main/root chain effectively secures all the value for all the chains in the hierarchy.

You could also have software that can handle the promote/demote system efficiently.

now at this point you have something fairly similar to what i originally outlined, only instead of actully moving btc from one chain to the other, you could just use seamless electronic exchanges.

You might even be able to merge the signatures in some way.  The transaction would have to be valid in both chains.

[markm]

Have you encountered the term "merged mining" yet?

If you are not familiar with it, take a look, as you seem to be trying to reach out and find it...

-MarkM-

[jl2012]

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

While BTC/USD > 0
(15. Alternate chains become more and more popular.
16. People sell bitcoin and buy altcoins
17. BTC/USD exchange rate decreases. Profit of bitcoin mining decreases
18. Miners switch to SHA256 altcoins
19. Goto 15)
20. End of bitcoin

[MoonShadow]

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

While BTC/USD > 0
(15. Alternate chains become more and more popular.
16. People sell bitcoin and buy altcoins
17. BTC/USD exchange rate decreases. Profit of bitcoin mining decreases
18. Miners switch to SHA256 altcoins
19. Goto 15)
20. End of bitcoin

More guessing.

[MoonShadow]

Some of you guys are really overthinking this.

[conv3rsion]

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

While BTC/USD > 0
(15. Alternate chains become more and more popular.
16. People sell bitcoin and buy altcoins
17. BTC/USD exchange rate decreases. Profit of bitcoin mining decreases
18. Miners switch to SHA256 altcoins
19. Goto 15)
20. End of bitcoin

10a Use cases for Bitcoin decrease as more transactions types become economically not feasible
10b New investment in Bitcoin decreases as potential use cases decrease
10c Additional integration into Bitcoin decreases
10d Network effects decrease value in Bitcoin
10e BTC / USD drops



Ask Friendster what happens when you can't f'in scale. Anybody remember Friendster?

[MoonShadow]

10a Use cases for Bitcoin decrease as more transactions types become economically not feasible
10b New investment in Bitcoin decreases as potential use cases decrease
10c Additional integration into Bitcoin decreases
10d Network effects decrease value in Bitcoin
10e BTC / USD drops



Ask Friendster what happens when you can't f'in scale. Anybody remember Friendster?

And this is exactly why some of you guys shouldn't be so hostile towards out-of-band transaction systems, even if that results in some degree of localized centralization.  For that matter, member2member transactions on MtGox is localized centralization, but does not imply that MtGox suddenly has some special power over the Bitcoin community.