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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
