From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8055892B for ; Tue, 3 Nov 2015 05:32:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCDB7187 for ; Tue, 3 Nov 2015 05:32:34 +0000 (UTC) Received: from localhost ([::1]:52750 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZtUCg-00157i-MS; Tue, 03 Nov 2015 00:32:18 -0500 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 In-Reply-To: References: Message-ID: X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:32:35 -0000 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 > 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