Topic: Is a reduced reward time possible? (Read 3068 times)
How many altcoin forked their blockchain to get the faster block times? Forking is different and harder to do than having the block time originally since it requires a certain activation threshold and other conditions before the variables can change.
Vitalik Buterin's (non-serious) proposal on soft-forking block time to 2 mins (increasing tx/sec capacity by x5):
https://www.reddit.com/r/btc/comments/428tjl/softforking_the_block_time_to_2_min_my_primarily/?ref=share&ref_source=link
Quote
So given that large portions of the bitcoin community seem to be strongly attached to this notion that hard forks are an unforgivable evil, to the point that schemes containing hundreds of lines of code are deemed to be a preferred alternative, I thought that I'd offer an alternative strategy to increasing the bitcoin blockchain's throughput with nothing more than a soft fork - one which is somewhat involved and counterintuitive, but for which the code changes are actually quite a bit smaller than some of the alternatives; particularly, "upper layers" of the protocol stack should need no changes at all.
...
...
Maybe it is just rumor but I heard that the Bitcoin network is already the world's largest computer network by an incredibly large margin. Is that just a lot of bunk? Because if what seems to be an excessive amount of capacity is not on the table after months of debate about blocksize to the point of nausea then why? How much capacity is just the right amount of security?
Actually the internet is the worlds largest computer network. What is "an excessive amount of capacity"? Capacity for what? Block size is not the Bitcoin network but rather the blockchain itself, which is different from the network. The network has immense capacity, just like the internet. Loads of data passes through the network, but the blockchain, that is a different matter, which is separate from the network.I've heard (don't know if it is reliable) that the Bitcoin network has the computing power of the top 500 supercomputers combined. Is that true or a bunch of horsecrap? if not true, let's get an accurate number. If true then it would seem talk about loss of security is not accurate.
It is not comparable. Supercomputers are almost like general application computers. They can do a lot of stuff, they are application specific like most mining hardware is. Sure the hash power is probably capable of producing SHA256d hashes faster than any supercomputer, but when it comes to doing other stuff, especially for benchmarks, the network can do squat. It is not a fair comparison, in fact, it is essentially a comparison of apples to oranges, they are two different things.As for a loss of security, while the loss of security at this time may be small, we shouldn't do anything which can result in any loss of security. However small the loss is, if we can avoid it, we should.
Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
Maybe it is just rumor but I heard that the Bitcoin network is already the world's largest computer network by an incredibly large margin. Is that just a lot of bunk? Because if what seems to be an excessive amount of capacity is not on the table after months of debate about blocksize to the point of nausea then why? How much capacity is just the right amount of security?
I've heard (don't know if it is reliable) that the Bitcoin network has the computing power of the top 500 supercomputers combined. Is that true or a bunch of horsecrap? if not true, let's get an accurate number. If true then it would seem talk about loss of security is not accurate.
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
In the case of a Finney attack, the quicker that the average block is mined, the less time the attacker has to execute the double payment and then broadcast his mined block (http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack). It would cost the attacker half as much time, but he would be racing against other miners who would be solving twice as fast. I imagine there are other security issues associated with faster reward time but I don't see how it makes Finney attacks more likely.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
Is this necessarily true? I think it depends on whether the confirmation accuracy scales at the same rate as the number of stale blocks. From what I understand, lower reward time --> more stale blocks --> more stale transactions percolating through the network --> less confidence in confirmations --> need for greater # of confirmations. 1) Is that right? 2) If so, I can't imagine each piece scales proportionally, which is what it seems like you're proposing above (in asserting that safe transaction time wouldn't change).
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
In the case of a Finney attack, the quicker that the average block is mined, the less time the attacker has to execute the double payment and then broadcast his mined block (http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack). It would cost the attacker half as much time, but he would be racing against other miners who would be solving twice as fast. I imagine there are other security issues associated with faster reward time but I don't see how it makes Finney attacks more likely.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
Is this necessarily true? I think it depends on whether the confirmation accuracy scales at the same rate as the number of stale blocks. From what I understand, lower reward time --> more stale blocks --> more stale transactions percolating through the network --> less confidence in confirmations --> need for greater # of confirmations. 1) Is that right? 2) If so, I can't imagine each piece scales proportionally, which is what it seems like you're proposing above (in asserting that safe transaction time wouldn't change).
Finney attack? really? how much does it cost to carry out such attack? thousands of dollars, correct?
Yes, but it gets cheaper with faster block time since it will cost less to get the equipment with the necessary hash power.what kind of merchant would accept thousands of dollars in payment, without waiting for a few confirmations?
What's that got to do with anything?It would take 10-20 minutes for a transaction to be considered safe, IF the transaction is high value. For everyday low value
transaction, 1st confirmation is more than enough. With faster blocks, 1st confirmation comes much faster, which is BETTER security
than 0 confirmation. Let's face it, currently a solid 6 confirmation often take a LONG time. With faster blocks, 6 confirmation is
still pretty solid, but takes a lot less time.
Not necessarily. It isn't about the number of confirmations. With faster blocks the diff is lower so if takes less hash power to find the same amount of blocks. What good does a confirmation do it the block the transaction was confirmed in is orphaned and the longer chain didn't contain that transaction? With lower diffs for a faster time, this scenario becomes more feasible.transaction, 1st confirmation is more than enough. With faster blocks, 1st confirmation comes much faster, which is BETTER security
than 0 confirmation. Let's face it, currently a solid 6 confirmation often take a LONG time. With faster blocks, 6 confirmation is
still pretty solid, but takes a lot less time.
Faster blocks hard to implement??? huh??? How hard can it be to implement when 99% of all altcoins has faster blocks???
It is easy to implement from the beginning like with an altcoin because it was there from the beginning and did not require a hard fork. How many altcoin forked their blockchain to get the faster block times? Forking is different and harder to do than having the block time originally since it requires a certain activation threshold and other conditions before the variables can change. It also requires more steps as the difficulty retarget algorithm needs to be changed and the difficulty needs to be dropped when the fork activates. That is more stuff to do than changing one variable when the fork activates for a block size limit increase.
Finney attack? really? how much does it cost to carry out such attack? thousands of dollars, correct?
what kind of merchant would accept thousands of dollars in payment, without waiting for a few confirmations?
It would take 10-20 minutes for a transaction to be considered safe, IF the transaction is high value. For everyday low value
transaction, 1st confirmation is more than enough. With faster blocks, 1st confirmation comes much faster, which is BETTER security
than 0 confirmation. Let's face it, currently a solid 6 confirmation often take a LONG time. With faster blocks, 6 confirmation is
still pretty solid, but takes a lot less time.
Faster blocks hard to implement??? huh??? How hard can it be to implement when 99% of all altcoins has faster blocks???
what kind of merchant would accept thousands of dollars in payment, without waiting for a few confirmations?
It would take 10-20 minutes for a transaction to be considered safe, IF the transaction is high value. For everyday low value
transaction, 1st confirmation is more than enough. With faster blocks, 1st confirmation comes much faster, which is BETTER security
than 0 confirmation. Let's face it, currently a solid 6 confirmation often take a LONG time. With faster blocks, 6 confirmation is
still pretty solid, but takes a lot less time.
Faster blocks hard to implement??? huh??? How hard can it be to implement when 99% of all altcoins has faster blocks???
You guys should search for these topics before asking the same questions that have been asked for many years. Just do a google search.
Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
There is also an increased overhead on SPV wallets (but not really that much) as they would need to store more block headers and thus more data.
And lastly, I think it may actually be a little harder to implement this than it would be to implement a higher block size limit, although to determine that would require some code digging which I don't want to do.
Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
There is also an increased overhead on SPV wallets (but not really that much) as they would need to store more block headers and thus more data.
And lastly, I think it may actually be a little harder to implement this than it would be to implement a higher block size limit, although to determine that would require some code digging which I don't want to do.
You guys should search for these topics before asking the same questions that have been asked for many years. Just do a google search.
Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
There is also an increased overhead on SPV wallets (but not really that much) as they would need to store more block headers and thus more data.
And lastly, I think it may actually be a little harder to implement this than it would be to implement a higher block size limit, although to determine that would require some code digging which I don't want to do.
Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.
The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations
There is also an increased overhead on SPV wallets (but not really that much) as they would need to store more block headers and thus more data.
And lastly, I think it may actually be a little harder to implement this than it would be to implement a higher block size limit, although to determine that would require some code digging which I don't want to do.
With 10 minute blocks, the largest pools have all the power, because the small-time miners are forced to join them, the smaller pools have no chance
to compete, because their variance is too high, sometimes can't find a block for days. This is why currently 2 pools from China account for nearly
60% of the hash rate.
With faster blocks, the smaller pool's luck becomes much more stable, and has a chance to compete with larger pools. Therefore improving
decentralization of hash rates.
to compete, because their variance is too high, sometimes can't find a block for days. This is why currently 2 pools from China account for nearly
60% of the hash rate.
With faster blocks, the smaller pool's luck becomes much more stable, and has a chance to compete with larger pools. Therefore improving
decentralization of hash rates.
I'm definitely not an expert on stats and probability (I only had one course in it and it was the most difficult I ever had) but cutting the reward time has a similar effect as joining a pool I think. By joining a pool the user increases their odds of "winning" but each win would result in a smaller reward. Same would be the case with cutting the reward time but not as drastic as joining a pool. It would double a user's chance of winning but they would only win half as much. They both have a null effect on the Return On Investment of the miner "I think" but there may be some nuances that skew the generality (the mining pool's algorithm is the biggest one I can think of).
[Why is orphaning more blocks too high a price for more throughput? It seems to me that any solution will involve some trade-off, just wondering why this one doesn't seem to be discussed as much as others.
I agree with the point about trade-offs. For some reason that I haven't quite found yet halving the reward time isn't one worth considering.
Quote
Also aren't there issues with the distribution of mining capacity being overly concentrated? Wouldn't alternatives like increasing block size make that problem even worse? If the reward time was lower wouldn't that put more power in the hands of the long tail?
I'm definitely not an expert on stats and probability (I only had one course in it and it was the most difficult I ever had) but cutting the reward time has a similar effect as joining a pool I think. By joining a pool the user increases their odds of "winning" but each win would result in a smaller reward. Same would be the case with cutting the reward time but not as drastic as joining a pool. It would double a user's chance of winning but they would only win half as much. They both have a null effect on the Return On Investment of the miner "I think" but there may be some nuances that skew the generality (the mining pool's algorithm is the biggest one I can think of).
Realistically? Nope. Not going to happen. It would require consensus from an overwhelming majority of all users and miners. Miners aren't going to voluntarily choose to have more of their blocks orphaned, just to increase the number of transactions that they can confirm per hour. If they wanted a hard fork to get more transactions per hour, there are plenty of other ways to do it.
Why is orphaning more blocks too high a price for more throughput? It seems to me that any solution will involve some trade-off, just wondering why this one doesn't seem to be discussed as much as others.
Also aren't there issues with the distribution of mining capacity being overly concentrated? Wouldn't alternatives like increasing block size make that problem even worse? If the reward time was lower wouldn't that put more power in the hands of the long tail?
You are exactly correct, faster blocks means small-time miners/pools can solve blocks much more often, and not needing to join huge mining pools to have a chance to mine blocks at all.
Faster blocks is 100% the superior solution, why it isn't being adopted? I have no idea, old habits die hard I guess. The entrenched interests are too proud to admit they are wrong, and altcoins had at least one thing right.
Realistically? Nope. Not going to happen. It would require consensus from an overwhelming majority of all users and miners. Miners aren't going to voluntarily choose to have more of their blocks orphaned, just to increase the number of transactions that they can confirm per hour. If they wanted a hard fork to get more transactions per hour, there are plenty of other ways to do it.
Why is orphaning more blocks too high a price for more throughput? It seems to me that any solution will involve some trade-off, just wondering why this one doesn't seem to be discussed as much as others.
Also aren't there issues with the distribution of mining capacity being overly concentrated? Wouldn't alternatives like increasing block size make that problem even worse? If the reward time was lower wouldn't that put more power in the hands of the long tail?
If decreasing the reward time results in an increase in orphaned blocks how have alt coins that have a quicker reward time (such as LiteCoin) handled the problem or have they?
They are "handling" the problem because their blocks are practically empty / trending much closer to 0kb rather than 1000kb.
That doesn't make any sense at all, since larger block size would also produce more orphans, making it not superior to faster blocks anyway.
If decreasing the reward time results in an increase in orphaned blocks how have alt coins that have a quicker reward time (such as LiteCoin) handled the problem or have they?
They are "handling" the problem because their blocks are practically empty / trending much closer to 0kb rather than 1000kb.
There is no issue with orphans, sure there will be more orphans, but the orphan rate is the same for all miners, so it ends up fair and business as usual.
Since there's no issue with orphans, altcoins does not need to deal with it, it's a non-issue. As you already mentioned, Litecoin operates just fine, with 2.5 minute blocks, no complaints from litecoin miners about orphans neither.
Block overhead is a non-issue, litecoin blockchain size is tiny compared to Bitcoin, even though it has nearly 3X more blocks. Transaction data takes up more disk space by far. A solution will need to be developed for the fast growing disk space usage anyway, faster blocks has nearly no impact on the disk space issue.
Faster blocks is 100% the superior solution, exactly 0 user ever said "nooo, my 1st confirmation came too fast".
I'm not even sure why bigger block size was chosen over faster blocks. Maybe it's arrogance, and not admitting altcoins got it right (faster blocks being superior).
Full blocks? I don't understand why they would be full after doubling? Perhaps I wasn't clear in what I am asking. When I suggest cutting the reward time in half from 10 minute targets to a 5 minute target I am not saying to also cut the block size in half. The block size would still be the same size but since a block is made twice as often then this would effectually double the blocksize.
What percent of a block is for non-transaction data? That would be the only increase in total blocksize since the number of transactions are determined by the "market" and the transaction volume. Processing the transactions in half the time should only increase the total of non-transaction data shouldn't it?
But, ok, we are getting a list of issues that would be affected and that's why I was asking. The first item in the list was that there would be an increase in the number of orphaned blocks and then I asked how other alt coins that have quicker reward times handle that problem. Haven't gotten any answers to that question yet and am curious if that is still a legitimate reason or not.
Since there's no issue with orphans, altcoins does not need to deal with it, it's a non-issue. As you already mentioned, Litecoin operates just fine, with 2.5 minute blocks, no complaints from litecoin miners about orphans neither.
Block overhead is a non-issue, litecoin blockchain size is tiny compared to Bitcoin, even though it has nearly 3X more blocks. Transaction data takes up more disk space by far. A solution will need to be developed for the fast growing disk space usage anyway, faster blocks has nearly no impact on the disk space issue.
Faster blocks is 100% the superior solution, exactly 0 user ever said "nooo, my 1st confirmation came too fast".
I'm not even sure why bigger block size was chosen over faster blocks. Maybe it's arrogance, and not admitting altcoins got it right (faster blocks being superior).
Quote
It's possible, but doesn't help scalability. If there are ill effects due to full blocks, making them twice as frequent won't really help.
Full blocks? I don't understand why they would be full after doubling? Perhaps I wasn't clear in what I am asking. When I suggest cutting the reward time in half from 10 minute targets to a 5 minute target I am not saying to also cut the block size in half. The block size would still be the same size but since a block is made twice as often then this would effectually double the blocksize.
Quote
Already blockchain is in gbs. If they implement your proposed way of reducing reward time by half every 4 years then we need piles of tbs of hard disk just for blockchain.
What percent of a block is for non-transaction data? That would be the only increase in total blocksize since the number of transactions are determined by the "market" and the transaction volume. Processing the transactions in half the time should only increase the total of non-transaction data shouldn't it?
But, ok, we are getting a list of issues that would be affected and that's why I was asking. The first item in the list was that there would be an increase in the number of orphaned blocks and then I asked how other alt coins that have quicker reward times handle that problem. Haven't gotten any answers to that question yet and am curious if that is still a legitimate reason or not.
But, ok, we are getting a list of issues that would be affected and that's why I was asking. The first item in the list was that there would be an increase in the number of orphaned blocks and then I asked how other alt coins that have quicker reward times handle that problem. Haven't gotten any answers to that question yet and am curious if that is still a legitimate reason or not.
AFAIK, they don't have any way to handle more orphan blocks. They just deal with it. However, miners on Bitcoin aren't going to just deal with it because that would be a change that is detrimental to them. Other altcoin miners deal with it because that was how the altcoin was originally designed. Quote
It's possible, but doesn't help scalability. If there are ill effects due to full blocks, making them twice as frequent won't really help.
Full blocks? I don't understand why they would be full after doubling? Perhaps I wasn't clear in what I am asking. When I suggest cutting the reward time in half from 10 minute targets to a 5 minute target I am not saying to also cut the block size in half. The block size would still be the same size but since a block is made twice as often then this would effectually double the blocksize.
Quote
Already blockchain is in gbs. If they implement your proposed way of reducing reward time by half every 4 years then we need piles of tbs of hard disk just for blockchain.
What percent of a block is for non-transaction data? That would be the only increase in total blocksize since the number of transactions are determined by the "market" and the transaction volume. Processing the transactions in half the time should only increase the total of non-transaction data shouldn't it?
But, ok, we are getting a list of issues that would be affected and that's why I was asking. The first item in the list was that there would be an increase in the number of orphaned blocks and then I asked how other alt coins that have quicker reward times handle that problem. Haven't gotten any answers to that question yet and am curious if that is still a legitimate reason or not.
I was just curious if the reward time could be reduced from every ten minutes (targetted) to every 5 minutes as a way to increase the blocksize?
[snip]
[snip]
It's possible, but doesn't help scalability. If there are ill effects due to full blocks, making them twice as frequent won't really help.
This is horrible. Already blockchain is in gbs. If they implement your proposed way of reducing reward time by half every 4 years then we need piles of tbs of hard disk just for blockchain. It is theoretically possible. But it should not happen. It won't be considered in the near future also. Current block interval of 10 minutes is acceptable at present. No need to change of it.
Jump to: