Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-14 📝 Original message:On Wednesday 14 February ...
📅 Original date posted:2018-02-14
📝 Original message: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
📝 Original message: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