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

[G. Andrew Stone]

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 question
> Local 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/6b594f46/attachment.html>