MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Nov 2015 00:32:18 -0500
From: jl2012@xbt.hk
To: Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CABsx9T3w-=bqbfmG=gVxJ8SQZCoEXA7vQbFD+kC2CH36bd=xPw@mail.gmail.com>
References: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
	<df48a2c44441f39c71579aa5e474ec38@xbt.hk>
	<CAE-z3OWJ8YvXU5aGqgs9VJnW99va=0=FoObmpHS3irg4Kh6wrQ@mail.gmail.com>
	<CABsx9T3w-=bqbfmG=gVxJ8SQZCoEXA7vQbFD+kC2CH36bd=xPw@mail.gmail.com>
Message-ID: <ceb486d3be77383158b15be98bfdc11f@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
Precedence: list

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