Bitcoin Forum
February 07, 2023, 07:20:43 AM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Is a reduced reward time possible?  (Read 3013 times)
Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 09, 2016, 02:05:56 AM
 #1

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? Of course the reward would be reduced by half also so that the total bitcoins being created would remain the same. If so, wouldn't this be another way of increasing the "blocksize" throughput? If a reward was issued every 5 minutes then a new block would be started every five minutes instead of every ten. And, if this process of halving the reward time (and reward) was perpetuated through the lifetime of bitcoin (meaning every time the reward was halved every four years the reward time was also cut in half) then the block size would be doubled at every halving as well?

As a thought experiment, if this process had been applied to the last reward halving 3 1/2 years ago would we be having this blocksize debate today? I think not. And if it had been applied then, how would it have affected mining since that time?



1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
1675754443
Hero Member
*
Offline Offline

Posts: 1675754443

View Profile Personal Message (Offline)

Ignore
1675754443
Reply with quote  #2

1675754443
Report to moderator
DannyHamilton
Legendary
*
Offline Offline

Activity: 3010
Merit: 3696



View Profile
January 09, 2016, 02:22:33 AM
 #2

I was just curious if the reward time could be reduced from every ten minutes (targetted) to every 5 minutes

Technically?  Sure.

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.

As a thought experiment, if this process had been applied to the last reward halving 3 1/2 years ago would we be having this blocksize debate today?

Yes.

And if it had been applied then, how would it have affected mining since that time?

There'd be a lot more orphaned blocks.

Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 09, 2016, 02:37:59 AM
 #3

I realize any change to the protocol requires consensus and that is what is what is going on about the block chain size now. I wasn't aware of the orphaned block issue as I never mined so thanks for that. Too bad there wasn't some way to reduce that at the same time as reducing the reward time as it seems doing so would solve other issues as well. It would also reduce confirmation time to five minutes as well.

How do "faster" altcoins solve the orphaned block problem? Litecoin generates blocks in half the time as what I am asking about?

I was just curious if the reward time could be reduced from every ten minutes (targetted) to every 5 minutes

Technically?  Sure.

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.

As a thought experiment, if this process had been applied to the last reward halving 3 1/2 years ago would we be having this blocksize debate today?

Yes.

And if it had been applied then, how would it have affected mining since that time?

There'd be a lot more orphaned blocks.


Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
January 09, 2016, 02:47:08 AM
 #4

We can accomplish something similar with subchains, which can be implemented without a hard or soft fork. The reward time would remain at 10 minutes, but each block would be composed of a series of faster-verifying weak blocks. 

A Visual Explanation of Subchains

Subchains are a practical application of "weak blocks," which add security to zero-confirmation transactions and permit massive scaling of Bitcoin.




Fig. 1.  Each time a block that satisfies the weak target is found, the subchain is extended.   When a block satisfying the strong target is found, the subchain is closed, becoming a strong block, and a new subchain begins.




Fig. 2.  Miners cooperate to build subchains in order to process more transactions and claim more fees without incurring additional orphaning risk.  This illustration visualizes "idealized" ¼-difficulty subchains (also referred to as 4x subchains).  In practice, each strong block may contain more or less than four weak blocks, due to randomness.




Fig. 3.  Miners build subchains layer by layer (a – c), where each layer corresponds to the solution of a weak block.  To propagate blocks (weak or strong), miners need only send their Δ-block and a reference to the subchain’s tip (f), reducing the quantity of transmitted bytes.  When a nonce that satisfies the strong target is found, the subchain is closed thereby becoming a strong block (d), and miners begin working on a new subchain (e).


For further reading, please refer to "Reduce Orphaning Risk and Improve Zero-Confirmation Security With Subchains."

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 253


View Profile
January 09, 2016, 05:11:22 AM
 #5

http://www.bitcoinunlimited.info/downloads/subchains.pdf

"Subchains" are just blocks mined lower than the normal difficulty target and then when the previous difficulty happens to get mined you call it a "strong block". (See Page 3 "Subchains")
It's no different than if I said we should increase the amount of transactions we can accept on the blockchain by, for example, decreasing the difficulty target by 10 times (Mining blocks at a target of every 1 minute) and then saying we have "strong blocks" when we happen to hit the more difficult target every roughly 10 minutes.

This doesn't do anything to solve the problems inherent with increased block size or faster blocks - Higher resource usage, particularly bandwidth, and orphaning- regardless of your unbacked and contradictory claims, see below.

Quote from: Peter R
In a scenario where subchains are the standard mechanism to build and propagate blocks, a miner can include all of the subchain’s transactions—and thus all of its fees—without incurring additional orphaning risk
Quote from: Peter R
A miner does, however, incur orphaning risk for the new transactions included in his Δ-block.

By their (dumb) fruits shall ye know them indeed...
Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 14, 2016, 07:08:51 PM
 #6

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? Is there no solution and "10 minutes" is the best compromise we can achieve as a balance? If handling orphaned blocks is the ONLY technical issue (and while acknowledging the consensus issue common to any fork proposal as we are witnessing) then how does that technical challenge compare with the others of current block size increase proposals? They all have some pros and cons. Are there any other "cons" to decreasing the reward time (while keeping the total reward the same as currently allowed and the blockchain size the same)?

vileygroun
Newbie
*
Offline Offline

Activity: 47
Merit: 0


View Profile
January 15, 2016, 06:03:02 AM
 #7

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.
fbueller
Sr. Member
****
Offline Offline

Activity: 412
Merit: 251


View Profile
January 15, 2016, 11:54:17 AM
 #8

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]


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.

Bitwasp Developer.
Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 15, 2016, 08:41:48 PM
 #9

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.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 2996
Merit: 5351


Just writing some code


View Profile WWW
January 15, 2016, 08:48:04 PM
 #10

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.

kokojie
Legendary
*
Offline Offline

Activity: 1792
Merit: 1002



View Profile
January 15, 2016, 08:50:13 PM
Last edit: January 15, 2016, 09:04:00 PM by kokojie
 #11

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

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.

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
AlexGR
Legendary
*
Offline Offline

Activity: 1708
Merit: 1041



View Profile
January 15, 2016, 09:04:06 PM
 #12

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.
kokojie
Legendary
*
Offline Offline

Activity: 1792
Merit: 1002



View Profile
January 15, 2016, 09:06:49 PM
 #13

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.

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
pootie
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
January 19, 2016, 12:34:25 AM
 #14

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?
kokojie
Legendary
*
Offline Offline

Activity: 1792
Merit: 1002



View Profile
January 19, 2016, 04:20:41 AM
 #15

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.

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 19, 2016, 07:09:01 PM
 #16

[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).
kokojie
Legendary
*
Offline Offline

Activity: 1792
Merit: 1002



View Profile
January 20, 2016, 12:59:31 AM
 #17

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.

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

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
saturn643
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 20, 2016, 01:23:10 AM
 #18

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.
kokojie
Legendary
*
Offline Offline

Activity: 1792
Merit: 1002



View Profile
January 20, 2016, 05:40:25 AM
 #19

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

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.

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
saturn643
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 20, 2016, 06:10:31 AM
 #20

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.

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!