Bitcoin Forum
September 28, 2021, 06:42:35 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: on the optimal difficulty setting for bitcoin  (Read 913 times)
socrates1024
Full Member
***
Offline Offline

Activity: 125
Merit: 104


Andrew Miller


View Profile
August 03, 2012, 11:04:34 AM
Last edit: August 03, 2012, 09:15:23 PM by socrates1024
 #1

What's the optimal setting for the puzzle difficulty? Is 10 minutes between blocks correct?

Ideally, there should be one stale block for every fee-earning block. This strikes the best balance between two performance goals:
- (Latency) the chain should grow quickly
- (Convergence) the network should settle quickly

Here's an easy way to maintain the proper difficulty setting. Miners should include in each block a set of novel stale blocks with shorter height. For every fee-winning block, we decrease the difficulty. For every stale block, we increase the difficulty. It's clear that in the steady state with constant hashpower, this scheme results in two proofs-of-work for every block in the chain.

Notice it would no longer be necessary for miners to report timestamps, and the parameter "10 minutes" would be eliminated altogether. The only remaining parameter is a 'gain' for how much to adjust the difficulty per block.

tl;dr:  First place wins a prize. Runners-up receive an honorable mention.

[edit] I originally used the wrong term "orphan block" when I meant "stale block", thanks sipa

amiller on freenode / 19G6VFcV1qZJxe3Swn28xz3F8gDKTznwEM
[my twitter] [research@umd]
I study Merkle trees, credit networks, and Byzantine Consensus algorithms.
1632811355
Hero Member
*
Offline Offline

Posts: 1632811355

View Profile Personal Message (Offline)

Ignore
1632811355
Reply with quote  #2

1632811355
Report to moderator
1632811355
Hero Member
*
Offline Offline

Posts: 1632811355

View Profile Personal Message (Offline)

Ignore
1632811355
Reply with quote  #2

1632811355
Report to moderator
1632811355
Hero Member
*
Offline Offline

Posts: 1632811355

View Profile Personal Message (Offline)

Ignore
1632811355
Reply with quote  #2

1632811355
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1632811355
Hero Member
*
Offline Offline

Posts: 1632811355

View Profile Personal Message (Offline)

Ignore
1632811355
Reply with quote  #2

1632811355
Report to moderator
1632811355
Hero Member
*
Offline Offline

Posts: 1632811355

View Profile Personal Message (Offline)

Ignore
1632811355
Reply with quote  #2

1632811355
Report to moderator
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 2058
Merit: 1027



View Profile WWW
August 03, 2012, 11:11:32 AM
 #2

Wasting 50% of the network hashrate on orphans is hardly optimal (making attacks twice as easy since they build on their own blocks), as is making lightweight clients have to record several block headers per minute.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
socrates1024
Full Member
***
Offline Offline

Activity: 125
Merit: 104


Andrew Miller


View Profile
August 03, 2012, 11:33:04 AM
 #3

Only an additional block header would need to be stored. There's no need to validate the redundant blocks, they could just be blank proofs-of-work. If someone really wants to do unpaid overtime to increase the difficulty then it's just as well.

I'm not totally sure about the number 2 though, so I'll think about that a bit more.

The important idea is to adjust the puzzle difficulty in order to maintain a stationary ratio of chain length to number of runners-up.

amiller on freenode / 19G6VFcV1qZJxe3Swn28xz3F8gDKTznwEM
[my twitter] [research@umd]
I study Merkle trees, credit networks, and Byzantine Consensus algorithms.
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!