A diversion on statistics:
There are two quantities available for consensus:
t target difficulty
h block hash where h < t
>From these we can form two quantities that might be used in consensus:
w work= log(sum(1/t_i))
f fitness = log(sum(1/h_i)) (term used by authors)
Pieter,
You are correct.
And also, I did prove what I set out to prove. The code provided privately
to the security team will in fact consume 99% of the CPU, which means it
does have an effect on the electorate. It is true the node still
stubbornly passes messages, but I would argue that this is
Very interesting,
Block mixing did not resolve the selfish mining that is currently observed
on the network. This mitigation was only intended to limit the maximum
impact of waiting for a 2nd block to be produced.
Rebalancing the selfish-mining incentives with FPNC and a faster block
creation ti
On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Rather than go through that again, I'd prefer we use the
> backwards compatible proposal from BIPs PR#945 and, if we want to
> maximize safety, consensus restrict v1 witness program s
On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> I propose an alternative to length restrictions suggested by
> Russell in https://github.com/bitcoin/bips/pull/945 : use the
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant,
Hello all,
By the way, is this FPNC is similar to the way the current (or recent) code of
Ethereum that is selecting branches based on the difficulty of the crypto
puzzles solved to obtain the blocks of this branch without comparing the sizes
of the subtrees?
Any ideas?
Best,
Önder
> On 8
