Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability

[TheFootMan]

Would not the best solution be a dynamic update?

With gavin suggestions we have that max blocksize will become

2014: 1mb
2015: 1.5mb
2016: 2.25mb
2017: 3.375mb
2018: 5.0625
2019: 7.59375
2020: 11.390625
2021: 17.0859375
2022: 25.62890625
2023: 38.44335937

Would it not be better to have something dynamic? I'm not sure how close we're to the current limit of 7tx/sec, but once that approaches, would it not be advised to increase the max blocksize slightly as to give room for the new demand, and then if demands for transaction bandwidth decreases, the max block size is adjusted accordingly?

Perhaps it could be a good idea to prevent the tiniest transactions on the network as well, and push these off to off-chain payment systems? For example, if youtube implemented bitcoin tips in their system, would it not be better that users could deposit a small amount with them, and then tip youtubers as they saw fit, instead of using the block chain to send tiny transactions all the time?

For example, the tiniest amount allowed to send could be 0.0001 BTC, about 0.05USD with today's prices. Would this help reduce the amount of  transactions currently being distributed on the bitcoin network?

[BADecker]

I remain sceptical on any block size increase, because it promotes centralization of nodes. If Gavin's plan is implemented there will be progressively less full nodes being able or willing to participate in the network because bandwidth and storage requirements are too demanding. A non-conditional yearly 50% increase is a very bold figure. It's not even clear if technology will be able keep up with this rate longer term.

If block size increases really can't be circumvented through other measures, they should not be done in a static irreversible step-by-step increase (comparable to coin issuance) but instead in a dynamic way that allows for increases and decreases based on previous usage (comparable to difficulty adjustment). Doing it that way would allow systemic self-regulation, always providing as much bandwidth as necessary but not (much) more than needed. So some healthy competition between transactions (size, fees) remains in place and resources (bandwidth, storage) are much more likely of being used responsibly and not being wasted.

Yes. And maybe an exponential moving average of previous usage.

How would something like this affect the 50% miner centralization control of Bitcoin?

[smoothie]

Would not the best solution be a dynamic update?

I think this is a good idea but it has other implications as far as network attacks. If no one really knows the size of a block because it is ever adjusting couldn't that be an attack vector?

[PolarPoint]

The max block size is only the maximum, miners may continue to mine 200k blocks if they wish. So, transactions volume may never change. We might have to wait until the next reward halving before we see any real benefits of this fork.

[btc-facebook]

I remain sceptical on any block size increase, because it promotes centralization of nodes. If Gavin's plan is implemented there will be progressively less full nodes being able or willing to participate in the network because bandwidth and storage requirements are too demanding. A non-conditional yearly 50% increase is a very bold figure. It's not even clear if technology will be able keep up with this rate longer term.

If block size increases really can't be circumvented through other measures, they should not be done in a static irreversible step-by-step increase (comparable to coin issuance) but instead in a dynamic way that allows for increases and decreases based on previous usage (comparable to difficulty adjustment). Doing it that way would allow systemic self-regulation, always providing as much bandwidth as necessary but not (much) more than needed. So some healthy competition between transactions (size, fees) remains in place and resources (bandwidth, storage) are much more likely of being used responsibly and not being wasted.

Just because the max block size is larger does not mean that every block (or even any block) will be as large as the max block size. If the miners do not include enough TXs to make the block a larger size then the nodes will not need to use as much bandwidth as they otherwise would, therefore there is little reason why a node that operates today would cease operating tomorrow if the block size were increased tomorrow.

I think having the max block size change based on the last n block sizes would be too complicated and would add an unnecessary level of complexity to the protocol. 

[Meuh6879]

why do you want increase block when the 7 transactions per second is not reach ?
http://btcaudio.tk/live = 0,7-0,9 transactions per second.

[TheFootMan]

why do you want increase block when the 7 transactions per second is not reach ?
http://btcaudio.tk/live = 0,7-0,9 transactions per second.

It's called vision. It's what some men have that's thinking ahead and not only looking at what they have in front of their nose.

[Meuh6879]

OK, but why is the block size limited ... at the beginning ? 

[TheFootMan]

OK, but why is the block size limited ... at the beginning ? 

Very good question! I don't have the answer. Maybe for the same reason that IPV4 address space became to small?

[gog1]

the blockchain is so bloated now, is there some way of reducing its size.

[247bitcoins]

anyone got a link to info on the 7 trx per sec limit?

I thought the network limit was more reliant on number of nodes than a limit in the script?

[TheFootMan]

the blockchain is so bloated now, is there some way of reducing its size.

There's work being done on this. If you read the bitcoin foundation post of Gavin where he talks about this proposed fork, he mentions this. Sorry no link.

[dserrano5]

anyone got a link to info on the 7 trx per sec limit?

Current block size limit is 1 Mb. An average transaction is 200-something bytes. One block every ten minutes, i.e. every 600 seconds.

You do the math .

[Lauda]

Well if this were to be done, then the developers should look at the hardfork wishlist, and implement more stuff from that.
The less forks that we have, the better.
Although I do agree that this needs to be done.

[Cryddit]

Miners are leaving transactions out of blocks today because the blocks propagate faster (ie, have more odds of being confirmed) if they are <250K.  Odds on losing the block fee exceed the transaction fees available, and the miner leaves the transaction unconfirmed. 

Raising the size of the largest allowed blocks will not change that. 

Do we have an implementation yet of broadcasting only the block header, and then letting the nodes assemble the blocks out of transactions they've already received over the network?  That would reduce miners' disincentives for including transactions, so wouldn't that would be the more immediate means of increasing the number of transactions per block?

I agree that the block size needs to be increased; I'm just saying that increasing the allowed block size won't help if miners still have a financial incentive to limit the actual block size to 250K.

[bf4btc]

anyone got a link to info on the 7 trx per sec limit?

Current block size limit is 1 Mb. An average transaction is 200-something bytes. One block every ten minutes, i.e. every 600 seconds.

You do the math .

The limit is also written into the protocol. What you are implying is that the block size limit would prevent the average number of TX per second to be more then 7. Under this theory someone could broadcast 20 TX one second then as long as few enough other TX get transmitted they will all get included in the block, however this is not how it works. It is my understanding that the nodes will reject TXs if more then 7 are transmitted in a second

[jabo38]

needs to be done.  bitcoin wasn't just built perfectly the first time.  it needs adjustments and this is one of them.

[santaClause]

needs to be done.  bitcoin wasn't just built perfectly the first time.  it needs adjustments and this is one of them.

The block size was appropriate for it's early days when there were few transactions, and balanced the resources needed to run a node with maintaining the ability to have a lot of TX per block. 

As bitcoin has evolved into more of a payment method, more transactions will occur every second which  equals more space in each block

[247bitcoins]

anyone got a link to info on the 7 trx per sec limit?

Current block size limit is 1 Mb. An average transaction is 200-something bytes. One block every ten minutes, i.e. every 600 seconds.

You do the math .

This is a result of number of nodes then? Or is it the difficulty level the nodes have imposed upon them?

The limit is also written into the protocol. What you are implying is that the block size limit would prevent the average number of TX per second to be more then 7. Under this theory someone could broadcast 20 TX one second then as long as few enough other TX get transmitted they will all get included in the block, however this is not how it works. It is my understanding that the nodes will reject TXs if more then 7 are transmitted in a second

What script in the core has a hard limit written into it?

I think the transactions are more limited as to difficulty than any hard line core limit???

The first response was simple math, current blocks mined at X time and it contains Y trans.

So 'difficulty' in creating a new block is the limiting factor, is it not?

If there is a hard limit in the core somewhere, can anyone point out to what part of the core on Github is the file showing any hard limit?

My understanding right now is that the so-called difficulty in mining new blocks is the speed factor?

If 7 tranx a second is the real limit, then why not ease difficulty and let btc hit it's full 21M or whatever limit in bct there is, less difficulty mining should up tranx per second.

At 7 a second it's a 600k daily limit which is way too small.

Global Debit and Branded CC trans in 2012 were 40 Billion Debit cards and 18 Billion credit card trans, so 60 Billion is the global yearly transactions.

BTC at 7 trans a second can do 220 million a year

So to be equal to credit cards it would have to increase trans speed 100 fold, that's why some geeks have said the core needs to be done in Assembly and put on a network of major super computers to get to the level of the global CC system, thousands of low end computers can't compete with super computers and a sleek assembly level system.

So maybe a trusted core network of 10 super computers and the old system gets canned.

Right now btc has no need to try to compete with a network that can do 20 Billion transactions a year live visa/mc

But if btc is to keep growing, it has to do way more than 200M trans a year.

Debit and CC info from

http://www.creditcards.com/credit-card-news/credit-card-industry-facts-personal-debt-statistics-1276.php

[mnmShadyBTC]

Miners are leaving transactions out of blocks today because the blocks propagate faster (ie, have more odds of being confirmed) if they are <250K.  Odds on losing the block fee exceed the transaction fees available, and the miner leaves the transaction unconfirmed. 

Raising the size of the largest allowed blocks will not change that. 

Do we have an implementation yet of broadcasting only the block header, and then letting the nodes assemble the blocks out of transactions they've already received over the network?  That would reduce miners' disincentives for including transactions, so wouldn't that would be the more immediate means of increasing the number of transactions per block?

I agree that the block size needs to be increased; I'm just saying that increasing the allowed block size won't help if miners still have a financial incentive to limit the actual block size to 250K.

As the block subsidy is reduced this will become less of an issue as a higher percentage of total block reward will be from TX fees.

Fore each additional second it takes for a block to propagate there is only ~1/600 chance (maybe more if the difficulty is increasing) that the block will be orphaned because of extra propagation time. If the amount of additional TX fees makes it worth the miners to take this risk then they will include the additional TXs and take the risk of their found block being orphaned