From: Eric Voskuil <eric@voskuil•org>
To: Marco Falke <falke.marco@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
Date: Wed, 14 Feb 2018 15:57:10 -0800 [thread overview]
Message-ID: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> (raw)
In-Reply-To: <CAK51vgDaSMH96VmHxgLswVQTxGGjy4VU0VnT4CZ7H+WJrrTApw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1977 bytes --]
On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote:
> I define a buried deployment as a consensus rule change that affects
> validity of blocks that are buried by a sufficiently large number of
> blocks in the current valid most-work chain,
Sufficient for what, specifically?
> but the current block (and all its parents) remain valid.
Remain valid in the case where the depth assumption is "sufficient" to
ensure that a chain split is not possible?
If this was true (which it is not), it would imply that there is no
reason to validate any block deeper than the most recent 25,000.
Presumably this means that people may continuously rely on some
authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000.
> BIP 123 suggests that BIPs in the consensus layer should be assigned a
> label "soft fork" or "hard fork". However, I think the differentiation
> into soft fork or hard fork should not be made for BIPs that document
> buried deployments. In contrast to soft forks and hard forks, buried
> deployments do not require community and miner coordination for a safe
> deployment.
They can only avoid this requirement based on the assumption that the
hard fork cannot result in a chain split. This is not the case.
> For a chain fork to happen due to a buried deployment, a massive chain
> reorganization must be produced off of a block in the very past.
In other words a "buried deployment" is a hard fork that is not likely
to cause a chain split. This is a subjective subcategory of hard fork,
not an independent category - unless maybe you can show that there is
the 25,000 blocks number is an objective threshold.
> In the extremely unlikely event of such a large chain reorganization,
> Bitcoin's general security assumptions would be violated regardless of
> the presence of a buried deployment.
This is untrue. The "security assumptions" of Bitcoin do not preclude
deep reorganizations.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2018-02-14 23:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 22:01 Marco Falke
2018-02-14 22:11 ` Luke Dashjr
2018-02-14 22:20 ` Gregory Maxwell
2018-02-14 23:57 ` Eric Voskuil [this message]
2018-02-18 18:57 ` Marco Falke
2018-02-21 17:27 ` Eric Voskuil
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=8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=falke.marco@gmail$(echo .)com \
/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