On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I think it is very important to make it clear that non-standard txs and non-standard scripts may become invalid in the future

There can be unavoidable situations which cause locked coins become unspendable.

In an ideal world, soft forks that make UTXOs unspendable should increase the tx version number. BIP-13 should have done that. That would make the change opt-in.

The disabled opcodes like OP_CAT were a DOS/network security change.

Invalidating locked coins is another reason that they shouldn't have been disabled permanently.

It would have been better to disable them for six months, so at least people can get their coins back after that. Inherently, protecting the network required some limitations being added so that nodes couldn't be crashed.

For guidelines

* Transaction version numbers will be increased, if possible

* Transactions with unknown/large version numbers are unsafe to use with locktime

* Reasonable notice is given that the change is being contemplated

* Non-opt-in changes will only be to protect the integrity of the network

Locked transaction that can be validated without excessive load on the network should be safe to use, even if non-standard.

An OP_CAT script that requires TBs of RAM to validate crosses the threshold of reasonableness.

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