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 96AAF90 for ; Sun, 1 Nov 2015 17:28:48 +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 68034139 for ; Sun, 1 Nov 2015 17:28:47 +0000 (UTC) Received: from localhost ([::1]:54980 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZswQu-0044qB-Uv; Sun, 01 Nov 2015 12:28:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 01 Nov 2015 12:28:39 -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 X-Mailman-Approved-At: Sun, 01 Nov 2015 17:40:00 +0000 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: Sun, 01 Nov 2015 17:28:48 -0000 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 EQUAL. The , 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