The other strategy is to have an informational BIP to define "safe" use of Bitcoin.

1. scriptPubKey must be one of the following types: P2PK, P2PKH, P2SH, n-of-m multisig with m < 4 (with or without CLTV or CSV, we should define standard use of CLTV and CSV)

2. For P2SH, the serialized script must be one of the standard type

3. No use of unknown transaction version

4. Tx size < 100k

5. If conditions 1-4 are all satisfied, the locktime must not be longer than 4 years from the creation of the tx

6. If at least one of the conditions 1-4 is not satisfied, the lock time must not be longer than 6 months from the creation of the tx

7. A chain of unconfirmed transactions is unsafe due the malleability

8. Tx created by wallet software last updated 1 year ago is unsafe

9. Permanently deleting a private key is unsafe (that might be safe if stricter practice is followed)

We must not introduce a new rule that may permanently invalidate a safe tx, unless in emergency. Even in emergency, we should try to preserve backward compatibility as much as possible (see the example at the end of my message)

Being unsafe means there is a chance that the tx may become unconfirmable, outputs become unspendable, or funds may be stolen without a private key.

A grace period of 5 years must be given for "soft-fork" type change of any of the rules. For example it is ok to introduce new standard script anytime but not to remove.

----------------------

Back to Gavin's original question. If you want to somehow keep backward compatibility for expensive-to-validate transactions in the future, you may have rules like there could only be at most one expensive-to-validate transaction in every 10 blocks, until year 2025. I know this is over-complicated but it's a possible way to address your concern.



Gavin Andresen via bitcoin-dev 於 2015-11-02 15:33 寫到:
On Sun, Nov 1, 2015 at 6:46 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

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.

I like those guidelines, although I'm sure there may be lots of
arguing over what fits under "protects the integrity of the network"
or what constitutes "reasonable notice" (publish a BIP at least 30
days before rolling out a change? 60 days? a year?)

--

--
Gavin Andresen


_______________________________________________
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

Reply via email to