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

Tue Aug 29 01:11:14 UTC 2017

Jan's algorithm doesn't redefine chainwork to be a ratio of
target/reward.  It continues to use target alone, just as today.  So the
incentive to mine atop the best block is clear.

Reward is set to a pure function of blocktime, which has the desired
property of being hashrate independent, and is only a tiebreaker in case
of identical difficulty.

The algorithm doesn't aim toward decreasing the block interval from 10
minutes, and it isn't clear to me whether in practice the average
interval would increase or decrease from that value, other things being
constant, although I suspect it would decrease because it is finally
free to do so.

What is clear is that mining would cease to be a poisson process and
become something else, something more purpose-built for the task and
unimaginable, had we not already accumulated the experience we have.

In addition to simulation, the idea needs to be tested by specific,
imaginative adversarial thinking.  Also, the prediction is testable that
Digishield etc. will show marked oscillation if mined optimally.

On 8/28/2017 9:33 AM, G. Andrew Stone via bitcoin-ml wrote:
> 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
> <mailto: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 question
>>     Local Time: August 28, 2017 2:34 PM
>>     UTC Time: August 28, 2017 12:34 PM
>>     From: erik.beijnoff at gmail.com <mailto:erik.beijnoff at gmail.com>
>>     To: Bitcoin and related network protocol discussion
>>     <bitcoin-ml at lists.linuxfoundation.org
>>     <mailto:bitcoin-ml at lists.linuxfoundation.org>>, Jan Nightingale
>>     <turifex at protonmail.ch <mailto: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
>     <mailto:bitcoin-ml at lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
>
>
>
>
> _______________________________________________
> 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/7c94d7b4/attachment.html>