Pages:
Author

Topic: Difficulty adjustment needs modifying - page 3. (Read 10435 times)

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
October 06, 2011, 12:21:44 AM
#77

You are right BTCchart is POS.


Ayee, we went -3.76495171661444% 9/27 and, using http://dot-bit.org/tools/nextDifficulty.php as been the closest thing to being accurate I have seen.

according to dot-bit;
Instant as of block 148,241 = +1.35848534244243%
Expected at block  149,184 = -3.92677906619912%

That will likely change and the instant was -4%~ earlier due to variance causing 2 days worth of bad luck for a few of the larger pools.


My table is simply the data for the last 2017 blocks.
Do with it as you will.

However "Instant" yes that figure is COMPLETELY meaningless (yes that is an example of it being true)

as for the guess at -4% I'd love to know where they even get that from
Look at my actual figures and tell me how you can estimate -4% ?

Take the number at half way and divide by 2? Cheesy Cheesy Cheesy
hero member
Activity: 504
Merit: 500
October 05, 2011, 08:59:06 PM
#76

You are right BTCchart is POS.


Ayee, we went -3.76495171661444% 9/27 and, using http://dot-bit.org/tools/nextDifficulty.php has been the closest thing to being accurate I have seen.

according to dot-bit;
Instant as of block 148,241 = +1.35848534244243%
Expected at block  149,184 = -3.92677906619912%

That will likely change and the instant was -4%~ earlier due to variance causing 2 days worth of bad luck for a few of the larger pools.

donator
Activity: 1731
Merit: 1008
October 05, 2011, 07:30:38 PM
#75
at 1060/2016  52%
2011-09-28 we are on the 5th so
29-30-31-1-2-3-4-5 , 8day out of 14 57%
We're at expected 9.6% increase...

You are right BTCchart is POS.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
October 05, 2011, 07:17:57 PM
#74
Just an FYI
Difficulty estimator at #ozcoin (;;bc,diffchange) is saying:
 -9.4% expected
but calculated based on only the last 3 days:
 -13.2% ...
Is Ozcoi.in estimate more accurate than bitcoinchart @ -5% ?

Estimate based on 3 day are near meaningless because of luck factor and anyway difficulty adjust based on past 2016, (we're already half-way).

IMO what we're seeing was the delay for people in EU to realize unprofitably and stopping their rig.
OK then I calculated it myself - feel free to point out any errors in:
http://tradebtc.net/diffcalc.html

Firstly "3 day are near meaningless" - um you ever done statistics?
see if you understand this: a sample > 20% of population ...

OK so from my table:
last 432 times:
 147800   18:00:10 2-Oct-2011 UTC   0x1a09ee5d (1689334.4045971)   14m 40s   10m 51.66s   -8.61%
back to first block after last diff change:
 147168   22:47:04 27-Sep-2011 UTC   0x1a09ee5d (1689334.4045971)   6m 24s   10m 53.95s   -8.99%
last 2016 times:
 146216   00:35:02 21-Sep-2011 UTC   0x1a098ea5 (1755425.3203287)   1m 36s   10m 41.79s   -6.96%

So I guess bitcoinchart is a piece of ... also
legendary
Activity: 905
Merit: 1012
October 05, 2011, 02:48:50 PM
#73
The problem is that if you have a drop-off of 50%, that's 50% of the potential computing power of the network that is now disillusioned with mining. And in fact, once you cross that 50% threshold it becomes *more* profitable for such miners to collaborate on forking the bitcoin (in terms of BTC, ignoring for the moment what effect this would have on the exchanges).

In reality people come and go for their own reasons, and you're never going to get 100% buy-in to cheat the system from miners who left. But it becomes a possibility once you cross that 50% threshold, so a conservative approach would be to never let that happen.
donator
Activity: 1731
Merit: 1008
October 05, 2011, 02:27:59 PM
#72
Not a counterargument by itself, because the point with doomsday is that difficulty doesn't get a chance to adjust.
about THE halving to 25btc, I think volumes will be written on the subject, when time will come.

Lots of things may change by then like a bigger share of miners using ASIC-FPGA, and greater adoption overall.
And at that time there will still be people mining in winter scenario, enough for having the difficulty adjusted within a month or so.

What fatal difference does that make to wait 30min per confirmation instead of 10min ?
When investing into bitcoins this a basics concept to understand and live with.
donator
Activity: 2058
Merit: 1054
October 05, 2011, 12:19:56 PM
#71
Hell you don't even have to have an attack, and the "doomsday" scenario is written into the code.
Mining right now is marginally profitable if you have efficient GPUs and cheap electricity.
It fairly obviously isn't profitable for a decent number of people, as evidenced by the dropping hash rate and difficulty.
Now look into the future a little it to the 50% drop in rewards.
Presto!  Anybody without free electricity won't be mining profitably anymore, and bitcoin has a namecoin type issue.

Bitcoin prices better at least double by then, or bitcoin is in serious trouble.
Halving is not going to cause doomsday, for several reasons.
 - Capital expenditure is a major component in mining cost. First, this means that there will be plenty of people who are making more than twice their electricity cost.
 - Second, it means that in the time before halving, people will avoid buying hardware in anticipation of decreased profitability, so the difficulty will be less than it would have otherwise been.
 - The price will gradually increase in the time before halving in anticipation of the reduced supply.


* Price does not have to double, only difficulty has to halve.
Not a counterargument by itself, because the point with doomsday is that difficulty doesn't get a chance to adjust.
donator
Activity: 1731
Merit: 1008
October 05, 2011, 09:49:58 AM
#70
...
Mining right now is marginally profitable if you have efficient GPUs and cheap electricity.
...
Presto!  Anybody without free electricity won't be mining profitably anymore, and bitcoin has a namecoin type issue.

Bitcoin prices better at least double by then, or bitcoin is in serious trouble.
* Have you pondered over ASICs efficiency to say "efficient GPUs"
* Winter in coming in the US so don't worry about people not having free electricity.
* Price does not have to double, only difficulty has to halve.
* Calm down.
full member
Activity: 210
Merit: 100
October 05, 2011, 09:34:46 AM
#69
Hell you don't even have to have an attack, and the "doomsday" scenario is written into the code.
Mining right now is marginally profitable if you have efficient GPUs and cheap electricity.
It fairly obviously isn't profitable for a decent number of people, as evidenced by the dropping hash rate and difficulty.
Now look into the future a little it to the 50% drop in rewards.
Presto!  Anybody without free electricity won't be mining profitably anymore, and bitcoin has a namecoin type issue.

Bitcoin prices better at least double by then, or bitcoin is in serious trouble.
donator
Activity: 1731
Merit: 1008
October 05, 2011, 08:48:27 AM
#68
Just an FYI
Difficulty estimator at #ozcoin (;;bc,diffchange) is saying:
 -9.4% expected
but calculated based on only the last 3 days:
 -13.2% ...
Is Ozcoi.in estimate more accurate than bitcoinchart @ -5% ?

Estimate based on 3 day are near meaningless because of luck factor and anyway difficulty adjust based on past 2016, (we're already half-way).

IMO what we're seeing was the delay for people in EU to realize unprofitably and stopping their rig.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
October 05, 2011, 07:52:44 AM
#67
Just an FYI
Difficulty estimator at #ozcoin (;;bc,diffchange) is saying:
 -9.4% expected
but calculated based on only the last 3 days:
 -13.2% ...
legendary
Activity: 2576
Merit: 1186
October 04, 2011, 01:20:41 PM
#66
Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once.

Is anyone maintaining a branch with these sort of housekeeping changes? A block chain fork may be years in the future, but it might be worth maintaining such a branch to keep such long-term changes in mind.
I was thinking that would be a good idea. I can help, but I don't think I have time to maintain such a branch by myself.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
October 04, 2011, 09:35:06 AM
#65
Is anyone maintaining a branch with these sort of housekeeping changes? A block chain fork may be years in the future, but it might be worth maintaining such a branch to keep such long-term changes in mind.

Good idea. Who wants to volunteer? I'm too busy...
vip
Activity: 447
Merit: 258
October 04, 2011, 09:19:50 AM
#64
Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once.

Is anyone maintaining a branch with these sort of housekeeping changes? A block chain fork may be years in the future, but it might be worth maintaining such a branch to keep such long-term changes in mind.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
October 04, 2011, 06:15:15 AM
#63
Anyone using block times for anything important is quite simply a fool.
This quote is worth preserving. There is a number of people on this forum who claim that bitcoin as-it-is-right-now is ready to maintain certifiable accounts for businesses. Who will be right?

Luke is not saying bitcon isn't good to go. He's saying the times shouldn't be used as times.
... and of course luke-jr is also correct about the times themselves.
They are the time you requested a getwork, which is NOT the time the block was found.

Looking at that in terms of a relationship between the two numbers: well the difference can be anything from 0 seconds up to 120 seconds.
(0 seconds if you are very lucky, have a very fast hashing device and very short network latency)
Default pushpool accepts work up to 120 seconds after the getwork request?
(msg.c:   WORK_EXPIRE_INT      = 120,)

So I guess that's also a possible hack to make your blocks always win if they are in an orphan battle?
Since you expect people to respond in 60 seconds (and most mining programs assume that also) the pool can push the time back almost 60 seconds and the miners would see no unexpected extra expired blocks? ...

Meanwhile ... back on topic.
So the suggestions are to actually redo the default 2016 calculation?
(due to the unstated but expected hacks due to having 2 different calculations working together ...)

Edit: though by the sounds of things it wont get implemented anyway ...
legendary
Activity: 1246
Merit: 1016
Strength in numbers
October 04, 2011, 01:28:07 AM
#62
Anyone using block times for anything important is quite simply a fool.
This quote is worth preserving. There is a number of people on this forum who claim that bitcoin as-it-is-right-now is ready to maintain certifiable accounts for businesses. Who will be right?

Luke is not saying bitcon isn't good to go. He's saying the times shouldn't be used as times.
legendary
Activity: 2128
Merit: 1073
October 04, 2011, 12:49:40 AM
#61
Anyone using block times for anything important is quite simply a fool.
This quote is worth preserving. There is a number of people on this forum who claim that bitcoin as-it-is-right-now is ready to maintain certifiable accounts for businesses. Who will be right?
legendary
Activity: 2576
Merit: 1186
October 04, 2011, 12:27:29 AM
#60
It's not dishonest, just imprecise.
You should post this in your FAQ. Many people are wondering whats wrong with your clock. If you happen to live in a country with an adversarial legal system, you will be invited to the court to explain this to the judge and the jury why the timestamps on your blocks are messing up the accounting ledgers of other people.
Anyone using block times for anything important is quite simply a fool. It's not meant to be precise, and never will be. Even if I didn't (ab)use it for improved efficiency, it would be the time that (many) miners began work on the block, not the time it was found. And even if it were precise, it has no relevance.
legendary
Activity: 2128
Merit: 1073
October 03, 2011, 11:21:09 PM
#59
It's not dishonest, just imprecise.
You should post this in your FAQ. Many people are wondering whats wrong with your clock. If you happen to live in a country with an adversarial legal system, you will be invited to the court to explain this to the judge and the jury why the timestamps on your blocks are messing up the accounting ledgers of other people.
Any change to how difficulty is calculated means a block chain fork. Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once.
Very wise statement. Bitcoin is like amber, the bugs inside are to be admired for their beauty as long as possible.
legendary
Activity: 2576
Merit: 1186
October 03, 2011, 10:07:44 PM
#58
I did some simulation of blocktime variance (assuming honest nodes,
It is my understanding that at least Eligius pool isn't a "honest node" and intentionally produces acausal blocks (or at least as close to acausal as they deem practical).
Eligius varies ntime to optimize getting work out to miners at a longpoll. Otherwise it could take many more seconds to generate work for all of them. It's not dishonest, just imprecise. The current variation allowances are not a problem, either.

Any change to how difficulty is calculated means a block chain fork. Any block chain fork should be avoided as long as feasibly possible. When it happens, we should have a large list of housekeeping changes to make at once.
Pages:
Jump to: