It will get correct results about :
- the existence every block
- the existence of every transaction

It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.

I fully agree with Mike here.

Le lun. 5 oct. 2015 à 14:04, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

>
> On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Well, let's agree to disagree on these two things:
> >
> > - I define "working" for a full node as verifying everything; if a node
> starts skipping bits then I'd say it's not really "working" according to
> its original design goals
>
> But assuming the hashrate majority has upgraded (and we're using 95% as
> the miner upgrade confirmation threshold to start activation, so that
> assumption seems pretty safe), a non-upgraded full node and an upgraded
> full will converge on what they see: "the most-work valid chain" will be
> the same for both. A non-upgraded full node wallet waiting for several
> confirmations (for example, 6 confirmations) will be just as safe as an
> upgraded one. In that sense, it keeps working. On top of that, nodes (of
> any kind) can use unknown block version numbers to notify the user or even
> stop working (the same notification mechanism you would use with hardforks).
>
> I agree that hardforks are necessary and we should deploy a hardfork asap
> to show the world they are indeed possible (bip99 proposes a likely
> uncontroversial one), but I still believe that is clear that softfork
> deployment is preferrable in many cases like this one.
>
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>