From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 09C0FC016F for ; Tue, 29 Sep 2020 01:58:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id E750384798 for ; Tue, 29 Sep 2020 01:58:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjdxC+Drh1Vq for ; Tue, 29 Sep 2020 01:58:39 +0000 (UTC) X-Greylist: delayed 00:07:24 by SQLgrey-1.7.6 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by whitealder.osuosl.org (Postfix) with ESMTPS id 1546084442 for ; Tue, 29 Sep 2020 01:58:38 +0000 (UTC) Received: by mail-io1-f44.google.com with SMTP id y16so793710ioc.0 for ; Mon, 28 Sep 2020 18:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coblox.tech; s=coblox; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=n0ClZ+VRykZOmj04ujy/LXrTvZ7jpa+SmBxqfANKRJ8=; b=fyLV4x94QURLscfDk+A1CKvDkbEhIJODB5S+ENh92z66hvTFzfdAAk5sR1sxcMGnLv EGpmGIxXglBa/2Lf7tVZY7rNDPiBb7F17tLX5BFzaMQtr/Qpmvm7CERAlbndHghdd2Ne 3sUgXdKT5ifH+Bn09Y+yrHBbk/vZJhkHoFSrawxQwQCCXaR75+bzxkbB9a4MzZmZu1SW zp8LMSJsnimxJFgYYVh9e9cVmcruLG/RJ8aCQYjeAKQqNK7kqZ05cO2jK4hKWPUR40ml szC7IoC5zhJ5Wr+ZFPeYQLxwbJEC2sEiy22FabtZ8tcNXkELbyGZlWp7EEHxiVVhamH4 shmw== 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=n0ClZ+VRykZOmj04ujy/LXrTvZ7jpa+SmBxqfANKRJ8=; b=PrYd3MecveF9jOrYyWpVs5fwOzvTox+nzUJ4GlZBsnfGh/Rxd96NRK34N0p8WjYhD3 /1aFlUgafbqjVWV7sCwLfS0Asvhpm+VXAQNrQIu33dpHkef9hjubhmuRQRsfyFMfaQRB 0TgGVkEhmtkojLF5+CWx1rZPBGG4xrk8mv6nKYCtwUaL5TKjAKBzoWEG0/YTasUmET8q EWQk+Dwk13ArSTiH6hgVBVVCX76FRNaZRdXXuIakyj6iN0Fx+dn2GWbzg+wdBKgiTlYT Stqd1JRMhbn8Yra5nb+/sZ5Ttbjaqot5h7RzCX4dNwOD5i3wuXCPJpkbcis8td1yFZfz WYNA== X-Gm-Message-State: AOAM532k2+OjKv4pazQgBwDuc6uJpnx8MUjt3TU/BzAzBtLSajoeSx6U rSYfX01RZ8+pjCfBVURz4/YNqZtSRnia6OwygqpLbYMM6sXrqK0h X-Google-Smtp-Source: ABdhPJydH+lj7StvqfdnvOQ54y/Hm1VUXB0Ub7zkngh7EPgvYbHtiKOfAi1qsiOgn2Un3GihDa620sWX5ohy55fSrnY= X-Received: by 2002:a92:d105:: with SMTP id a5mr1081183ilb.206.1601344274703; Mon, 28 Sep 2020 18:51:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Franck Royer Date: Tue, 29 Sep 2020 11:51:03 +1000 Message-ID: To: Mike Brooks , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a83d7e05b06a048d" X-Mailman-Approved-At: Tue, 29 Sep 2020 02:18:44 +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 01:58:40 -0000 --000000000000a83d7e05b06a048d Content-Type: text/plain; charset="UTF-8" On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: [snip] > 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 scores and keep the highest. In this > case no matter what happens - some nodes will have to change their tip and > a fitness test makes sure this happens immediately. > Hi Mike, Any reason why you decided to consider the higher value the "fittest" one instead of keeping in line with the difficulty algorithm where smallest values, prefixed with more zeroes, are considered more valuable/difficult? Also, can you elaborate if anything special would happen if the competitive chains were created around a difficulty adjustment? Cheers, Franck [snip] --000000000000a83d7e05b06a048d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin= -dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
[snip]
=

The solution above also has 19 prefixed zeros, and is being broa= dcast for the same blockheight value of 639254 - and a fitness score of 1.2= 82.=C2=A0 With Nakamoto Consensus both of these solutions would be equivale= nt and a given node would adopt the one that it received first.=C2=A0 In Fl= oating-Post Nakamoto Consensus, we compare the fitness scores and keep the = highest.=C2=A0 In this case no matter what happens - some nodes will have t= o change their tip and a fitness test makes sure this happens immediately.= =C2=A0


Hi Mik= e,

Any reason why you decided to consider the high= er value the "fittest" one instead of keeping in line with the di= fficulty algorithm where smallest values, prefixed with more zeroes, are co= nsidered more valuable/difficult?
=C2=A0
Also, can = you elaborate if anything special would happen if the competitive chains we= re created around a difficulty adjustment?

Che= ers, Franck

[snip]
--000000000000a83d7e05b06a048d--