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

[Jan Nightingale]

>they don't even need to wait for a block to alter their target.

Yes - exactly! That's how the information about the current hash power would be obtained. Each block is a bet and a discrete sample of the current hashing power. There are many possible ways to view that problem, but in the simple Bayesian inference framework, miner's initial network's hash power estimate would form a prior distribution. An observed orphan lowers the probability of low difficulties, a non-orphaned block raises it.

Time between blocks is also useful.

Couple even that simple Bayesian model with the knowledge of the current BCH/BTC ratio (and/or other sha256 coins) and other external data - and the hashpower estimate is likely to be very close to the true one.

> -------- Original Message --------
> Subject: Re: [Bitcoin-ml] Solving the difficulty adjustment problem by asking the opposite question
> Local Time: August 27, 2017 4:43 AM
> UTC Time: August 27, 2017 2:43 AM
> From: tomh at thinlink.com
> To: Jan Nightingale <turifex at protonmail.ch>
> bitcoin-ml at lists.linuxfoundation.org <bitcoin-ml at lists.linuxfoundation.org>
>
> On 8/26/2017 6:45 PM, Jan Nightingale wrote:
>> I agree that the block size is a separate problem and can be dropped,
>> but not minimum time between blocks (unless you meant just leaving at
>> a "natural" timestamp 1 sec limit?). The higher it is the longer the
>> convergence time gets. Additionally the 10 minute sampling rate is imo
>> simply too low - as price ratio and miners can potentially change much
>> faster - inevitably resulting in oscillations.
>>
>
> It"s nice that it would be up to each miner to decide how to read the
> tea leaves.  They can assume all blocktime variation signals a hashrate
> change, even though it doesn"t, but as the alts that retarget every
> block do.  Or they can fit the data how they like.  But you"re enabling
> them to make adjustments as fast and as often as they like -- they don"t
> even need to wait for a block to alter their target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170827/733ab28d/attachment.html>