Block size limit problem

[konradp]

Hi,

One block is solved every ~10 minutes. It is limited to 1mb, which means that there is a limited number of transactions per unit of time.

i.e. blockchain.info reports that in recently solved blocks one transaction used ~0.5kb, so there is a limit of 1mb/0.5kb == 2 097 152 transactions for every block.

I do understand that transactions which did not fit in one block go to the next one, but what if we will have constantly over 2 097 152 transactions every 10 minutes? That's only 3495/second, once Bitcoin will become popular, and used around the entire world, it's not so difficult to imagine this will happen some day.

Or am I missing something?

[TierNolan]

You miscalculated.  It is worse than that.

Transactions are around 250 bytes (not 512).  1MB/250byes = 4194 transactions.  That is 7 transactions per second.

There is a trade-off.  If you make the block size larger, then the blockchain grows.  This makes it harder to run a node.

A small block size means that fees are higher due to space limitations.

If you see bitcoin as "store of value", then security is critical.  This means that the p2p nature of the system must be protected, so smaller blocks are better.

If you see it as purely a payment system, then larger blocks are better as they have a higher number of transactions per second.

You can get the best of both worlds (somewhat) if you use the current bitcoin system as the foundation and then build fast/low cost transaction services on top of it.

The "channels" system would be an example of that.

[konradp]

You miscalculated.

Indeed  I messed up bytes with kilobytes...

I understand everything until this point:

You can get the best of both worlds (somewhat) if you use the current bitcoin system as the foundation and then build fast/low cost transaction services on top of it.

The "channels" system would be an example of that.

What do you mean by "if you use the current bitcoin system as the foundation"? This is a proposal for a change in Bitcoin? Or is this something existing already?

[TierNolan]

What do you mean by "if you use the current bitcoin system as the foundation"? This is a proposal for a change in Bitcoin? Or is this something existing already?

Taking the channels system as an example, that allows you create a micro-payment channel.  Only 2 transactions are required.

Once it is setup, you can make as many small payments to the provider as you want without using the block chain at all.

Another system would be where the current bitcoin system is used as a foundation/long term store.  Other chains would act like psuedo banks.  You could move money between 2 people in the same "bank" without having to use the main chain.  For inter-bank transfers, those "bank" chains could sync up once a day or something.  This would mean 1 transaction per day for all transactions between those chains.

If a sub-chain fails, then only people with money in that chain would lose.

Bank chains could also be simple banks and you would have to trust them with some of your money, but the advantage would be lower fees.  They might use chains though for extra transparency.

For long term savings, you could use the main chain.

[konradp]

OK, thanks!

[kokojie]

Hi,

One block is solved every ~10 minutes. It is limited to 1mb, which means that there is a limited number of transactions per unit of time.

i.e. blockchain.info reports that in recently solved blocks one transaction used ~0.5kb, so there is a limit of 1mb/0.5kb == 2 097 152 transactions for every block.

I do understand that transactions which did not fit in one block go to the next one, but what if we will have constantly over 2 097 152 transactions every 10 minutes? That's only 3495/second, once Bitcoin will become popular, and used around the entire world, it's not so difficult to imagine this will happen some day.

Or am I missing something?

Much of the retail transactions will eventually happen offchain, kinda like what coinbase does now. If buyer/seller both have coinbase, the transaction will happen off chain. The only thing that happen "on chain" are deposit/withdrawals at coinbase

[dreamspark]

Including the fact that transactions will as said mainly happen of chain, another point to note is the size of blocks being produced at the moment, there are a number of reasons for this, one being individual miner limits, that I think can be addressed way before talking about blocks full of transactions.

[somic]

how much size is best for a block? according to the block reward? is there a proportion?

[dreamspark]

how much size is best for a block? according to the block reward? is there a proportion?

The size of a block has nothing to do with the reward. It is just that, a max size that the block can be, currently this is 1mb.

[konradp]

kokojie:

Much of the retail transactions will eventually happen offchain, kinda like what coinbase does now. If buyer/seller both have coinbase, the transaction will happen off chain. The only thing that happen "on chain" are deposit/withdrawals at coinbase

This is something I don't quite understand... how a transaction may happen "offchain"? Do you mean that something (blocks?) may be included outside the main blockchain and still be valid?

[TierNolan]

This is something I don't quite understand... how a transaction may happen "offchain"? Do you mean that something (blocks?) may be included outside the main blockchain and still be valid?

With channels, you can do micropayments.

For example, if a service charged $0.01 a minute for a video stream, then that would work out at 0.00002BTC per minute.

You "lock" 0.1BTC into the channel.  This requires 1 transaction in the block chain.

The provider sends you a transaction which pays you 0.1BTC but you can't cash it for 24 hours.

Other than that, the 0.1BTC can only be spent if you both agree.

This means you can get your money back in 24 hours no matter what.

You watch the video, and every 60 seconds, your client sends 0.00002 BTC to the provider.

You actually send the provider a signed transaction

Pays you 0.99998
Pays provider 0.00002

The provider doesn't broadcast it, it just keeps it.

60 seconds later, your client sends

Pays you 0.99996
Pays provider 0.00004

Again, the provider doesn't send out the transaction to the network.  It is private between the 2 of you.

Once you stop watching the video, you can "close" the channel.

At that point, the provider signs the last transaction you sent him and broadcasts it.

The provider will also broadcast it.  That will result in you get back most of your money except the portion that you gave to the provider.

If the provider goes offline, then you could use the refund transaction 24 hours later, and get all your money back.  Providers would have to be careful to send out their transaction first.

Another way to move transactions off the main chain is to have services like banks.  The banks would send money to each other via the bitcoin system but customers would use the banks.

If 2 banks had 1000 customers send money between each other, then banks could consolidate that transaction into a single transaction.

You could store your savings in your own wallet but use banks for day to day transactions.  That way you would pay less fees (but also be more at risk).

[konradp]

This is something I don't quite understand... how a transaction may happen "offchain"? Do you mean that something (blocks?) may be included outside the main blockchain and still be valid?

With channels, you can do micropayments.

For example, if a service charged $0.01 a minute for a video stream, then that would work out at 0.00002BTC per minute.

You "lock" 0.1BTC into the channel.  This requires 1 transaction in the block chain.

The provider sends you a transaction which pays you 0.1BTC but you can't cash it for 24 hours.

Other than that, the 0.1BTC can only be spent if you both agree.

This means you can get your money back in 24 hours no matter what.

You watch the video, and every 60 seconds, your client sends 0.00002 BTC to the provider.

You actually send the provider a signed transaction

Pays you 0.99998
Pays provider 0.00002

The provider doesn't broadcast it, it just keeps it.

60 seconds later, your client sends

Pays you 0.99996
Pays provider 0.00004

Again, the provider doesn't send out the transaction to the network.  It is private between the 2 of you.

Once you stop watching the video, you can "close" the channel.

At that point, the provider signs the last transaction you sent him and broadcasts it.

The provider will also broadcast it.  That will result in you get back most of your money except the portion that you gave to the provider.

If the provider goes offline, then you could use the refund transaction 24 hours later, and get all your money back.  Providers would have to be careful to send out their transaction first.

Another way to move transactions off the main chain is to have services like banks.  The banks would send money to each other via the bitcoin system but customers would use the banks.

If 2 banks had 1000 customers send money between each other, then banks could consolidate that transaction into a single transaction.

You could store your savings in your own wallet but use banks for day to day transactions.  That way you would pay less fees (but also be more at risk).

OK, I get it now. So it will look like this: there will first appear problems with Bitcoin, and then we'll see banks as a solution? So, this is going to be like "Hey, there is a problem with Bitcoin, but if most of you will start using banks, our for example, then everything will be fine"?

[Sukrim]

See https://en.bitcoin.it/wiki/Maximum_transaction_rate on the wiki (unfortunately nothing links there...)

[TierNolan]

OK, I get it now. So it will look like this: there will first appear problems with Bitcoin, and then we'll see banks as a solution? So, this is going to be like "Hey, there is a problem with Bitcoin, but if most of you will start using banks, our for example, then everything will be fine"?

Banks was the just 1 option.

The channels thing allows lots of micropayments without overloading the blockchain.

I think alternative chains would also help.

You could have a gold / silver / copper coin kind of thing.  

There is a system to allow transactions between bitcoin and alt-chains.  It is weakened due to tx malleability, but in principle, it should work.

This would allow people buy alt-coins with their bitcoins and then use the alt-coins for actual transactions.  Bitcoin would be the "gold" and the altcoins would be like copper coins.

The conversion fee would vary.

There is also a proposal to have a formal hierarchy of chains.  Coins are moved between chains on a one to one basis but you can have lots of chains, so the effective transaction limit is increased.

Coins in the root/main chain would be the most secure, but would have high tx fees.

What would be good would be an alt-coin which has no minting.  You get alt-coins by sending bitcoins to some address.  This then credits your account on the alt-chain.

Similarly, you can redeem the alt-coins back into bitcoins.

[Sukrim]

You're just describing Ripple here...

What would be good would be an alt-coin which has no minting.  You get alt-coins by sending bitcoins to some address.  This then credits your account on the alt-chain.

Similarly, you can redeem the alt-coins back into bitcoins.

[JohanS]

Wouldn´t it be possible to update the size of blocks to enable more transactions when this become a limiting factor for transactions? I.e when the average number of transactions is 7 per second, the size increase to 1,5 MB. When the number reaces 10, increase to 2mb end so on and so forth... Or is changing the blocksize a difficult technical issue?

[TierNolan]

You're just describing Ripple here...

Well, I was thinking of a formal chain.  Ripple doesn't have that right? 

It is a trust chain, where you set limits about how much you trust various peers?

You are right that it is another option.

Ideally, public auditing wouldn't have to be scarified in other to support increasing the transactions per second.

[konradp]

OK, I get it now. So it will look like this: there will first appear problems with Bitcoin, and then we'll see banks as a solution? So, this is going to be like "Hey, there is a problem with Bitcoin, but if most of you will start using banks, our for example, then everything will be fine"?

Banks was the just 1 option.

The channels thing allows lots of micropayments without overloading the blockchain.

I think alternative chains would also help.

You could have a gold / silver / copper coin kind of thing.  

There is a system to allow transactions between bitcoin and alt-chains.  It is weakened due to tx malleability, but in principle, it should work.

This would allow people buy alt-coins with their bitcoins and then use the alt-coins for actual transactions.  Bitcoin would be the "gold" and the altcoins would be like copper coins.

The conversion fee would vary.

There is also a proposal to have a formal hierarchy of chains.  Coins are moved between chains on a one to one basis but you can have lots of chains, so the effective transaction limit is increased.

Coins in the root/main chain would be the most secure, but would have high tx fees.

What would be good would be an alt-coin which has no minting.  You get alt-coins by sending bitcoins to some address.  This then credits your account on the alt-chain.

Similarly, you can redeem the alt-coins back into bitcoins.

Yes, I know it was only one option, but the channels concept seemed very specific one to me.

Anyway, just like JohanS mentioned (above) isn't it simpler to increase the block size?

[TierNolan]

Wouldn´t it be possible to update the size of blocks to enable more transactions when this become a limiting factor for transactions? I.e when the average number of transactions is 7 per second, the size increase to 1,5 MB. When the number reaces 10, increase to 2mb end so on and so forth... Or is changing the blocksize a difficult technical issue?

It is just changing a parameter in the source code.

The difficulty is getting everyone to agree to it.  If they boost it to 2MB, then older clients won't accept the new blocks.

You have to convince everyone to upgrade.

There is a 32MB limit to the size of messages in the protocol.  At the moment, blocks have to fit in a single protocol message.  Going past 32MB blocks would mean a protocol change of some kind.  Maybe blocks could be split over multiple messages.

Increasing the message size could make networking a little more difficult.  It isn't that big an issue though.

If you increase to 2MB, then the size of the blockchain potentially doubles.  That means more hard drive usage.

The tradeoff is that a small block size means less load on the nodes.  This means more nodes and so the system retains its decentralize nature.  

A larger block size means more transactions per second, so the network can expand more.

[konradp]

Wouldn´t it be possible to update the size of blocks to enable more transactions when this become a limiting factor for transactions? I.e when the average number of transactions is 7 per second, the size increase to 1,5 MB. When the number reaces 10, increase to 2mb end so on and so forth... Or is changing the blocksize a difficult technical issue?

It is just changing a parameter in the source code.

The difficulty is getting everyone to agree to it.  If they boost it to 2MB, then older clients won't accept the new blocks.

You have to convince everyone to upgrade.

There is a 32MB limit to the size of messages in the protocol.  At the moment, blocks have to fit in a single protocol message.  Going past 32MB blocks would mean a protocol change of some kind.  Maybe blocks could be split over multiple messages.

Increasing that could make networking a little more difficult.  It isn't that big an issue though.

If you increase to 2MB, then the size of the blockchain potentially doubles.  That means more hard drive usage.

The tradeoff is that a small block size means less load on the nodes.  This means more nodes and so the system retains its decentralize nature.  

A larger block size means more transactions per second, so the network can expand more.

But we're are talking about distant future, the network, cpus, drives, all of these will be faster and bigger with time. So why didn't Satoshi decide to limit the block size to 32 MB at the beginning?

[TierNolan]

But we're are talking about distant future, the network, cpus, drives, all of these will be faster and bigger with time. So why didn't Satoshi decide to limit the block size to 32 MB at the beginning?

He could also have made the 1MB limit a soft limit and the 32 MB limit a hard one.

The working plan seems to be that it won't be increased until people start complaining about it.

If it was increased, then a majority of miners could still limit the blocks to 1MB by refusing to build on any 2MB blocks.

The trick is to allow traders (merchants and their customers) and savers have some say.  If all 3 groups agreed, then it could be increased.

Arguably, if trades and miners agreed, then there isn't much savers could do about it.

[konradp]

OK, I get it now (I think), thank you for all your answers!