My answer is simply "No", you don't have to maintain backward
compatibility for non-standard tx.
The same question applies to P2SH. Before the deployment of BIP16, one
could have created a time-locked tx with one of the output was in the
form of HASH160 <hash> EQUAL. The <hash>, however, is not a hash of a
valid serialized script, so the output is now permanently frozen.
It also applies to all the OP codes disabled by Satoshi: one could have
created a time-locked tx with those now disabled OP codes.
Same for BIP65 with the use of OP_NOP2. Following your logic, we can't
make any softfork related to the script system.
I think it is very important to make it clear that non-standard txs and
non-standard scripts may become invalid in the future
Gavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:
I'm hoping this fits under the moderation rule of "short-term changes
to the Bitcoin protcol" (I'm not exactly clear on what is meant by
"short-term"; it would be lovely if the moderators would start a
thread on bitcoin-discuss to clarify that):
Should it be a requirement that ANY one-megabyte transaction that is
valid
under the existing rules also be valid under new rules?
Pro: There could be expensive-to-validate transactions created and
given a
lockTime in the future stored somewhere safe. Their owners may have no
other way of spending the funds (they might have thrown away the
private
keys), and changing validation rules to be more strict so that those
transactions are invalid would be an unacceptable confiscation of
funds.
Con: It is extremely unlikely there are any such large, timelocked
transactions, because the Core code has had a clear policy for years
that
100,000-byte transactions are "standard" and are relayed and
mined, and
larger transactions are not. The requirement should be relaxed so that
only
valid 100,000-byte transaction under old consensus rules must be valid
under new consensus rules (larger transactions may or may not be
valid).
I had to wrestle with that question when I implemented BIP101/Bitcoin
XT
when deciding on a limit for signature hashing (and decided the right
answer was to support any "non-attack"1MB transaction; see
https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more
details).
--
--
Gavin Andresen
Links:
------
[1] https://bitcoincore.org/~gavin/ValidationSanity.pdf
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
