1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <franck@coblox.tech>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 09C0FC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2020 01:58:38 +0000 (UTC)
Received: by mail-io1-f44.google.com with SMTP id y16so793710ioc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
In-Reply-To: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
From: Franck Royer <franck@coblox.tech>
Date: Tue, 29 Sep 2020 11:51:03 +1000
Message-ID: <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
To: Mike Brooks <f@in.st.capital>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: 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
<div dir=3D"ltr"><div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin=
-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br></div><div>[snip] <br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span id=
=3D"gmail-m_3279177725432408729gmail-m_2766209350405513116gmail-docs-intern=
al-guid-77a2432b-7fff-62c3-0753-fe93652ca512"></span><div><span id=3D"gmail=
-m_3279177725432408729gmail-m_2766209350405513116gmail-docs-internal-guid-7=
7a2432b-7fff-62c3-0753-fe93652ca512"><p dir=3D"ltr" style=3D"line-height:1.=
38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fam=
ily:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeri=
c:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space=
:pre-wrap">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</span></p></span></div></div></blockquote><div><br></div><div>Hi Mik=
e,</div><div><br></div><div>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?<br></div><div>=C2=A0</div><div>Also, can =
you elaborate if anything special would happen if the competitive chains we=
re created around a difficulty adjustment?<br></div><div><br></div><div>Che=
ers, Franck<br></div><div><br></div><div>[snip] <br></div></div></div>
--000000000000a83d7e05b06a048d--
|
