TheFootMan
|
|
October 11, 2014, 08:26:59 PM |
|
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
Legendary
Offline
Activity: 3934
Merit: 1378
|
|
October 11, 2014, 09:04:48 PM |
|
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
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
|
October 11, 2014, 09:59:43 PM |
|
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?
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
PolarPoint
|
|
October 11, 2014, 10:30:10 PM |
|
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
Legendary
Offline
Activity: 1862
Merit: 1015
|
|
October 11, 2014, 10:53:52 PM |
|
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
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
October 11, 2014, 11:08:27 PM |
|
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
|
|
October 11, 2014, 11:46:36 PM |
|
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
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
October 11, 2014, 11:47:49 PM |
|
OK, but why is the block size limited ... at the beginning ?
|
|
|
|
TheFootMan
|
|
October 11, 2014, 11:49:39 PM |
|
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
|
|
October 12, 2014, 12:04:40 AM |
|
the blockchain is so bloated now, is there some way of reducing its size.
|
|
|
|
247bitcoins
Newbie
Offline
Activity: 25
Merit: 0
|
|
October 12, 2014, 12:15:03 AM |
|
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
|
|
October 12, 2014, 12:44:46 AM |
|
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
Legendary
Offline
Activity: 1974
Merit: 1029
|
|
October 12, 2014, 01:21:07 AM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
October 12, 2014, 01:27:52 AM |
|
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.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
|
October 12, 2014, 02:55:05 AM |
|
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
|
|
October 12, 2014, 12:07:35 PM |
|
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
Legendary
Offline
Activity: 1232
Merit: 1001
mining is so 2012-2013
|
|
October 12, 2014, 12:20:15 PM |
|
needs to be done. bitcoin wasn't just built perfectly the first time. it needs adjustments and this is one of them.
|
|
|
|
santaClause
|
|
October 12, 2014, 05:19:23 PM |
|
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
Newbie
Offline
Activity: 25
Merit: 0
|
|
October 12, 2014, 05:56:05 PM |
|
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
|
|
October 12, 2014, 10:40:25 PM |
|
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
|
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ PRIMEDICE The Premier Bitcoin Gambling Experience - PRIMEDICE 3 HAS LAUNCHED @PrimeDice ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
|
|
|
|