path: root/37/1802f9f521ae4b86a6ffbb95ef3b12dc1726b4

Return-Path: <willtech@live.com.au>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 91558C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 6C6A987084
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 75WIhO6UkCoB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:12 +0000 (UTC)
X-Greylist: delayed 00:34:07 by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
 (mail-oln040092254083.outbound.protection.outlook.com [40.92.254.83])
 by hemlock.osuosl.org (Postfix) with ESMTPS id AFEE487079
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:11 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KNb8etBE7PaJhxiCSD8lYPbknMH8QfcGbl9+5SkvzJpAtBfDciEE/5QmpWEIGDnWoZfJgKi/mA2nmna9KV6nD6YW7d6eL8BL6ETh6LD03BKaSyflgMkJzCjb9jUwqvvPxqmtgHUhAs6wXMPcC88vuYB1YLUlj6UYrJRXLrCePglxsQbU6LZBXKPW2Z87cNgeJETOf6+2sfRdUQXxJmH0NAJgOzDjgNxGvFEi2m2sXHscUBGtROQO20Vy8T5Z6NIBbytPMiB4matraKTIpWP/G5jO/a4YSQeKcZwHpjKVeGe8smm50opXB+dZ+dd/6hNDYzPD5Q/Ui4p1yxbdMrPp/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1o+KG908f5cQg4YHPAhLCse+zPYnQcojCAP4i52Uk+U=;
 b=X6LfaT+qkj4seZQPgqwskzLNHknz5tU/09VT84qHGgZ7XEBiVDjc6Ea1OnXOKgIXB5mFMefaoykzshsiDUetbIRdlK8dCE7jf6sABEGuXHE9aaC+BoBrOWmmAzYOkTK5GadQS/jwntwjUDerE9U1Rr0kOLhsNuV0bwZcvhq/E7Ektfbvqdkj5ZMG2R55W848Mbm6TYa1Zs4uJyQXDC2z7FGViaaOC59A3s8UlJTrxHDQ9jp90UUvq7vGklFI15OciqNFakUfiGvI0l8197+v32u+6bI9iN+g2hiKy4E5AeCwy6UgP2cD2yVdzKOUBuRDYB0x00q0jHlKCMlvQQ3SEg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
Received: from SG2APC01FT024.eop-APC01.prod.protection.outlook.com
 (2a01:111:e400:7ebd::50) by
 SG2APC01HT064.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::295)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Tue, 29 Sep
 2020 03:10:36 +0000
Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM (10.152.250.51) by
 SG2APC01FT024.mail.protection.outlook.com (10.152.250.185) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3412.21 via Frontend Transport; Tue, 29 Sep 2020 03:10:36 +0000
Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM
 ([fe80::7824:d690:5506:7f95]) by PSXP216MB0967.KORP216.PROD.OUTLOOK.COM
 ([fe80::7824:d690:5506:7f95%8]) with mapi id 15.20.3412.029; Tue, 29 Sep 2020
 03:10:36 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, Mike Brooks
 <f@in.st.capital>
Thread-Topic: [bitcoin-dev] Floating-Point Nakamoto Consensus
Thread-Index: AQHWkzTDRX06cyQol02+jyZ664P+sql+74xp
Date: Tue, 29 Sep 2020 03:10:36 +0000
Message-ID: <PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
In-Reply-To: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:D21F0FC69498A8EE0917DC1E091E220B1169ACB7F27A129D8EF1C6A78A3321A5;
 UpperCasedChecksum:DE8689A99E253EDD05EDF7B83C3D05658BEB624AC49E7CADFD1298C4FE0AFAAC;
 SizeAsReceived:6908; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [jMazCu4uEbWNOahT/MUJdQtb1b91/DEb]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 04594707-bf8f-4e03-20d3-08d864253c6a
x-ms-traffictypediagnostic: SG2APC01HT064:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rwks7quhLH2TOTf8dqbpFnQTReNKaOBqtekM3e4Rn0vTOJNJks8NC7/KBv/fdovaRUrpef6uj4gSlz4Y/m5uFd4shGyFiZ7FP6Cr5pkPmqrRK40UAVpC7Flx1pdXbTmVDJMkzAiuJeuVWHUc6PZeaVdnzOtijwBuy34lv8Q5Czto7/vEOsCf1ejemfLdmeu2RiqoLeKnlBxrEf6omx6NuBLjKLM7DujeiSrJ1QOMQ/bwwB2KKoBl7Gmcqz5Q1mU6
x-ms-exchange-antispam-messagedata: R3RLJz3AbSANAUXzNByqcdgU/Rc/u0cj2X6ZHwfkSzaSJ6xAVuBu0pF0TKuw2UMzmE7Ar6liCjz6dF6ajfVAJe10+fe2xnJqcDTB4hInw2zhMHVFgFv2YuXJxklQNGT/Y9WUF/Rz9r6mV7Z4WRdciQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT024.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 04594707-bf8f-4e03-20d3-08d864253c6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 03:10:36.2581 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT064
X-Mailman-Approved-At: Tue, 29 Sep 2020 07:29:39 +0000
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 03:45:16 -0000

--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

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 ki=
nd of race condition.

The said race condition, it is not noted, is 'self-resolving' with the netw=
ork adopting the longest chain with the highest proof of work as any conten=
tious tip is built on. This is the proper reason for waiting for two confir=
mations for a transaction as a minimum proof of its inclusion in the blockc=
hain (without fraud), and for waiting for six confirmations before consider=
ing that a transaction is 'final'.

I take it that your work is intended to allow the network to decide immedia=
tely 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 wi=
th the greater precision proof. When comparing two competing blocks there i=
s an indirect reference to a higher proof of work due to the greater precis=
ion in the block hash, although the answer could have been arrived with few=
er attempts. As it is, the total proof of work is not directly calculated b=
ut is evaluated as the chain with more blocks being the chain with more pro=
of-of-work, whereas in the cases two blocks are received as alternates exte=
nding the same chain tip there is currently no method of comparison to dete=
rmine which of the blocks, and the correct tip is not chosen without furthe=
r 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-spli=
t 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
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


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 i=
t 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 co=
nsideration in the initial design - but here we are a decade later with ama=
zing 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 worke=
d 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 amazin=
g - thank you everyone for a great project.

This current proposal really has nothing to do with SegWit - but it is an u=
pdate that will make the network a little better for the future, and we hop=
e you enjoy the paper.

PDF:
https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floa=
ting-Point%20Nakamoto%20Consensus.pdf

Pull Request:
https://github.com/bitcoin/bitcoin/pull/19665/files

---



Floating-Point Nakamoto Consensus


Abstract =97 It has been shown that Nakamoto Consensus is very useful in th=
e formation of long-term global agreement =97 and has issues with short-ter=
m disagreement which can lead to re-organization (=93or-org=94) of the bloc=
kchain.  A malicious miner with knowledge of a specific kind of denial-of-s=
ervice (DoS) vulnerability can gain an unfair advantage in the current Bitc=
oin network, and can be used to undermine the security guarantees that deve=
lopers rely upon.  Floating-Point Nakamoto consensu makes it more expensive=
 to replace an already mined block vs. creation of a new block, and by reso=
lving ambiguity of competition solutions it helps achieve global consumers =
more quickly.  A floating-point fitness test strongly incentivises the corr=
ect network behavior, and prevents disagreement from ever forming in the fi=
rst place.

Introduction

The Bitcoin protocol was created to provide a decentralized consensus on a =
fully distributed p2p network.  A problem arises when more than one proof-o=
f-work is presented as the next solution block in the blockchain.  Two solu=
tions of the same height are seen as authoritative equals which is the basi=
s of a growing disagreement. A node will adopt the first solution seen, as =
both solutions propagate across the network a race condition of disagreemen=
t is formed. This race condition can be controlled by byzentiene fault inje=
ction commonly referred to as an =93eclipsing=94 attack.  When two segments=
 of the network disagree it creates a moment of weakness in which less than=
 51% of the network=92s computational resources are required to keep the ne=
twork balanced against itself.

Nakamoto Consensus

Nakamoto Consensus is the process of proving computational resources in ord=
er 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-on=
e-vote), then representation could be subverted by anyone able to allocate =
many IPs. A consensus is only formed when the prevailing decision has the g=
reatest proof-of-work effort invested in it. In order for a Nakamoto Consen=
sus to operate, the network must ensure that incentives are aligned such th=
at the resources needed to subvert a proof-of-work based consensus outweigh=
 the resources gained through its exploitation. In this consensus model, th=
e proof-of-work requirements for the creation of the next valid solution ha=
s the exact same cost as replacing the current solution. There is no penalt=
y 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 substan=
tial barrier for a single dishonest node to overcome.


A minimal network peer-to-peer structure is required to support Nakamoto Co=
nesus, and for our purposes this is entirely decentralized. Messages are br=
oadcast 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 happene=
d while they were gone.  This design makes no guarantees that the peers con=
nected do not misrepresent the network or so called =93dishonest nodes.=94 =
Without a central authority or central view - all peers depend on the data =
provided by neighboring peers - therefore a dishonest node can continue unt=
il a peer is able to make contact an honest node.

Security

In this threat model let us assume a malicious miner possesses knowledge of=
 an unpatched DoS vulnerability (=930-day=94) which will strictly prevent h=
onest nodes from communicating to new members of the network - a so-called =
=93total eclipse.=94  The kind of DoS vulnerability needed to conduct an ec=
lipse does not need to consume all CPU or computaitly ability of target nod=
es - but rather prevent target nodes from forming new connections that woul=
d undermine the eclipsing effect. These kinds of DoS vulnerabilities are so=
mewhat less substional than actually knocking a powerful-mining node offlin=
e.  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 t=
o form a connection to a segment of the network that isn=92t entirely suppr=
essed. Let us assume a defense-in-depth strategy and plan on this kind of f=
ailure.


Let us now consider that the C++ Bitcoind has a finite number of worker thr=
eads and a finite number of connections that can be serviced by these worke=
rs.  When a rude client occupies all connections - then a pidgin-hole princ=
iple comes into play. If a network's maximum capacity for connection handle=
rs =91k=92, is the sum of all available worker threads for all nodes in the=
 network, establishing =91k+1=92 connections by the pidgin-hole principle w=
ill prevent any new connections from being formed by honest nodes - thereby=
 creating a perfect eclipse for any new miners joining the network would on=
ly be able to form connections with dishonest nodes.


Now let=92s assume a dishonest node is modified in two ways - it increases =
the maximum connection handles to hundreds of thousands instead of the curr=
ent value which is about 10. Then this node is modified to ignore any solut=
ion blocks found by honest nodes - thus forcing the dishonest side of the n=
etwork 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 solu=
tion propagates through nodes one hop at a time. This propagation can be pr=
edicted and shaped by dishonest non-voting nodes that are being used to pas=
s messages for honest nodes.


At this point an attacker can expedite the transmission of one solution, wh=
ile slowing another. If ever a competing proof-of-work is broadcasted to th=
e network, the adversary will use their network influence to split knowledg=
e of the proof-of-work as close to =BD 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 resou=
rces or adjusting the eclipsing effect to make sure the system is in balanc=
e.   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=92s transactions have been valida=
ted on the honest chain - at which point the attacker will add more nodes t=
o the dishonest chain to make sure it is the ultimate winner - thus replaci=
ng out the honest chain with the one generated by dishonest miners.


This attack is convenient from the adversary=92s perspective,  Bitcoin bein=
g a broadcast network advertises the IP addresses of all active nodes - and=
 Shodan and the internet scanning project can find all passive nodes respon=
ding on TCP 8333.  This should illuminate all honest nodes on the network, =
and even honest nodes that are trying to obscure themselves by not announci=
ng their presence.  This means that the attacker doesn=92t need to know exa=
ctly which node is used by a targeted exchange - if the attacker has subdue=
d all nodes then the targeted exchange must be operating a node within this=
 set of targeted honest nodes.


During a split in the blockchain, each side of the network will honor a sep=
arate merkel-tree formation and therefore a separate ledger of transactions=
. An adversary will then broadcast currency deposits to public exchanges, b=
ut only on the weaker side, leaving the stronger side with no transaction f=
rom the adversary. Any exchange that confirms one of these deposits is rely=
ing 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 Ethere=
um network which would be unaffected by this attack.  When the weaker chain=
 collapses, the transaction that the exchange acted upon is no longer codif=
ied in Bitcoin blockchain's global ledger, and will be replaced with a vers=
ion of the that did not contain these deposits.


Nakamoto Consensus holds no guarantees that it=92s process is deterministic=
.  In the short term, we can observe that the Nakamoto Consensus is empiric=
ally non-deterministic which is evident by re-organizations (re-org) as a m=
ethod of resolving disagreements within the network.   During a reorganizat=
ion 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 disr=
upt the normal flow of messages on the network which creates disagreement b=
etween miners.


DeFi (Decentralized Finance) and smart-contract obligations depend on netwo=
rk stability and determinism.  Failure to pay contracts, such as what happe=
ned on =93black thursday=94 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 blo=
ckchain network has split then a contract may fire and have it=92s side-eff=
ects execute only to have the transaction on the ledger to be replaced.  An=
other 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 th=
e weaker chain that lost. Some smart contracts, such as collateral backed l=
oans have a redemption clause which would force the borrower on the loan to=
 lose their deposit entirely.


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 attack=
er is able to exert the computational power to ensure that proof-of-work bl=
ocks are regularly found on both sides of the network.  The amount of resou=
rces needed to balance the network against itself is far less than a 51% at=
tack - thereby undermining the security guarantees needed for a decentraliz=
ed untrusted payment network to function.  An adversary with a sufficiently=
 large network of dishonest bots could use this to take a tally of which mi=
ners are participating in which side of the network split. This will create=
 an attacker-controlled hard fork of the network with two mutually exclusiv=
e merkle trees. Whereby the duration of this split is arbitrary, and the de=
cision in which chain to collapse is up to the individual with the most IP =
address, not the most computation.


In Satoshi Nakamoto=92s original paper it was stated that the electorate sh=
ould 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.

Chain Fitness

Any solution to byzantine fault-injection or the intentional formation of d=
isagreements 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 curr=
ent winning block. This added cost comes from a method of disagreement reso=
lution where not every solution block is the same value, and a more-fit sol=
ution 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=92s strength is carried forward and the loser wil=
l have to work harder and harder to maintain the disagreement.  In most cas=
es 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 winn=
er and to greatly incentivize the network to adopt the dominant chain no ma=
tter how many valid solutions are advertised, or what order they arrive.


The first step in Floating-Point Nakamoto Consensus is that all nodes in th=
e 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 th=
e solution with the higher fitness value is the winner which is then propag=
ated 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 mos=
t-fit block, failing to do so risks wasting resources on a mining of a bloc=
k that would be discarded.  To make sure that incentives are aligned, any z=
ero-prefix proof of work could be the next solution, but now in order to re=
place the current winning solution an adversary would need a zero-prefix bl=
ock that is also more fit that the current solution - which is much more co=
mputationally expensive to produce.

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, ea=
ch 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 ti=
p - and it is better to have it done as quickly as possible so that consens=
us is maintained.


In order to have a purely decentralized solution, this kind of agreement mu=
st be empirically derived from the existing proof-of-work so that it is uni=
versally and identically verifiable by all nodes on the network.  Additiona=
lly, this fitness-test evaluation needs to ensure that no two competing sol=
utions can be numerically equivalent.


Let us suppose that two or more valid solutions will be proposed for the sa=
me block.  To weigh the value of a given solution, let's consider a solutio=
n for block 639254, in which the following hash was proposed:

    00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8


There are 19 zeros, and the remaining hash in base 16 starts with 9e3 and e=
nds with f8.  This can value can be represented in floating point as:

    19.847052573336114130069196154809453027792121882588614904


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.

   1.847


Now let us suppose that a few minutes later another solution is advertised =
to the network shown in base16 below:

    000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2


The solution above also has 19 prefixed zeros, and is being broadcast for t=
he same blockheight value of 639254 - and a fitness score of 1.282.  With N=
akamoto Consensus both of these solutions would be equivalent and a given n=
ode would adopt the one that it received first.  In Floating-Post Nakamoto =
Consensus, we compare the fitness scores and keep the highest.  In this cas=
e no matter what happens - some nodes will have to change their tip and a f=
itness test makes sure this happens immediately.


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 sho=
uldn=92t need to validate any lower-valued solution.  In fact this fitness =
value has a high degree of confidence that it won=92t be unseated by a larg=
er value - being able to produce a proof-of-work with 19 0=92s and a decima=
l component greater than 0.847 is non-trivial.  As time passes any nodes th=
at 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.

All nodes are incentivized to support the solution with the highest fitness=
 value - irregardless of which order these proof-of-work were validated. Mi=
ners are incentivized to support the dominant chain which helps preserve th=
e global consensus.


Let us assume that the underlying cryptographic hash-function used to gener=
ate a proof-of-work is an ideal primitive, and therefore a node cannot forc=
e the outcome of the non-zero component of their proof-of-work.  Additional=
ly 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 w=
ould split the keyspace of remaining solutions in half.  Given that the wor=
k needed to form a  new block remains a constant at 19 blocks for this peri=
od - 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 soluti=
on.  To leverage a chain replacement on nodes conducting Floating-Point Nak=
amoto Consensus a malicious miner would have to expend significantly more r=
esources.


Each successive n+1 solution variant of the same block-height must therefor=
e 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 tim=
e 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 r=
easoning, we can see that a demissiniong keyspace increases the amount of w=
ork needed to find a solution that also meets this new criteria.


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 proo=
f-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 domina=
nt 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 va=
lue of 1.240 as the previous block.   Now, let=92s say this group of isolat=
ed miners manages to present a new conflicting proof-of-work solution for 6=
39255:


     000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6


The above base16 block has a fitness score of 1.532  The fitness value for =
the previous block 639254 is added together:


     2.772 =3D 1.240 + 1.532


In this specific case, no other solution has been broadcast for block heigh=
t 639255 - putting the weaker branch in the lead.  If the weaker branch is =
sufficiently lucky, and finds a solution before the dominant branch then th=
is solution will have a higher overall fitness score, and this solution wil=
l propagate as it has the higher value.  This is also important for transac=
tions on the network as they benefit from using the most recently formed bl=
ock - which will have the highest local fitness score at the time of its di=
scovery.  At this junction, the weaker branch has an opportunity to prevail=
 enterally thus ending the split.


Now let us return to the DoS threat model and explore the worst-case scenar=
io created by byzantine fault injection. Let us assume that both the weaker=
 group and the dominant group have produced competing proof-of-work solutio=
ns for blocks 639254 and 639255 respectively.  Let=92s assume that the domi=
nant group that went with the 1.847 fitness score - also produces a solutio=
n with a similar fitness value and advertises the following solution to the=
 network:


0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113

19.414973649464574877549198290879237036867705594421756179

or

3.262 =3D 1.847 + 1.415


A total of 3.262 is still dominant over the lesser 2.772 - in order to over=
come 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 su=
pplant the dominant chain it must overcome a -0.49 point deficit. In tradit=
ional Nakamoto Consensus the nodes would see both forks as authoritative eq=
uals which creates a divide in mining capacity while two groups of miners s=
earch for the next block.  In Floating-Point Nakamoto Consensus any nodes r=
eceiving both forks, would prefer to mine on the chain with an overall fitn=
ess score of +3.262 - making it even harder for the weaker chain to find mi=
ners to compete in any future disagreement, thereby eroding support for the=
 weaker chain. This kind of comparison requires an empirical method for det=
ermining fitness by miners following the same same system of rules will ins=
ure a self-fulfilled outcome.  After all nodes adopt the dominant chain nor=
mal Nakamoto Consuess can resume without having to take into consideration =
block fitness. This example shows how disagreement can be resolved more qui=
ckly if the network has a mechanism to resolve ambiguity and de-incentivise=
 dissent.

Soft Fork

Blockchain networks that would like to improve the consensus generation met=
hod by adding a fitness test should be able to do so using a =93Soft Fork=
=94 otherwise known as a compatible software update.  By contrast a =93Hard=
-Fork=94 is a separate incompatible network that does not form the same con=
sensus.  Floating-Point Nakamoto Consensus can be implemented as a soft-for=
k 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 stabilit=
y.  This is because once a small number of nodes start following the same r=
ules then they will become the deciding factor in which chain is chosen.  C=
lients that are using only traditional Nakamoto Consensus will still agree =
with new clients over the total chain length. Miners that adopt the new str=
ategy early, will be less likely to lose out on mining invalid solutions.

Conclusion

Floating-Point Nakamoto consensus allows the network to form a consensus mo=
re quickly by avoiding ambiguity allowing for determinism to take hold. Bit=
coin 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 undermin=
e the guarantees that blockchain developers are depending on.


Any blockchain using Nakamoto Consensus can be modified to use a fitness co=
nstraint such as the one used by a Floating-Point Nakamoto Consensus.  An e=
xample 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 fo=
llowing pull request:

https://github.com/bitcoin/bitcoin/pull/19665/files


Paper:

https://github.com/in-st/Floating-Point-Nakamoto-Consensus

https://in.st.capital<https://in.st.capital/>


--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">Good Afternoon,</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">Re: [bitcoin-dev] Floating-Point Na=
kamoto Consensus</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I note that the discussion thread f=
or this proposal
</span><span style=3D"font-family: Calibri, Helvetica, sans-serif; font-siz=
e: 12pt; color: rgb(0, 0, 0);">has previously received HARD_NAK
</span><br>
</div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I note in the whitepaper the follow=
ing basic introduction of need:</span><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">&gt;As a result a</span><span style=
=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rg=
b(0, 0, 0);">node will simply adopt the first
 solution seen, creating a kind of race condition.</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"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 confirmatio=
ns for a transaction as a minimum proof of its inclusion in the blockchain =
(without fraud), and for waiting for six confirmations before considering t=
hat a transaction is 'final'.</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I take it that your work is intende=
d 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 wo=
rk with the greater precision proof. When comparing two competing blocks th=
ere is an indirect reference to a higher proof of work due to the greater p=
recision in the block hash, although
 the answer could have been arrived with fewer attempts. As it is, the tota=
l proof of work is not directly calculated but is evaluated as the chain wi=
th more blocks being the chain with more proof-of-work, whereas in the case=
s 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 f=
urther proof-of-work to extend a tip. Resolving this reduces the network ex=
pense of reorganisation in ordinary
 conditions but in the case of a network-split resolves nothing.<br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">KING JAMES HRMH</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">Great British Empire<br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div id=3D"Signature">
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div>Regards,
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>and other projects</div>
<div>&nbsp;</div>
<div>earn.com/willtech</div>
<div>linkedin.com/in/damianwilliamson</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 tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev &lt;bit=
coin-dev-bounces@lists.linuxfoundation.org&gt; on behalf of Mike Brooks via=
 bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Friday, 25 September 2020 5:40 AM<br>
<b>To:</b> bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Subject:</b> [bitcoin-dev] Floating-Point Nakamoto Consensus</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">&nbsp; Hey Everyone,
<div><br>
</div>
<div>&nbsp;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&nb=
sp;be sharing it with you today. There are so few people that truly underst=
and this topic, but we are all pulling in
 the same direction to make Bitcoin better and it shows.&nbsp; It is wildly=
 underrated that future proofing was never really a consideration&nbsp;in t=
he initial&nbsp;design - but here we are a decade later with amazing soluti=
ons like SegWit which&nbsp;gives us a real future-proofing
 framework.&nbsp; The fact that future-proofing was added to Bitcoin with a=
 softfork gives me goosebumps.&nbsp;I'd just like to take the time to thank=
 the people who worked on SegWit and it is an appreciation&nbsp;that comes =
up in conversation of how difficult and necessary
 that process was,&nbsp;and this appreciation may not be vocalized to the g=
reat 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 ever=
yone for a great project.</div>
<div><br>
</div>
<div>This current proposal really has nothing to do with&nbsp;SegWit - but =
it is an update that will make the network a little better for the future, =
and we hope you enjoy the paper.&nbsp;</div>
<div><br>
</div>
<div>PDF:<br>
<a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/=
master/Floating-Point%20Nakamoto%20Consensus.pdf" target=3D"_blank">https:/=
/github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floating-Po=
int%20Nakamoto%20Consensus.pdf</a></div>
<div>&nbsp;</div>
<div>Pull Request:<br>
<span id=3D"x_gmail-m_2766209350405513116gmail-docs-internal-guid-e08d4203-=
7fff-1140-7022-8ecfe80e9fea"><a href=3D"https://github.com/bitcoin/bitcoin/=
pull/19665/files" target=3D"_blank" style=3D"text-decoration-line:none"><sp=
an style=3D"font-size:11pt; font-family:Arial; background-color:transparent=
; font-variant-numeric:normal; font-variant-east-asian:normal; text-decorat=
ion-line:underline; vertical-align:baseline; white-space:pre-wrap">https://=
github.com/bitcoin/bitcoin/pull/19665/files</span></a></span>&nbsp;&nbsp;<b=
r>
</div>
<div><br>
</div>
<div>---</div>
<div><br>
</div>
<div><span id=3D"x_gmail-m_2766209350405513116gmail-docs-internal-guid-77a2=
432b-7fff-62c3-0753-fe93652ca512"><br>
<p dir=3D"ltr" style=3D"line-height:1.38; text-align:center; margin-top:0pt=
; margin-bottom:0pt">
<span style=3D"font-size:14pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">Floating-Point Naka=
moto Consensus</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:9pt; font-family:Arial; color:rgb(0,0,0); backgrou=
nd-color:transparent; font-weight:700; font-variant-numeric:normal; font-va=
riant-east-asian:normal; vertical-align:baseline; white-space:pre-wrap">Abs=
tract =97
</span><span style=3D"font-size:9pt; font-family:Arial; color:rgb(0,0,0); b=
ackground-color:transparent; font-variant-numeric:normal; font-variant-east=
-asian:normal; vertical-align:baseline; white-space:pre-wrap">It has been s=
hown that Nakamoto Consensus is very
 useful in the formation of long-term global agreement =97 and has issues w=
ith short-term disagreement which can lead to re-organization (=93or-org=94=
) of the blockchain.&nbsp; A malicious miner with knowledge of a specific k=
ind of denial-of-service (DoS) vulnerability
 can gain an unfair advantage in the current Bitcoin network, and can be us=
ed to undermine the security guarantees that developers rely upon.&nbsp; Fl=
oating-Point Nakamoto consensu makes it more expensive to replace an alread=
y mined block vs. creation of a new block,
 and by resolving ambiguity of competition solutions it helps achieve globa=
l consumers more quickly.&nbsp; A floating-point fitness test strongly ince=
ntivises the correct network behavior, and prevents disagreement from ever =
forming in the first place.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Introduction</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 Bitcoin protocol was created to provide a decentralized consensus on a ful=
ly distributed p2p network.&nbsp; A problem arises when more than one proof=
-of-work is presented as the next solution block in the blockchain.&nbsp; T=
wo 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 =93eclipsing=94 attack.&nbsp; When tw=
o segments of the network disagree it creates a moment of weakness in which=
 less than 51% of the network=92s computational resources are required to k=
eep the network balanced against itself.&nbsp;</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Nakamoto
 Consensus</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Nakamoto
 Consensus is the process of proving computational resources in order to de=
termine eligibility to participate in the decision making process.&nbsp; If=
 the outcome of an election were based on one node (or one-IP-address-one-v=
ote), then representation could be subverted
 by anyone able to allocate many IPs. A consensus is only formed when the p=
revailing decision has the greatest proof-of-work effort invested in it. In=
 order for a Nakamoto Consensus to operate, the network must ensure that in=
centives are aligned such that the
 resources needed to subvert a proof-of-work based consensus outweigh the r=
esources gained through its exploitation. In this consensus model, the proo=
f-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 hones=
t and transparent, which is a substantial barrier for a single dishonest no=
de to overcome.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">A
 minimal network peer-to-peer structure is required to support Nakamoto Con=
esus, and for our purposes this is entirely decentralized. Messages are bro=
adcast on a best-effort basis, and nodes can leave and rejoin the network a=
t will, accepting the longest proof-of-work
 chain as proof of what happened while they were gone.&nbsp; This design ma=
kes no guarantees that the peers connected do not misrepresent the network =
or so called =93dishonest nodes.=94 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 pee=
r is able to make contact an honest node.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Security&nbsp;</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 this threat model let us assume a malicious miner possesses knowledge of a=
n unpatched DoS vulnerability (=930-day=94) which will strictly prevent hon=
est nodes from communicating to new members of the network - a so-called =
=93total eclipse.=94&nbsp; The kind of DoS vulnerability
 needed to conduct an eclipse does not need to consume all CPU or computait=
ly ability of target nodes - but rather prevent target nodes from forming n=
ew connections that would undermine the eclipsing effect. These kinds of Do=
S vulnerabilities are somewhat less
 substional than actually knocking a powerful-mining node offline.&nbsp; Th=
is class of attacks are valuable to an adversary because in order for an ho=
nest node to prove that a dishonest node is lying - they would need to form=
 a connection to a segment of the network
 that isn=92t entirely suppressed. Let us assume a defense-in-depth strateg=
y and plan on this kind of failure.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Let
 us now consider that the C++ Bitcoind has a finite number of worker thread=
s and a finite number of connections that can be serviced by these workers.=
&nbsp; When a rude client occupies all connections - then a pidgin-hole pri=
nciple comes into play. If a network's
 maximum capacity for connection handlers =91k=92, is the sum of all availa=
ble worker threads for all nodes in the network, establishing =91k+1=92 con=
nections 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 on=
ly be able to form connections with dishonest nodes.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let=92s 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 competit=
ive-solution to split the network in two sides that disagree about which ti=
p of the chain to use.&nbsp; 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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">At
 this point an attacker can expedite the transmission of one solution, whil=
e 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
 =BD as possible. If the network eclipse is perfect then an adversary can l=
everage 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. &nbsp; As long as two sides of the network are perfectly in disagr=
eement 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=92s transactions have been validated on the honest chain - at wh=
ich point the attacker will add more nodes to the dishonest chain to make s=
ure it is the ultimate winner - thus
 replacing out the honest chain with the one generated by dishonest miners.=
</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">This
 attack is convenient from the adversary=92s perspective,&nbsp; Bitcoin bei=
ng a broadcast network advertises the IP addresses of all active nodes - an=
d Shodan and the internet scanning project can find all passive nodes respo=
nding on TCP 8333.&nbsp; This should illuminate
 all honest nodes on the network, and even honest nodes that are trying to =
obscure themselves by not announcing their presence.&nbsp; This means that =
the attacker doesn=92t need to know exactly which node is used by a targete=
d 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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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 a=
dversary will then broadcast currency deposits to public exchanges, but onl=
y on the weaker side, leaving the
 stronger side with no transaction from the adversary. Any exchange that co=
nfirms 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 t=
hat 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 Eth=
ereum network which would be unaffected
 by this attack.&nbsp; When the weaker chain collapses, the transaction tha=
t the exchange acted upon is no longer codified in Bitcoin blockchain's glo=
bal ledger, and will be replaced with a version of the that did not contain=
 these deposits.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Nakamoto
 Consensus holds no guarantees that it=92s process is deterministic.&nbsp; =
In the short term, we can observe that the Nakamoto Consensus is empiricall=
y non-deterministic which is evident by re-organizations (re-org) as a meth=
od of resolving disagreements within the
 network. &nbsp; During a reorganization a blockchain network is at its wea=
kest point, and a 51% attack to take the network becomes unnecessary. An ad=
versary 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 betw=
een miners.&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">DeFi
 (Decentralized Finance) and smart-contract obligations depend on network s=
tability and determinism.&nbsp; Failure to pay contracts, such as what happ=
ened on =93black thursday=94 resulted in secured loans accidentally falling=
 into redemption.&nbsp; The transactions used
 by a smart contract are intended to be completed quickly and the outcome i=
s irreversible.&nbsp; However, if the blockchain network has split then a c=
ontract may fire and have it=92s side-effects execute only to have the tran=
saction on the ledger to be replaced.&nbsp;
 Another example is that a hard-fork might cause the payer of a smart contr=
act to default - as the transaction that they broadcasted ended up being on=
 the weaker chain that lost. Some smart contracts, such as collateral backe=
d loans have a redemption clause
 which would force the borrower on the loan to lose their deposit entirely.=
&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">With
 two sides of the network balanced against each other - an attacker has spl=
it the blockchain and this hard-fork can last for as long as the attacker i=
s able to exert the computational power to ensure that proof-of-work blocks=
 are regularly found on both sides
 of the network.&nbsp; The amount of resources needed to balance the networ=
k against itself is far less than a 51% attack - thereby undermining the se=
curity guarantees needed for a decentralized untrusted payment network to f=
unction.&nbsp; An adversary with a sufficiently
 large network of dishonest bots could use this to take a tally of which mi=
ners are participating in which side of the network split. This will create=
 an attacker-controlled hard fork of the network with two mutually exclusiv=
e 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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 Satoshi Nakamoto=92s original paper it was stated that the electorate shou=
ld be represented by computational effort in the form of a proof-of-work, a=
nd only these nodes can participate in the consues process.&nbsp; However, =
the electorate can be misled by non-voting
 nodes which can reshape the network to benefit an individual adversary.</s=
pan></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Chain
 Fitness</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 solution to byzantine fault-injection or the intentional formation of disa=
greements must be fully decentralized. A blockchain is allowed to split bec=
ause there is ambiguity in the Nakamoto proof-of-work, which creates the en=
vironment for a race-condition to
 form. To resolve this, Floating-Point Nakamoto Consensus makes it increasi=
ngly more expensive to replace the current winning block. This added cost c=
omes from a method of disagreement resolution where not every solution bloc=
k 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-r=
ace, whereby the winning team=92s strength is carried forward and the loser=
 will have to work harder and harder
 to maintain the disagreement.&nbsp; In most cases Floating-Point Nakamoto =
Consensus will prevent a re-org blockchain from ever going past a single bl=
ock thereby expediting the formation of a global consensus.&nbsp; 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 the=
y arrive.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 first step in Floating-Point Nakamoto Consensus is that all nodes in the n=
etwork should continue to conduct traditional Nakamoto Consensus and the fo=
rmation of new blocks is dictated by the same zero-prefix proof-of-work req=
uirements.&nbsp; If at any point there
 are two solution blocks advertised for the same height - then a floating-p=
oint fitness value is calculated and the solution with the higher fitness v=
alue 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 o=
f a block that would be discarded.&nbsp; To make sure that incentives are a=
ligned, any zero-prefix proof of work
 could be the next solution, but now in order to replace the current winnin=
g solution an adversary would need a zero-prefix block that is also more fi=
t that the current solution - which is much more computationally expensive =
to produce.</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 changes to the current tip of the blockchain must be avoided as much as po=
ssible. 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.&nbsp; 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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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 unive=
rsally and identically verifiable by all nodes on the network.&nbsp; Additi=
onally, this fitness-test evaluation
 needs to ensure that no two competing solutions can be numerically equival=
ent.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Let
 us suppose that two or more valid solutions will be proposed for the same =
block.&nbsp; To weigh the value of a given solution, let's consider a solut=
ion for block 639254, in which the following hash was proposed:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8</sp=
an></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">There
 are 19 zeros, and the remaining hash in base 16 starts with 9e3 and ends w=
ith f8.&nbsp; This can value can be represented in floating point as:</span=
></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;19.847052573336114130069196154809453027792121882588614904</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">To
 simplify further lets give this block a single whole number to represent o=
ne complete solution, and use a rounded floating-point value to represent s=
ome fraction of additional work exerted by the miner.&nbsp;</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;1.847</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2</sp=
an></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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.&nbsp; With=
 Nakamoto Consensus both of these solutions would be equivalent and a given=
 node would adopt the one that it received
 first.&nbsp; In Floating-Post Nakamoto Consensus, we compare the fitness s=
cores and keep the highest.&nbsp; In this case no matter what happens - som=
e nodes will have to change their tip and a fitness test makes sure this ha=
ppens immediately.&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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=
=92t need to validate any lower-valued solution.&nbsp; In fact this fitness=
 value has a high degree of confidence
 that it won=92t be unseated by a larger value - being able to produce a pr=
oof-of-work with 19 0=92s and a decimal component greater than 0.847 is non=
-trivial.&nbsp; 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.&nbs=
p;</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">All
 nodes are incentivized to support the solution with the highest fitness va=
lue - irregardless of which order these proof-of-work were validated. Miner=
s are incentivized to support the dominant chain which helps preserve the g=
lobal consensus.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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 t=
he outcome of the non-zero component of their proof-of-work.&nbsp; Addition=
ally if we assume an ideal cipher then
 the fitness of all possible solutions is gaussian-random. With these assum=
ptions then on average a new solution would split the keyspace of remaining=
 solutions in half.&nbsp; Given that the work needed to form a&nbsp; new bl=
ock 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 s=
olution.&nbsp; 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=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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. &nbsp; 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.&nbsp; With inductive reasoning, we can see that a demiss=
iniong keyspace increases the amount
 of work needed to find a solution that also meets this new criteria.</span=
></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let us assume a heavily-fragmented network where some nodes have gotten on=
e or both of the solutions.&nbsp; In the case of nodes that received the pr=
oof-of-work solution with a fitness of 1.847, they will be happily mining o=
n 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.&nbsp; However, we must as=
sume some parts of the network never got the message about 1.847 proof of w=
ork, and instead continued to mine using
 a value of 1.240 as the previous block. &nbsp; Now, let=92s say this group=
 of isolated miners manages to present a new conflicting proof-of-work solu=
tion for 639255:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091=
a6</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 above base16 block has a fitness score of 1.532&nbsp; The fitness value fo=
r the previous block 639254 is added together:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;2.772
 =3D 1.240 + 1.532</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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.&nbsp; 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=
.&nbsp; This is also important for transactions on the network as they bene=
fit from using the most recently formed block - which will have the highest=
 local fitness score at the time of its
 discovery.&nbsp; At this junction, the weaker branch has an opportunity to=
 prevail enterally thus ending the split.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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 gr=
oup and the dominant group have produced competing proof-of-work solutions =
for blocks 639254 and 639255 respectively.&nbsp;
 Let=92s assume that the dominant group that went with the 1.847 fitness sc=
ore - also produces a solution with a similar fitness value and advertises =
the following solution to the network:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">0000000000000000000=
455207e375bf1dac0d483a7442239f1ef2c70d050c113</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">19.4149736494645748=
77549198290879237036867705594421756179</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">or</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">3.262 =3D 1.847 + 1=
.415</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">A
 total of 3.262 is still dominant over the lesser 2.772 - in order to overc=
ome this - the 2nd winning block needs to make up for all of the losses in =
the previous block.&nbsp; In this scenario, in order for the weaker chain t=
o supplant the dominant chain it must
 overcome a -0.49 point deficit. In traditional Nakamoto Consensus the node=
s would see both forks as authoritative equals which creates a divide in mi=
ning capacity while two groups of miners search for the next block.&nbsp; I=
n Floating-Point Nakamoto Consensus any
 nodes receiving both forks, would prefer to mine on the chain with an over=
all 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 mine=
rs following the same same system of rules will insure a self-fulfilled out=
come.&nbsp; After all nodes adopt the dominant chain normal Nakamoto Consue=
ss 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 ambiguit=
y and de-incentivise dissent.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Soft
 Fork</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Blockchain
 networks that would like to improve the consensus generation method by add=
ing a fitness test should be able to do so using a =93Soft Fork=94 otherwis=
e known as a compatible software update.&nbsp; By contrast a =93Hard-Fork=
=94 is a separate incompatible network that does
 not form the same consensus.&nbsp; Floating-Point Nakamoto Consensus can b=
e implemented as a soft-fork because both patched, and non-patched nodes ca=
n co-exist and non-patched nodes will benefit from a kind of herd immunity =
in overall network stability.&nbsp; This is
 because once a small number of nodes start following the same rules then t=
hey will become the deciding factor in which chain is chosen.&nbsp; Clients=
 that are using only traditional Nakamoto Consensus will still agree with n=
ew 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=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Conclusion</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an: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 becom=
e an essential utility, and attacks against our networks must be avoided an=
d adapting, patching and protecting
 the network is a constant effort. An organized attack against a cryptocurr=
ency network will undermine the guarantees that blockchain developers are d=
epending on.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 blockchain using Nakamoto Consensus can be modified to use a fitness const=
raint such as the one used by a Floating-Point Nakamoto Consensus.&nbsp; An=
 example implementation has been written and submitted as a PR to the bitco=
in core which is free to be adapted by
 other networks.</span></p>
<br>
<br>
<br>
<br>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">A complete implemen=
tation of Floating-Point Nakamoto
 consensus is in the following pull request:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://github.com/bitcoin/bitcoin/pull/19665/files" target=3D"_=
blank" style=3D"text-decoration-line:none"><span style=3D"font-size:11pt; f=
ont-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/pu=
ll/19665/files</span></a></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">Paper:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Consensus" targ=
et=3D"_blank" style=3D"text-decoration-line:none"><span style=3D"font-size:=
11pt; font-family:Arial; background-color:transparent; font-variant-numeric=
:normal; font-variant-east-asian:normal; text-decoration-line:underline; ve=
rtical-align:baseline; white-space:pre-wrap">https://github.com/in-st/Float=
ing-Point-Nakamoto-Consensus</span></a></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://in.st.capital/" target=3D"_blank" style=3D"text-decorati=
on-line:none"><span style=3D"font-size:11pt; font-family:Arial; background-=
color:transparent; font-variant-numeric:normal; font-variant-east-asian:nor=
mal; text-decoration-line:underline; vertical-align:baseline; white-space:p=
re-wrap">https://in.st.capital</span></a></p>
<div class=3D"x_gmail-yj6qo"></div>
<br class=3D"x_gmail-Apple-interchange-newline">
</span></div>
</div>
</div>
</div>
</body>
</html>

--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_--