jl2012 [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-04 📝 Original message:Gavin Andresen 於 ...
📅 Original date posted:2016-02-04
📝 Original message:Gavin Andresen 於 2016-02-04 12:36 寫到:
> This BIP is unnecessary, in my opinion.
>
> I'm going to take issue with items (2) and (3) that are the motivation
> for this BIP:
>
> " 2. Full nodes and SPV nodes following original consensus rules may
> not be aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
>
> If a hardfork is deployed by increasing the version number in blocks
> (as is done for soft forks), then there is no risk-- Full and SPV
> nodes should notice that they are seeing up-version blocks and warn
> the user that they are using obsolete software.
>
> It doesn't matter if the software is obsolete because of hard or soft
> fork, the difference in risks between those two cases will not be
> understood by the typical full node or SPV node user.
Thanks for your comments.
In the case of a softfork, as long as an user waits for a few
confirmations, the risk of money loss is very low. In the worst case
they run a full node with SPV security. In the case of a hardfork, the
consequence of failing to upgrade to the economic majority fork *is*
fatal, even if an user waits for 1000 confirmations. Not to mention the
risk of having 2 economically active forks. That's why wallets should
STOP accepting and sending tx after a hardfork bit is detected and wait
for users' instructions.
> " 3. In the case which the original consensus rules are also valid
> under the new consensus rules, users following the new chain may
> unexpectedly reorg back to the original chain if it grows faster than
> the new one. People may find their confirmed transactions becoming
> unconfirmed and lose money."
>
> If a hard or soft fork uses a 'grace period' (as described in BIP 9 or
> BIP 101) then there is essentially no risk that a reorg will happen
> past the triggering block. A block-chain re-org of two thousand or
> more blocks on the main Bitcoin chain is unthinkable-- the economic
> chaos would be massive, and the reaction to such a drastic (and
> extremely unlikely) event would certainly be a hastily imposed
> checkpoint to get everybody back onto the chain that everybody was
> using for economic transactions.
No, the "triggering block" you mentioned is NOT where the hardfork
starts. Using BIP101 as an example, the hardfork starts when the first
>1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork.
> Since I don't agree with the motivations for this BIP, I don't think
> the proposed mechanism (a negative-version-number-block) is necessary.
> And since it would simply add more consensus-level code, I believe the
> keep-it-simple principle applies.
>
> --
>
> --
> Gavin Andresen
📝 Original message:Gavin Andresen 於 2016-02-04 12:36 寫到:
> This BIP is unnecessary, in my opinion.
>
> I'm going to take issue with items (2) and (3) that are the motivation
> for this BIP:
>
> " 2. Full nodes and SPV nodes following original consensus rules may
> not be aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
>
> If a hardfork is deployed by increasing the version number in blocks
> (as is done for soft forks), then there is no risk-- Full and SPV
> nodes should notice that they are seeing up-version blocks and warn
> the user that they are using obsolete software.
>
> It doesn't matter if the software is obsolete because of hard or soft
> fork, the difference in risks between those two cases will not be
> understood by the typical full node or SPV node user.
Thanks for your comments.
In the case of a softfork, as long as an user waits for a few
confirmations, the risk of money loss is very low. In the worst case
they run a full node with SPV security. In the case of a hardfork, the
consequence of failing to upgrade to the economic majority fork *is*
fatal, even if an user waits for 1000 confirmations. Not to mention the
risk of having 2 economically active forks. That's why wallets should
STOP accepting and sending tx after a hardfork bit is detected and wait
for users' instructions.
> " 3. In the case which the original consensus rules are also valid
> under the new consensus rules, users following the new chain may
> unexpectedly reorg back to the original chain if it grows faster than
> the new one. People may find their confirmed transactions becoming
> unconfirmed and lose money."
>
> If a hard or soft fork uses a 'grace period' (as described in BIP 9 or
> BIP 101) then there is essentially no risk that a reorg will happen
> past the triggering block. A block-chain re-org of two thousand or
> more blocks on the main Bitcoin chain is unthinkable-- the economic
> chaos would be massive, and the reaction to such a drastic (and
> extremely unlikely) event would certainly be a hastily imposed
> checkpoint to get everybody back onto the chain that everybody was
> using for economic transactions.
No, the "triggering block" you mentioned is NOT where the hardfork
starts. Using BIP101 as an example, the hardfork starts when the first
>1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork.
> Since I don't agree with the motivations for this BIP, I don't think
> the proposed mechanism (a negative-version-number-block) is necessary.
> And since it would simply add more consensus-level code, I believe the
> keep-it-simple principle applies.
>
> --
>
> --
> Gavin Andresen