Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91558C016F for ; Tue, 29 Sep 2020 03:45:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6C6A987084 for ; Tue, 29 Sep 2020 03:45:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75WIhO6UkCoB for ; Tue, 29 Sep 2020 03:45:12 +0000 (UTC) X-Greylist: delayed 00:34:07 by SQLgrey-1.7.6 Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254083.outbound.protection.outlook.com [40.92.254.83]) by hemlock.osuosl.org (Postfix) with ESMTPS id AFEE487079 for ; Tue, 29 Sep 2020 03:45:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KNb8etBE7PaJhxiCSD8lYPbknMH8QfcGbl9+5SkvzJpAtBfDciEE/5QmpWEIGDnWoZfJgKi/mA2nmna9KV6nD6YW7d6eL8BL6ETh6LD03BKaSyflgMkJzCjb9jUwqvvPxqmtgHUhAs6wXMPcC88vuYB1YLUlj6UYrJRXLrCePglxsQbU6LZBXKPW2Z87cNgeJETOf6+2sfRdUQXxJmH0NAJgOzDjgNxGvFEi2m2sXHscUBGtROQO20Vy8T5Z6NIBbytPMiB4matraKTIpWP/G5jO/a4YSQeKcZwHpjKVeGe8smm50opXB+dZ+dd/6hNDYzPD5Q/Ui4p1yxbdMrPp/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1o+KG908f5cQg4YHPAhLCse+zPYnQcojCAP4i52Uk+U=; b=X6LfaT+qkj4seZQPgqwskzLNHknz5tU/09VT84qHGgZ7XEBiVDjc6Ea1OnXOKgIXB5mFMefaoykzshsiDUetbIRdlK8dCE7jf6sABEGuXHE9aaC+BoBrOWmmAzYOkTK5GadQS/jwntwjUDerE9U1Rr0kOLhsNuV0bwZcvhq/E7Ektfbvqdkj5ZMG2R55W848Mbm6TYa1Zs4uJyQXDC2z7FGViaaOC59A3s8UlJTrxHDQ9jp90UUvq7vGklFI15OciqNFakUfiGvI0l8197+v32u+6bI9iN+g2hiKy4E5AeCwy6UgP2cD2yVdzKOUBuRDYB0x00q0jHlKCMlvQQ3SEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from SG2APC01FT024.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::50) by SG2APC01HT064.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::295) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Tue, 29 Sep 2020 03:10:36 +0000 Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM (10.152.250.51) by SG2APC01FT024.mail.protection.outlook.com (10.152.250.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Tue, 29 Sep 2020 03:10:36 +0000 Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM ([fe80::7824:d690:5506:7f95]) by PSXP216MB0967.KORP216.PROD.OUTLOOK.COM ([fe80::7824:d690:5506:7f95%8]) with mapi id 15.20.3412.029; Tue, 29 Sep 2020 03:10:36 +0000 From: LORD HIS EXCELLENCY JAMES HRMH To: bitcoin-dev , Mike Brooks Thread-Topic: [bitcoin-dev] Floating-Point Nakamoto Consensus Thread-Index: AQHWkzTDRX06cyQol02+jyZ664P+sql+74xp Date: Tue, 29 Sep 2020 03:10:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D21F0FC69498A8EE0917DC1E091E220B1169ACB7F27A129D8EF1C6A78A3321A5; UpperCasedChecksum:DE8689A99E253EDD05EDF7B83C3D05658BEB624AC49E7CADFD1298C4FE0AFAAC; SizeAsReceived:6908; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [jMazCu4uEbWNOahT/MUJdQtb1b91/DEb] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 04594707-bf8f-4e03-20d3-08d864253c6a x-ms-traffictypediagnostic: SG2APC01HT064: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rwks7quhLH2TOTf8dqbpFnQTReNKaOBqtekM3e4Rn0vTOJNJks8NC7/KBv/fdovaRUrpef6uj4gSlz4Y/m5uFd4shGyFiZ7FP6Cr5pkPmqrRK40UAVpC7Flx1pdXbTmVDJMkzAiuJeuVWHUc6PZeaVdnzOtijwBuy34lv8Q5Czto7/vEOsCf1ejemfLdmeu2RiqoLeKnlBxrEf6omx6NuBLjKLM7DujeiSrJ1QOMQ/bwwB2KKoBl7Gmcqz5Q1mU6 x-ms-exchange-antispam-messagedata: R3RLJz3AbSANAUXzNByqcdgU/Rc/u0cj2X6ZHwfkSzaSJ6xAVuBu0pF0TKuw2UMzmE7Ar6liCjz6dF6ajfVAJe10+fe2xnJqcDTB4hInw2zhMHVFgFv2YuXJxklQNGT/Y9WUF/Rz9r6mV7Z4WRdciQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT024.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 04594707-bf8f-4e03-20d3-08d864253c6a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 03:10:36.2581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT064 X-Mailman-Approved-At: Tue, 29 Sep 2020 07:29:39 +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: Tue, 29 Sep 2020 03:45:16 -0000 --_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 ki= nd of race condition. The said race condition, it is not noted, is 'self-resolving' with the netw= ork adopting the longest chain with the highest proof of work as any conten= tious tip is built on. This is the proper reason for waiting for two confir= mations for a transaction as a minimum proof of its inclusion in the blockc= hain (without fraud), and for waiting for six confirmations before consider= ing that a transaction is 'final'. I take it that your work is intended to allow the network to decide immedia= tely 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 work wi= th the greater precision proof. When comparing two competing blocks there i= s an indirect reference to a higher proof of work due to the greater precis= ion in the block hash, although the answer could have been arrived with few= er attempts. As it is, the total proof of work is not directly calculated b= ut is evaluated as the chain with more blocks being the chain with more pro= of-of-work, whereas in the cases two blocks are received as alternates exte= nding the same chain tip there is currently no method of comparison to dete= rmine which of the blocks, and the correct tip is not chosen without furthe= r proof-of-work to extend a tip. Resolving this reduces the network expense= of reorganisation in ordinary conditions but in the case of a network-spli= t 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 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 been = well received and there is a lot of excitement on this side to be sharing i= t 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 better and it= shows. It is wildly underrated that future proofing was never really a co= nsideration in the initial design - but here we are a decade later with ama= zing 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 time to thank the people who worke= d 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 respond to new threats is nothing short of amazin= g - thank you everyone for a great project. This current proposal really has nothing to do with SegWit - but it is an u= pdate that will make the network a little better for the future, and we hop= e you enjoy the paper. PDF: https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floa= ting-Point%20Nakamoto%20Consensus.pdf Pull Request: https://github.com/bitcoin/bitcoin/pull/19665/files --- Floating-Point Nakamoto Consensus Abstract =97 It has been shown that Nakamoto Consensus is very useful in th= e formation of long-term global agreement =97 and has issues with short-ter= m disagreement which can lead to re-organization (=93or-org=94) of the bloc= kchain. A malicious miner with knowledge of a specific kind of denial-of-s= ervice (DoS) vulnerability can gain an unfair advantage in the current Bitc= oin network, and can be used to undermine the security guarantees that deve= lopers rely upon. Floating-Point Nakamoto consensu makes it more expensive= to replace an already mined block vs. creation of a new block, and by reso= lving ambiguity of competition solutions it helps achieve global consumers = more quickly. A floating-point fitness test strongly incentivises the corr= ect network behavior, and prevents disagreement from ever forming in the fi= rst 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-o= f-work is presented as the next solution block in the blockchain. Two solu= tions of the same height are seen as authoritative equals which is the basi= s of a growing disagreement. A node will adopt the first solution seen, as = both solutions propagate across the network a race condition of disagreemen= t is formed. This race condition can be controlled by byzentiene fault inje= ction commonly referred to as an =93eclipsing=94 attack. When two segments= of the network disagree it creates a moment of weakness in which less than= 51% of the network=92s computational resources are required to keep the ne= twork balanced against itself. Nakamoto Consensus Nakamoto Consensus is the process of proving computational resources in ord= er 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-on= e-vote), then representation could be subverted by anyone able to allocate = many IPs. A consensus is only formed when the prevailing decision has the g= reatest proof-of-work effort invested in it. In order for a Nakamoto Consen= sus to operate, the network must ensure that incentives are aligned such th= at the resources needed to subvert a proof-of-work based consensus outweigh= the resources gained through its exploitation. In this consensus model, th= e proof-of-work requirements for the creation of the next valid solution ha= s the exact same cost as replacing the current solution. There is no penalt= y 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 substan= tial barrier for a single dishonest node to overcome. A minimal network peer-to-peer structure is required to support Nakamoto Co= nesus, and for our purposes this is entirely decentralized. Messages are br= oadcast 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 what happene= d while they were gone. This design makes no guarantees that the peers con= nected do not misrepresent the network or so called =93dishonest nodes.=94 = Without a central authority or central view - all peers depend on the data = provided by neighboring peers - therefore a dishonest node can continue unt= il 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 (=930-day=94) which will strictly prevent h= onest nodes from communicating to new members of the network - a so-called = =93total eclipse.=94 The kind of DoS vulnerability needed to conduct an ec= lipse does not need to consume all CPU or computaitly ability of target nod= es - but rather prevent target nodes from forming new connections that woul= d undermine the eclipsing effect. These kinds of DoS vulnerabilities are so= mewhat less substional than actually knocking a powerful-mining node offlin= e. 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 t= o form a connection to a segment of the network that isn=92t entirely suppr= essed. Let us assume a defense-in-depth strategy and plan on this kind of f= ailure. Let us now consider that the C++ Bitcoind has a finite number of worker thr= eads and a finite number of connections that can be serviced by these worke= rs. When a rude client occupies all connections - then a pidgin-hole princ= iple comes into play. If a network's maximum capacity for connection handle= rs =91k=92, is the sum of all available worker threads for all nodes in the= network, establishing =91k+1=92 connections by the pidgin-hole principle w= ill 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=92s assume a dishonest node is modified in two ways - it increases = the maximum connection handles to hundreds of thousands instead of the curr= ent value which is about 10. Then this node is modified to ignore any solut= ion blocks found by honest nodes - thus forcing the dishonest side of the n= etwork 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 solu= tion propagates through nodes one hop at a time. This propagation can be pr= edicted and shaped by dishonest non-voting nodes that are being used to pas= s messages for honest nodes. At this point an attacker can expedite the transmission of one solution, wh= ile slowing another. If ever a competing proof-of-work is broadcasted to th= e network, the adversary will use their network influence to split knowledg= e of the proof-of-work as close to =BD as possible. If the network eclipse = is perfect then an adversary can 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 attacker from adding additional computation resou= rces or adjusting the eclipsing effect to make sure the system is in balanc= e. As long as two sides of the network are perfectly in disagreement 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=92s 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. This attack is convenient from the adversary=92s perspective, Bitcoin bein= g a broadcast network advertises the IP addresses of all active nodes - and= Shodan and the internet scanning project can find all passive nodes respon= ding on TCP 8333. This should illuminate all honest nodes on the network, = and even honest nodes that are trying to obscure themselves by not announci= ng their presence. This means that the attacker doesn=92t need to know exa= ctly which node is used by a targeted exchange - if the attacker has subdue= d 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 sep= arate merkel-tree formation and therefore a separate ledger of transactions= . An adversary will then broadcast currency deposits to public exchanges, b= ut only on the weaker side, leaving the stronger side with no transaction f= rom the adversary. Any exchange that confirms one of these deposits is rely= ing 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 out the account balance on a = different blockchain - such as Tether which is an erc20 token on the Ethere= um network which would be unaffected by this attack. When the weaker chain= collapses, the transaction that the exchange acted upon is no longer codif= ied in Bitcoin blockchain's global ledger, and will be replaced with a vers= ion of the that did not contain these deposits. Nakamoto Consensus holds no guarantees that it=92s process is deterministic= . In the short term, we can observe that the Nakamoto Consensus is empiric= ally non-deterministic which is evident by re-organizations (re-org) as a m= ethod of resolving disagreements within the network. During a reorganizat= ion 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 disr= upt the normal flow of messages on the network which creates disagreement b= etween miners. DeFi (Decentralized Finance) and smart-contract obligations depend on netwo= rk stability and determinism. Failure to pay contracts, such as what happe= ned on =93black thursday=94 resulted in secured loans accidentally falling = into redemption. The transactions used by a smart contract are intended to= be completed quickly and the outcome is irreversible. However, if the blo= ckchain network has split then a contract may fire and have it=92s side-eff= ects execute only to have the transaction on the ledger to be replaced. An= other example is that a hard-fork might cause the payer of a smart contract= to default - as the transaction that they broadcasted ended up being on th= e weaker chain that lost. Some smart contracts, such as collateral backed l= oans 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 attack= er is able to exert the computational power to ensure that proof-of-work bl= ocks are regularly found on both sides of the network. The amount of resou= rces needed to balance the network against itself is far less than a 51% at= tack - thereby undermining the security guarantees needed for a decentraliz= ed untrusted payment network to function. 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 de= cision in which chain to collapse is up to the individual with the most IP = address, not the most computation. In Satoshi Nakamoto=92s original paper it was stated that the electorate sh= ould 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 d= isagreements must be fully decentralized. A blockchain is allowed to split = because there is ambiguity in the Nakamoto proof-of-work, which creates the= environment for a race-condition to form. To resolve this, Floating-Point = Nakamoto Consensus makes it increasingly more expensive to replace the curr= ent winning block. This added cost comes from a method of disagreement reso= lution where not every solution block is the same value, and a more-fit sol= ution 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-race,= whereby the winning team=92s strength is carried forward and the loser wil= l have to work harder and harder to maintain the disagreement. In most cas= es 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 cements the lead of the winn= er and to greatly incentivize the network to adopt the dominant chain no ma= tter how many valid solutions are advertised, or what order they arrive. The first step in Floating-Point Nakamoto Consensus is that all nodes in th= e 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 blocks advertised for= the same height - then a floating-point fitness value is calculated and th= e solution with the higher fitness value is the winner which is then propag= ated 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 mos= t-fit block, failing to do so risks wasting resources on a mining of a bloc= k that would be discarded. To make sure that incentives are aligned, any z= ero-prefix proof of work could be the next solution, but now in order to re= place the current winning solution an adversary would need a zero-prefix bl= ock that is also more fit that the current solution - which is much more co= mputationally 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, ea= ch 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 ti= p - and it is better to have it done as quickly as possible so that consens= us is maintained. In order to have a purely decentralized solution, this kind of agreement mu= st be empirically derived from the existing proof-of-work so that it is uni= versally and identically verifiable by all nodes on the network. Additiona= lly, this fitness-test evaluation needs to ensure that no two competing sol= utions can be numerically equivalent. Let us suppose that two or more valid solutions will be proposed for the sa= me block. To weigh the value of a given solution, let's consider a solutio= n 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 e= nds 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 to represent= some fraction of additional work exerted by the miner. 1.847 Now let us suppose that a few minutes later another solution is advertised = to the network shown in base16 below: 000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2 The solution above also has 19 prefixed zeros, and is being broadcast for t= he same blockheight value of 639254 - and a fitness score of 1.282. With N= akamoto Consensus both of these solutions would be equivalent and a given n= ode would adopt the one that it received first. In Floating-Post Nakamoto = Consensus, we compare the fitness scores and keep the highest. In this cas= e no matter what happens - some nodes will have to change their tip and a f= itness test makes sure this happens immediately. 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 sho= uldn=92t need to validate any lower-valued solution. In fact this fitness = value has a high degree of confidence that it won=92t be unseated by a larg= er value - being able to produce a proof-of-work with 19 0=92s and a decima= l 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. Mi= ners are incentivized to support the dominant chain which helps preserve th= e global consensus. Let us assume that the underlying cryptographic hash-function used to gener= ate a proof-of-work is an ideal primitive, and therefore a node cannot forc= e the outcome of the non-zero component of their proof-of-work. Additional= ly if we assume an ideal cipher then the fitness of all possible solutions = is gaussian-random. With these assumptions then on average a new solution w= ould split the keyspace of remaining solutions in half. Given that the wor= k needed to form a new block remains a constant at 19 blocks for this peri= od - 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 soluti= on. To leverage a chain replacement on nodes conducting Floating-Point Nak= amoto Consensus a malicious miner would have to expend significantly more r= esources. Each successive n+1 solution variant of the same block-height must therefor= e 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 tim= e 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 r= easoning, we can see that a demissiniong keyspace increases the amount of w= ork 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 proo= f-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 domina= nt 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 va= lue of 1.240 as the previous block. Now, let=92s say this group of isolat= ed miners manages to present a new conflicting proof-of-work solution for 6= 39255: 000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6 The above base16 block has a fitness score of 1.532 The fitness value for = 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 heigh= t 639255 - putting the weaker branch in the lead. If the weaker branch is = sufficiently lucky, and finds a solution before the dominant branch then th= is solution will have a higher overall fitness score, and this solution wil= l propagate as it has the higher value. This is also important for transac= tions on the network as they benefit from using the most recently formed bl= ock - which will have the highest local fitness score at the time of its di= scovery. 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 scenar= io created by byzantine fault injection. Let us assume that both the weaker= group and the dominant group have produced competing proof-of-work solutio= ns for blocks 639254 and 639255 respectively. Let=92s assume that the domi= nant group that went with the 1.847 fitness score - also produces a solutio= n with a similar fitness value and advertises the following solution 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 over= come 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 su= pplant the dominant chain it must overcome a -0.49 point deficit. In tradit= ional Nakamoto Consensus the nodes would see both forks as authoritative eq= uals which creates a divide in mining capacity while two groups of miners s= earch for the next block. In Floating-Point Nakamoto Consensus any nodes r= eceiving both forks, would prefer to mine on the chain with an overall fitn= ess score of +3.262 - making it even harder for the weaker chain to find mi= ners to compete in any future disagreement, thereby eroding support for the= weaker chain. This kind of comparison requires an empirical method for det= ermining fitness by miners following the same same system of rules will ins= ure a self-fulfilled outcome. After all nodes adopt the dominant chain nor= mal Nakamoto Consuess can resume without having to take into consideration = block fitness. This example shows how disagreement can be resolved more qui= ckly 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 met= hod by adding a fitness test should be able to do so using a =93Soft Fork= =94 otherwise known as a compatible software update. By contrast a =93Hard= -Fork=94 is a separate incompatible network that does not form the same con= sensus. Floating-Point Nakamoto Consensus can be implemented as a soft-for= k because both patched, and non-patched nodes can co-exist and non-patched = nodes will benefit from a kind of herd immunity in overall network stabilit= y. This is because once a small number of nodes start following the same r= ules then they will become the deciding factor in which chain is chosen. C= lients that are using only traditional Nakamoto Consensus will still agree = with new clients over the total chain length. Miners that adopt the new str= ategy early, will be less likely to lose out on mining invalid solutions. Conclusion Floating-Point Nakamoto consensus allows the network to form a consensus mo= re quickly by avoiding ambiguity allowing for determinism to take hold. Bit= coin 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 will undermin= e the guarantees that blockchain developers are depending on. Any blockchain using Nakamoto Consensus can be modified to use a fitness co= nstraint such as the one used by a Floating-Point Nakamoto Consensus. An e= xample 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 fo= llowing pull request: https://github.com/bitcoin/bitcoin/pull/19665/files Paper: https://github.com/in-st/Floating-Point-Nakamoto-Consensus https://in.st.capital --_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Good Afternoon,

Re: [bitcoin-dev] Floating-Point Na= kamoto Consensus

I note that the discussion thread f= or this proposal has previously received HARD_NAK

I note in the whitepaper the follow= ing 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 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 intende= d 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 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.

 
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 <bit= coin-dev-bounces@lists.linuxfoundation.org> on behalf of Mike Brooks via= bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Friday, 25 September 2020 5:40 AM
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Floating-Point Nakamoto Consensus
 
  Hey Everyone,

 A lot of work has gone into this paper, and the current revision= has been well received and there is a lot of excitement on this side to&nb= sp;be 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.  It is wildly= underrated that future proofing was never really a consideration in t= he initial design - but here we are a decade later with amazing soluti= ons 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 time 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 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 SegWit - but = it is an update that will make the network a little better for the future, = and we hope you enjoy the paper. 

 

---


Floating-Point Naka= moto Consensus


Abs= tract =97 It has been s= hown that Nakamoto Consensus is very useful in the formation of long-term global agreement =97 and has issues w= ith short-term disagreement which can lead to re-organization (=93or-org=94= ) of the blockchain.  A malicious miner with knowledge of a specific k= ind 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.  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.  A floating-point fitness test strongly ince= ntivises 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 ful= ly distributed p2p network.  A problem arises when more than one proof= -of-work is presented as the next solution block in the blockchain.  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 =93eclipsing=94 attack.  When tw= o segments of the network disagree it creates a moment of weakness in which= less than 51% of the network=92s computational resources are required to k= eep the network balanced against itself. 

Nakamoto Consensus

Nakamoto Consensus is the process of proving computational resources in order to de= termine eligibility to participate in the decision making process.  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.  This design ma= kes no guarantees that the peers connected do not misrepresent the network = or so called =93dishonest nodes.=94 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.

Security 

In this threat model let us assume a malicious miner possesses knowledge of a= n unpatched DoS vulnerability (=930-day=94) which will strictly prevent hon= est nodes from communicating to new members of the network - a so-called = =93total eclipse.=94  The kind of DoS vulnerability 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.  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=92t entirely suppressed. Let us assume a defense-in-depth strateg= y 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.=   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 =91k=92, is the sum of all availa= ble worker threads for all nodes in the network, establishing =91k+1=92 con= nections 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=92s assume a dishonest node is modified in two ways - it increases 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 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.  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 =BD as possible. If the network eclipse is perfect then an adversary can l= everage an eigen-vector of computational effort to keep the disagreement in= balance for as long as it 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 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=92s transactions have been validated on the honest chain - at wh= ich point the attacker will add more nodes to the dishonest chain to make s= ure 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=92s perspective,  Bitcoin bei= ng a broadcast network advertises the IP addresses of all active nodes - an= d Shodan and the internet scanning project can find all passive nodes respo= nding on TCP 8333.  This should illuminate all honest nodes on the network, and even honest nodes that are trying to = obscure themselves by not announcing their presence.  This means that = the attacker doesn=92t need to know exactly which node is used by a targete= d 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.  When the weaker chain collapses, the transaction tha= t the exchange acted upon is no longer codified in Bitcoin blockchain's glo= bal ledger, and will be replaced with a version of the that did not contain= these deposits.


Nakamoto Consensus holds no guarantees that it=92s process is deterministic.  = 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.   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. 


DeFi (Decentralized Finance) and smart-contract obligations depend on network s= tability and determinism.  Failure to pay contracts, such as what happ= ened on =93black thursday=94 resulted in secured loans accidentally falling= into redemption.  The transactions used by a smart contract are intended to be completed quickly and the outcome i= s irreversible.  However, if the blockchain network has split then a c= ontract may fire and have it=92s side-effects execute only to have the tran= saction on the ledger to be replaced.  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.=  


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.  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.  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=92s original paper it was stated that the electorate shou= ld be represented by computational effort in the form of a proof-of-work, a= nd 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 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=92s strength is carried forward 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 bl= ock thereby expediting the formation of a global consensus.  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.  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.  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.  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.  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.  To weigh the value of a given solution, let's consider a solut= ion 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 w= ith 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 o= ne complete solution, and use a rounded floating-point value to represent s= ome fraction of additional work exerted by the miner. 

   = ;1.847


Now let us suppose that a few minutes later another solution is advertised 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.  With= Nakamoto Consensus both of these solutions would be equivalent and a given= node would adopt the one that it received first.  In Floating-Post Nakamoto Consensus, we compare the fitness s= cores and keep the highest.  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. 


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= =92t need to validate any lower-valued solution.  In fact this fitness= value has a high degree of confidence that it won=92t be unseated by a larger value - being able to produce a pr= oof-of-work with 19 0=92s and a decimal component greater than 0.847 is non= -trivial.  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.&nbs= p;

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.  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.  Given that the work needed to form a  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.  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.   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 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.  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.  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.   Now, let=92s say this group= of isolated miners manages to present a new conflicting proof-of-work solu= tion for 639255:


   = ;  000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091= a6


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 bene= fit 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 the weaker gr= oup and the dominant group have produced competing proof-of-work solutions = for blocks 639254 and 639255 respectively.  Let=92s assume that the dominant group that went with the 1.847 fitness sc= ore - also produces a solution with a similar fitness value and advertises = the following solution to the network:


0000000000000000000= 455207e375bf1dac0d483a7442239f1ef2c70d050c113

19.4149736494645748= 77549198290879237036867705594421756179

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

Soft 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 =93Soft Fork=94 otherwis= e known as a compatible software update.  By contrast a =93Hard-Fork= =94 is a separate incompatible network that does not form the same consensus.  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.  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.  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.

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 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.  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 implemen= tation of Floating-Point Nakamoto consensus is in the following pull request:

https://github.com/bitcoin/bitcoin/pu= ll/19665/files


Paper:

https://github.com/in-st/Float= ing-Point-Nakamoto-Consensus

https://in.st.capital


--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_--