From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3A947C0051 for ; Fri, 25 Sep 2020 16:04:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 294DB86D08 for ; Fri, 25 Sep 2020 16:04:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXICpL7RCduP for ; Fri, 25 Sep 2020 16:04:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D0EC086CF6 for ; Fri, 25 Sep 2020 16:04:32 +0000 (UTC) Received: by mail-wr1-f41.google.com with SMTP id x14so4123260wrl.12 for ; Fri, 25 Sep 2020 09:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GebpYleRTUW4OLr1qOd9n6Kjo3C9yW1MCbUfzsXvD/g=; b=abG/XOk0e6AxnIr5qOxElH1OWUx10L2ewiBnloGYcGD8tZrkvwtmdEFVP2e0Oq2MVn EG8WNb7j4p9kUNnUeFdVexAzdOuMZrnatqiXxjqIJo37OMjCo6HTZZe2PQrnz7QsDl8d wYLuGcH3hEXVU4597B/N51wRU0LkVW9jbPd+oyriZVpiP5ZGvpmYYNnE8hnxflistiHd Fg9OuTD6S4xjMNzuNASihU6uwWv+/fdf/EJHzANM70LG7OiC2g9jLciJ6o2ZE8Icnj54 P07BbpQ8KC7+rvd+1vgd69pJ9mstbdTnEVxrg6Vp9jafJGbhDut1y3LRd/Uft1ZuoRvD /F5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GebpYleRTUW4OLr1qOd9n6Kjo3C9yW1MCbUfzsXvD/g=; b=tLIQIGqB/A5lBngQ3HkIBUCc3AR5vEcXR2pBqV+xgEVuaLASQCIB5pN9uexeWU+yx7 EotU1XAwsxHDVVHkzGQqXYj0cFpo0yzGU/c1OJi97j87l98fdHnkxcHVaF9AUVmrGNPG KnK3/HWPrIBGG/ui2hwaRqoER8Ns6mjgpWEKvKCdlPwjn1Tj0VrOWQ3brfxG+1dQf90y lDG4vvHqNSqr5shK8UNviTfYBdctJsvHbm1AZXH+hJHVx5IJxCL+C6/DIv3JkKCeQXE9 q2hNUwZYVLHUYSvIO7D2QWV7XngFv5YGf3sMjyyceFDK6fEeUQjdvQ8IlFvqD7ujX4Jl HY/g== X-Gm-Message-State: AOAM53237HTdsbWOZq1ShW0CEsmc5UFCvIhPUT4OxAFs/luAqWgOmGil U8K7wUa5at+QLSgVjo2DTjPeD93ZLT39ohNraCNWAw== X-Google-Smtp-Source: ABdhPJxhmLw5mxtUeifpseMn93OG0a8vnZahPErFeZzdscLkg+FW+aVXgfa0IA+xbNVO4oLd9uwH1kiso0yyi/RzQNk= X-Received: by 2002:adf:f5ce:: with SMTP id k14mr5141420wrp.286.1601049869941; Fri, 25 Sep 2020 09:04:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike Brooks Date: Fri, 25 Sep 2020 09:04:11 -0700 Message-ID: To: bitcoin ml , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c417c605b025786b" X-Mailman-Approved-At: Fri, 25 Sep 2020 17:52:18 +0000 Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:04:37 -0000 --000000000000c417c605b025786b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Thomas, A fitness value is only additive for the length of the disagreement, and only used to solve disagreements of the same height. This isn't as large of a departure as you are expecting. For 50,000 blocks of agreement, then no floating point value is calculated. All the best, Mike On Fri, Sep 25, 2020 at 8:57 AM bitcoin ml via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > This is a pretty big departure from cumulative POW. > > Could you explain to me what you see happening if a node with this patch > and no history starts to sync, and some random node gives it a block with= a > better fitness test for say height 250,000? No other solution will have a > better fitness test at that height, so from my understanding its going to > stop syncing. How about even later - say this proposal is activated at > block 750,000. At 850,000, someone decides it'd be fun to publish a new > block 800,000 with a better fitness test. What happens the 50,000 blocks? > > I can imagine the miners not being particularly happy about it - their > previously 50:50 chance (well, sort of, it's based on resources- > connectivity, validation overheads, etc) their tied block would succeed, = vs > the situation with this change - blocks that are inherently more or less > valid than others. > > I think these days people are more focused on improving defences at the > networking layer than in the consensus layer - especially when it affects > mining incentives. I don't see how people will take this seriously - > especially when you regard how often consensus changes are made to _fix_ > something as opposed to add something new. > > Best regards, > > Thomas > On 9/24/20 8:40 PM, Mike Brooks via bitcoin-dev wrote: > > Hey Everyone, > > A lot of work has gone into this paper, and the current revision has bee= n > well received and there is a lot of excitement on this side to be sharing > it with you today. There are so few people that truly understand this > topic, but we are all pulling in the same direction to make Bitcoin bette= r > and it shows. It is wildly underrated that future proofing was never > really a consideration in the initial design - but here we are a decade > later with amazing solutions like SegWit which gives us a real > future-proofing framework. The fact that future-proofing was added to > Bitcoin with a softfork gives me goosebumps. I'd just like to take the ti= me > to thank the people who worked on SegWit and it is an appreciation that > comes up in conversation of how difficult and necessary that process > was, and this appreciation may not be vocalized to the great people who > worked on it. The fact that Bitcoin keeps improving and is able to respon= d > to new threats is nothing short of amazing - thank you everyone for a gre= at > project. > > This current proposal really has nothing to do with SegWit - but it is an > update that will make the network a little better for the future, and we > hope you enjoy the paper. > > PDF: > > https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Fl= oating-Point%20Nakamoto%20Consensus.pdf > > Pull Request: > https://github.com/bitcoin/bitcoin/pull/19665/files > > --- > > > Floating-Point Nakamoto Consensus > > Abstract =E2=80=94 It has been shown that Nakamoto Consensus is very usef= ul in > the formation of long-term global agreement =E2=80=94 and has issues with > short-term disagreement which can lead to re-organization (=E2=80=9Cor-or= g=E2=80=9D) of the > blockchain. A malicious miner with knowledge of a specific kind of > denial-of-service (DoS) vulnerability can gain an unfair advantage in the > current Bitcoin network, and can be used to undermine the security > guarantees that developers rely upon. Floating-Point Nakamoto consensu > makes it more expensive to replace an already mined block vs. creation of= a > new block, and by resolving ambiguity of competition solutions it helps > achieve global consumers more quickly. A floating-point fitness test > strongly incentivises the correct network behavior, and prevents > disagreement from ever forming in the first place. > Introduction > > The Bitcoin protocol was created to provide a decentralized consensus on = a > fully distributed p2p network. A problem arises when more than one > proof-of-work is presented as the next solution block in the blockchain. > Two solutions of the same height are seen as authoritative equals which i= s > the basis of a growing disagreement. A node will adopt the first solution > seen, as both solutions propagate across the network a race condition of > disagreement is formed. This race condition can be controlled by byzentie= ne > fault injection commonly referred to as an =E2=80=9Ceclipsing=E2=80=9D at= tack. When two > segments of the network disagree it creates a moment of weakness in which > less than 51% of the network=E2=80=99s computational resources are requir= ed to keep > the network balanced against itself. > Nakamoto Consensus > > Nakamoto Consensus is the process of proving computational resources in > order to determine eligibility to participate in the decision making > process. If the outcome of an election were based on one node (or > one-IP-address-one-vote), then representation could be subverted by anyon= e > able to allocate many IPs. A consensus is only formed when the prevailing > decision has the greatest proof-of-work effort invested in it. In order f= or > a Nakamoto Consensus to operate, the network must ensure that incentives > are aligned such that the resources needed to subvert a proof-of-work bas= ed > consensus outweigh the resources gained through its exploitation. In this > consensus model, the proof-of-work requirements for the creation of the > next valid solution has the exact same cost as replacing the current > solution. There is no penalty for dishonesty, and this has worked well in > practice because the majority of the nodes on the network are honest and > transparent, which is a substantial barrier for a single dishonest node t= o > overcome. > > A minimal network peer-to-peer structure is required to support Nakamoto > Conesus, and for our purposes this is entirely decentralized. Messages ar= e > broadcast on a best-effort basis, and nodes can leave and rejoin the > network at will, accepting the longest proof-of-work chain as proof of wh= at > happened while they were gone. This design makes no guarantees that the > peers connected do not misrepresent the network or so called =E2=80=9Cdis= honest > nodes.=E2=80=9D Without a central authority or central view - all peers d= epend on > the data provided by neighboring peers - therefore a dishonest node can > continue until a peer is able to make contact an honest node. > Security > > In this threat model let us assume a malicious miner possesses knowledge > of an unpatched DoS vulnerability (=E2=80=9C0-day=E2=80=9D) which will st= rictly prevent > honest nodes from communicating to new members of the network - a so-call= ed > =E2=80=9Ctotal eclipse.=E2=80=9D The kind of DoS vulnerability needed to= conduct an > eclipse does not need to consume all CPU or computaitly ability of target > nodes - but rather prevent target nodes from forming new connections that > would undermine the eclipsing effect. These kinds of DoS vulnerabilities > are somewhat less substional than actually knocking a powerful-mining nod= e > offline. This class of attacks are valuable to an adversary because in > order for an honest node to prove that a dishonest node is lying - they > would need to form a connection to a segment of the network that isn=E2= =80=99t > entirely suppressed. Let us assume a defense-in-depth strategy and plan o= n > this kind of failure. > > Let us now consider that the C++ Bitcoind has a finite number of worker > threads and a finite number of connections that can be serviced by these > workers. When a rude client occupies all connections - then a pidgin-hol= e > principle comes into play. If a network's maximum capacity for connection > handlers =E2=80=98k=E2=80=99, is the sum of all available worker threads = for all nodes in > the network, establishing =E2=80=98k+1=E2=80=99 connections by the pidgin= -hole principle > will prevent any new connections from being formed by honest nodes - > thereby creating a perfect eclipse for any new miners joining the network > would only be able to form connections with dishonest nodes. > > Now let=E2=80=99s assume a dishonest node is modified in two ways - it in= creases > the maximum connection handles to hundreds of thousands instead of the > current value which is about 10. Then this node is modified to ignore any > solution blocks found by honest nodes - thus forcing the dishonest side o= f > the network to keep searching for a competitive-solution to split the > network in two sides that disagree about which tip of the chain to use. > Any new solution propagates through nodes one hop at a time. This > propagation can be predicted and shaped by dishonest non-voting nodes tha= t > are being used to pass messages for honest nodes. > > At this point an attacker can expedite the transmission of one solution, > while slowing another. If ever a competing proof-of-work is broadcasted t= o > the network, the adversary will use their network influence to split > knowledge of the proof-of-work as close to =C2=BD as possible. If the net= work > eclipse is perfect then an adversary can leverage an eigen-vector of > computational effort to keep the disagreement in balance for as long as i= t > is needed. No mechanism is stopping the attacker from adding additional > computation resources or adjusting the eclipsing effect to make sure the > system is in balance. As long as two sides of the network are perfectly > in disagreement and generating new blocks - the attacker has intentionall= y > created a hard-fork against the will of the network architects and > operators. The disagreement needs to be kept open until the adversary=E2= =80=99s > transactions have been validated on the honest chain - at which point the > attacker will add more nodes to the dishonest chain to make sure it is th= e > ultimate winner - thus replacing out the honest chain with the one > generated by dishonest miners. > > This attack is convenient from the adversary=E2=80=99s perspective, Bitc= oin being > a broadcast network advertises the IP addresses of all active nodes - and > Shodan and the internet scanning project can find all passive nodes > responding on TCP 8333. This should illuminate all honest nodes on the > network, and even honest nodes that are trying to obscure themselves by n= ot > announcing their presence. This means that the attacker doesn=E2=80=99t = need to > know exactly which node is used by a targeted exchange - if the attacker > has subdued all nodes then the targeted exchange must be operating a node > within this set of targeted honest nodes. > > During a split in the blockchain, each side of the network will honor a > separate merkel-tree formation and therefore a separate ledger of > transactions. An adversary will then broadcast currency deposits to publi= c > exchanges, but only on the weaker side, leaving the stronger side with no > transaction from the adversary. Any exchange that confirms one of these > deposits is relying upon nodes that have been entirely eclipsed so that > they cannot see the competing chain - at this point anyone looking to > confirm a transaction is vulnerable to a double-spend. With this currency > deposited on a chain that will become ephemeral, the attacker can wire ou= t > the account balance on a different blockchain - such as Tether which is a= n > erc20 token on the Ethereum network which would be unaffected by this > attack. When the weaker chain collapses, the transaction that the exchan= ge > acted upon is no longer codified in Bitcoin blockchain's global ledger, a= nd > will be replaced with a version of the that did not contain these deposit= s. > > Nakamoto Consensus holds no guarantees that it=E2=80=99s process is > deterministic. In the short term, we can observe that the Nakamoto > Consensus is empirically non-deterministic which is evident by > re-organizations (re-org) as a method of resolving disagreements within t= he > network. During a reorganization a blockchain network is at its weakest > point, and a 51% attack to take the network becomes unnecessary. An > adversary who can eclipse honest hosts on the network can use this as a > means of byzantine fault-injection to disrupt the normal flow of messages > on the network which creates disagreement between miners. > > DeFi (Decentralized Finance) and smart-contract obligations depend on > network stability and determinism. Failure to pay contracts, such as wha= t > happened on =E2=80=9Cblack thursday=E2=80=9D resulted in secured loans ac= cidentally falling > into redemption. The transactions used by a smart contract are intended = to > be completed quickly and the outcome is irreversible. However, if the > blockchain network has split then a contract may fire and have it=E2=80= =99s > side-effects execute only to have the transaction on the ledger to be > replaced. Another example is that a hard-fork might cause the payer of a > smart contract to default - as the transaction that they broadcasted ende= d > up being on the weaker chain that lost. Some smart contracts, such as > collateral backed loans have a redemption clause which would force the > borrower on the loan to lose their deposit entirely. > > With two sides of the network balanced against each other - an attacker > has split the blockchain and this hard-fork can last for as long as the > attacker is able to exert the computational power to ensure that > proof-of-work blocks are regularly found on both sides of the network. T= he > amount of resources needed to balance the network against itself is far > less than a 51% attack - thereby undermining the security guarantees need= ed > for a decentralized untrusted payment network to function. An adversary > with a sufficiently large network of dishonest bots could use this to tak= e > a tally of which miners are participating in which side of the network > split. This will create an attacker-controlled hard fork of the network > with two mutually exclusive merkle trees. Whereby the duration of this > split is arbitrary, and the decision in which chain to collapse is up to > the individual with the most IP address, not the most computation. > > In Satoshi Nakamoto=E2=80=99s original paper it was stated that the elect= orate > should be represented by computational effort in the form of a > proof-of-work, and only these nodes can participate in the consues > process. However, the electorate can be misled by non-voting nodes which > can reshape the network to benefit an individual adversary. > Chain Fitness > > Any solution to byzantine fault-injection or the intentional formation of > disagreements must be fully decentralized. A blockchain is allowed to spl= it > because there is ambiguity in the Nakamoto proof-of-work, which creates t= he > environment for a race-condition to form. To resolve this, Floating-Point > Nakamoto Consensus makes it increasingly more expensive to replace the > current winning block. This added cost comes from a method of disagreemen= t > resolution where not every solution block is the same value, and a more-f= it > solution is always chosen over a weaker solution. Any adversary attemptin= g > to have a weaker chain to win out would have to overcome a kind of > relay-race, whereby the winning team=E2=80=99s strength is carried forwar= d and the > loser will have to work harder and harder to maintain the disagreement. = In > most cases Floating-Point Nakamoto Consensus will prevent a re-org > blockchain from ever going past a single block thereby expediting the > formation of a global consensus. Floating-Point Nakamoto Consensus cemen= ts > the lead of the winner and to greatly incentivize the network to adopt th= e > dominant chain no matter how many valid solutions are advertised, or what > order they arrive. > > The first step in Floating-Point Nakamoto Consensus is that all nodes in > the network should continue to conduct traditional Nakamoto Consensus and > the formation of new blocks is dictated by the same zero-prefix > proof-of-work requirements. If at any point there are two solution block= s > advertised for the same height - then a floating-point fitness value is > calculated and the solution with the higher fitness value is the winner > which is then propagated to all neighbors. Any time two solutions are > advertised then a re-org is inevitable and it is in the best interest of > all miners to adopt the most-fit block, failing to do so risks wasting > resources on a mining of a block that would be discarded. To make sure > that incentives are aligned, any zero-prefix proof of work could be the > next solution, but now in order to replace the current winning solution a= n > adversary would need a zero-prefix block that is also more fit that the > current solution - which is much more computationally expensive to produc= e. > > Any changes to the current tip of the blockchain must be avoided as much > as possible. To avoid thrashing between two or more competitive solutions= , > each replacement can only be done if it is more fit, thereby proving that > it has an increased expense. If at any point two solutions of the same > height are found it means that eventually some node will have to replace > their tip - and it is better to have it done as quickly as possible so th= at > consensus is maintained. > > In order to have a purely decentralized solution, this kind of agreement > must be empirically derived from the existing proof-of-work so that it is > universally and identically verifiable by all nodes on the network. > Additionally, this fitness-test evaluation needs to ensure that no two > competing solutions can be numerically equivalent. > > Let us suppose that two or more valid solutions will be proposed for the > same block. To weigh the value of a given solution, let's consider a > solution for block 639254, in which the following hash was proposed: > > 00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8 > > There are 19 zeros, and the remaining hash in base 16 starts with 9e3 and > ends with f8. This can value can be represented in floating point as: > > 19.847052573336114130069196154809453027792121882588614904 > > To simplify further lets give this block a single whole number to > represent one complete solution, and use a rounded floating-point value t= o > represent some fraction of additional work exerted by the miner. > > 1.847 > > Now let us suppose that a few minutes later another solution is advertise= d > to the network shown in base16 below: > > 000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2 > > The solution above also has 19 prefixed zeros, and is being broadcast for > the same blockheight value of 639254 - and a fitness score of 1.282. Wit= h > Nakamoto Consensus both of these solutions would be equivalent and a give= n > node would adopt the one that it received first. In Floating-Post Nakamo= to > Consensus, we compare the fitness scores and keep the highest. In this > case no matter what happens - some nodes will have to change their tip an= d > a fitness test makes sure this happens immediately. > > With both solutions circulating in the network - any node who has receive= d > both proof-of-works should know 1.847 is the current highest value, and > shouldn=E2=80=99t need to validate any lower-valued solution. In fact th= is fitness > value has a high degree of confidence that it won=E2=80=99t be unseated b= y a larger > value - being able to produce a proof-of-work with 19 0=E2=80=99s and a d= ecimal > component greater than 0.847 is non-trivial. As time passes any nodes th= at > received a proof-of-work with a value 1.204 - their view of the network > should erode as these nodes adopt the 1.847 version of the blockchain. > > All nodes are incentivized to support the solution with the highest > fitness value - irregardless of which order these proof-of-work were > validated. Miners are incentivized to support the dominant chain which > helps preserve the global consensus. > > Let us assume that the underlying cryptographic hash-function used to > generate a proof-of-work is an ideal primitive, and therefore a node cann= ot > force the outcome of the non-zero component of their proof-of-work. > Additionally if we assume an ideal cipher then the fitness of all possibl= e > solutions is gaussian-random. With these assumptions then on average a ne= w > solution would split the keyspace of remaining solutions in half. Given > that the work needed to form a new block remains a constant at 19 blocks > for this period - it is cheaper to produce a N+1 block that has any > floating point value as this is guaranteed to be adopted by all nodes if = it > is the first solution. To leverage a chain replacement on nodes conducti= ng > Floating-Point Nakamoto Consensus a malicious miner would have to expend > significantly more resources. > > Each successive n+1 solution variant of the same block-height must > therefore on average consume half of the remaining finite keyspace. > Resulting in a the n+1 value not only needed to overcome the 19 zero > prefix, but also the non-zero fitness test. It is possible for an > adversary to waste their time making a 19 where n+1 was not greater, at > which point the entire network will have had a chance to move on with the > next solution. With inductive reasoning, we can see that a demissiniong > keyspace increases the amount of work needed to find a solution that also > meets this new criteria. > > Now let us assume a heavily-fragmented network where some nodes have > gotten one or both of the solutions. In the case of nodes that received > the proof-of-work solution with a fitness of 1.847, they will be happily > mining on this version of the blockchain. The nodes that have gotten both > 1.847 and .240 will still be mining for the 1.847 domainite version, > ensuring a dominant chain. However, we must assume some parts of the > network never got the message about 1.847 proof of work, and instead > continued to mine using a value of 1.240 as the previous block. Now, > let=E2=80=99s say this group of isolated miners manages to present a new > conflicting proof-of-work solution for 639255: > > 000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6 > > The above base16 block has a fitness score of 1.532 The fitness value fo= r > the previous block 639254 is added together: > > 2.772 =3D 1.240 + 1.532 > > In this specific case, no other solution has been broadcast for block > height 639255 - putting the weaker branch in the lead. If the weaker > branch is sufficiently lucky, and finds a solution before the dominant > branch then this solution will have a higher overall fitness score, and > this solution will propagate as it has the higher value. This is also > important for transactions on the network as they benefit from using the > most recently formed block - which will have the highest local fitness > score at the time of its discovery. At this junction, the weaker branch > has an opportunity to prevail enterally thus ending the split. > > Now let us return to the DoS threat model and explore the worst-case > scenario created by byzantine fault injection. Let us assume that both th= e > weaker group and the dominant group have produced competing proof-of-work > solutions for blocks 639254 and 639255 respectively. Let=E2=80=99s assum= e that the > dominant group that went with the 1.847 fitness score - also produces a > solution with a similar fitness value and advertises the following soluti= on > to the network: > > 0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113 > > 19.414973649464574877549198290879237036867705594421756179 > > or > > 3.262 =3D 1.847 + 1.415 > > A total of 3.262 is still dominant over the lesser 2.772 - in order to > overcome this - the 2nd winning block needs to make up for all of the > losses in the previous block. In this scenario, in order for the weaker > chain to supplant the dominant chain it must overcome a -0.49 point > deficit. In traditional Nakamoto Consensus the nodes would see both forks > as authoritative equals which creates a divide in mining capacity while t= wo > groups of miners search for the next block. In Floating-Point Nakamoto > Consensus any nodes receiving both forks, would prefer to mine on the cha= in > with an overall fitness score of +3.262 - making it even harder for the > weaker chain to find miners to compete in any future disagreement, thereb= y > eroding support for the weaker chain. This kind of comparison requires an > empirical method for determining fitness by miners following the same sam= e > system of rules will insure a self-fulfilled outcome. After all nodes > adopt the dominant chain normal Nakamoto Consuess can resume without havi= ng > to take into consideration block fitness. This example shows how > disagreement can be resolved more quickly if the network has a mechanism = to > resolve ambiguity and de-incentivise dissent. > Soft Fork > > Blockchain networks that would like to improve the consensus generation > method by adding a fitness test should be able to do so using a =E2=80=9C= Soft Fork=E2=80=9D > otherwise known as a compatible software update. By contrast a =E2=80=9C= Hard-Fork=E2=80=9D > is a separate incompatible network that does not form the same consensus. > Floating-Point Nakamoto Consensus can be implemented as a soft-fork becau= se > both patched, and non-patched nodes can co-exist and non-patched nodes wi= ll > benefit from a kind of herd immunity in overall network stability. This = is > because once a small number of nodes start following the same rules then > they will become the deciding factor in which chain is chosen. Clients > that are using only traditional Nakamoto Consensus will still agree with > new clients over the total chain length. Miners that adopt the new strate= gy > early, will be less likely to lose out on mining invalid solutions. > Conclusion > > Floating-Point Nakamoto consensus allows the network to form a consensus > more quickly by avoiding ambiguity allowing for determinism to take hold. > Bitcoin has become an essential utility, and attacks against our networks > must be avoided and adapting, patching and protecting the network is a > constant effort. An organized attack against a cryptocurrency network wil= l > undermine the guarantees that blockchain developers are depending on. > > Any blockchain using Nakamoto Consensus can be modified to use a fitness > constraint such as the one used by a Floating-Point Nakamoto Consensus. = An > example implementation has been written and submitted as a PR to the > bitcoin core which is free to be adapted by other networks. > > > > > > A complete implementation of Floating-Point Nakamoto consensus is in the > following pull request: > > https://github.com/bitcoin/bitcoin/pull/19665/files > > Paper: > > https://github.com/in-st/Floating-Point-Nakamoto-Consensus > > https://in.st.capital > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://list= s.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000c417c605b025786b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Thomas,

A fitness value is only add= itive for the length of the disagreement, and only used to solve disagreeme= nts of the same height.=C2=A0 This isn't as large of a departure as you= are expecting.=C2=A0 For 50,000 blocks of agreement, then no floating poin= t value is calculated.=C2=A0

All the best,
Mike

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

Hi,

This is a pretty big departure from cumulative POW.

Could you explain to me what you see happening if a node with this patch and no history starts to sync, and some random node gives it a block with a better fitness test for say height 250,000? No other solution will have a better fitness test at that height, so from my understanding its going to stop syncing. How about even later - say this proposal is activated at block 750,000. At 850,000, someone decides it'd be fun to publish a new block 800,000 with a better fitness test. What happens the 50,000 blocks?

I can imagine the miners not being particularly happy about it - their previously 50:50 chance (well, sort of, it's based on resources- connectivity, validation overheads, etc) their tied block would succeed, vs the situation with this change - blocks that are inherently more or less valid than others.

I think these days people are more focused on improving defences at the networking layer than in the consensus layer - especially when it affects mining incentives. I don't see how people will take this seriously - especially when you regard how often consensus changes are made to _fix_ something as opposed to add something new.

Best regards,

Thomas

On 9/24/20 8:40 PM, Mike Brooks via bitcoin-dev wrote:
=20
=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. The= re are so few people that truly understand this topic, but we are all pulling in the same direction to make Bitcoin better and it shows.=C2=A0 It is wildly underrated that future proofing was never really a consideration=C2=A0in the initial=C2=A0design - bu= t here we are a decade later with amazing solutions like SegWit which=C2=A0gives us a real future-proofing framework.=C2=A0 The f= act that future-proofing was added to Bitcoin with a softfork gives me goosebumps.=C2=A0I'd just like to take the time to t= hank the people who worked on SegWit and it is an appreciation=C2=A0th= at comes up in conversation of how difficult and necessary that process was,=C2=A0and this appreciation may not be vocalized to t= he great people who worked on it. The fact that Bitcoin keeps improving and is able to respond to new threats is nothing short of amazing - thank you everyone for a great project.

This current proposal really has nothing to do with=C2=A0SegWi= t - but it is an update that will make the network a little better for the future, and we hope you enjoy the paper.=C2=A0

=C2=A0

---


Floating-Point Nakamoto Consensus


Abstract =E2=80=94 It has been shown that Nakamoto Consensus is very useful i= n the formation of long-term global agreement =E2=80=94 and has issues with= short-term disagreement which can lead to re-organization (=E2=80=9Cor-org= =E2=80=9D) of the blockchain.=C2=A0 A malicious miner with knowledge of a s= pecific kind of denial-of-service (DoS) vulnerability can gain an unfair ad= vantage in the current Bitcoin network, and can be used to undermine the se= curity guarantees that developers rely upon.=C2=A0 Floating-Point Nakamoto = consensu makes it more expensive to replace an already mined block vs. crea= tion of a new block, and by resolving ambiguity of competition solutions it= helps achieve global consumers more quickly.=C2=A0 A floating-point fitnes= s test strongly incentivises the correct network behavior, and prevents dis= agreement from ever forming in the first place.

Introduction

The Bitcoin pr= otocol was created to provide a decentralized consensus on a fully distribu= ted p2p network.=C2=A0 A problem arises when more than one proof-of-work is= presented as the next solution block in the blockchain.=C2=A0 Two solution= s of the same height are seen as authoritative equals which is the basis of= a growing disagreement. A node will adopt the first solution seen, as both= solutions propagate across the network a race condition of disagreement is= formed. This race condition can be controlled by byzentiene fault injectio= n commonly referred to as an =E2=80=9Ceclipsing=E2=80=9D attack.=C2=A0 When= two segments of the network disagree it creates a moment of weakness in wh= ich less than 51% of the network=E2=80=99s computational resources are requ= ired to keep the network balanced against itself.=C2=A0

Nakamoto Consensus

Nakamoto Conse= nsus is the process of proving computational resources in order to determin= e eligibility to participate in the decision making process.=C2=A0 If the o= utcome of an election were based on one node (or one-IP-address-one-vote), = then representation could be subverted by anyone able to allocate many IPs.= A consensus is only formed when the prevailing decision has the greatest p= roof-of-work effort invested in it. In order for a Nakamoto Consensus to op= erate, the network must ensure that incentives are aligned such that the re= sources needed to subvert a proof-of-work based consensus outweigh the reso= urces gained through its exploitation. In this consensus model, the proof-o= f-work requirements for the creation of the next valid solution has the exa= ct same cost as replacing the current solution. There is no penalty for dis= honesty, and this has worked well in practice because the majority of the n= odes on the network are honest and transparent, which is a substantial barr= ier for a single dishonest node to overcome.


A minimal netw= ork peer-to-peer structure is required to support Nakamoto Conesus, and for= our purposes this is entirely decentralized. Messages are broadcast on a b= est-effort basis, and nodes can leave and rejoin the network at will, accep= ting the longest proof-of-work chain as proof of what happened while they w= ere gone.=C2=A0 This design makes no guarantees that the peers connected do= not misrepresent the network or so called =E2=80=9Cdishonest nodes.=E2=80= =9D Without a central authority or central view - all peers depend on the d= ata provided by neighboring peers - therefore a dishonest node can continue= until a peer is able to make contact an honest node.

Security=C2=A0

In this threat= model let us assume a malicious miner possesses knowledge of an unpatched = DoS vulnerability (=E2=80=9C0-day=E2=80=9D) which will strictly prevent hon= est nodes from communicating to new members of the network - a so-called = =E2=80=9Ctotal eclipse.=E2=80=9D=C2=A0 The kind of DoS vulnerability needed= to conduct an eclipse does not need to consume all CPU or computaitly abil= ity of target nodes - but rather prevent target nodes from forming new conn= ections that would undermine the eclipsing effect. These kinds of DoS vulne= rabilities are somewhat less substional than actually knocking a powerful-m= ining node offline.=C2=A0 This class of attacks are valuable to an adversar= y because in order for an honest node to prove that a dishonest node is lyi= ng - they would need to form a connection to a segment of the network that = isn=E2=80=99t entirely suppressed. Let us assume a defense-in-depth strateg= y and plan on this kind of failure.


Let us now con= sider that the C++ Bitcoind has a finite number of worker threads and a fin= ite number of connections that can be serviced by these workers.=C2=A0 When= a rude client occupies all connections - then a pidgin-hole principle come= s into play. If a network's maximum capacity for connection handlers = =E2=80=98k=E2=80=99, is the sum of all available worker threads for all nod= es in the network, establishing =E2=80=98k+1=E2=80=99 connections by the pi= dgin-hole principle will prevent any new connections from being formed by h= onest nodes - thereby creating a perfect eclipse for any new miners joining= the network would only be able to form connections with dishonest nodes.


Now let=E2=80= =99s assume a dishonest node is modified in two ways - it increases the max= imum connection handles to hundreds of thousands instead of the current val= ue which is about 10. Then this node is modified to ignore any solution blo= cks found by honest nodes - thus forcing the dishonest side of the network = to keep searching for a competitive-solution to split the network in two si= des that disagree about which tip of the chain to use.=C2=A0 Any new soluti= on propagates through nodes one hop at a time. This propagation can be pred= icted and shaped by dishonest non-voting nodes that are being used to pass = messages for honest nodes.


At this point = an attacker can expedite the transmission of one solution, while slowing an= other. If ever a competing proof-of-work is broadcasted to the network, the= adversary will use their network influence to split knowledge of the proof= -of-work as close to =C2=BD as possible. If the network eclipse is perfect = then an adversary can leverage an eigen-vector of computational effort to k= eep the disagreement in balance for as long as it is needed. No mechanism i= s stopping the attacker from adding additional computation resources or adj= usting the eclipsing effect to make sure the system is in balance. =C2=A0 A= s long as two sides of the network are perfectly in disagreement and genera= ting new blocks - the attacker has intentionally created a hard-fork agains= t the will of the network architects and operators. The disagreement needs = to be kept open until the adversary=E2=80=99s transactions have been valida= ted on the honest chain - at which point the attacker will add more nodes t= o the dishonest chain to make sure it is the ultimate winner - thus replaci= ng out the honest chain with the one generated by dishonest miners.<= /p>

This attack is= convenient from the adversary=E2=80=99s perspective,=C2=A0 Bitcoin being a= broadcast network advertises the IP addresses of all active nodes - and Sh= odan and the internet scanning project can find all passive nodes respondin= g on TCP 8333.=C2=A0 This should illuminate all honest nodes on the network= , and even honest nodes that are trying to obscure themselves by not announ= cing their presence.=C2=A0 This means that the attacker doesn=E2=80=99t nee= d to know exactly which node is used by a targeted exchange - if the attack= er has subdued all nodes then the targeted exchange must be operating a nod= e within this set of targeted honest nodes.


During a split= in the blockchain, each side of the network will honor a separate merkel-t= ree formation and therefore a separate ledger of transactions. An adversary= will then broadcast currency deposits to public exchanges, but only on the= weaker side, leaving the stronger side with no transaction from the advers= ary. Any exchange that confirms one of these deposits is relying upon nodes= that have been entirely eclipsed so that they cannot see the competing cha= in - at this point anyone looking to confirm a transaction is vulnerable to= a double-spend. With this currency deposited on a chain that will become e= phemeral, the attacker can wire out the account balance on a different bloc= kchain - such as Tether which is an erc20 token on the Ethereum network whi= ch would be unaffected by this attack.=C2=A0 When the weaker chain collapse= s, the transaction that the exchange acted upon is no longer codified in Bi= tcoin blockchain's global ledger, and will be replaced with a version o= f the that did not contain these deposits.


Nakamoto Conse= nsus holds no guarantees that it=E2=80=99s process is deterministic.=C2=A0 = In the short term, we can observe that the Nakamoto Consensus is empiricall= y non-deterministic which is evident by re-organizations (re-org) as a meth= od of resolving disagreements within the network. =C2=A0 During a reorganiz= ation a blockchain network is at its weakest point, and a 51% attack to tak= e the network becomes unnecessary. An adversary who can eclipse honest host= s on the network can use this as a means of byzantine fault-injection to di= srupt the normal flow of messages on the network which creates disagreement= between miners.=C2=A0


DeFi (Decentra= lized Finance) and smart-contract obligations depend on network stability a= nd determinism.=C2=A0 Failure to pay contracts, such as what happened on = =E2=80=9Cblack thursday=E2=80=9D resulted in secured loans accidentally fal= ling into redemption.=C2=A0 The transactions used by a smart contract are i= ntended to be completed quickly and the outcome is irreversible.=C2=A0 Howe= ver, if the blockchain network has split then a contract may fire and have = it=E2=80=99s side-effects execute only to have the transaction on the ledge= r to be replaced.=C2=A0 Another example is that a hard-fork might cause the= payer of a smart contract to default - as the transaction that they broadc= asted ended up being on the weaker chain that lost. Some smart contracts, s= uch as collateral backed loans have a redemption clause which would force t= he borrower on the loan to lose their deposit entirely.=C2=A0


With two sides= of the network balanced against each other - an attacker has split the blo= ckchain and this hard-fork can last for as long as the attacker is able to = exert the computational power to ensure that proof-of-work blocks are regul= arly found on both sides of the network.=C2=A0 The amount of resources need= ed to balance the network against itself is far less than a 51% attack - th= ereby undermining the security guarantees needed for a decentralized untrus= ted payment network to function.=C2=A0 An adversary with a sufficiently lar= ge network of dishonest bots could use this to take a tally of which miners= are participating in which side of the network split. This will create an = attacker-controlled hard fork of the network with two mutually exclusive me= rkle trees. Whereby the duration of this split is arbitrary, and the decisi= on in which chain to collapse is up to the individual with the most IP addr= ess, not the most computation.


In Satoshi Nak= amoto=E2=80=99s original paper it was stated that the electorate should be = represented by computational effort in the form of a proof-of-work, and onl= y these nodes can participate in the consues process.=C2=A0 However, the el= ectorate can be misled by non-voting nodes which can reshape the network to= benefit an individual adversary.

Chain Fitness

Any solution t= o byzantine fault-injection or the intentional formation of disagreements m= ust be fully decentralized. A blockchain is allowed to split because there = is ambiguity in the Nakamoto proof-of-work, which creates the environment f= or a race-condition to form. To resolve this, Floating-Point Nakamoto Conse= nsus makes it increasingly more expensive to replace the current winning bl= ock. This added cost comes from a method of disagreement resolution where n= ot every solution block is the same value, and a more-fit solution is alway= s chosen over a weaker solution. Any adversary attempting to have a weaker = chain to win out would have to overcome a kind of relay-race, whereby the w= inning team=E2=80=99s strength is carried forward and the loser will have t= o work harder and harder to maintain the disagreement.=C2=A0 In most cases = Floating-Point Nakamoto Consensus will prevent a re-org blockchain from eve= r going past a single block thereby expediting the formation of a global co= nsensus.=C2=A0 Floating-Point Nakamoto Consensus cements the lead of the wi= nner and to greatly incentivize the network to adopt the dominant chain no = matter how many valid solutions are advertised, or what order they arrive.<= /span>


The first step= in Floating-Point Nakamoto Consensus is that all nodes in the network shou= ld continue to conduct traditional Nakamoto Consensus and the formation of = new blocks is dictated by the same zero-prefix proof-of-work requirements.= =C2=A0 If at any point there are two solution blocks advertised for the sam= e height - then a floating-point fitness value is calculated and the soluti= on with the higher fitness value is the winner which is then propagated to = all neighbors. Any time two solutions are advertised then a re-org is inevi= table and it is in the best interest of all miners to adopt the most-fit bl= ock, failing to do so risks wasting resources on a mining of a block that w= ould be discarded.=C2=A0 To make sure that incentives are aligned, any zero= -prefix proof of work could be the next solution, but now in order to repla= ce the current winning solution an adversary would need a zero-prefix block= that is also more fit that the current solution - which is much more compu= tationally expensive to produce.

Any changes to= the current tip of the blockchain must be avoided as much as possible. To = avoid thrashing between two or more competitive solutions, each replacement= can only be done if it is more fit, thereby proving that it has an increas= ed expense.=C2=A0 If at any point two solutions of the same height are foun= d it means that eventually some node will have to replace their tip - and i= t is better to have it done as quickly as possible so that consensus is mai= ntained.


In order to ha= ve a purely decentralized solution, this kind of agreement must be empirica= lly derived from the existing proof-of-work so that it is universally and i= dentically verifiable by all nodes on the network.=C2=A0 Additionally, this= fitness-test evaluation needs to ensure that no two competing solutions ca= n be numerically equivalent.


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 solution f= or block 639254, in which the following hash was proposed:

=C2=A0=C2=A0= =C2=A0=C2=A000000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f= 8


There are 19 z= eros, and the remaining hash in base 16 starts with 9e3 and ends with f8.= =C2=A0 This can value can be represented in floating point as:

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


To simplify fu= rther lets give this block a single whole number to represent one complete = solution, and use a rounded floating-point value to represent some fraction= of additional work exerted by the miner.=C2=A0

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


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

=C2=A0=C2=A0= =C2=A0=C2=A0000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc= 2


The solution a= bove also has 19 prefixed zeros, and is being broadcast for the same blockh= eight value of 639254 - and a fitness score of 1.282.=C2=A0 With Nakamoto C= onsensus both of these solutions would be equivalent and a given node would= adopt the one that it received first.=C2=A0 In Floating-Post Nakamoto Cons= ensus, we compare the fitness scores and keep the highest.=C2=A0 In this ca= se no matter what happens - some nodes will have to change their tip and a = fitness test makes sure this happens immediately.=C2=A0


With both solu= tions circulating in the network - any node who has received both proof-of-= works should know 1.847 is the current highest value, and shouldn=E2=80=99t= need to validate any lower-valued solution.=C2=A0 In fact this fitness val= ue has a high degree of confidence that it won=E2=80=99t be unseated by a l= arger value - being able to produce a proof-of-work with 19 0=E2=80=99s and= a decimal component greater than 0.847 is non-trivial.=C2=A0 As time passe= s any nodes that received a proof-of-work with a value 1.204 - their view o= f the network should erode as these nodes adopt the 1.847 version of the bl= ockchain.=C2=A0

All nodes are = incentivized to support the solution with the highest fitness value - irreg= ardless of which order these proof-of-work were validated. Miners are incen= tivized to support the dominant chain which helps preserve the global conse= nsus.


Let us assume = that the underlying cryptographic hash-function used to generate a proof-of= -work is an ideal primitive, and therefore a node cannot force the outcome = of the non-zero component of their proof-of-work.=C2=A0 Additionally if we = assume an ideal cipher then the fitness of all possible solutions is gaussi= an-random. With these assumptions then on average a new solution would spli= t the keyspace of remaining solutions in half.=C2=A0 Given that the work ne= eded to form a=C2=A0 new block remains a constant at 19 blocks for this per= iod - it is cheaper to produce a N+1 block that has any floating point valu= e as this is guaranteed to be adopted by all nodes if it is the first solut= ion.=C2=A0 To leverage a chain replacement on nodes conducting Floating-Poi= nt Nakamoto Consensus a malicious miner would have to expend significantly = more resources.


Each successiv= e n+1 solution variant of the same block-height must therefore on average c= onsume half of the remaining finite keyspace. Resulting in a the n+1 value = not only needed to overcome the 19 zero prefix, but also the non-zero fitne= ss test. =C2=A0 It is possible for an adversary to waste their time making = a 19 where n+1 was not greater, at which point the entire network will have= had a chance to move on with the next solution.=C2=A0 With inductive reaso= ning, we can see that a demissiniong keyspace increases the amount of work = needed to find a solution that also meets this new criteria.


Now let us ass= ume a heavily-fragmented network where some nodes have gotten one or both o= f the solutions.=C2=A0 In the case of nodes that received the proof-of-work= solution with a fitness of 1.847, they will be happily mining on this vers= ion of the blockchain. The nodes that have gotten both 1.847 and .240 will = still be mining for the 1.847 domainite version, ensuring a dominant chain.= =C2=A0 However, we must assume some parts of the network never got the mess= age about 1.847 proof of work, and instead continued to mine using a value = of 1.240 as the previous block. =C2=A0 Now, let=E2=80=99s say this group of= isolated miners manages to present a new conflicting proof-of-work solutio= n for 639255:


=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0000000000000000000058d8ebeb076584bb5853c80111bc06b5ada354= 63091a6


The above base= 16 block has a fitness score of 1.532=C2=A0 The fitness value for the previ= ous block 639254 is added together:


=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02.772 =3D 1.240 + 1.532


In this specif= ic case, no other solution has been broadcast for block height 639255 - put= ting the weaker branch in the lead.=C2=A0 If the weaker branch is sufficien= tly lucky, and finds a solution before the dominant branch then this soluti= on will have a higher overall fitness score, and this solution will propaga= te as it has the higher value.=C2=A0 This is also important for transaction= s on the network as they benefit from using the most recently formed block = - which will have the highest local fitness score at the time of its discov= ery.=C2=A0 At this junction, the weaker branch has an opportunity to prevai= l enterally thus ending the split.


Now let us ret= urn to the DoS threat model and explore the worst-case scenario created by = byzantine fault injection. Let us assume that both the weaker group and the= dominant group have produced competing proof-of-work solutions for blocks = 639254 and 639255 respectively.=C2=A0 Let=E2=80=99s assume that the dominan= t group that went with the 1.847 fitness score - also produces a solution w= ith a similar fitness value and advertises the following solution to the ne= twork:


0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113<= /p>

19.414973649464574877549198290879237036867705594421756179

or

3.262 =3D 1.847 + 1.415


A total of 3.2= 62 is still dominant over the lesser 2.772 - in order to overcome this - th= e 2nd winning block needs to make up for all of the losses in the previous = block.=C2=A0 In this scenario, in order for the weaker chain to supplant th= e dominant chain it must overcome a -0.49 point deficit. In traditional Nak= amoto Consensus the nodes would see both forks as authoritative equals whic= h creates a divide in mining capacity while two groups of miners search for= the next block.=C2=A0 In Floating-Point Nakamoto Consensus any nodes recei= ving both forks, would prefer to mine on the chain with an overall fitness = score of +3.262 - making it even harder for the weaker chain to find miners= to compete in any future disagreement, thereby eroding support for the wea= ker chain. This kind of comparison requires an empirical method for determi= ning fitness by miners following the same same system of rules will insure = a self-fulfilled outcome.=C2=A0 After all nodes adopt the dominant chain no= rmal Nakamoto Consuess can resume without having to take into consideration= block fitness. This example shows how disagreement can be resolved more qu= ickly if the network has a mechanism to resolve ambiguity and de-incentivis= e dissent.

Soft Fork

Blockchain net= works that would like to improve the consensus generation method by adding = a fitness test should be able to do so using a =E2=80=9CSoft Fork=E2=80=9D = otherwise known as a compatible software update.=C2=A0 By contrast a =E2=80= =9CHard-Fork=E2=80=9D is a separate incompatible network that does not form= the same consensus.=C2=A0 Floating-Point Nakamoto Consensus can be impleme= nted as a soft-fork because both patched, and non-patched nodes can co-exis= t and non-patched nodes will benefit from a kind of herd immunity in overal= l network stability.=C2=A0 This is because once a small number of nodes sta= rt following the same rules then they will become the deciding factor in wh= ich chain is chosen.=C2=A0 Clients that are using only traditional Nakamoto= Consensus will still agree with new clients over the total chain length. M= iners that adopt the new strategy early, will be less likely to lose out on= mining invalid solutions.

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 becom= e an essential utility, and attacks against our networks must be avoided an= d adapting, patching and protecting the network is a constant effort. An or= ganized attack against a cryptocurrency network will undermine the guarante= es that blockchain developers are depending on.


Any blockchain= using Nakamoto Consensus can be modified to use a fitness constraint such = as the one used by a Floating-Point Nakamoto Consensus.=C2=A0 An example im= plementation has been written and submitted as a PR to the bitcoin core whi= ch is free to be adapted by other networks.






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/bitcoi=
n-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000c417c605b025786b--