What if a miner mines a block that has a very high block reward (i.e.
confirmed a juicy transaction), while at the same time having a floating
point fitness very close to the minimum?
For the sake of argument, let's say the block reward is 6.50 (4% more
than average), the fitness is 1.001, and the orphan rate is 0.3%.
With Nakamoto consensus, the miners would (allegedly) find it in their
best interest to work on that block, since it was first. It's a problem
when they don't, but the system basically works right now.
With FPNC, the miners have two equally valid options:
1) Attempt to create a block building on top of that block (reward:
6.25)
2) Attempt to replace (reward: 6.50)
If they do (1), their probability of success given a matching hash is
(100 - orphan rate)%, which is very close to 100%.
If they do the second, their probability of success given a hit is (100
- percentile(1.001)), which also is very close to 100%.
Option 1 has EV of .997 * 1 * 6.25 = 6.25.
Option 2 has EV of (1 - quantile(1.001)) * 1.04 * 6.25, which is surely
above 6.25. I don't know how to calculate the quantile, but it's
obvious.
With the block subsidy getting lower and lower as time goes on, the
probability of this happening goes up.
Don't we want miners to always keep the chain going forward? Your
proposal incentivizes reorgs.
On 2020-10-10 01:26, Mike Brooks via bitcoin-dev wrote:
James,
FPNC and NC will always select the highest-work chain, I am suggesting
that by adding more bits of precision we avoid confusion.
Part 2 -> Using a genetic algorithm that passes fitness with heredity
to resolve disagreements has never been introduced to this mailing
list. This hard-nack is null and void.
Best Regards,
Michael
On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 simply adopt the first solution seen,
creating a kind of race condition.
The said race condition, it is not noted, is 'self-resolving' with
the network adopting the longest chain with the highest proof of
work as any contentious tip is built on. This is the proper reason
for waiting for two confirmations for a transaction as a minimum
proof of its inclusion in the blockchain (without fraud), and for
waiting for six confirmations before considering that a transaction
is 'final'.
I take it that your work is intended to allow the network to decide
immediately without waiting for a chain to be further extended, in
that case, the solution should be as noted elsewhere to accept the
higher proof of work with the greater precision proof. When
comparing two competing blocks there is an indirect reference to a
higher proof of work due to the greater precision in the block hash,
although the answer could have been arrived with fewer attempts. As
it is, the total proof of work is not directly calculated but is
evaluated as the chain with more blocks being the chain with more
proof-of-work, whereas in the cases two blocks are received as
alternates extending the same chain tip there is currently no method
of comparison to determine which of the blocks, and the correct tip
is not chosen without further proof-of-work to extend a tip.
Resolving this reduces the network expense of reorganisation in
ordinary conditions but in the case of a network-split resolves
nothing.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au [1]
www.go-overt.com [2]
and other projects
earn.com/willtech [3]
linkedin.com/in/damianwilliamson [4]
m. 0487135719
f. 61261470192
----
-------------------------
From: bitcoin-dev <bitcoin-dev-boun...@lists.linuxfoundation.org> on
behalf of Mike Brooks via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>
Sent: Friday, 25 September 2020 5:40 AM
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Floating-Point Nakamoto Consensus
Hey Everyone,
A lot of work has gone into this paper, and the current revision
has been well received and there is a lot of excitement on this side
to be sharing it with you today. There are so few people that truly
understand this topic, but we are all pulling in the same direction
to make Bitcoin better and it shows. It is wildly underrated that
future proofing was never really a consideration in the initial
design - but here we are a decade later with amazing solutions like
SegWit which gives us a real future-proofing framework. The fact
that future-proofing was added to Bitcoin with a softfork gives me
goosebumps. I'd just like to take the time to thank the people who
worked on SegWit and it is an appreciation that comes up in
conversation of how difficult and necessary that process was, and
this appreciation may not be vocalized to the great people who
worked on it. The fact that Bitcoin keeps improving and is able to
respond to new threats is nothing short of amazing - thank you
everyone for a great project.
This current proposal really has nothing to do with SegWit - but it
is an update that will make the network a little better for the
future, and we hope you enjoy the paper.
PDF:...
CONCLUSION
Floating-Point Nakamoto consensus allows the network to form a
consensus more quickly by avoiding ambiguity allowing for
determinism to take hold. Bitcoin has become an essential utility,
and attacks against our networks must be avoided and adapting,
patching and protecting the network is a constant effort. An
organized attack against a cryptocurrency network will undermine the
guarantees that blockchain developers are depending on.
Any blockchain using Nakamoto Consensus can be modified to use a
fitness constraint such as the one used by a Floating-Point Nakamoto
Consensus. An example implementation has been written and submitted
as a PR to the bitcoin core which is free to be adapted by other
networks.
A complete implementation of Floating-Point Nakamoto consensus is in
the following pull request:
https://github.com/bitcoin/bitcoin/pull/19665/files [5]
Paper:
https://github.com/in-st/Floating-Point-Nakamoto-Consensus [6]
https://in.st.capital [7]
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] http://www.willtech.com.au
[2] http://www.go-overt.com
[3] http://earn.com/willtech
[4] http://linkedin.com/in/damianwilliamson
[5] https://github.com/bitcoin/bitcoin/pull/19665/files
[6] https://github.com/in-st/Floating-Point-Nakamoto-Consensus
[7] https://in.st.capital/
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
