* [bitcoin-dev] Amend the BIP 123 process to include buried deployments
@ 2018-02-14 22:01 Marco Falke
2018-02-14 22:11 ` Luke Dashjr
2018-02-14 23:57 ` Eric Voskuil
0 siblings, 2 replies; 6+ messages in thread
From: Marco Falke @ 2018-02-14 22:01 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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, but the current block
(and all its parents) remain valid.
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.
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
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
2018-02-14 22:01 [bitcoin-dev] Amend the BIP 123 process to include buried deployments Marco Falke
@ 2018-02-14 22:11 ` Luke Dashjr
2018-02-14 22:20 ` Gregory Maxwell
2018-02-14 23:57 ` Eric Voskuil
1 sibling, 1 reply; 6+ messages in thread
From: Luke Dashjr @ 2018-02-14 22:11 UTC (permalink / raw)
To: bitcoin-dev, Marco Falke
On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
> 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 also do not require software coordination. Therefore, why should there be
BIPs at all? Seems to me that we should instead add these documents to
https://github.com/bitcoin-core/docs
That being said, I'm also okay with just adding an Annex to the original
softfork/hardfork BIP describing each shortcut. It just seems annoying to have
two BIPs for every protocol change: one for the change itself, and then
another for implementation-specific shortcuts taken.
Luke
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
2018-02-14 22:11 ` Luke Dashjr
@ 2018-02-14 22:20 ` Gregory Maxwell
0 siblings, 0 replies; 6+ messages in thread
From: Gregory Maxwell @ 2018-02-14 22:20 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
>> 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 also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs
In that sense, no but they help people understand the system (e.g. so
they don't go look at implementations and confuse that the activations
they expect are simply not there); and they aid other implementations
in understanding what other people have already analyzed and concluded
was safe. You could certainly get an analysis wrong for one of these
things.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
2018-02-14 22:01 [bitcoin-dev] Amend the BIP 123 process to include buried deployments Marco Falke
2018-02-14 22:11 ` Luke Dashjr
@ 2018-02-14 23:57 ` Eric Voskuil
2018-02-18 18:57 ` Marco Falke
1 sibling, 1 reply; 6+ messages in thread
From: Eric Voskuil @ 2018-02-14 23:57 UTC (permalink / raw)
To: Marco Falke, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
2018-02-14 23:57 ` Eric Voskuil
@ 2018-02-18 18:57 ` Marco Falke
2018-02-21 17:27 ` Eric Voskuil
0 siblings, 1 reply; 6+ messages in thread
From: Marco Falke @ 2018-02-18 18:57 UTC (permalink / raw)
Cc: Bitcoin Protocol Discussion
> They also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs
Consensus is not trivial. I think documentation is important, even if
it seems simple to some.
Personally, I don't care too much where to place the documentation,
but the BIPs repo seems a good place, since it also hosts other
informational documents.
To prevent "two BIPs for every protocol change", related buried
deployments could be bundled. E.g. the ISM BIP 90 change.
On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil <eric@voskuil•org> wrote:
> 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?
Sufficiently large to prevent potential bike-shedding. The expected
number of blocks in two weeks could be considered a lower bound. Then
multiply that by 10 or 20.
>
>> 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.
>
Note that a checkpoint *freezes* the chain completely at a given
height. Buried deployments are *not* checkpoints.
Also note that buried deployments only make sense after a protocol
upgrade has happened (i.e. a soft fork or hard fork). If a miner has
the resources to cause a chain split, they could trivially do that
even in the complete absence of buried deployments. Buried deployments
are *not* a solution to 50% attacks.
>> 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.
Please note that a buried deployment can very well be a soft fork. I
think this makes it even clearer, that such a label makes no sense for
buried deployments.
>> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
2018-02-18 18:57 ` Marco Falke
@ 2018-02-21 17:27 ` Eric Voskuil
0 siblings, 0 replies; 6+ messages in thread
From: Eric Voskuil @ 2018-02-21 17:27 UTC (permalink / raw)
To: Marco Falke, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 5248 bytes --]
On 02/18/2018 10:57 AM, Marco Falke via bitcoin-dev wrote:
>> They also do not require software coordination. Therefore, why should there be
>> BIPs at all? Seems to me that we should instead add these documents to
>> https://github.com/bitcoin-core/docs
>
> Consensus is not trivial. I think documentation is important, even if
> it seems simple to some.
> Personally, I don't care too much where to place the documentation,
> but the BIPs repo seems a good place, since it also hosts other
> informational documents.
>
> To prevent "two BIPs for every protocol change", related buried
> deployments could be bundled. E.g. the ISM BIP 90 change.
You seem to have missed the point. Either the "buried deployment" is a
consensus rule, and requires a BIP, or it is not a consensus rule, and
does not warrant a BIP.
You are arguing that it is not a consensus rule, yet requires a BIP. You
also strongly imply that it is a consensus rule ("consensus is important").
If it is a consensus rule it is either a hard fork (valid tx set
expansion) or a soft fork (valid tx set contraction). You are attempting
to create an independent category that violates this clear engineering
definition. The category you desire is actually a subcategory of hard
fork (employing an arbitrary threshold for likelihood of causing a chain
split).
> On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> 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?
>
> Sufficiently large to prevent potential bike-shedding. The expected
> number of blocks in two weeks could be considered a lower bound. Then
> multiply that by 10 or 20.
The arbitrary threshold. It seems it could be anything. Such a
definition has no clear *engineering* usefulness.
>>> 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.
>>
> Note that a checkpoint *freezes* the chain completely at a given
> height. Buried deployments are *not* checkpoints.
You are arguing a point that I did not make. The issue is that you argue
a "buried deployment" hard fork cannot create a chain split. This itself
implies that the chain is "frozen" at the depth below which the chain
cannot be split. In other words, by accepting your logic, we must
conclude there is no reason whatsoever to validate the chain prior to
that depth. This would lead to the conclusion that check-pointing the
chain to that depth is always sufficient validation.
> Also note that buried deployments only make sense after a protocol
> upgrade has happened (i.e. a soft fork or hard fork). If a miner has
> the resources to cause a chain split, they could trivially do that
> even in the complete absence of buried deployments. Buried deployments
> are *not* a solution to 50% attacks.
Not sure why you are making this obvious but seemingly-irrelevant point.
>>> 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.
>
> Please note that a buried deployment can very well be a soft fork. I
> think this makes it even clearer, that such a label makes no sense for
> buried deployments.
No, it cannot. Removal of an activated soft fork (valid tx set
contraction) is a hard fork (valid tx set expansion), and a new
activation rule for an active soft fork creates a path to that removal.
Given this error you may want to reconsider your proposal.
>>> 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-21 17:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-14 22:01 [bitcoin-dev] Amend the BIP 123 process to include buried deployments Marco Falke
2018-02-14 22:11 ` Luke Dashjr
2018-02-14 22:20 ` Gregory Maxwell
2018-02-14 23:57 ` Eric Voskuil
2018-02-18 18:57 ` Marco Falke
2018-02-21 17:27 ` Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox