path: root/d8/bfc017c8ee7d4dc92103499d62360ab0e3ba6d

Return-Path: <m@ib.tc>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3A947C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 16:04:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 294DB86D08
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 16:04:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TXICpL7RCduP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 16:04:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com
 [209.85.221.41])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id D0EC086CF6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 16:04:32 +0000 (UTC)
Received: by mail-wr1-f41.google.com with SMTP id x14so4123260wrl.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 09:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=GebpYleRTUW4OLr1qOd9n6Kjo3C9yW1MCbUfzsXvD/g=;
 b=abG/XOk0e6AxnIr5qOxElH1OWUx10L2ewiBnloGYcGD8tZrkvwtmdEFVP2e0Oq2MVn
 EG8WNb7j4p9kUNnUeFdVexAzdOuMZrnatqiXxjqIJo37OMjCo6HTZZe2PQrnz7QsDl8d
 wYLuGcH3hEXVU4597B/N51wRU0LkVW9jbPd+oyriZVpiP5ZGvpmYYNnE8hnxflistiHd
 Fg9OuTD6S4xjMNzuNASihU6uwWv+/fdf/EJHzANM70LG7OiC2g9jLciJ6o2ZE8Icnj54
 P07BbpQ8KC7+rvd+1vgd69pJ9mstbdTnEVxrg6Vp9jafJGbhDut1y3LRd/Uft1ZuoRvD
 /F5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=GebpYleRTUW4OLr1qOd9n6Kjo3C9yW1MCbUfzsXvD/g=;
 b=tLIQIGqB/A5lBngQ3HkIBUCc3AR5vEcXR2pBqV+xgEVuaLASQCIB5pN9uexeWU+yx7
 EotU1XAwsxHDVVHkzGQqXYj0cFpo0yzGU/c1OJi97j87l98fdHnkxcHVaF9AUVmrGNPG
 KnK3/HWPrIBGG/ui2hwaRqoER8Ns6mjgpWEKvKCdlPwjn1Tj0VrOWQ3brfxG+1dQf90y
 lDG4vvHqNSqr5shK8UNviTfYBdctJsvHbm1AZXH+hJHVx5IJxCL+C6/DIv3JkKCeQXE9
 q2hNUwZYVLHUYSvIO7D2QWV7XngFv5YGf3sMjyyceFDK6fEeUQjdvQ8IlFvqD7ujX4Jl
 HY/g==
X-Gm-Message-State: AOAM53237HTdsbWOZq1ShW0CEsmc5UFCvIhPUT4OxAFs/luAqWgOmGil
 U8K7wUa5at+QLSgVjo2DTjPeD93ZLT39ohNraCNWAw==
X-Google-Smtp-Source: ABdhPJxhmLw5mxtUeifpseMn93OG0a8vnZahPErFeZzdscLkg+FW+aVXgfa0IA+xbNVO4oLd9uwH1kiso0yyi/RzQNk=
X-Received: by 2002:adf:f5ce:: with SMTP id k14mr5141420wrp.286.1601049869941; 
 Fri, 25 Sep 2020 09:04:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
In-Reply-To: <dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
From: Mike Brooks <m@ib.tc>
Date: Fri, 25 Sep 2020 09:04:11 -0700
Message-ID: <CALFqKjQoe6HGpLe3TSt+XvaiUKS6M3MyAYg=SWUu1Kd9+Mcr4g@mail.gmail.com>
To: bitcoin ml <bitcoin.ml@thomaskerin.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c417c605b025786b"
X-Mailman-Approved-At: Fri, 25 Sep 2020 17:52:18 +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: Fri, 25 Sep 2020 16:04:37 -0000

--000000000000c417c605b025786b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Thomas,

A fitness value is only additive for the length of the disagreement, and
only used to solve disagreements of the same height.  This isn't as large
of a departure as you are expecting.  For 50,000 blocks of agreement, then
no floating point value is calculated.

All the best,
Mike

On Fri, Sep 25, 2020 at 8:57 AM bitcoin ml via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> This is a pretty big departure from cumulative POW.
>
> Could you explain to me what you see happening if a node with this patch
> and no history starts to sync, and some random node gives it a block with=
 a
> better fitness test for say height 250,000? No other solution will have a
> better fitness test at that height, so from my understanding its going to
> stop syncing. How about even later - say this proposal is activated at
> block 750,000. At 850,000, someone decides it'd be fun to publish a new
> block 800,000 with a better fitness test. What happens the 50,000 blocks?
>
> I can imagine the miners not being particularly happy about it - their
> previously 50:50 chance (well, sort of, it's based on resources-
> connectivity, validation overheads, etc) their tied block would succeed, =
vs
> the situation with this change - blocks that are inherently more or less
> valid than others.
>
> I think these days people are more focused on improving defences at the
> networking layer than in the consensus layer - especially when it affects
> mining incentives. I don't see how people will take this seriously -
> especially when you regard how often consensus changes are made to _fix_
> something as opposed to add something new.
>
> Best regards,
>
> Thomas
> On 9/24/20 8:40 PM, Mike Brooks via bitcoin-dev wrote:
>
>   Hey Everyone,
>
>  A lot of work has gone into this paper, and the current revision has bee=
n
> 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 bette=
r
> 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 ti=
me
> 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 respon=
d
> to new threats is nothing short of amazing - thank you everyone for a gre=
at
> project.
>
> This current proposal really has nothing to do with SegWit - but it is an
> update that will make the network a little better for the future, and we
> hope you enjoy the paper.
>
> PDF:
>
> https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Fl=
oating-Point%20Nakamoto%20Consensus.pdf
>
> Pull Request:
> https://github.com/bitcoin/bitcoin/pull/19665/files
>
> ---
>
>
> Floating-Point Nakamoto Consensus
>
> Abstract =E2=80=94 It has been shown that Nakamoto Consensus is very usef=
ul in
> the formation of long-term global agreement =E2=80=94 and has issues with
> short-term disagreement which can lead to re-organization (=E2=80=9Cor-or=
g=E2=80=9D) 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.
> 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-of-work is presented as the next solution block in the blockchain.
> Two solutions of the same height are seen as authoritative equals which i=
s
> 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 byzentie=
ne
> fault injection commonly referred to as an =E2=80=9Ceclipsing=E2=80=9D at=
tack.  When two
> segments of the network disagree it creates a moment of weakness in which
> less than 51% of the network=E2=80=99s computational resources are requir=
ed to keep
> the network balanced against itself.
> Nakamoto Consensus
>
> 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 anyon=
e
> 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 f=
or
> a Nakamoto Consensus to operate, the network must ensure that incentives
> are aligned such that the resources needed to subvert a proof-of-work bas=
ed
> 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 t=
o
> overcome.
>
> A minimal network peer-to-peer structure is required to support Nakamoto
> Conesus, and for our purposes this is entirely decentralized. Messages ar=
e
> 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 wh=
at
> happened while they were gone.  This design makes no guarantees that the
> peers connected do not misrepresent the network or so called =E2=80=9Cdis=
honest
> nodes.=E2=80=9D Without a central authority or central view - all peers d=
epend on
> the data provided by neighboring peers - therefore a dishonest node can
> continue until 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 (=E2=80=9C0-day=E2=80=9D) which will st=
rictly prevent
> honest nodes from communicating to new members of the network - a so-call=
ed
> =E2=80=9Ctotal eclipse.=E2=80=9D  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 nod=
e
> 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=E2=
=80=99t
> entirely suppressed. Let us assume a defense-in-depth strategy and plan o=
n
> this kind of failure.
>
> 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-hol=
e
> principle comes into play. If a network's maximum capacity for connection
> handlers =E2=80=98k=E2=80=99, is the sum of all available worker threads =
for all nodes in
> the network, establishing =E2=80=98k+1=E2=80=99 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.
>
> Now let=E2=80=99s assume a dishonest node is modified in two ways - it in=
creases
> 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 o=
f
> 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 tha=
t
> are being used to pass messages for honest nodes.
>
> At this point an attacker can expedite the transmission of one solution,
> while slowing another. If ever a competing proof-of-work is broadcasted t=
o
> the network, the adversary will use their network influence to split
> knowledge of the proof-of-work as close to =C2=BD as possible. If the net=
work
> eclipse is perfect then an adversary can leverage an eigen-vector of
> computational effort to keep the disagreement in balance for as long as i=
t
> 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 intentionall=
y
> created a hard-fork against the will of the network architects and
> operators. The disagreement needs to be kept open until the adversary=E2=
=80=99s
> 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 th=
e
> ultimate winner - thus replacing out the honest chain with the one
> generated by dishonest miners.
>
> This attack is convenient from the adversary=E2=80=99s perspective,  Bitc=
oin 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 n=
ot
> announcing their presence.  This means that the attacker doesn=E2=80=99t =
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.
>
> 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 publi=
c
> 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 ou=
t
> the account balance on a different blockchain - such as Tether which is a=
n
> erc20 token on the Ethereum network which would be unaffected by this
> attack.  When the weaker chain collapses, the transaction that the exchan=
ge
> acted upon is no longer codified in Bitcoin blockchain's global ledger, a=
nd
> will be replaced with a version of the that did not contain these deposit=
s.
>
> Nakamoto Consensus holds no guarantees that it=E2=80=99s 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 t=
he
> 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.
>
> DeFi (Decentralized Finance) and smart-contract obligations depend on
> network stability and determinism.  Failure to pay contracts, such as wha=
t
> happened on =E2=80=9Cblack thursday=E2=80=9D resulted in secured loans ac=
cidentally 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=E2=80=
=99s
> 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 ende=
d
> 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.
>
> 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.  T=
he
> amount of resources needed to balance the network against itself is far
> less than a 51% attack - thereby undermining the security guarantees need=
ed
> for a decentralized untrusted payment network to function.  An adversary
> with a sufficiently large network of dishonest bots could use this to tak=
e
> 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.
>
> In Satoshi Nakamoto=E2=80=99s original paper it was stated that the elect=
orate
> 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.
> Chain Fitness
>
> Any solution to byzantine fault-injection or the intentional formation of
> disagreements must be fully decentralized. A blockchain is allowed to spl=
it
> because there is ambiguity in the Nakamoto proof-of-work, which creates t=
he
> 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 disagreemen=
t
> resolution where not every solution block is the same value, and a more-f=
it
> solution is always chosen over a weaker solution. Any adversary attemptin=
g
> to have a weaker chain to win out would have to overcome a kind of
> relay-race, whereby the winning team=E2=80=99s strength is carried forwar=
d 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 cemen=
ts
> the lead of the winner and to greatly incentivize the network to adopt th=
e
> dominant chain no matter how many valid solutions are advertised, or what
> order they arrive.
>
> 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 block=
s
> 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 a=
n
> adversary would need a zero-prefix block that is also more fit that the
> current solution - which is much more computationally expensive to produc=
e.
>
> 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 th=
at
> consensus is maintained.
>
> 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.
>
> 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:
>
>     00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8
>
> 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:
>
>     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 t=
o
> represent some fraction of additional work exerted by the miner.
>
>    1.847
>
> Now let us suppose that a few minutes later another solution is advertise=
d
> to the network shown in base16 below:
>
>     000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2
>
> 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.  Wit=
h
> Nakamoto Consensus both of these solutions would be equivalent and a give=
n
> node would adopt the one that it received first.  In Floating-Post Nakamo=
to
> 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 an=
d
> a fitness test makes sure this happens immediately.
>
> With both solutions circulating in the network - any node who has receive=
d
> both proof-of-works should know 1.847 is the current highest value, and
> shouldn=E2=80=99t need to validate any lower-valued solution.  In fact th=
is fitness
> value has a high degree of confidence that it won=E2=80=99t be unseated b=
y a larger
> value - being able to produce a proof-of-work with 19 0=E2=80=99s and a d=
ecimal
> 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. Miners are incentivized to support the dominant chain which
> helps preserve the global consensus.
>
> Let us assume that the underlying cryptographic hash-function used to
> generate a proof-of-work is an ideal primitive, and therefore a node cann=
ot
> 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 possibl=
e
> solutions is gaussian-random. With these assumptions then on average a ne=
w
> 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 conducti=
ng
> Floating-Point Nakamoto Consensus a malicious miner would have to expend
> significantly more resources.
>
> 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.
>
> 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=E2=80=99s say this group of isolated miners manages to present a new
> conflicting proof-of-work solution for 639255:
>
>      000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6
>
> The above base16 block has a fitness score of 1.532  The fitness value fo=
r
> 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
> 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.
>
> 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 th=
e
> weaker group and the dominant group have produced competing proof-of-work
> solutions for blocks 639254 and 639255 respectively.  Let=E2=80=99s assum=
e 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 soluti=
on
> 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
> 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 t=
wo
> groups of miners search for the next block.  In Floating-Point Nakamoto
> Consensus any nodes receiving both forks, would prefer to mine on the cha=
in
> 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, thereb=
y
> eroding support for the weaker chain. This kind of comparison requires an
> empirical method for determining fitness by miners following the same sam=
e
> system of rules will insure a self-fulfilled outcome.  After all nodes
> adopt the dominant chain normal Nakamoto Consuess can resume without havi=
ng
> 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.
> Soft Fork
>
> Blockchain networks that would like to improve the consensus generation
> method by adding a fitness test should be able to do so using a =E2=80=9C=
Soft Fork=E2=80=9D
> otherwise known as a compatible software update.  By contrast a =E2=80=9C=
Hard-Fork=E2=80=9D
> is a separate incompatible network that does not form the same consensus.
> Floating-Point Nakamoto Consensus can be implemented as a soft-fork becau=
se
> both patched, and non-patched nodes can co-exist and non-patched nodes wi=
ll
> 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 strate=
gy
> early, will be less likely to lose out on mining invalid solutions.
> Conclusion
>
> Floating-Point Nakamoto consensus allows the network to form a consensus
> more quickly by avoiding ambiguity allowing for determinism to take hold.
> Bitcoin has become an essential utility, and attacks against our networks
> must be avoided and adapting, patching and protecting the network is a
> constant effort. An organized attack against a cryptocurrency network wil=
l
> undermine the guarantees that blockchain developers are depending on.
>
> Any blockchain using Nakamoto Consensus can be modified to use a fitness
> constraint such as the one used by a Floating-Point Nakamoto Consensus.  =
An
> example implementation has been written and submitted as a PR to the
> bitcoin core which is free to be adapted by other networks.
>
>
>
>
>
> A complete implementation of Floating-Point Nakamoto consensus is in the
> following pull request:
>
> https://github.com/bitcoin/bitcoin/pull/19665/files
>
> Paper:
>
> https://github.com/in-st/Floating-Point-Nakamoto-Consensus
>
> https://in.st.capital
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000c417c605b025786b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Thomas,<div><br></div><div>A fitness value is only add=
itive for the length of the disagreement, and only used to solve disagreeme=
nts of the same height.=C2=A0 This isn&#39;t as large of a departure as you=
 are expecting.=C2=A0 For 50,000 blocks of agreement, then no floating poin=
t value is calculated.=C2=A0</div><div><br></div><div>All the best,</div><d=
iv>Mike</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, Sep 25, 2020 at 8:57 AM bitcoin ml via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <p>Hi,</p>
    <p>This is a pretty big departure from cumulative POW.<br>
    </p>
    <p>Could you explain to me what you see happening if a node with
      this patch and no history starts to sync, and some random node
      gives it a block with a better fitness test for say height
      250,000? No other solution will have a better fitness test at that
      height, so from my understanding its going to stop syncing. How
      about even later - say this proposal is activated at block
      750,000. At 850,000, someone decides it&#39;d be fun to publish a new
      block 800,000 with a better fitness test. What happens the 50,000
      blocks?<br>
    </p>
    <p>I can imagine the miners not being particularly happy about it -
      their previously 50:50 chance (well, sort of, it&#39;s based on
      resources- connectivity, validation overheads, etc) their tied
      block would succeed, vs the situation with this change - blocks
      that are inherently more or less valid than others.<br>
    </p>
    <p>I think these days people are more focused on improving defences
      at the networking layer than in the consensus layer - especially
      when it affects mining incentives. I don&#39;t see how people will
      take this seriously - especially when you regard how often
      consensus changes are made to _fix_ something as opposed to add
      something new. <br>
    </p>
    <p>Best regards,</p>
    <p>Thomas<br>
    </p>
    <div>On 9/24/20 8:40 PM, Mike Brooks via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">=C2=A0 Hey Everyone,
        <div><br>
        </div>
        <div>=C2=A0A 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=C2=A0be sharing it with you today. The=
re
          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.=C2=A0 It is wildly underrated that future proofing was
          never really a consideration=C2=A0in the initial=C2=A0design - bu=
t here
          we are a decade later with amazing solutions like SegWit
          which=C2=A0gives us a real future-proofing framework.=C2=A0 The f=
act
          that future-proofing was added to Bitcoin with a softfork
          gives me goosebumps.=C2=A0I&#39;d just like to take the time to t=
hank
          the people who worked on SegWit and it is an appreciation=C2=A0th=
at
          comes up in conversation of how difficult and necessary that
          process was,=C2=A0and this appreciation may not be vocalized to t=
he
          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=C2=A0SegWi=
t
          - but it is an update that will make the network a little
          better for the future, and we hope you enjoy the paper.=C2=A0</di=
v>
        <div><br>
        </div>
        <div>PDF:<br>
          <a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Conse=
nsus/blob/master/Floating-Point%20Nakamoto%20Consensus.pdf" target=3D"_blan=
k">https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/F=
loating-Point%20Nakamoto%20Consensus.pdf</a></div>
        <div>=C2=A0</div>
        <div>Pull Request:<br>
          <span id=3D"gmail-m_5584359834845366843gmail-m_276620935040551311=
6gmail-docs-internal-guid-e08d4203-7fff-1140-7022-8ecfe80e9fea"><a href=3D"=
https://github.com/bitcoin/bitcoin/pull/19665/files" style=3D"text-decorati=
on-line:none" target=3D"_blank"><span style=3D"font-size:11pt;font-family:A=
rial;background-color:transparent;font-variant-numeric:normal;font-variant-=
east-asian:normal;text-decoration-line:underline;vertical-align:baseline;wh=
ite-space:pre-wrap">https://github.com/bitcoin/bitcoin/pull/19665/files</sp=
an></a></span>=C2=A0=C2=A0<br>
        </div>
        <div><br>
        </div>
        <div>---</div>
        <div><br>
        </div>
        <div><span id=3D"gmail-m_5584359834845366843gmail-m_276620935040551=
3116gmail-docs-internal-guid-77a2432b-7fff-62c3-0753-fe93652ca512"><br>
            <p dir=3D"ltr" style=3D"line-height:1.38;text-align:center;marg=
in-top:0pt;margin-bottom:0pt"><span style=3D"font-size:14pt;font-family:Ari=
al;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:norma=
l;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wr=
ap">Floating-Point Nakamoto Consensus</span></p>
            <br>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"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;whit=
e-space:pre-wrap">Abstract =E2=80=94 </span><span style=3D"font-size:9pt;fo=
nt-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 i=
n the formation of long-term global agreement =E2=80=94 and has issues with=
 short-term disagreement which can lead to re-organization (=E2=80=9Cor-org=
=E2=80=9D) of the blockchain.=C2=A0 A malicious miner with knowledge of a s=
pecific kind of denial-of-service (DoS) vulnerability can gain an unfair ad=
vantage in the current Bitcoin network, and can be used to undermine the se=
curity guarantees that developers rely upon.=C2=A0 Floating-Point Nakamoto =
consensu makes it more expensive to replace an already mined block vs. crea=
tion of a new block, and by resolving ambiguity of competition solutions it=
 helps achieve global consumers more quickly.=C2=A0 A floating-point fitnes=
s test strongly incentivises the correct network behavior, and prevents dis=
agreement from ever forming in the first place.</span></p>
            <h4 dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margi=
n-bottom:4pt"><span style=3D"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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">The Bitcoin pr=
otocol was created to provide a decentralized consensus on a fully distribu=
ted p2p network.=C2=A0 A problem arises when more than one proof-of-work is=
 presented as the next solution block in the blockchain.=C2=A0 Two solution=
s 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 injectio=
n commonly referred to as an =E2=80=9Ceclipsing=E2=80=9D attack.=C2=A0 When=
 two segments of the network disagree it creates a moment of weakness in wh=
ich less than 51% of the network=E2=80=99s computational resources are requ=
ired to keep the network balanced against itself.=C2=A0</span></p>
            <h4 dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margi=
n-bottom:4pt"><span style=3D"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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Nakamoto Conse=
nsus is the process of proving computational resources in order to determin=
e eligibility to participate in the decision making process.=C2=A0 If the o=
utcome 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 p=
roof-of-work effort invested in it. In order for a Nakamoto Consensus to op=
erate, the network must ensure that incentives are aligned such that the re=
sources needed to subvert a proof-of-work based consensus outweigh the reso=
urces gained through its exploitation. In this consensus model, the proof-o=
f-work requirements for the creation of the next valid solution has the exa=
ct same cost as replacing the current solution. There is no penalty for dis=
honesty, and this has worked well in practice because the majority of the n=
odes on the network are honest and transparent, which is a substantial barr=
ier for a single dishonest node 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">A minimal netw=
ork peer-to-peer structure is required to support Nakamoto Conesus, and for=
 our purposes this is entirely decentralized. Messages are broadcast on a b=
est-effort basis, and nodes can leave and rejoin the network at will, accep=
ting the longest proof-of-work chain as proof of what happened while they w=
ere gone.=C2=A0 This design makes no guarantees that the peers connected do=
 not misrepresent the network or so called =E2=80=9Cdishonest nodes.=E2=80=
=9D Without a central authority or central view - all peers depend on the d=
ata 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=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margi=
n-bottom:4pt"><span style=3D"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=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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 (=E2=80=9C0-day=E2=80=9D) which will strictly prevent hon=
est nodes from communicating to new members of the network - a so-called =
=E2=80=9Ctotal eclipse.=E2=80=9D=C2=A0 The kind of DoS vulnerability needed=
 to conduct an eclipse does not need to consume all CPU or computaitly abil=
ity of target nodes - but rather prevent target nodes from forming new conn=
ections that would undermine the eclipsing effect. These kinds of DoS vulne=
rabilities are somewhat less substional than actually knocking a powerful-m=
ining node offline.=C2=A0 This class of attacks are valuable to an adversar=
y because in order for an honest node to prove that a dishonest node is lyi=
ng - they would need to form a connection to a segment of the network that =
isn=E2=80=99t 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Let us now con=
sider that the C++ Bitcoind has a finite number of worker threads and a fin=
ite number of connections that can be serviced by these workers.=C2=A0 When=
 a rude client occupies all connections - then a pidgin-hole principle come=
s into play. If a network&#39;s maximum capacity for connection handlers =
=E2=80=98k=E2=80=99, is the sum of all available worker threads for all nod=
es in the network, establishing =E2=80=98k+1=E2=80=99 connections by the pi=
dgin-hole principle will prevent any new connections from being formed by h=
onest 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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now let=E2=80=
=99s assume a dishonest node is modified in two ways - it increases the max=
imum connection handles to hundreds of thousands instead of the current val=
ue which is about 10. Then this node is modified to ignore any solution blo=
cks 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 si=
des that disagree about which tip of the chain to use.=C2=A0 Any new soluti=
on propagates through nodes one hop at a time. This propagation can be pred=
icted 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">At this point =
an attacker can expedite the transmission of one solution, while slowing an=
other. 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 =C2=BD as possible. If the network eclipse is perfect =
then an adversary can leverage an eigen-vector of computational effort to k=
eep the disagreement in balance for as long as it is needed. No mechanism i=
s stopping the attacker from adding additional computation resources or adj=
usting the eclipsing effect to make sure the system is in balance. =C2=A0 A=
s long as two sides of the network are perfectly in disagreement and genera=
ting new blocks - the attacker has intentionally created a hard-fork agains=
t the will of the network architects and operators. The disagreement needs =
to be kept open until the adversary=E2=80=99s 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.</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">This attack is=
 convenient from the adversary=E2=80=99s perspective,=C2=A0 Bitcoin being a=
 broadcast network advertises the IP addresses of all active nodes - and Sh=
odan and the internet scanning project can find all passive nodes respondin=
g on TCP 8333.=C2=A0 This should illuminate all honest nodes on the network=
, and even honest nodes that are trying to obscure themselves by not announ=
cing their presence.=C2=A0 This means that the attacker doesn=E2=80=99t nee=
d to know exactly which node is used by a targeted exchange - if the attack=
er has subdued all nodes then the targeted exchange must be operating a nod=
e 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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-t=
ree 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 advers=
ary. Any exchange that confirms one of these deposits is relying upon nodes=
 that have been entirely eclipsed so that they cannot see the competing cha=
in - 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 e=
phemeral, the attacker can wire out the account balance on a different bloc=
kchain - such as Tether which is an erc20 token on the Ethereum network whi=
ch would be unaffected by this attack.=C2=A0 When the weaker chain collapse=
s, the transaction that the exchange acted upon is no longer codified in Bi=
tcoin blockchain&#39;s global ledger, and will be replaced with a version o=
f 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Nakamoto Conse=
nsus holds no guarantees that it=E2=80=99s process is deterministic.=C2=A0 =
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. =C2=A0 During a reorganiz=
ation a blockchain network is at its weakest point, and a 51% attack to tak=
e the network becomes unnecessary. An adversary who can eclipse honest host=
s on the network can use this as a means of byzantine fault-injection to di=
srupt the normal flow of messages on the network which creates disagreement=
 between miners.=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">DeFi (Decentra=
lized Finance) and smart-contract obligations depend on network stability a=
nd determinism.=C2=A0 Failure to pay contracts, such as what happened on =
=E2=80=9Cblack thursday=E2=80=9D resulted in secured loans accidentally fal=
ling into redemption.=C2=A0 The transactions used by a smart contract are i=
ntended to be completed quickly and the outcome is irreversible.=C2=A0 Howe=
ver, if the blockchain network has split then a contract may fire and have =
it=E2=80=99s side-effects execute only to have the transaction on the ledge=
r to be replaced.=C2=A0 Another example is that a hard-fork might cause the=
 payer of a smart contract to default - as the transaction that they broadc=
asted ended up being on the weaker chain that lost. Some smart contracts, s=
uch as collateral backed loans have a redemption clause which would force t=
he borrower on the loan to lose their deposit entirely.=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">With two sides=
 of the network balanced against each other - an attacker has split the blo=
ckchain 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 regul=
arly found on both sides of the network.=C2=A0 The amount of resources need=
ed to balance the network against itself is far less than a 51% attack - th=
ereby undermining the security guarantees needed for a decentralized untrus=
ted payment network to function.=C2=A0 An adversary with a sufficiently lar=
ge 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 me=
rkle trees. Whereby the duration of this split is arbitrary, and the decisi=
on in which chain to collapse is up to the individual with the most IP addr=
ess, 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">In Satoshi Nak=
amoto=E2=80=99s original paper it was stated that the electorate should be =
represented by computational effort in the form of a proof-of-work, and onl=
y these nodes can participate in the consues process.=C2=A0 However, the el=
ectorate can be misled by non-voting nodes which can reshape the network to=
 benefit an individual adversary.</span></p>
            <h4 dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margi=
n-bottom:4pt"><span style=3D"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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Any solution t=
o byzantine fault-injection or the intentional formation of disagreements m=
ust be fully decentralized. A blockchain is allowed to split because there =
is ambiguity in the Nakamoto proof-of-work, which creates the environment f=
or a race-condition to form. To resolve this, Floating-Point Nakamoto Conse=
nsus makes it increasingly more expensive to replace the current winning bl=
ock. This added cost comes from a method of disagreement resolution where n=
ot every solution block is the same value, and a more-fit solution is alway=
s 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 w=
inning team=E2=80=99s strength is carried forward and the loser will have t=
o work harder and harder to maintain the disagreement.=C2=A0 In most cases =
Floating-Point Nakamoto Consensus will prevent a re-org blockchain from eve=
r going past a single block thereby expediting the formation of a global co=
nsensus.=C2=A0 Floating-Point Nakamoto Consensus cements the lead of the wi=
nner 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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">The first step=
 in Floating-Point Nakamoto Consensus is that all nodes in the network shou=
ld continue to conduct traditional Nakamoto Consensus and the formation of =
new blocks is dictated by the same zero-prefix proof-of-work requirements.=
=C2=A0 If at any point there are two solution blocks advertised for the sam=
e height - then a floating-point fitness value is calculated and the soluti=
on 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 inevi=
table and it is in the best interest of all miners to adopt the most-fit bl=
ock, failing to do so risks wasting resources on a mining of a block that w=
ould be discarded.=C2=A0 To make sure that incentives are aligned, any zero=
-prefix proof of work could be the next solution, but now in order to repla=
ce 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 compu=
tationally 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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 increas=
ed expense.=C2=A0 If at any point two solutions of the same height are foun=
d it means that eventually some node will have to replace their tip - and i=
t is better to have it done as quickly as possible so that consensus is mai=
ntained.</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">In order to ha=
ve a purely decentralized solution, this kind of agreement must be empirica=
lly derived from the existing proof-of-work so that it is universally and i=
dentically verifiable by all nodes on the network.=C2=A0 Additionally, this=
 fitness-test evaluation needs to ensure that no two competing solutions ca=
n be numerically equivalent.</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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.=C2=
=A0 To weigh the value of a given solution, let&#39;s consider a solution f=
or 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A0=C2=A000000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f=
8</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">There are 19 z=
eros, and the remaining hash in base 16 starts with 9e3 and ends with f8.=
=C2=A0 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A0=C2=A019.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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">To simplify fu=
rther 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.=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A01.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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now let us sup=
pose 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A0=C2=A0000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc=
2</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">The solution a=
bove also has 19 prefixed zeros, and is being broadcast for the same blockh=
eight value of 639254 - and a fitness score of 1.282.=C2=A0 With Nakamoto C=
onsensus both of these solutions would be equivalent and a given node would=
 adopt the one that it received first.=C2=A0 In Floating-Post Nakamoto Cons=
ensus, we compare the fitness scores and keep the highest.=C2=A0 In this ca=
se no matter what happens - some nodes will have to change their tip and a =
fitness test makes sure this happens immediately.=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">With both solu=
tions circulating in the network - any node who has received both proof-of-=
works should know 1.847 is the current highest value, and shouldn=E2=80=99t=
 need to validate any lower-valued solution.=C2=A0 In fact this fitness val=
ue has a high degree of confidence that it won=E2=80=99t be unseated by a l=
arger value - being able to produce a proof-of-work with 19 0=E2=80=99s and=
 a decimal component greater than 0.847 is non-trivial.=C2=A0 As time passe=
s any nodes that received a proof-of-work with a value 1.204 - their view o=
f the network should erode as these nodes adopt the 1.847 version of the bl=
ockchain.=C2=A0</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">All nodes are =
incentivized to support the solution with the highest fitness value - irreg=
ardless of which order these proof-of-work were validated. Miners are incen=
tivized to support the dominant chain which helps preserve the global conse=
nsus.</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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.=C2=A0 Additionally if we =
assume an ideal cipher then the fitness of all possible solutions is gaussi=
an-random. With these assumptions then on average a new solution would spli=
t the keyspace of remaining solutions in half.=C2=A0 Given that the work ne=
eded to form a=C2=A0 new block remains a constant at 19 blocks for this per=
iod - it is cheaper to produce a N+1 block that has any floating point valu=
e as this is guaranteed to be adopted by all nodes if it is the first solut=
ion.=C2=A0 To leverage a chain replacement on nodes conducting Floating-Poi=
nt 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Each successiv=
e n+1 solution variant of the same block-height must therefore on average c=
onsume 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 fitne=
ss test. =C2=A0 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.=C2=A0 With inductive reaso=
ning, 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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now let us ass=
ume a heavily-fragmented network where some nodes have gotten one or both o=
f the solutions.=C2=A0 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 vers=
ion 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.=
=C2=A0 However, we must assume some parts of the network never got the mess=
age about 1.847 proof of work, and instead continued to mine using a value =
of 1.240 as the previous block. =C2=A0 Now, let=E2=80=99s say this group of=
 isolated miners manages to present a new conflicting proof-of-work solutio=
n 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0000000000000000000058d8ebeb076584bb5853c80111bc06b5ada354=
63091a6</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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">The above base=
16 block has a fitness score of 1.532=C2=A0 The fitness value for the previ=
ous 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A02.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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">In this specif=
ic case, no other solution has been broadcast for block height 639255 - put=
ting the weaker branch in the lead.=C2=A0 If the weaker branch is sufficien=
tly lucky, and finds a solution before the dominant branch then this soluti=
on will have a higher overall fitness score, and this solution will propaga=
te as it has the higher value.=C2=A0 This is also important for transaction=
s 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 discov=
ery.=C2=A0 At this junction, the weaker branch has an opportunity to prevai=
l 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Now let us ret=
urn 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.=C2=A0 Let=E2=80=99s assume that the dominan=
t group that went with the 1.847 fitness score - also produces a solution w=
ith a similar fitness value and advertises the following solution to the ne=
twork:</span></p>
            <br>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113</span><=
/p>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">19.414973649464574877549198290879237036867705594421756179</span></p>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">or</span></p>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">A total of 3.2=
62 is still dominant over the lesser 2.772 - in order to overcome this - th=
e 2nd winning block needs to make up for all of the losses in the previous =
block.=C2=A0 In this scenario, in order for the weaker chain to supplant th=
e dominant chain it must overcome a -0.49 point deficit. In traditional Nak=
amoto Consensus the nodes would see both forks as authoritative equals whic=
h creates a divide in mining capacity while two groups of miners search for=
 the next block.=C2=A0 In Floating-Point Nakamoto Consensus any nodes recei=
ving 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 wea=
ker chain. This kind of comparison requires an empirical method for determi=
ning fitness by miners following the same same system of rules will insure =
a self-fulfilled outcome.=C2=A0 After all nodes adopt the dominant chain no=
rmal Nakamoto Consuess can resume without having to take into consideration=
 block fitness. This example shows how disagreement can be resolved more qu=
ickly if the network has a mechanism to resolve ambiguity and de-incentivis=
e dissent.</span></p>
            <h4 dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margi=
n-bottom:4pt"><span style=3D"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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Blockchain net=
works that would like to improve the consensus generation method by adding =
a fitness test should be able to do so using a =E2=80=9CSoft Fork=E2=80=9D =
otherwise known as a compatible software update.=C2=A0 By contrast a =E2=80=
=9CHard-Fork=E2=80=9D is a separate incompatible network that does not form=
 the same consensus.=C2=A0 Floating-Point Nakamoto Consensus can be impleme=
nted as a soft-fork because both patched, and non-patched nodes can co-exis=
t and non-patched nodes will benefit from a kind of herd immunity in overal=
l network stability.=C2=A0 This is because once a small number of nodes sta=
rt following the same rules then they will become the deciding factor in wh=
ich chain is chosen.=C2=A0 Clients that are using only traditional Nakamoto=
 Consensus will still agree with new clients over the total chain length. M=
iners 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;margi=
n-bottom:4pt"><span style=3D"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=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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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 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 or=
ganized attack against a cryptocurrency network will undermine the guarante=
es that blockchain developers are depending 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=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-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.=C2=A0 An example im=
plementation has been written and submitted as a PR to the bitcoin core whi=
ch 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;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">A complete implementation 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;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://github.com/bitcoin/bitcoin/=
pull/19665/files" style=3D"text-decoration-line:none" target=3D"_blank"><sp=
an style=3D"font-size:11pt;font-family:Arial;background-color:transparent;f=
ont-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-l=
ine:underline;vertical-align:baseline;white-space:pre-wrap">https://github.=
com/bitcoin/bitcoin/pull/19665/files</span></a></p>
            <br>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Aria=
l;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wra=
p">Paper:</span></p>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://github.com/in-st/Floating-P=
oint-Nakamoto-Consensus" style=3D"text-decoration-line:none" target=3D"_bla=
nk"><span style=3D"font-size:11pt;font-family:Arial;background-color:transp=
arent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decor=
ation-line:underline;vertical-align:baseline;white-space:pre-wrap">https://=
github.com/in-st/Floating-Point-Nakamoto-Consensus</span></a></p>
            <p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://in.st.capital/" style=3D"te=
xt-decoration-line:none" target=3D"_blank"><span style=3D"font-size:11pt;fo=
nt-family:Arial;background-color:transparent;font-variant-numeric:normal;fo=
nt-variant-east-asian:normal;text-decoration-line:underline;vertical-align:=
baseline;white-space:pre-wrap">https://in.st.capital</span></a></p>
            <br>
          </span></div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
bitcoin-dev mailing list
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a>
</pre>
    </blockquote>
  </div>

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

--000000000000c417c605b025786b--