<div dir="ltr"><div>James,</div><div><br></div><div>FPNC and NC will always select the highest-work chain, I am suggesting that by adding more bits of precision we avoid confusion.</div><div><br></div><div>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.</div><div><br></div><div>Best Regards,</div><div>Michael</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Good Afternoon,</span></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Re: [bitcoin-dev] Floating-Point Nakamoto Consensus</span></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">I note that the discussion thread for this proposal
</span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">has previously received HARD_NAK
</span><br>
</div>
<div><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">I note in the whitepaper the following basic introduction of need:</span><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">>As a result a</span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">node will simply adopt the first
 solution seen, creating a kind of race condition.</span></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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'.</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br>
</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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.<br>
</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br>
</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">KING JAMES HRMH</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Great British Empire<br>
</span></div>
<div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br>
</span></div>
<div id="m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-1733070628655924658Signature">
<div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<div>Regards,
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)</div>
<div>of Hougun Manor & Glencoe & British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div> </div>
<div>Willtech</div>
<div><a href="http://www.willtech.com.au" target="_blank">www.willtech.com.au</a></div>
<div><a href="http://www.go-overt.com" target="_blank">www.go-overt.com</a></div>
<div>and other projects</div>
<div> </div>
<div><a href="http://earn.com/willtech" target="_blank">earn.com/willtech</a></div>
<div><a href="http://linkedin.com/in/damianwilliamson" target="_blank">linkedin.com/in/damianwilliamson</a></div>
<div><br>
</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. 61261470192</div>
<div><br>
</div>
<div><br>
</div>
----</div>
</div>
</div>
</div>
</div>
<div>
<hr style="display:inline-block;width:98%">
<div id="m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-1733070628655924658divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> bitcoin-dev <<a href="mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target="_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a>> on behalf of Mike Brooks via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>><br>
<b>Sent:</b> Friday, 25 September 2020 5:40 AM<br>
<b>To:</b> bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>><br>
<b>Subject:</b> [bitcoin-dev] Floating-Point Nakamoto Consensus</font>
<div> </div>
</div>
<div>
<div dir="ltr">  Hey Everyone,
<div><br>
</div>
<div> 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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>PDF:<br>
<a href="https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floating-Point%20Nakamoto%20Consensus.pdf" target="_blank">https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floating-Point%20Nakamoto%20Consensus.pdf</a></div>
<div> </div>
<div>Pull Request:<br>
<span id="m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-1733070628655924658x_gmail-m_2766209350405513116gmail-docs-internal-guid-e08d4203-7fff-1140-7022-8ecfe80e9fea"><a href="https://github.com/bitcoin/bitcoin/pull/19665/files" style="text-decoration-line:none" target="_blank"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">https://github.com/bitcoin/bitcoin/pull/19665/files</span></a></span>  <br>
</div>
<div><br>
</div>
<div>---</div>
<div><br>
</div>
<div><span id="m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-1733070628655924658x_gmail-m_2766209350405513116gmail-docs-internal-guid-77a2432b-7fff-62c3-0753-fe93652ca512"><br>
<p dir="ltr" style="line-height:1.38;text-align:center;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:14pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Floating-Point Nakamoto Consensus</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:9pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Abstract —
</span><span style="font-size:9pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">It has been shown that Nakamoto Consensus is very
 useful in the formation of long-term global agreement — and has issues with short-term disagreement which can lead to re-organization (“or-org”) of the blockchain.  A malicious miner with knowledge of a specific kind of denial-of-service (DoS) vulnerability
 can gain an unfair advantage in the current Bitcoin network, and can be used to undermine the security guarantees that developers rely upon.  Floating-Point Nakamoto consensu makes it more expensive to replace an already mined block vs. creation of a new block,
 and by resolving ambiguity of competition solutions it helps achieve global consumers more quickly.  A floating-point fitness test strongly incentivises the correct network behavior, and prevents disagreement from ever forming in the first place.</span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Introduction</span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The
 Bitcoin protocol was created to provide a decentralized consensus on a fully distributed p2p network.  A problem arises when more than one proof-of-work is presented as the next solution block in the blockchain.  Two solutions of the same height are seen as
 authoritative equals which is the basis of a growing disagreement. A node will adopt the first solution seen, as both solutions propagate across the network a race condition of disagreement is formed. This race condition can be controlled by byzentiene fault
 injection commonly referred to as an “eclipsing” attack.  When two segments of the network disagree it creates a moment of weakness in which less than 51% of the network’s computational resources are required to keep the network balanced against itself. </span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Nakamoto
 Consensus</span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Nakamoto
 Consensus is the process of proving computational resources in order to determine eligibility to participate in the decision making process.  If the outcome of an election were based on one node (or one-IP-address-one-vote), then representation could be subverted
 by anyone able to allocate many IPs. A consensus is only formed when the prevailing decision has the greatest proof-of-work effort invested in it. In order for a Nakamoto Consensus to operate, the network must ensure that incentives are aligned such that the
 resources needed to subvert a proof-of-work based consensus outweigh the resources gained through its exploitation. In this consensus model, the proof-of-work requirements for the creation of the next valid solution has the exact same cost as replacing the
 current solution. There is no penalty for dishonesty, and this has worked well in practice because the majority of the nodes on the network are honest and transparent, which is a substantial barrier for a single dishonest node to overcome.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">A
 minimal network peer-to-peer structure is required to support Nakamoto Conesus, and for our purposes this is entirely decentralized. Messages are broadcast on a best-effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work
 chain as proof of what happened while they were gone.  This design makes no guarantees that the peers connected do not misrepresent the network or so called “dishonest nodes.” Without a central authority or central view - all peers depend on the data provided
 by neighboring peers - therefore a dishonest node can continue until a peer is able to make contact an honest node.</span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Security </span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">In
 this threat model let us assume a malicious miner possesses knowledge of an unpatched DoS vulnerability (“0-day”) which will strictly prevent honest nodes from communicating to new members of the network - a so-called “total eclipse.”  The kind of DoS vulnerability
 needed to conduct an eclipse does not need to consume all CPU or computaitly ability of target nodes - but rather prevent target nodes from forming new connections that would undermine the eclipsing effect. These kinds of DoS vulnerabilities are somewhat less
 substional than actually knocking a powerful-mining node offline.  This class of attacks are valuable to an adversary because in order for an honest node to prove that a dishonest node is lying - they would need to form a connection to a segment of the network
 that isn’t entirely suppressed. Let us assume a defense-in-depth strategy and plan on this kind of failure.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Let
 us now consider that the C++ Bitcoind has a finite number of worker threads and a finite number of connections that can be serviced by these workers.  When a rude client occupies all connections - then a pidgin-hole principle comes into play. If a network's
 maximum capacity for connection handlers ‘k’, is the sum of all available worker threads for all nodes in the network, establishing ‘k+1’ connections by the pidgin-hole principle will prevent any new connections from being formed by honest nodes - thereby
 creating a perfect eclipse for any new miners joining the network would only be able to form connections with dishonest nodes.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now
 let’s assume a dishonest node is modified in two ways - it increases the maximum connection handles to hundreds of thousands instead of the current value which is about 10. Then this node is modified to ignore any solution blocks found by honest nodes - thus
 forcing the dishonest side of the network to keep searching for a competitive-solution to split the network in two sides that disagree about which tip of the chain to use.  Any new solution propagates through nodes one hop at a time. This propagation can be
 predicted and shaped by dishonest non-voting nodes that are being used to pass messages for honest nodes.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">At
 this point an attacker can expedite the transmission of one solution, while slowing another. If ever a competing proof-of-work is broadcasted to the network, the adversary will use their network influence to split knowledge of the proof-of-work as close to
 ½ as possible. If the network eclipse is perfect then an adversary can leverage an eigen-vector of computational effort to keep the disagreement in balance for as long as it is needed. No mechanism is stopping the attacker from adding additional computation
 resources or adjusting the eclipsing effect to make sure the system is in balance.   As long as two sides of the network are perfectly in disagreement and generating new blocks - the attacker has intentionally created a hard-fork against the will of the network
 architects and operators. The disagreement needs to be kept open until the adversary’s transactions have been validated on the honest chain - at which point the attacker will add more nodes to the dishonest chain to make sure it is the ultimate winner - thus
 replacing out the honest chain with the one generated by dishonest miners.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">This
 attack is convenient from the adversary’s perspective,  Bitcoin being a broadcast network advertises the IP addresses of all active nodes - and Shodan and the internet scanning project can find all passive nodes responding on TCP 8333.  This should illuminate
 all honest nodes on the network, and even honest nodes that are trying to obscure themselves by not announcing their presence.  This means that the attacker doesn’t need to know exactly which node is used by a targeted exchange - if the attacker has subdued
 all nodes then the targeted exchange must be operating a node within this set of targeted honest nodes.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">During
 a split in the blockchain, each side of the network will honor a separate merkel-tree formation and therefore a separate ledger of transactions. An adversary will then broadcast currency deposits to public exchanges, but only on the weaker side, leaving the
 stronger side with no transaction from the adversary. Any exchange that confirms one of these deposits is relying upon nodes that have been entirely eclipsed so that they cannot see the competing chain - at this point anyone looking to confirm a transaction
 is vulnerable to a double-spend. With this currency deposited on a chain that will become ephemeral, the attacker can wire out the account balance on a different blockchain - such as Tether which is an erc20 token on the Ethereum network which would be unaffected
 by this attack.  When the weaker chain collapses, the transaction that the exchange acted upon is no longer codified in Bitcoin blockchain's global ledger, and will be replaced with a version of the that did not contain these deposits.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Nakamoto
 Consensus holds no guarantees that it’s process is deterministic.  In the short term, we can observe that the Nakamoto Consensus is empirically non-deterministic which is evident by re-organizations (re-org) as a method of resolving disagreements within the
 network.   During a reorganization a blockchain network is at its weakest point, and a 51% attack to take the network becomes unnecessary. An adversary who can eclipse honest hosts on the network can use this as a means of byzantine fault-injection to disrupt
 the normal flow of messages on the network which creates disagreement between miners. </span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">DeFi
 (Decentralized Finance) and smart-contract obligations depend on network stability and determinism.  Failure to pay contracts, such as what happened on “black thursday” resulted in secured loans accidentally falling into redemption.  The transactions used
 by a smart contract are intended to be completed quickly and the outcome is irreversible.  However, if the blockchain network has split then a contract may fire and have it’s side-effects execute only to have the transaction on the ledger to be replaced. 
 Another example is that a hard-fork might cause the payer of a smart contract to default - as the transaction that they broadcasted ended up being on the weaker chain that lost. Some smart contracts, such as collateral backed loans have a redemption clause
 which would force the borrower on the loan to lose their deposit entirely. </span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">With
 two sides of the network balanced against each other - an attacker has split the blockchain and this hard-fork can last for as long as the attacker is able to exert the computational power to ensure that proof-of-work blocks are regularly found on both sides
 of the network.  The amount of resources needed to balance the network against itself is far less than a 51% attack - thereby undermining the security guarantees needed for a decentralized untrusted payment network to function.  An adversary with a sufficiently
 large network of dishonest bots could use this to take a tally of which miners are participating in which side of the network split. This will create an attacker-controlled hard fork of the network with two mutually exclusive merkle trees. Whereby the duration
 of this split is arbitrary, and the decision in which chain to collapse is up to the individual with the most IP address, not the most computation.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">In
 Satoshi Nakamoto’s original paper it was stated that the electorate should be represented by computational effort in the form of a proof-of-work, and only these nodes can participate in the consues process.  However, the electorate can be misled by non-voting
 nodes which can reshape the network to benefit an individual adversary.</span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Chain
 Fitness</span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Any
 solution to byzantine fault-injection or the intentional formation of disagreements must be fully decentralized. A blockchain is allowed to split because there is ambiguity in the Nakamoto proof-of-work, which creates the environment for a race-condition to
 form. To resolve this, Floating-Point Nakamoto Consensus makes it increasingly more expensive to replace the current winning block. This added cost comes from a method of disagreement resolution where not every solution block is the same value, and a more-fit
 solution is always chosen over a weaker solution. Any adversary attempting to have a weaker chain to win out would have to overcome a kind of relay-race, whereby the winning team’s strength is carried forward and the loser will have to work harder and harder
 to maintain the disagreement.  In most cases Floating-Point Nakamoto Consensus will prevent a re-org blockchain from ever going past a single block thereby expediting the formation of a global consensus.  Floating-Point Nakamoto Consensus cements the lead
 of the winner and to greatly incentivize the network to adopt the dominant chain no matter how many valid solutions are advertised, or what order they arrive.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The
 first step in Floating-Point Nakamoto Consensus is that all nodes in the network should continue to conduct traditional Nakamoto Consensus and the formation of new blocks is dictated by the same zero-prefix proof-of-work requirements.  If at any point there
 are two solution blocks advertised for the same height - then a floating-point fitness value is calculated and the solution with the higher fitness value is the winner which is then propagated to all neighbors. Any time two solutions are advertised then a
 re-org is inevitable and it is in the best interest of all miners to adopt the most-fit block, failing to do so risks wasting resources on a mining of a block that would be discarded.  To make sure that incentives are aligned, any zero-prefix proof of work
 could be the next solution, but now in order to replace the current winning solution an adversary would need a zero-prefix block that is also more fit that the current solution - which is much more computationally expensive to produce.</span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Any
 changes to the current tip of the blockchain must be avoided as much as possible. To avoid thrashing between two or more competitive solutions, each replacement can only be done if it is more fit, thereby proving that it has an increased expense.  If at any
 point two solutions of the same height are found it means that eventually some node will have to replace their tip - and it is better to have it done as quickly as possible so that consensus is maintained.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">In
 order to have a purely decentralized solution, this kind of agreement must be empirically derived from the existing proof-of-work so that it is universally and identically verifiable by all nodes on the network.  Additionally, this fitness-test evaluation
 needs to ensure that no two competing solutions can be numerically equivalent.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Let
 us suppose that two or more valid solutions will be proposed for the same block.  To weigh the value of a given solution, let's consider a solution for block 639254, in which the following hash was proposed:</span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">    00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">There
 are 19 zeros, and the remaining hash in base 16 starts with 9e3 and ends with f8.  This can value can be represented in floating point as:</span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">    19.847052573336114130069196154809453027792121882588614904</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">To
 simplify further lets give this block a single whole number to represent one complete solution, and use a rounded floating-point value to represent some fraction of additional work exerted by the miner. </span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">   1.847</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now
 let us suppose that a few minutes later another solution is advertised to the network shown in base16 below:</span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">    000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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 these solutions would be equivalent and a given node would adopt the one that it received
 first.  In Floating-Post Nakamoto Consensus, we compare the fitness scores and keep the highest.  In this case no matter what happens - some nodes will have to change their tip and a fitness test makes sure this happens immediately. </span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">With
 both solutions circulating in the network - any node who has received both proof-of-works should know 1.847 is the current highest value, and shouldn’t need to validate any lower-valued solution.  In fact this fitness value has a high degree of confidence
 that it won’t be unseated by a larger value - being able to produce a proof-of-work with 19 0’s and a decimal component greater than 0.847 is non-trivial.  As time passes any nodes that received a proof-of-work with a value 1.204 - their view of the network
 should erode as these nodes adopt the 1.847 version of the blockchain. </span></p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">All
 nodes are incentivized to support the solution with the highest fitness value - irregardless of which order these proof-of-work were validated. Miners are incentivized to support the dominant chain which helps preserve the global consensus.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Let
 us assume that the underlying cryptographic hash-function used to generate a proof-of-work is an ideal primitive, and therefore a node cannot force the outcome of the non-zero component of their proof-of-work.  Additionally if we assume an ideal cipher then
 the fitness of all possible solutions is gaussian-random. With these assumptions then on average a new solution would split the keyspace of remaining solutions in half.  Given that the work needed to form a  new block remains a constant at 19 blocks for this
 period - it is cheaper to produce a N+1 block that has any floating point value as this is guaranteed to be adopted by all nodes if it is the first solution.  To leverage a chain replacement on nodes conducting Floating-Point Nakamoto Consensus a malicious
 miner would have to expend significantly more resources.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Each
 successive n+1 solution variant of the same block-height must therefore on average consume half of the remaining finite keyspace. Resulting in a the n+1 value not only needed to overcome the 19 zero prefix, but also the non-zero fitness test.   It is possible
 for an adversary to waste their time making a 19 where n+1 was not greater, at which point the entire network will have had a chance to move on with the next solution.  With inductive reasoning, we can see that a demissiniong keyspace increases the amount
 of work needed to find a solution that also meets this new criteria.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now
 let us assume a heavily-fragmented network where some nodes have gotten one or both of the solutions.  In the case of nodes that received the proof-of-work solution with a fitness of 1.847, they will be happily mining on this version of the blockchain. The
 nodes that have gotten both 1.847 and .240 will still be mining for the 1.847 domainite version, ensuring a dominant chain.  However, we must assume some parts of the network never got the message about 1.847 proof of work, and instead continued to mine using
 a value of 1.240 as the previous block.   Now, let’s say this group of isolated miners manages to present a new conflicting proof-of-work solution for 639255:</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">     000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The
 above base16 block has a fitness score of 1.532  The fitness value for the previous block 639254 is added together:</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">     2.772
 = 1.240 + 1.532</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">In
 this specific case, no other solution has been broadcast for block height 639255 - putting the weaker branch in the lead.  If the weaker branch is sufficiently lucky, and finds a solution before the dominant branch then this solution will have a higher overall
 fitness score, and this solution will propagate as it has the higher value.  This is also important for transactions on the network as they benefit from using the most recently formed block - which will have the highest local fitness score at the time of its
 discovery.  At this junction, the weaker branch has an opportunity to prevail enterally thus ending the split.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now
 let us return to the DoS threat model and explore the worst-case scenario created by byzantine fault injection. Let us assume that both the weaker group and the dominant group have produced competing proof-of-work solutions for blocks 639254 and 639255 respectively. 
 Let’s assume that the dominant group that went with the 1.847 fitness score - also produces a solution with a similar fitness value and advertises the following solution to the network:</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">19.414973649464574877549198290879237036867705594421756179</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">or</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">3.262 = 1.847 + 1.415</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">A
 total of 3.262 is still dominant over the lesser 2.772 - in order to overcome this - the 2nd winning block needs to make up for all of the losses in the previous block.  In this scenario, in order for the weaker chain to supplant the dominant chain it must
 overcome a -0.49 point deficit. In traditional Nakamoto Consensus the nodes would see both forks as authoritative equals which creates a divide in mining capacity while two groups of miners search for the next block.  In Floating-Point Nakamoto Consensus any
 nodes receiving both forks, would prefer to mine on the chain with an overall fitness score of +3.262 - making it even harder for the weaker chain to find miners to compete in any future disagreement, thereby eroding support for the weaker chain. This kind
 of comparison requires an empirical method for determining fitness by miners following the same same system of rules will insure a self-fulfilled outcome.  After all nodes adopt the dominant chain normal Nakamoto Consuess can resume without having to take
 into consideration block fitness. This example shows how disagreement can be resolved more quickly if the network has a mechanism to resolve ambiguity and de-incentivise dissent.</span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Soft
 Fork</span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Blockchain
 networks that would like to improve the consensus generation method by adding a fitness test should be able to do so using a “Soft Fork” otherwise known as a compatible software update.  By contrast a “Hard-Fork” is a separate incompatible network that does
 not form the same consensus.  Floating-Point Nakamoto Consensus can be implemented as a soft-fork because both patched, and non-patched nodes can co-exist and non-patched nodes will benefit from a kind of herd immunity in overall network stability.  This is
 because once a small number of nodes start following the same rules then they will become the deciding factor in which chain is chosen.  Clients that are using only traditional Nakamoto Consensus will still agree with new clients over the total chain length.
 Miners that adopt the new strategy early, will be less likely to lose out on mining invalid solutions.</span></p>
<h4 dir="ltr" style="line-height:1.38;margin-top:14pt;margin-bottom:4pt"><span style="font-size:12pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Conclusion</span></h4>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<br>
<br>
<br>
<br>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">A complete implementation of Floating-Point Nakamoto
 consensus is in the following pull request:</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<a href="https://github.com/bitcoin/bitcoin/pull/19665/files" style="text-decoration-line:none" target="_blank"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">https://github.com/bitcoin/bitcoin/pull/19665/files</span></a></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Paper:</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<a href="https://github.com/in-st/Floating-Point-Nakamoto-Consensus" style="text-decoration-line:none" target="_blank"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">https://github.com/in-st/Floating-Point-Nakamoto-Consensus</span></a></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt">
<a href="https://in.st.capital/" style="text-decoration-line:none" target="_blank"><span style="font-size:11pt;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">https://in.st.capital</span></a></p>
<div></div>
<br>
</span></div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div>