From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Mike Brooks <m@ib•tc>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Mike Brooks <f@in•st.capital>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Wed, 30 Sep 2020 23:44:59 +0000 [thread overview]
Message-ID: <SSp6MfYHW3q4TqoWyK-2ZUzLQbAqaWxTzJd62cAwKd1tFRac-embhjUZKogr3m__GcIezY5-llLyO91lur7bamlM6tiHRs-nGCNMxe2UKLE=@protonmail.com> (raw)
In-Reply-To: <CALFqKjQDx7BrGEUJLhN=VXS8c--bVOJV4pvQTV6ag2Cy+GjWbw@mail.gmail.com>
Good morning Mike,
An observation to be made is that the current "first seen" is more incentive-compatible than floating-point Nakamoto consensus.
If a miner A mines a block at height N, then obviously the first block it has seen is that block.
If due to propagation delays on the network, another miner B mines an alternative block (let us say with more fitness score, regardless of the details of the fitness metric you use) at height N, miner A has no incentive to reject its own version of that block and mine on top of the miner B alternative version, even if floating-point Nakamoto consensus is deployed by most nodes.
Even if the rest of the mining network is now mining on top of the miner B version, if miner A chances on another new block at N+1 built on top of its own version of block N, then it would still win both blocks and earn the block subsidy and fees of two blocks.
And since block height, as I understand it, trumps over floating-point Nakamoto consensus, the B version will be reorganized out anyway in that case.
If miner A had switched to mining on top of the miner B block, then if it won another block at height N+1, it would have lost the block subsidy+fees of the lower-scoring miner A block at height N.
Thus, floating-point Nakamoto consensus is not incentive-compatible, so I doubt it would have any kind of adoption.
The problems with stability you mention can be fixed, fairly trivially, by simply waiting for 3 confirmations rather than just 1 confirmation.
In a relativistic universe, information cannot propagate faster than light-speed, and thus there will always be a communications network delay in propagating data.
As I see it, floating-point Nakamoto consensus cannot fix this issue, as it cannot change underlying laws of the universe.
If your goal is "stability" of some kind, then there is still always a possibility that two miners on opposite sides of the Earth will create blocks at the same height outside of the light cones of each other.
In a relativistic universe, this cannot be eliminated unless all miners occupy the same physical location, i.e. have centralized in the same mining hardware.
One of those two blocks created will, with high probability, have a lower score, and thus any nodes in the light cone of the miner of the lower-scored block will still experience a reorg, as they will first see one block, then switch to the higher-scored block when it arrives to them.
Thus, floating-point Nakamoto consensus cannot provide complete stability of the network, still, as the universe we operate in does not have instantaneous information transfer.
A wise designer of automated systems will ***still*** wait for 3 confirmations before doing anything, and by then, the effects of floating-point Nakamoto consensus will be literally a thing of the past.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-09-30 23:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 19:40 Mike Brooks
2020-09-25 15:18 ` bitcoin ml
2020-09-25 16:04 ` Mike Brooks
2020-09-25 16:33 ` Jeremy
2020-09-25 17:35 ` Mike Brooks
2020-09-26 10:11 ` David A. Harding
2020-09-26 11:09 ` Mike Brooks
2020-09-29 1:51 ` Franck Royer
2020-09-29 16:00 ` Mike Brooks
2020-09-30 6:31 ` ZmnSCPxj
2020-09-30 6:37 ` Mike Brooks
2020-09-30 23:44 ` ZmnSCPxj [this message]
2020-09-30 23:53 ` Mike Brooks
2020-10-01 1:36 ` ZmnSCPxj
[not found] ` <CALFqKjT_ZTnqzhvRRpFV4wzVf2pi=_G-qJvSkDmkZkhYwS-3qg@mail.gmail.com>
[not found] ` <LPR_1lQZZGN-sT86purDUy8X_jF0XH35_xxdaqzRXHXPSZDtGVowS-FgIq1RN2mtT1Ds0bBErYvM-1TF7usCSAjojCCfkk5WOnZAvBLFzII=@protonmail.com>
[not found] ` <CALFqKjR+uK2Rr4dUsL+D=ZUba2sroqnkhC1xcGHdjjupvDc7+Q@mail.gmail.com>
2020-10-01 6:47 ` ZmnSCPxj
2020-10-04 15:58 ` Mike Brooks
2020-10-01 16:42 ` Larry Ruane
2020-10-01 19:26 ` Mike Brooks
2020-09-29 3:10 ` LORD HIS EXCELLENCY JAMES HRMH
2020-10-10 1:26 ` Mike Brooks
2020-10-15 16:02 ` yanmaani
2020-10-08 18:43 ` Bob McElrath
2020-10-10 0:59 ` Mike Brooks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='SSp6MfYHW3q4TqoWyK-2ZUzLQbAqaWxTzJd62cAwKd1tFRac-embhjUZKogr3m__GcIezY5-llLyO91lur7bamlM6tiHRs-nGCNMxe2UKLE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=f@in$(echo .)st.capital \
--cc=m@ib$(echo .)tc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox