path: root/c9/e57ca7d57c10003113d54a05329023a329d6ab

Return-Path: <m@ib.tc>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7D284C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Oct 2020 17:42:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 68F328780D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Oct 2020 17:42:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lv0u0L43ISPp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Oct 2020 17:42:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com
 [209.85.128.67])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 8188D87809
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Oct 2020 17:42:05 +0000 (UTC)
Received: by mail-wm1-f67.google.com with SMTP id e23so3596386wme.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 09 Oct 2020 10:42:05 -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
 :cc; bh=tAcZkzYfuQwfvGBrFVVch7FJHKBQRSnvuPOgWmEovJA=;
 b=NqY2XZ6fKtU+vrm13RTsDT61Zf1d67OiWiIHYnZ2TY4/qn5gJx3iwegF5Xx8d/uqxN
 YifzPaxbwzdGUDMU3Rcv3yUJzIS9StinP1s2L1moaUHd3e4jGo0dtsgELoD9+PGjF70F
 21XmbongvXqkeuPJSgWB/1iOCMnr6ioW3LSIUdXbuPUhC/ngLRenKloJC8yJVxq6cMdU
 H+f8gmawRUIr7XFw+e3CZZ0bhaesl9LbsNvq8jN74ka7t5jV4fU2YexSwbayopJE2chJ
 sPpZJqUc1goBT9NhwS1Dtbsze7FeU5NnboQu+hb6+4jx2tjWtTMIJ7iEOv3Ivw2v4pTa
 Svkg==
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:cc;
 bh=tAcZkzYfuQwfvGBrFVVch7FJHKBQRSnvuPOgWmEovJA=;
 b=PpnZkJ6ONrORqm7GBqU9PUBor9btjZGn0HV5d+1iLtJjI30uWe4hF+N9/56prEVRx1
 rYY1NEny5HselMOHc23fcR0aqfu+ZnGUeNdw3ZYq6YrCu/xTu3C0HlzUduFpRFk6qw6o
 lal2TGQOG91wdgqvyu26Qw/l86OS8PbYXlH/wQHpJKndpA8iU2r1Ld4f3vAA5DLgtUOs
 myvx8gd/SZuyrRf7V/a1nZ2qPKcZFgkbS0Vt3Rb2Lm1kzF237ipibmhBRYXJ9wK7l3ce
 1mIqzYkO2iA1cN7qUIS2+rkXZcOz/JYMC//Bovrx372KNDcfr7cvzhOs/01qYCCBdX1R
 q+xQ==
X-Gm-Message-State: AOAM531yJ4Dxr32YeBSIyMsJLnddp5RQ7/vfJkZEw1aBppW2JU3zwszM
 /9C1evFzxhCd5ZJ/Zmdm3eqir0vZE5tQEJcq0ehvzg==
X-Google-Smtp-Source: ABdhPJw88HBLjI4BA/eao5oX8ik5GIoMNznk4+zBv7UPuEtT7JNuCVunmtm2KP2bKtOWGaEwsWFkTrLBsaFEgIanxr8=
X-Received: by 2002:a7b:c305:: with SMTP id k5mr15946190wmj.102.1602265323748; 
 Fri, 09 Oct 2020 10:42:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
From: Mike Brooks <m@ib.tc>
Date: Fri, 9 Oct 2020 18:26:07 -0700
Message-ID: <CALFqKjRn8GM0H=ph0S7i=cm-w1LbjGSwwn1BTP=t2WgcXw2h9g@mail.gmail.com>
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000755f8205b1407710"
X-Mailman-Approved-At: Fri, 09 Oct 2020 17:47:01 +0000
Cc: Mike Brooks <f@in.st.capital>
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, 09 Oct 2020 17:42:10 -0000

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

James,

FPNC and NC will always select the highest-work chain, I am suggesting that
by adding more bits of precision we avoid confusion.

Part 2 -> Using a genetic algorithm that passes fitness with heredity to
resolve disagreements has never been introduced to this mailing list.  This
hard-nack is null and void.

Best Regards,
Michael

On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good Afternoon,
>
> Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
>
> I note that the discussion thread for this proposal has previously
> received HARD_NAK
>
> I note in the whitepaper the following basic introduction of need:
> >As a result anode will simply adopt the first solution seen, creating a
> kind of race condition.
>
> The said race condition, it is not noted, is 'self-resolving' with the
> network adopting the longest chain with the highest proof of work as any
> contentious tip is built on. This is the proper reason for waiting for tw=
o
> confirmations for a transaction as a minimum proof of its inclusion in th=
e
> blockchain (without fraud), and for waiting for six confirmations before
> considering that a transaction is 'final'.
>
> I take it that your work is intended to allow the network to decide
> immediately without waiting for a chain to be further extended, in that
> case, the solution should be as noted elsewhere to accept the higher proo=
f
> of work with the greater precision proof. When comparing two competing
> blocks there is an indirect reference to a higher proof of work due to th=
e
> greater precision in the block hash, although the answer could have been
> arrived with fewer attempts. As it is, the total proof of work is not
> directly calculated but is evaluated as the chain with more blocks being
> the chain with more proof-of-work, whereas in the cases two blocks are
> received as alternates extending the same chain tip there is currently no
> method of comparison to determine which of the blocks, and the correct ti=
p
> is not chosen without further proof-of-work to extend a tip. Resolving th=
is
> reduces the network expense of reorganisation in ordinary conditions but =
in
> the case of a network-split resolves nothing.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> 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 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 list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>James,</div><div><br></div><div>FPNC and NC will alwa=
ys=C2=A0select=C2=A0the highest-work chain, I am suggesting that by adding =
more bits of precision=C2=A0we avoid confusion.</div><div><br></div><div>Pa=
rt 2 -&gt; Using a genetic algorithm that passes fitness with heredity to r=
esolve disagreements has never been introduced to this mailing list.=C2=A0 =
This hard-nack is null and void.</div><div><br></div><div>Best Regards,</di=
v><div>Michael</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES =
HRMH via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div 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;colo=
r:rgb(0,0,0)">Good Afternoon,</span></div>
<div><br>
</div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">Re: [bitcoin-dev] Floating-Point Nakamoto Consensus</spa=
n></div>
<div><br>
</div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">I note that the discussion thread for this proposal
</span><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12=
pt;color:rgb(0,0,0)">has previously received HARD_NAK
</span><br>
</div>
<div><br>
</div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">I note in the whitepaper the following basic introductio=
n of need:</span><br>
</div>
<div><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:Calib=
ri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">node will simply a=
dopt the first
 solution seen, creating a kind of race condition.</span></div>
<div><br>
</div>
<div><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 &#39;self-r=
esolving&#39; 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 &#39;final&#39;.</span></div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)"><br>
</span></div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">I take it that your work is intended to allow the networ=
k 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><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)"><br>
</span></div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">KING JAMES HRMH</span></div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)">Great British Empire<br>
</span></div>
<div><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt=
;color:rgb(0,0,0)"><br>
</span></div>
<div id=3D"m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-173307=
0628655924658Signature">
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<div>Regards,
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&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>=C2=A0</div>
<div>Willtech</div>
<div><a href=3D"http://www.willtech.com.au" target=3D"_blank">www.willtech.=
com.au</a></div>
<div><a href=3D"http://www.go-overt.com" target=3D"_blank">www.go-overt.com=
</a></div>
<div>and other projects</div>
<div>=C2=A0</div>
<div><a href=3D"http://earn.com/willtech" target=3D"_blank">earn.com/willte=
ch</a></div>
<div><a href=3D"http://linkedin.com/in/damianwilliamson" target=3D"_blank">=
linkedin.com/in/damianwilliamson</a></div>
<div><br>
</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. 61261470192</div>
<div><br>
</div>
<div><br>
</div>
----</div>
</div>
</div>
</div>
</div>
<div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-173307=
0628655924658divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev-bounces@lists.linuxfoundation.org</a>&gt; on behalf of Mik=
e Brooks via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<=
br>
<b>Sent:</b> Friday, 25 September 2020 5:40 AM<br>
<b>To:</b> bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br=
>
<b>Subject:</b> [bitcoin-dev] Floating-Point Nakamoto Consensus</font>
<div>=C2=A0</div>
</div>
<div>
<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. 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.=C2=A0 It is wildly=
 underrated that future proofing was never really a consideration=C2=A0in t=
he initial=C2=A0design - but here we are a decade later with amazing soluti=
ons like SegWit which=C2=A0gives us a real future-proofing
 framework.=C2=A0 The fact 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=A0that co=
mes up in conversation of how difficult and necessary
 that process was,=C2=A0and 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=C2=A0SegWit - 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</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>=C2=A0</div>
<div>Pull Request:<br>
<span id=3D"m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-17330=
70628655924658x_gmail-m_2766209350405513116gmail-docs-internal-guid-e08d420=
3-7fff-1140-7022-8ecfe80e9fea"><a href=3D"https://github.com/bitcoin/bitcoi=
n/pull/19665/files" style=3D"text-decoration-line:none" target=3D"_blank"><=
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;vertical-align:baseline;white-space:pre-wrap">https://githu=
b.com/bitcoin/bitcoin/pull/19665/files</span></a></span>=C2=A0=C2=A0<br>
</div>
<div><br>
</div>
<div>---</div>
<div><br>
</div>
<div><span id=3D"m_2578037212881741593gmail-m_-2059436566520006889gmail-m_-=
1733070628655924658x_gmail-m_2766209350405513116gmail-docs-internal-guid-77=
a2432b-7fff-62c3-0753-fe93652ca512"><br>
<p dir=3D"ltr" style=3D"line-height:1.38;text-align:center;margin-top:0pt;m=
argin-bottom:0pt">
<span style=3D"font-size:14pt;font-family:Arial;color:rgb(0,0,0);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">Floating-Point Nakamoto Co=
nsensus</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-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;white-space:pre-wrap">Abstract =
=E2=80=94
</span><span style=3D"font-size:9pt;font-family:Arial;color:rgb(0,0,0);back=
ground-color:transparent;font-variant-numeric:normal;font-variant-east-asia=
n:normal;vertical-align:baseline;white-space:pre-wrap">It has been shown th=
at Nakamoto Consensus is very
 useful in the formation of long-term global agreement =E2=80=94 and has is=
sues 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 knowled=
ge of a specific kind 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.=C2=A0 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.=C2=A0 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:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">In=
troduction</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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">The
 Bitcoin protocol was created to provide a decentralized consensus on a ful=
ly distributed 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 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 =E2=80=9Ceclipsing=E2=80=9D attack.=
=C2=A0 When two segments of the network disagree it creates a moment of wea=
kness in which less than 51% of the network=E2=80=99s computational resourc=
es are required to keep the network balanced against itself.=C2=A0</span></=
p>
<h4 dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;margin-bottom:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Na=
kamoto
 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-east-asian:norm=
al;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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 This design ma=
kes 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 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:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Se=
curity=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-east-asian:norm=
al;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 (=E2=80=9C0-day=E2=80=9D) which will strictly=
 prevent honest 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 vulnerabil=
ity
 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.=C2=A0 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=E2=80=99t entirely suppressed. Let us assume a defense-in-depth s=
trategy 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-east-asian:norm=
al;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.=
=C2=A0 When a rude client occupies all connections - then a pidgin-hole pri=
nciple comes into play. If a network&#39;s
 maximum capacity for connection handlers =E2=80=98k=E2=80=99, is the sum o=
f 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 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">Now
 let=E2=80=99s assume a dishonest node is modified in two ways - it increas=
es the maximum connection handles to hundreds of thousands instead of the c=
urrent value which is about 10. Then this node is modified to ignore any so=
lution 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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
 =C2=BD as possible. If the network eclipse is perfect then an adversary ca=
n 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 attac=
ker from adding additional computation
 resources or adjusting the eclipsing effect to make sure the system is in =
balance. =C2=A0 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=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 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">This
 attack is convenient from the adversary=E2=80=99s perspective,=C2=A0 Bitco=
in being a broadcast network advertises the IP addresses of all active node=
s - and Shodan and the internet scanning project can find all passive nodes=
 responding 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 announcing their presence.=C2=A0 This means that =
the attacker doesn=E2=80=99t need to know exactly which node is used by a t=
argeted 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 When the weaker chain collapses, the transaction tha=
t the exchange acted upon is no longer codified in Bitcoin blockchain&#39;s=
 global ledger, and will be replaced with a version of the that did not con=
tain 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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">Nakamoto
 Consensus 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 emp=
irically non-deterministic which is evident by re-organizations (re-org) as=
 a method of resolving disagreements within the
 network. =C2=A0 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.=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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">DeFi
 (Decentralized Finance) and smart-contract obligations depend on network s=
tability and determinism.=C2=A0 Failure to pay contracts, such as what happ=
ened on =E2=80=9Cblack thursday=E2=80=9D resulted in secured loans accident=
ally falling into redemption.=C2=A0 The transactions used
 by a smart contract are intended to be completed quickly and the outcome i=
s irreversible.=C2=A0 However, if the blockchain network has split then a c=
ontract may fire and have it=E2=80=99s side-effects execute only to have th=
e transaction on the ledger to be replaced.=C2=A0
 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.=
=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-east-asian:norm=
al;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.=C2=A0 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">In
 Satoshi Nakamoto=E2=80=99s original paper it was stated that the electorat=
e should be represented by computational effort in the form of a proof-of-w=
ork, and only these nodes can participate in the consues process.=C2=A0 How=
ever, 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:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Ch=
ain
 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-east-asian:norm=
al;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=E2=80=99s strength is carried forward and the=
 loser will have to work harder and harder
 to maintain the disagreement.=C2=A0 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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 s=
olution 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2=A0=C2=A000=
000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8</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-east-asian:norm=
al;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.=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-east-asian:norm=
al;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-east-asian:norm=
al;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.=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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2=A01.847</s=
pan></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-east-asian:norm=
al;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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2=A0=C2=A000=
0000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2</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-east-asian:norm=
al;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.=C2=A0 With=
 Nakamoto Consensus 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 Consensus, we compare the fitness s=
cores and keep the highest.=C2=A0 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.=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-east-asian:norm=
al;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=
=E2=80=99t need to validate any lower-valued solution.=C2=A0 In fact this f=
itness value has a high degree of confidence
 that it won=E2=80=99t be unseated by a larger value - being able to produc=
e 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 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.=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-east-asian:norm=
al;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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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.=C2=A0 Given that the work needed to form a=C2=A0 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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. =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 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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.=C2=A0 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. =C2=A0 Now, let=E2=80=99s say this=
 group of isolated miners manages to present a new conflicting proof-of-wor=
k solution 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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6</spa=
n></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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">The
 above base16 block has a fitness score of 1.532=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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-east-asian:norm=
al;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.=C2=A0 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=
.=C2=A0 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.=C2=A0 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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0
 Let=E2=80=99s assume that the dominant group that went with the 1.847 fitn=
ess score - also produces a solution with a similar fitness value and adver=
tises 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;ma=
rgin-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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">0000000000000000000455207e=
375bf1dac0d483a7442239f1ef2c70d050c113</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">19.41497364946457487754919=
8290879237036867705594421756179</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-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-east-asian:norm=
al;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;ma=
rgin-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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">3.262 =3D 1.847 + 1.415</s=
pan></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-east-asian:norm=
al;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.=C2=A0 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.=C2=A0 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.=C2=A0 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:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">So=
ft
 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-east-asian:norm=
al;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 =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 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.=C2=A0 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.=C2=A0 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:4pt=
"><span style=3D"font-size:12pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;font-weight:400;font-variant-numeric:normal;font=
-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Co=
nclusion</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-east-asian:norm=
al;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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;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.=C2=A0 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;ma=
rgin-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-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap">A complete implementation =
of Floating-Point Nakamoto
 consensus is in the following pull request:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-bottom:0pt">
<a href=3D"https://github.com/bitcoin/bitcoin/pull/19665/files" 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://github.com/bitcoin/bitcoin/pull/1966=
5/files</span></a></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-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-east-asian:norm=
al;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;ma=
rgin-bottom:0pt">
<a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Consensus" styl=
e=3D"text-decoration-line:none" target=3D"_blank"><span style=3D"font-size:=
11pt;font-family:Arial;background-color:transparent;font-variant-numeric:no=
rmal;font-variant-east-asian:normal;text-decoration-line:underline;vertical=
-align:baseline;white-space:pre-wrap">https://github.com/in-st/Floating-Poi=
nt-Nakamoto-Consensus</span></a></p>
<p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;ma=
rgin-bottom:0pt">
<a href=3D"https://in.st.capital/" style=3D"text-decoration-line:none" targ=
et=3D"_blank"><span style=3D"font-size:11pt;font-family:Arial;background-co=
lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;=
text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap=
">https://in.st.capital</span></a></p>
<div></div>
<br>
</span></div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=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>
</div>

--000000000000755f8205b1407710--