Bitcoin Forum
June 23, 2024, 09:49:40 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Difficulty cap  (Read 878 times)
bitcreditscc (OP)
Hero Member
*****
Offline Offline

Activity: 602
Merit: 501



View Profile
July 19, 2015, 04:34:30 PM
 #1

What would be the possible gains and losses from placing a difficulty cap?

for example :-

Code:

    if (bnNew < bnMAXPowLimit) // meaning target diff is higher than required cap
        bnNew = bnMAXPowLimit; //diff is set to cap


coinpr0n
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
July 19, 2015, 04:59:33 PM
 #2

I'm no expert but I'd guess the time between blocks would be reduced (going towards zero), probably cause lots of orphan blocks, also coins from block rewards would quickly be depleted and more "losses". I don't see the gains.

bitcreditscc (OP)
Hero Member
*****
Offline Offline

Activity: 602
Merit: 501



View Profile
July 19, 2015, 05:20:19 PM
 #3

I'm no expert but I'd guess the time between blocks would be reduced (going towards zero), probably cause lots of orphan blocks, also coins from block rewards would quickly be depleted and more "losses". I don't see the gains.

I guess the main gain i can see would be that a well placed cap (maybe a floating cap based of the average diff of actual ten minute blocks) would ensure more reliable ten minutes per tx confirm. So in simple terms this could be used to fight the 1 hour blocks spans that sometimes happen.

So yeah the problem of block time tending to zero would be addressed by a dynamic cap. With this in mind block reward schedule (may)? remain fairly stable , right?

of course the actual engineering would be highly complicated, but i'm very interested in knowing opinions and possible holes in this idea.

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.
 

achow101
Staff
Legendary
*
Offline Offline

Activity: 3430
Merit: 6720


Just writing some code


View Profile WWW
July 19, 2015, 05:31:31 PM
 #4

Technically there is a max difficulty. It is a very very very big number.

I'm no expert but I'd guess the time between blocks would be reduced (going towards zero), probably cause lots of orphan blocks, also coins from block rewards would quickly be depleted and more "losses". I don't see the gains.

I guess the main gain i can see would be that a well placed cap (maybe a floating cap based of the average diff of actual ten minute blocks) would ensure more reliable ten minutes per tx confirm. So in simple terms this could be used to fight the 1 hour blocks spans that sometimes happen.

So yeah the problem of block time tending to zero would be addressed by a dynamic cap. With this in mind block reward schedule (may)? remain fairly stable , right?

of course the actual engineering would be highly complicated, but i'm very interested in knowing opinions and possible holes in this idea.

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.
 
How would a dynamic cap be calculated and how would consensus be achieved to decide that cap? Although that cap might help keep confirmation times steady, it may not always help since the miners might just be really unlucky and not be able to find a block that works with the cap.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3074



View Profile
July 19, 2015, 05:34:14 PM
 #5

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.

That scenario just creates an opportunity for other miners to take their market share.

Vires in numeris
bitcreditscc (OP)
Hero Member
*****
Offline Offline

Activity: 602
Merit: 501



View Profile
July 19, 2015, 05:40:50 PM
 #6

Technically there is a max difficulty. It is a very very very big number.

I'm no expert but I'd guess the time between blocks would be reduced (going towards zero), probably cause lots of orphan blocks, also coins from block rewards would quickly be depleted and more "losses". I don't see the gains.

I guess the main gain i can see would be that a well placed cap (maybe a floating cap based of the average diff of actual ten minute blocks) would ensure more reliable ten minutes per tx confirm. So in simple terms this could be used to fight the 1 hour blocks spans that sometimes happen.

So yeah the problem of block time tending to zero would be addressed by a dynamic cap. With this in mind block reward schedule (may)? remain fairly stable , right?

of course the actual engineering would be highly complicated, but i'm very interested in knowing opinions and possible holes in this idea.

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.
 
How would a dynamic cap be calculated and how would consensus be achieved to decide that cap? Although that cap might help keep confirmation times steady, it may not always help since the miners might just be really unlucky and not be able to find a block that works with the cap.

Diff is calculated based on the average time-span over a 2 week period. We can in much the same way look at a given period of time, say a day and pick blocks that were within a 2 minute span from 9-11 minutes , check their diff and calculate the average. This becomes the diff cap. But this topic isn't about how to do it, i am more interested in answers on the benefits and pitfalls of such a system. You just highlighted an issue i had thought of...but do we not increase the odds of a block being found on time by using the mechanism i have spoken off?

We are saying that luck and diff are both contributing factors to block time... doesn't the "luck" increase if we impose a max diff for any given time ?


bitcreditscc (OP)
Hero Member
*****
Offline Offline

Activity: 602
Merit: 501



View Profile
July 19, 2015, 05:48:34 PM
 #7

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.

That scenario just creates an opportunity for other miners to take their market share.

Correct me if i am wrong but Miners are really just tx processors, the purpose of mining is to secure the ledger by adding subsequent data that requires a certain amount of work completed (with lottery factor) and block rewards are just the reward you get for helping secure the ledger?

As a result falling of hash is not about market share for miners but about security, namely in the form of transactions confirmation and time.  

Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3074



View Profile
July 19, 2015, 05:54:42 PM
 #8

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.

That scenario just creates an opportunity for other miners to take their market share.

Correct me if i am wrong but Miners are really just tx processors, the purpose of mining is to secure the ledger by adding subsequent data that requires a certain amount of work completed (with lottery factor) and block rewards are just the reward you get for helping secure the ledger?

As a result falling of hash is not about market share for miners but about security, namely in the form of transactions confirmation and time.  

You're not accounting for the exchange rate. The exchange rate essentially caps the hashrate already, discounting those with subsidized electricity or no concept of profit and loss. That cap defines the size of the market for mining.

Vires in numeris
bitcreditscc (OP)
Hero Member
*****
Offline Offline

Activity: 602
Merit: 501



View Profile
July 19, 2015, 06:28:50 PM
 #9

Scenario :- "Chinese gov crackdown on power wasting bitcoin mines" would wipe off over half the globes' mining power in a day, diff is high and a huge chunk of hash disappearing suddenly could stall the chain or at the very least blocks would take days to solve until adjustment day, god forbid we should be so unlucky that the hash falls off a day or two after diff adj.

That scenario just creates an opportunity for other miners to take their market share.

Correct me if i am wrong but Miners are really just tx processors, the purpose of mining is to secure the ledger by adding subsequent data that requires a certain amount of work completed (with lottery factor) and block rewards are just the reward you get for helping secure the ledger?

As a result falling of hash is not about market share for miners but about security, namely in the form of transactions confirmation and time.  

You're not accounting for the exchange rate. The exchange rate essentially caps the hashrate already, discounting those with subsidized electricity or no concept of profit and loss. That cap defines the size of the market for mining.

I don't think you quite understand the question in this thread. Anyway, BTC in and off itself is a closed system it can only be effected from within. Market has never responded to changes in hash rate, it responds to investor confidence and speculative activity. But in response to your statement.... if today the hash rate dropped to half , here are things you haven't considered.

1) It takes X amount of hash to hopefully keep a steady stram of ten minute blocks , we half the amount of hash ....what will happen?
2) With unconfirmed tx piling up in mempools , some instances will crash compounding the problem across service providers and some miners
3) Investor confidence in BTC will fall....leading to a price crash.....

So in this scenario, rather that the remaining miners making a profit, they will be

1) Stuck with high diff blocks
2) Facing a price crash , so more miners will fall off

It becomes a loop whereby miners fall off, blocks get slower, price falls.

But this is not the point of this thread, a bit too early to be going off topic.

coinpr0n
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
July 19, 2015, 06:43:58 PM
 #10

The difficulty algorithm is already dynamic, albeit for a _minimum_ difficulty. What you are proposing is a dynamic limit for what would be a _maximum_ difficulty. I see what you're saying: the problem of being stuck with too high a difficulty is something that some smaller altcoins have suffered from in the past (Terracoin?). But I thought some altcoins came up with "solutions" to this problem? Was it called Gravity-Well? Again, though, I wouldn't really know if Bitcoin would benefit from this.

Pages: [1]
  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!