Handling hash drop off

[TierNolan]

I was thinking about possible way to get "real" time into the calculations for hashing loss.

When a node connects to the network, it has no concept of time for the network.

However, once it has synced, it would know when the last block was found.

The block difficulty and reward would drop together.  This prevents abusing the system.  Miners would get a variance reduction by using smaller blocks.

The rule would be that every 10 minutes would cause a factor of 2 reduction in the acceptable POW difficulty per block.  After 10 minutes, a block with difficulty and reward at 50% of the standard would be accepted and built on.  The timestamp would also have to be 10 minutes ahead of the previous block's (maybe).

The mining rule would start at 20 minutes, so the default client wouldn't mine lower difficulty blocks until 20 mins have passed and then the same time minutes interval.

If 45 mins had passed the default client would accept blocks that are 1/16 the difficulty (or higher) and produce blocks that are 1/8 difficulty.

Since the (mint reward/difficulty is the same), there is little incentive to abusing the system.

Nodes which have only just joined the network would accept all new blocks and produce full blocks.

You could also adjust the payout system.  If you make a 1/2 difficulty block, you get half the tx fees and the rest are paid to the winner of the next block (that probably needs to be scaled too though).

[1713425470]

1713425470

[1713425470]

1713425470

[1713425470]

1713425470

[1713425470]

1713425470

[Peter Todd]

Your idea doesn't work because you can't assume that clocks are synchronized; if anything the current 2 hour window is too short.

If you don't require the timestamp to be set 10 minutes ahead of the previous block you've effectively just reduced the time between blocks; mining is a random process so if you find a half-difficulty block why wouldn't you broadcast it to the network?

If you do require the timestamp miners have every reason to always mine with a timestamp >= 10 minutes ahead of the previous block just in case they find a half-difficulty block. Eventually they'll get close enough to the 2 hour window that network consensus is impacted, likely for clients first because clients have the most difficulty and least incentive to make sure their clocks are really accurate.

If you decide that a half-difficulty block gets less than half the reward, again, mining is a random process so why bother at all? If fees are sufficient to make up the difference, then you are back to having incentives to make fake timestamps and will soon run into consensus problems.

Finally a large miner also has an incentive to mine blocks close together because it increases the orphan rate of their competitors more than it increases the orphan rate for them, thus reducing competition over time, and making available more transactions for them to mine and collect fees from.

Moral of the story is that it's really dangerous for there to be incentives in Bitcoin for miners to make inaccurate timestamps, yet it's also really dangerous for nodes to tighten the 2 hour rule for accepting timestamps that appear to be in the future due to the risk of forking the network. It's quite possible that widespread use of Bitcoin for timestamping could create such perverse incentives. It's also possible that the nLockTime feature could do that too, because if a miner knows of a high-fee transaction with a time-based nLockTime they have an incentive to set their block timestamp sufficiently far ahead for the transaction to be finalized even if that means faking the block timestamp; if miners start running code to do this automatically an attacker could provoke a fork by just creating lots of transactions with nLockTime in the future and getting those transactions to miners.

[TierNolan]

Your idea doesn't work because you can't assume that clocks are synchronized; if anything the current 2 hour window is too short.

The sync was the last block header received.  It isn't timestamp based.

Clients will accept blocks with the lower difficulty.  However, miners will only build on a lower difficulty block if the previous block was received at least 10 minutes previously.  There is no need to have a block time.

Sending out early low difficulty blocks means that acceptance of your block would be delayed by other miners.  If they produce a full block they jump over your block anyway, so there is less incentive for them to care.

I think lower difficulty blocks could be defined to set their timestamp relative to the previous block.

So,

50%: prev-timestamp + 10 mins
25%: prev-timestamp + 20 mins

Normal clients wouldn't produce low difficulty blocks until 20 mins after the last block, so the timestamp will effectively increase by 10 mins every 20 mins (or 20 mins every 30 mins).

If you don't require the timestamp to be set 10 minutes ahead of the previous block you've effectively just reduced the time between blocks; mining is a random process so if you find a half-difficulty block why wouldn't you broadcast it to the network?

You have to set the difficulty in the header before you try to mine it.

After 20 mins of no blocks, miners would recompute their header (just change the difficulty field) and continue mining.  If they hit a block, then all other miners will accept it since it is at least 20 mins in the future so the other miners will have see the parent more than the 10 min threshold.

If you do require the timestamp miners have every reason to always mine with a timestamp >= 10 minutes ahead of the previous block just in case they find a half-difficulty block.

As above, their is no gain to miners to using different sized blocks.  You can mine a 50% block for 50% of the reward.

TX fees need to be handled though.

I think a fee pool might be a way to handle it.

When a block is found:

D = fraction of standard difficulty
P = reward pool total
M = minting reward
T = TX fees in the block
C = coinbase max input

P = P + M*D

C = D*(T + 0.01*P)

P = P + (1-D)*T

In normal situations, the reward pool would get funded by the block reward and then 1% would be withdrawn.  In steady state the pool would have 100 times M, so they payout would be equal to the M.

Eventually they'll get close enough to the 2 hour window that network consensus is impacted

That is why it is important that there is no incentive to produce smaller difficulty blocks.

Finally a large miner also has an incentive to mine blocks close together because it increases the orphan rate of their competitors more than it increases the orphan rate for them, thus reducing competition over time, and making available more transactions for them to mine and collect fees from.

If the chain is

A <- B <- C

but C is a 50% difficulty block, then C*, which is full difficulty, will win, even if it is found later.

This means other miners can decide not to mine on low difficulty blocks will low(er) risk.

[kjj]

I know that you've been around long enough to know how to search.  Are you really going to make us list all of the reasons why this is a bad idea yet again?

[TierNolan]

I know that you've been around long enough to know how to search.  Are you really going to make us list all of the reasons why this is a bad idea yet again?

I was trying to address concerns.

Miners could release low difficulty blocks created when aiming for higher difficulty

Difficulty has to be decided before mining starts since it is a header field.  A low difficulty block is only acceptable if the miner sets it up that way initially.

Block speed up is dangerous

A transition occurs if the network propagation delay is longer than the block finding time.  Miners should then hoard their blocks and release as a unit.

However, under this rule "Fast" blocks are only accepted by miners if 10 minutes have passed since the miner last saw a block being added to the chain (or I guess technically "tree").

Miners don't produce such blocks until 20 mins have passed.

This could be further improved by just using the headers for this purpose, since they propagate quickly.

Timestamp abuse

If low difficulty blocks gave a better reward to hashing ratio then miners might try to manipulate the timestamps.

However, the system is set so you get the same risk/reward ratio.

If fact, releasing low difficulty blocks has the added hazard that if a low difficulty block and a high difficulty block are found together, then the tie goes to the higher difficulty block.

-----

Anyway, the rules are

- when receiving block headers (or blocks) for the first time, record the local system time of receipt
- The D value for a block is (block difficulty) / (nominal difficulty)
- a block of difficulty D is considered "stable" if
-- its parent was received at least log2(D) * (10 minutes) ago
-- its parent is stable
- only build on top of stable blocks
- D can't be set more than 1

- the difficulty of blocks a node mines would be
-- pow(2, (time since parent received) / (10 minutes) - 1)

The rewards would be as I said in my previous post.  

You get a share of the transaction fees equal to D * (fees) and a share of the reward pool of (0.01 * pool total) * D.  The remaining TX fees are added to the reward pool.

This means that a node has to wait until 10 minutes have passed after connecting, though it takes hours to sync anyway.

[TierNolan]

I was thinking about a tweak to this to make things easier.

Difficulty re-target periods are determined based on POW, not block rate.

The difficulty for a block starts at double the difficulty of the previous block and halves every 10 minutes.

Miners reduce the difficulty target as time passes, since they received the last block.

The recommended targets are

0-10 mins: 2X
10-20 mins: 1X
20-30 mins: 0.5X
30+ mins: 0.25X

If this sequence is used, then other nodes are unlikely to queue any blocks this node produces.

The maximum block difficulty accepted is 2X the previous block.

Nodes will accept new blocks with minimum difficulty based on time since the last block.

<10: >=1X
10-20: >= 0.5X
20+: >= 0.25X

If a miner receives a 0.25X POW block 2 minutes after he received the last block, he adds it to a queue and it will be released 18 minutes later.

Nodes wait 30 minutes after start-up before activating the queue.

The block reward is proportional to the POW of the block.

If you submit a block with 10% of the nominal block POW, then you get 10% of the minting fee, 10% of the transaction fees and 10% of 1% of the prize pool.

The other 90% goes into the prize pool.

After 2 weeks worth of POW, the system re-targets the POW for a new nominal block POW.

[gmaxwell]

Nodes will accept new blocks with minimum difficulty based on time since the last block.

Isn't altchains getting exploited when doing this not enough to dissuade this kind of perennial proposal? (IIRC, TRC did this and got owned and had to change rules again)

Moreover, what you're suggesting would make it _much_ easier to exploit a node whos network you've isolated... deny it the honest chain for a while to drive the acceptable difficulty down, then start mining a low difficulty fork to let it count up confirmations and accept your phantom payments.

[TierNolan]

Moreover, what you're suggesting would make it _much_ easier to exploit a node whos network you've isolated... deny it the honest chain for a while to drive the acceptable difficulty down, then start mining a low difficulty fork to let it count up confirmations and accept your phantom payments.

Confirms would have to be POW based rather than block count based.

You could show confirms (12 / 123.45) meaning 12 block confirms and the total rewards for miners on blocks built on the transaction is 123.45 coins.