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
|
Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 728D6C0859
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Sep 2020 16:33:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 49474875DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Sep 2020 16:33:30 +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 Cv2SC9dtLg-u
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Sep 2020 16:33:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by hemlock.osuosl.org (Postfix) with ESMTPS id EFDBA875CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Sep 2020 16:33:28 +0000 (UTC)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com
[209.85.208.41]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08PGXQdd003034
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 25 Sep 2020 12:33:27 -0400
Received: by mail-ed1-f41.google.com with SMTP id c8so3121006edv.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Sep 2020 09:33:27 -0700 (PDT)
X-Gm-Message-State: AOAM530F65bnb7+iBOcYDfkki0fTcCCHRXAMVXhbx35ywFuXv+aJ5GJT
OmdEa+Y0J7q7dHPyX+5UkSASRQBJvaA7ubXW8jo=
X-Google-Smtp-Source: ABdhPJwyEIDiDths3XZoKF3Ni/+QBc8eyneOwfHWQDRIcKaR5rd5KIac9ZoM1OWC2arMHLRWtLsNrZYZWJe0jPQ4UXI=
X-Received: by 2002:a05:6402:1717:: with SMTP id
y23mr2324440edu.112.1601051606146;
Fri, 25 Sep 2020 09:33:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
<dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
In-Reply-To: <dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 25 Sep 2020 09:33:14 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>
Message-ID: <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>
To: bitcoin ml <bitcoin.ml@thomaskerin.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004063dc05b025e02a"
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: Fri, 25 Sep 2020 16:33:30 -0000
--0000000000004063dc05b025e02a
Content-Type: text/plain; charset="UTF-8"
If I understand correctly, this is purely a policy level decision to accept
first-seen or a secondary deterministic test, but the most-work chain is
still always better than a "more fit" but less work chain.
In any case, I'm skeptical of the properties of this change. First-seen has
a nice property that once you receive a block, you have a substantially
reduced incentive to try to orphan it because the rest of the network is
going to work on building on that block. With fitness, I have a 50% shot if
I mine a block of mine being accepted, so floating point would have the
effect of destabilizing consensus convergence at the tip.
I could see using a fitness rule like this be useful if you see both blocks
within some very small window, e.g., 10 seconds, as it could decrease
partition risk if it's likely the orphan was mined within close range of
the other.
--0000000000004063dc05b025e02a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If I und=
erstand correctly, this is purely a policy level decision to accept first-s=
een or a secondary deterministic test, but the most-work chain is still alw=
ays better than a "more fit" but less work chain.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">In any ca=
se, I'm skeptical of the properties of this change. First-seen has a ni=
ce property that once you receive a block, you have a substantially reduced=
incentive to try to orphan it because the rest of the network is going to =
work on building on that block. With fitness, I have a 50% shot if I mine a=
block of mine being accepted, so floating point would have the effect of d=
estabilizing consensus convergence at the tip.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">I could see using a fi=
tness rule like this be useful if you see both blocks within some very smal=
l window, e.g., 10 seconds, as it could decrease partition risk if it's=
likely the orphan was mined within close range of the other.<br></div></di=
v></div>
--0000000000004063dc05b025e02a--
|
