Global difficulty adjustments #1627

Open
opened 2020-05-12 06:41:03 +02:00 by PeterSurda · 0 comments
PeterSurda commented 2020-05-12 06:41:03 +02:00 (Migrated from github.com)

The whitepaper specifies:

The difficulty of the proof-of-work should be proportional to the size of the message and should be set such that an average computer must expend an average of four minutes of work in order to send a typical message.

From this perspective, the current difficulty is too low. I propose:

  • a mechanism for announcing a difficulty change
  • a transparent process for determining global difficulty
  • a deadline by which the process is put into the place
  • further research into whether the requirements specified in the whitepaper make sense

It is difficult to create a decentralised mechanism for determining the difficulty. Instead I propose a centralised solution based on a transparent mechanism. There could be a new object signed by a central authority announcing the current difficulty.

The process can take external sources of average consumer CPU, e.g. Steam Hardware and Software Survey or UserBenchmark. At the moment the average CPU looks to be a quad core Ivy Bridge Intel CPU. This can be used as a base for the initial change.

Then there is a question about what size of message should be considered "average", what TTL, and if the 4 minutes should include an ACK.

The whitepaper specifies: > The difficulty of the proof-of-work should be proportional to the size of the message and should be set such that an average computer must expend an average of four minutes of work in order to send a typical message. From this perspective, the current difficulty is too low. I propose: - a mechanism for announcing a difficulty change - a transparent process for determining global difficulty - a deadline by which the process is put into the place - further research into whether the requirements specified in the whitepaper make sense It is difficult to create a decentralised mechanism for determining the difficulty. Instead I propose a centralised solution based on a transparent mechanism. There could be a new object signed by a central authority announcing the current difficulty. The process can take external sources of average consumer CPU, e.g. [Steam Hardware and Software Survey](https://store.steampowered.com/hwsurvey/cpus/) or [UserBenchmark](https://cpu.userbenchmark.com/SpeedTest/793/IntelR-CoreTM-i5-3570-CPU---340GHz). At the moment the average CPU looks to be a quad core Ivy Bridge Intel CPU. This can be used as a base for the initial change. Then there is a question about what size of message should be considered "average", what TTL, and if the 4 minutes should include an ACK.
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-08#1627
No description provided.