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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Return-Path: <yanmaani@cock.li>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id C939BC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 16:02:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id AAF7787FCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 16:02:18 +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 ODIWkLbC7-OS
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 16:02:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.cock.li (mail.cock.li [37.120.193.124])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 6999687E75
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 16:02:16 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1602777729; bh=AD1UImQLROMtXFFo7SG+F005h6q9Y2sw2ELHz4XF6Wc=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=ARboFYqhwlxC747RglMcYjey31xcom+gJs10i5+M0syY9TNCRTpgWznssIpouhXyU
G528in44LB2SsggqYiuH5CZxG4mDoR3K4qn5EX0LE/QS2A7IYNdEP/Qn2tRHvpDEOT
0FkDp/Qd/nlYjyNJDsZ/5sEBOen8FFySeKLgPo0M25vTP9S1M4CqeEzdrneUHubLdH
PFs76RSEJXrav3AMaulQucoXvu47rWkqmHjO3cpfroXABtHeDggX44p3//0DcF6oPf
YErsbNkDvtgCYalryOFpmILKhDt/r44FPp+N0EuEDfk6dESSBX9MghYH4kzYucMuQ0
z3rFX3bV2mNHQ==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 15 Oct 2020 16:02:09 +0000
From: yanmaani@cock.li
To: Mike Brooks <m@ib.tc>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CALFqKjRn8GM0H=ph0S7i=cm-w1LbjGSwwn1BTP=t2WgcXw2h9g@mail.gmail.com>
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
<PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
<CALFqKjRn8GM0H=ph0S7i=cm-w1LbjGSwwn1BTP=t2WgcXw2h9g@mail.gmail.com>
Message-ID: <3f39574d60ad9eecbc0a410fe04b1d54@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.10
X-Mailman-Approved-At: Thu, 15 Oct 2020 16:21:14 +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: Thu, 15 Oct 2020 16:02:18 -0000
What if a miner mines a block that has a very high block reward (i.e.
confirmed a juicy transaction), while at the same time having a floating
point fitness very close to the minimum?
For the sake of argument, let's say the block reward is 6.50 (4% more
than average), the fitness is 1.001, and the orphan rate is 0.3%.
With Nakamoto consensus, the miners would (allegedly) find it in their
best interest to work on that block, since it was first. It's a problem
when they don't, but the system basically works right now.
With FPNC, the miners have two equally valid options:
1) Attempt to create a block building on top of that block (reward:
6.25)
2) Attempt to replace (reward: 6.50)
If they do (1), their probability of success given a matching hash is
(100 - orphan rate)%, which is very close to 100%.
If they do the second, their probability of success given a hit is (100
- percentile(1.001)), which also is very close to 100%.
Option 1 has EV of .997 * 1 * 6.25 = 6.25.
Option 2 has EV of (1 - quantile(1.001)) * 1.04 * 6.25, which is surely
above 6.25. I don't know how to calculate the quantile, but it's
obvious.
With the block subsidy getting lower and lower as time goes on, the
probability of this happening goes up.
Don't we want miners to always keep the chain going forward? Your
proposal incentivizes reorgs.
On 2020-10-10 01:26, Mike Brooks via bitcoin-dev wrote:
> James,
>
> FPNC and NC will always select the highest-work chain, I am suggesting
> that by adding more bits of precision we avoid confusion.
>
> Part 2 -> Using a genetic algorithm that passes fitness with heredity
> to resolve disagreements has never been introduced to this mailing
> list. This hard-nack is null and void.
>
> Best Regards,
> Michael
>
> On Tue, Sep 29, 2020 at 12:30 AM LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 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 confirmations for a transaction as a minimum
>> proof of its inclusion in the blockchain (without fraud), and for
>> waiting for six confirmations before considering that a transaction
>> is 'final'.
>>
>> I take it that your work is intended 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 work with the greater precision proof. When
>> comparing two competing blocks there is an indirect reference to a
>> higher proof of work due to the greater precision in the block hash,
>> although the answer could have been arrived with fewer attempts. As
>> it is, the total proof of work is not directly calculated but is
>> evaluated as the chain with more blocks being the chain with more
>> proof-of-work, whereas in the cases 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 further 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-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 [1]
>> www.go-overt.com [2]
>> and other projects
>>
>> earn.com/willtech [3]
>> linkedin.com/in/damianwilliamson [4]
>>
>> m. 0487135719
>> f. 61261470192
>>
>> ----
>>
>> -------------------------
>>
>> From: bitcoin-dev <bitcoin-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 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 better 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 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 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 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:...
>> 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 will 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 [5]
>> Paper:
>>
>> https://github.com/in-st/Floating-Point-Nakamoto-Consensus [6]
>>
>> https://in.st.capital [7]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> Links:
> ------
> [1] http://www.willtech.com.au
> [2] http://www.go-overt.com
> [3] http://earn.com/willtech
> [4] http://linkedin.com/in/damianwilliamson
> [5] https://github.com/bitcoin/bitcoin/pull/19665/files
> [6] https://github.com/in-st/Floating-Point-Nakamoto-Consensus
> [7] https://in.st.capital/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|