From mboxrd@z Thu Jan 1 00:00:00 1970 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 -> 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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio= n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> 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)">>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 'self-r= esolving' with the network adopting the longest chain with the highest = proof of work as any contentious tip is built on. This is the proper reason for waiting for two confirmatio= ns for a transaction as a minimum proof of its inclusion in the blockchain = (without fraud), and for waiting for six confirmations before considering t= hat a transaction is 'final'.</span></div> <div><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 (& HMRH)</div> <div>of Hougun Manor & Glencoe & British Empire</div> <div>MR. Damian A. James Williamson</div> <div>Wills</div> <div><br> </div> <div>et al.</div> <div><br> </div> <div>=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 <<a = href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_bl= ank">bitcoin-dev-bounces@lists.linuxfoundation.org</a>> on behalf of Mik= e Brooks via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound= ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><= br> <b>Sent:</b> Friday, 25 September 2020 5:40 AM<br> <b>To:</b> bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat= ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><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'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'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'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'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--