[Bitcoin-ml] Solving the difficulty adjustment problem by asking the opposite question

Mon Aug 28 17:27:34 UTC 2017

All good points

>However, should the most efficient miner (the miner offering the largest difficulty for the lowest price) EVER mine on top of a less efficient block produced by a different miner?

I agree that it requires simulation.
It seems to me that the simplest equilibrium solution would be to try to orphan future block(s) until their timestamp becomes valid, at which point start mining on top of them. Even in the absence of more complicated strategies miners would have an incentive to relay their future blocks earlier to allow other miners to switch the instant they become valid. Late relaying would pay a latency price.

>So if our desired block interval is 2 minutes, we basically need to create an additional benefit so that a less-efficient chain of 2 minute blocks is preferred over a more efficient chain of 20 minute blocks

I don't think that's possible as selfishly mining two blocks with cumulative difficulty X would be equivalent to one block with X difficulty

>Without it, for example, as actual block construction efficiency increases a possible solution is a stable difficulty with lower reward

Lower reward would require the tip to become increasingly in the past. Is that what you meant?

P.S. Would you agree with switching to ethereum-style difficulty adjustment now - which is arguably better than relying on benevolent miners to keep the difficulty high enough - and potentially switching to more complex strategies later?

> -------- Original Message --------
> Subject: Re: [Bitcoin-ml] Solving the difficulty adjustment problem by asking the opposite question
> Local Time: August 28, 2017 6:33 PM
> UTC Time: August 28, 2017 4:33 PM
> From: g.andrew.stone at gmail.com
> To: Jan Nightingale <turifex at protonmail.ch>, Bitcoin and related network protocol discussion <bitcoin-ml at lists.linuxfoundation.org>
> Erik Beijnoff <erik.beijnoff at gmail.com>
>
> Jan et. al.,
> If you ignore the human-applied semantics of block time and simplify the process a bit you'll see that your proposal is equivalent to a block auction where the miner basically picks a difficulty and reward and offers that solved block for "sale" and the network "buys" the block with the highest difficulty and the lowest price.  To set readers on the path to realizing this, note that the miner picks the timestamp, and the purpose of the timestamp is to offer a reward based on a function that is something like: block reward = base reward * (timestamp - prior timestamp)/10 minutes.  So the miner is effectively offering a price for the block via a timestamp filtered through some math.
>
> So let's call a block's and chain's "efficiency" to be the ratio of difficulty to reward.  It makes sense that the network prefers the cheapest, most difficult chain (most efficient chain) since this chain minimizes coin inflation while still increasing the chain's value by allowing economic activity (committing transactions).
>
> We need to understand in greater detail when a profit-optimizing miner chooses to mine on top of an existing block verses continuing to mine a sibling.  If block difficulty is considered in isolation (without looking at prior history) there seems to me to be no reason for a miner to switch to the next block.  But an easy solution to this is to take the entire chain's difficulty into account.  Essentially, the miner is offering an entire chain for "sale" (of which he's added a single block on the tip) which therefore has a cumulative difficulty and a cumulative price.
>
> So if a particular miner sees a tip with a new block with a larger difficulty and cheaper price than other chains offer, it makes lots of sense to switch to mining on that new tip since the better ratio will make it more likely that that chain remain the best.
>
> However, should the most efficient miner (the miner offering the largest difficulty for the lowest price) EVER mine on top of a less efficient block produced by a different miner?  As the algorithm sits so far, I think that the answer is "no".
>
> So if our desired block interval is 2 minutes, we basically need to create an additional benefit so that a less-efficient chain of 2 minute blocks is preferred over a more efficient chain of 20 minute blocks (or a more efficient chain of 10 second blocks).  This will encourage the most efficient miner to mine on top of less efficient blocks.  This forcing function also creates the single solution we want out of many possibilities.  Without it, for example, as actual block construction efficiency increases a possible solution is a stable difficulty with lower reward, rather than today's constant reward and increasing difficulty.
>
> I haven't considered what the forcing function could be.  We want it to look like a valley pushing actual block intervals to our preferred block interval -- if it is not, the system will peg on one side or the other and we will end up with undesirable effects, like blocks being rejected based on the exact clock settings of particular nodes.
>
> In sum, I think that the approach is very interesting, but think that it does need to be fleshed out in detail and then simulated or mathematically proven to have stable behavior.
>
> One problem with the approach is that it puts a lot of pressure on miners to properly price blocks or there will be a lot of orphans.  Analysis needs to be done and algorithms created to do this reasonably effectively.
>
> On Mon, Aug 28, 2017 at 9:43 AM, Jan Nightingale via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org> wrote:
>
>> Reasonable, I agree it's complex.
>>
>> However the two other proposed solutions aren't going to work - ss they keep using past blocks for measurement, so the only possible outcome is a change in the oscillation period.
>> Especially now that it's public knowledge that there are supporting miners willing to mine at a loss - so the issue of maturing block rewards can be offloaded on them. As long as they wake up in time ;)
>>
>> Even if these miners somehow were able to afford that indefinitely, POW becomes pointless, as by using BCH you are effectively trusting them to do that, so they could as well run a simple time-stamping server.
>>
>> The simplest alternative that should be able to work without mining at a loss is Ethereum-style duration-dependent difficulty, also requiring fast blocks due to the inherent variance.
>>
>>> -------- Original Message --------
>>> Subject: Re: [Bitcoin-ml] Solving the difficulty adjustment problem by asking the opposite questionLocal Time: August 28, 2017 2:34 PM
>>> UTC Time: August 28, 2017 12:34 PM
>>> From: erik.beijnoff at gmail.com
>>> To: Bitcoin and related network protocol discussion <bitcoin-ml at lists.linuxfoundation.org>, Jan Nightingale <turifex at protonmail.ch>
>>> With regards to your initial proposal Jan - I’ve done some more thinking and think this is a very interesting proposal for the future.
>>>
>>> It is however not something that should be used to solve the immediate situation with the issue of asymmetric emergency difficulty adjustments (EDA).
>>>
>>> The immediate situation with the EDA seems to have been countered by the major miners. This brings quite a lot of hope but it does not solve the underlying issue. Right now they might be able to keep it under control but just a bigger shift in valuation at the wrong time in a difficulty period could throw the system off balance. To me it seems like we have a natural instability in the system rules.
>>>
>>> I’m therefore repeating my request to the developers of the central clients (in no particular order Tom Zander, Peter Rizun, sickpig, thezerg, freetrader, deadalnix and others) to agree on a common proposal that should be prepared, implemented and agreed with the miners. This proposal should be ready for deployment *if* it turns out that we will return to an unstable state.
>>>
>>> Basing the stability of the system on faith in benevolent mining is a very risky proposal.
>>>
>>> As I understand it there are at least two different proposals that have been presented by Tom Z and deadalnix respectively. From a quicker evaluation without any underlying simulations, both seem like good proposals to me. I’d be happy if we would proceed with either one of them.
>>
>> _______________________________________________
>> bitcoin-ml mailing list
>> bitcoin-ml at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170828/88ec01b2/attachment.html>