MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 15 Oct 2020 16:02:09 +0000
From: yanmaani@cock.li
To: Mike Brooks <m@ib.tc>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CALFqKjRn8GM0H=ph0S7i=cm-w1LbjGSwwn1BTP=t2WgcXw2h9g@mail.gmail.com>
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
 <CALFqKjRn8GM0H=ph0S7i=cm-w1LbjGSwwn1BTP=t2WgcXw2h9g@mail.gmail.com>
Message-ID: <3f39574d60ad9eecbc0a410fe04b1d54@cock.li>
User-Agent: Roundcube Webmail/1.3.10
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Precedence: list

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-bounces@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