HIS EXCELLENCY JAMES HRMH via
bitcoin-dev wrote:
Good Afternoon,
Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
I note that the discussion thread for this proposal has previously
received HARD_NAK
I note in the whitepaper the following basic introduction of need:
As a result anode will sim
ack is null and void.
Best Regards,
Michael
On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev wrote:
> Good Afternoon,
>
> Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
>
> I note that the discussion thread for this proposal has previously
> re
Hey Bob McElarth,
I appreciate this discussion. The issues with chain thrashing was
explicitly addressed with heredity, I saw this problem, and there is an
elegant solution here.
Sorry that summation process wasn't made clear in the paper, I'll be sure
to go back and improve this. Here is a
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
Good Morning ZmnSCPxj ,
It is cheaper and easier to delay messages, or preempt the spreading of
messages, than it is to produce a better fitness score. Whether it be
through pre-emption or an eclipse - an adversary can influence the size of
both sides of the disagreement, which is a strange
Hey Larry,
Great project, and great youtube video. Expect a PR from me.
... If you actively ping nodes that are running a weaker block, you could
inform them of the new block, there could be a mechanism to
eradicate dissent.
-Mike
On Thu, Oct 1, 2020 at 9:43 AM Larry Ruane wrote:
> Hello
Hello Mike and others,
I just want to plug the open-source POW network mining simulator I recently
wrote: https://github.com/LarryRuane/minesim
It simulates Bitcoin's existing POW (of course), but probably would be easy
to modify to correspond to variations such as the one being proposed here.
ZmnSCPxj,
The growing tare in growing disagreement continues to divide mining
capacity while the network waits for formation of future blocks - you'll
never get to complete consensus unless three is a way to avoid ambiguity
in disagreement, which you have not addressed. The topic of my
Good morning Mike,
That is better than implied name-calling and refusing to lay out your argument
in detail.
It is still sub-optimal since you are still being insulting by labeling me as
"reactionary", when you could have just laid out the exact same argument ***in
the first place*** without
Good morning Mike,
> ZmnSCPxj,
>
> The growing tare in growing disagreement continues to divide mining capacity
> while the network waits for formation of future blocks - you'll never get to
> complete consensus unless three is a way to avoid ambiguity in disagreement,
> which you have not
Good morning Mike,
An observation to be made is that the current "first seen" is more
incentive-compatible than floating-point Nakamoto consensus.
If a miner A mines a block at height N, then obviously the first block it has
seen is that block.
If due to propagation delays on the network,
ZmnSCPxj,
No, it would be better to use parachains for Mars.
-Mike Brooks
On Tue, Sep 29, 2020, 11:31 PM ZmnSCPxj wrote:
>
> > At this point very little is stopping us from speeding up block
> creation times. PoS networks are proving that conformations can be a minute
> or less - why not
> At this point very little is stopping us from speeding up block creation
>times. PoS networks are proving that conformations can be a minute or less -
>why not allow for a block formation time that is 6 or 12 times faster than the
>current target and have 1/6th (or 1/12th) of the subsidy to
Hey Frank,
Firstly, I must commend you on two very good questions.
The reason why I chose to maximize the value is because I approached this
as an optimization problem to be solved with a genetic algorithm, and it
fit with my internal model of a kind of relay race that moves forward
faster. When
Good Afternoon,
Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
I note that the discussion thread for this proposal has previously received
HARD_NAK
I note in the whitepaper the following basic introduction of need:
>As a result anode will simply adopt the first solution seen, creat
On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
[snip]
> The solution above also has 19 prefixed zeros, and is being broadcast for
> the same blockheight value of 639254 - and a fitness score of 1.282. With
> Nakamoto Consensus both of
Very interesting find - there are similarities here, but this is hardly
identical.
>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003584.html
I am largely in agreement with Quinn (from 2013) - simply using the lowest
block value was a bad idea because the value cannot be
On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev wrote:
> - with a fitness test you have a 100% chance of a new block from being
> accepted, and only a 50% or less chance for replacing a block which has
> already been mined. This is all about keeping incentives moving
Hey Jeremy,
Thanks for your response, but I think you misunderstood a crucial feature
- with a fitness test you have a 100% chance of a new block from being
accepted, and only a 50% or less chance for replacing a block which has
already been mined. This is all about keeping incentives moving
Hey Thomas,
A fitness value is only additive for the length of the disagreement, and
only used to solve disagreements of the same height. This isn't as large
of a departure as you are expecting. For 50,000 blocks of agreement, then
no floating point value is calculated.
All the best,
Mike
On
Re: Floating-Point Nakamoto Consensus (bitcoin ml)
>
> This is a pretty big departure from cumulative POW.
It's still cumulative. But instead of cumulating network difficulty,
they cumulate log_2(solution difficulty).
So if two solutions are found simultaneously, and one has a hash
that's only
If I understand correctly, this is purely a policy level decision to accept
first-seen or a secondary deterministic test, but the most-work chain is
still always better than a "more fit" but less work chain.
In any case, I'm skeptical of the properties of this change. First-seen has
a nice
Hi,
This is a pretty big departure from cumulative POW.
Could you explain to me what you see happening if a node with this patch
and no history starts to sync, and some random node gives it a block
with a better fitness test for say height 250,000? No other solution
will have a better
23 matches
Mail list logo
