Bitcoin Forum
April 26, 2024, 09:33:42 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 [10]  All
  Print  
Author Topic: Date for 25 BTC per Block  (Read 34961 times)
MatthewLM
Legendary
*
Offline Offline

Activity: 1190
Merit: 1004


View Profile
November 28, 2012, 07:47:57 PM
 #181

If you could figure out the expected block height (for all time), the actual block height and the block rate over the last 2016 blocks then...

1. Add 2016 to the expected block height and take away the actual block height to get the number of blocks desired.
2. Determine the expected number of blocks to be created at the current rate.
3. Adjust difficulty to make expected rate hit the desired number.
4. Limit difficulty change to prevent large changes.

So if we have a difficulty change at block 2016000, and 2001 weeks have passed then we expect to be at block 2017008. Let's say over the last 2016 blocks, they were created at 8 blocks an hour. We need to reach block 2017008 + 2016 in two weeks time which is block 2019024. This is 3024 blocks more than 2016000, so we want 3024 blocks. This means we want a block creation rate of 3024/(14*24) an hour which is 9 blocks an hour. To try to get this rate we can adjust the difficulty by 8/9 = 0.889.

I probably explained that terribly but hopefully I got across the general idea. I didn't think about it too much and it is indeed academic, it doesn't matter.
1714167222
Hero Member
*
Offline Offline

Posts: 1714167222

View Profile Personal Message (Offline)

Ignore
1714167222
Reply with quote  #2

1714167222
Report to moderator
1714167222
Hero Member
*
Offline Offline

Posts: 1714167222

View Profile Personal Message (Offline)

Ignore
1714167222
Reply with quote  #2

1714167222
Report to moderator
1714167222
Hero Member
*
Offline Offline

Posts: 1714167222

View Profile Personal Message (Offline)

Ignore
1714167222
Reply with quote  #2

1714167222
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
November 28, 2012, 11:45:44 PM
 #182

2. Determine the expected number of blocks to be created at the current rate.

what is the "current rate", how do you calculate/measure it?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
dooglus
Legendary
*
Offline Offline

Activity: 2940
Merit: 1330



View Profile
November 29, 2012, 02:10:53 AM
 #183

2. Determine the expected number of blocks to be created at the current rate.

what is the "current rate", how do you calculate/measure it?

I think his scheme, now that I understand it, is to work out how long it is supposed to be until the next difficulty change, calculate the current hash rate from the time taken to find the last 2016 blocks, and set the difficulty such that if the hashrate stays the same over the next period as it was for the previous period then the next difficulty change happens when it 'should', based on 10-minute blocks from the start.

So in my hypothetical situation in which everyone starts mining 10 times faster due to ASIC or alien technology, and assuming that the previous difficulty adjustment happened when it should have (since we've been using Matthew's system for a while), the next adjustment will happen 14-1.4=12.6 days too soon, and so the next adjustment period needs to take 14+12.6=26.6 days.  We know that at the current rate it'll only take another 1.4 days, so we need to increase the difficulty by a factor of 26.6/1.4 = 19 to get back on target.

If the hash rate stays the same, and we do end up with the next adjustment happening on the 'right' day, the next adjustment will reduce the difficulty by a factor of 26.6/14 = 1.9x.

Overall we've increased by 19x and then reduced by 1.9, giving a resulting adjustment over 2 periods of 10x, which matches the increase in hashing power.  So we end up back on schedule, but at the expense of having a very slow 26.6 days during which blocks took an average of 19 minutes each to find.

Do I understand it right now?

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
November 29, 2012, 07:48:27 AM
 #184

If you could figure out the expected block height (for all time), the actual block height and the block rate over the last 2016 blocks then...

1. Add 2016 to the expected block height and take away the actual block height to get the number of blocks desired.
2. Determine the expected number of blocks to be created at the current rate.
3. Adjust difficulty to make expected rate hit the desired number.
4. Limit difficulty change to prevent large changes.

So if we have a difficulty change at block 2016000, and 2001 weeks have passed then we expect to be at block 2017008. Let's say over the last 2016 blocks, they were created at 8 blocks an hour. We need to reach block 2017008 + 2016 in two weeks time which is block 2019024. This is 3024 blocks more than 2016000, so we want 3024 blocks. This means we want a block creation rate of 3024/(14*24) an hour which is 9 blocks an hour. To try to get this rate we can adjust the difficulty by 8/9 = 0.889.

I probably explained that terribly but hopefully I got across the general idea. I didn't think about it too much and it is indeed academic, it doesn't matter.

One morea cademinc thought; the difficulty should be calculated after every block, only input counted from a longer period (2 weeks?).
Ie for every block, count a difficulty which will result in expected block height in next 2 weeks (if hash rate stays the same).

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
November 29, 2012, 07:54:27 AM
 #185

the difficulty should be calculated after every block

yep, based on a rolling 2-week / 2016 block period.
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
November 29, 2012, 07:59:25 AM
 #186

I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.

Let us wait 'till december has passed with judging this. I doubt it's been priced in correctly.


I agree with molecular; The production has just halved, if the demand stays the same and no extra reserves are being used, the price should double.

Of course, when the price rises, some reserves are taken in to markets which slows down the rise.

But this is just speculating. We'll see.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1011


View Profile
November 29, 2012, 09:23:02 AM
 #187

I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.

Let us wait 'till december has passed with judging this. I doubt it's been priced in correctly.


I agree with molecular; The production has just halved, if the demand stays the same and no extra reserves are being used, the price should double.

Of course, when the price rises, some reserves are taken in to markets which slows down the rise.

But this is just speculating. We'll see.
Yeah but guess what: you're not the only one who came to that conclusion. And lots of people bought-in anticipating the rise in price... which itself caused the price to rise. That's what I mean by being "already factored into the price." Look at the price 6 mo ago vs today. Hey, it doubled! Coincidence? Only partly.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
jl2035
Full Member
***
Offline Offline

Activity: 146
Merit: 100



View Profile
November 29, 2012, 09:33:12 AM
 #188

So, it ended up being November 28th in most every populated timezone.

Specifically, 2012-11-28 15:24:38 UTC
 - http://blockchain.info/block-index/322335/000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e

I was really expecting there to be some larger exchange rate volatility over the last few days.  I was expecting GPU miners to already have been selling in quantity on eBay.  

But it has been pretty quiet.


I think people expected asics to be shipped at least in november. That not being the case changed some things... many GPU miners will try for a few days more... Smiley

JOIN Bitbiz bitbiz.io
MatthewLM
Legendary
*
Offline Offline

Activity: 1190
Merit: 1004


View Profile
November 29, 2012, 12:53:44 PM
 #189

Do I understand it right now?

Yes, I was thinking along those lines.

the difficulty should be calculated after every block

yep, based on a rolling 2-week / 2016 block period.


No reason why not to do this, it should keep the difficulty more stable this way because much could happen in 2 weeks.
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
November 30, 2012, 07:55:07 AM
Last edit: November 30, 2012, 08:37:22 AM by Nite69
 #190

hmm.. did miners already start to turn off their machines.. 51 minutes since last block, 2 prevs are at 20 minute interval, block 210261

I think I'll keep mine running for a while.. but HEY! if the rate halves it will also halve the reward :-(


Edit: normal variance, I guess. F.ex. Slush hashrate does not seem to drop at all: https://mining.bitcoin.cz/stats/

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
Pages: « 1 2 3 4 5 6 7 8 9 [10]  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!