From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7D284C0051 for ; 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 ; 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 ; 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 ; Fri, 9 Oct 2020 17:42:05 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id e23so3596386wme.2 for ; 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: In-Reply-To: From: Mike Brooks Date: Fri, 9 Oct 2020 18:26:07 -0700 Message-ID: To: LORD HIS EXCELLENCY JAMES HRMH , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000755f8205b1407710" X-Mailman-Approved-At: Fri, 09 Oct 2020 17:47:01 +0000 Cc: Mike Brooks 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 on > behalf of Mike Brooks via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> > *Sent:* Friday, 25 September 2020 5:40 AM > *To:* bitcoin-dev > *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
James,

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.

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.

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> wrot= e:
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 introductio= n of need:
>As a result anode will simply a= dopt the first solution seen, creating a kind of race condition.

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'.

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.

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.

=C2=A0
Willtech
and other projects
=C2=A0


m. 0487135719
f. 61261470192


----
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Mik= e Brooks via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org><= br> Sent: Friday, 25 September 2020 5:40 AM
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> Subject: [bitcoin-dev] Floating-Point Nakamoto Consensus
=C2=A0
=C2=A0 Hey Everyone,

=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.

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

=C2=A0

---


Floating-Point Nakamoto Co= nsensus


Abstract = =E2=80=94 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.

In= troduction

= 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

Na= kamoto Consensus

= 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.


= 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.

Se= curity=C2=A0

= 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.


= 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.


= 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.


= 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.=


= 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.


= 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.


= 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


= 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


= 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.


= 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.

Ch= ain Fitness

= 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.


= 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.

= 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.


= 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.


= 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:<= /p>

= =C2=A0=C2=A0=C2=A0=C2=A000= 000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8


= 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:

= =C2=A0=C2=A0=C2=A0=C2=A019= .847052573336114130069196154809453027792121882588614904


= 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

= =C2=A0=C2=A0=C2=A01.847


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

= =C2=A0=C2=A0=C2=A0=C2=A000= 0000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2


= 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


= 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

= 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.


= 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.


= 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.


= 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:


= =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6


= 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:


= =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A02.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.=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.


= 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:


0000000000000000000455207e= 375bf1dac0d483a7442239f1ef2c70d050c113

19.41497364946457487754919= 8290879237036867705594421756179

or

3.262 =3D 1.847 + 1.415


= 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.

So= ft Fork

= 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.

Co= nclusion

= 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.


= 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.






A complete implementation = of Floating-Point Nakamoto consensus is in the following pull request:

https://github.com/bitcoin/bitcoin/pull/1966= 5/files


Paper:

https://github.com/in-st/Floating-Poi= nt-Nakamoto-Consensus

https://in.st.capital


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000755f8205b1407710--