From: "David A. Harding" <dave@dtrt.org>
To: Mike Brooks <m@ib.tc>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Sat, 26 Sep 2020 06:11:23 -0400 [thread overview]
Message-ID: <20200926101123.utnxzs7kx5ozwedm@ganymede> (raw)
In-Reply-To: <CALFqKjTcTVK40XpzRR1Mre42CNURgyP1ppG4ZeTfs5a51WiesA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev wrote:
> - with a fitness test you have a 100% chance of a new block from being
> accepted, and only a 50% or less chance for replacing a block which has
> already been mined. This is all about keeping incentives moving forward.
FYI, I think this topic has been discussed on the list before (in
response to the selfish mining paper). See this proposal:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003583.html
Of its responses, I thought these two stood out in particular:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003584.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003588.html
I think there may be some related contemporary discussion from
BitcoinTalk as well; here's a post that's not directly related to the
idea of using hash values but which does describe some of the challenges
in replacing first seen as the tip disambiguation method. There may be
other useful posts in that thread---I didn't take the time to skim all
11 pages.
https://bitcointalk.org/index.php?topic=324413.msg3476697#msg3476697
-Dave
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-26 10:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 19:40 [bitcoin-dev] Floating-Point Nakamoto Consensus 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 [this message]
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
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=20200926101123.utnxzs7kx5ozwedm@ganymede \
--to=dave@dtrt.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=m@ib.tc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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