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 5219A267 for ; Sat, 8 Aug 2015 19:18:58 +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 9119C1A0 for ; Sat, 8 Aug 2015 19:18:56 +0000 (UTC) Received: from localhost ([::1]:33290 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZO9du-001je6-SO; Sat, 08 Aug 2015 15:18:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 08 Aug 2015 15:18:54 -0400 From: jl2012@xbt.hk To: Mark Friedenbach In-Reply-To: References: Message-ID: <44dcb2c03d0bc344ca7a32ee0ddf1f8d@xbt.hk> 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] The use of tx version field in BIP62 and 68 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: Sat, 08 Aug 2015 19:18:58 -0000 I think I have explained my motivation but let me try to make it clearer. For example, BIP62 says "scriptPubKey evaluation will be required to result in a single non-zero value". If we had BIP62 before BIP16, P2SH could not be done in the current form because BIP16 leaves more than one element on the stake for non-upgrading nodes. BIP17 also violates BIP62. BIP68 is "only enforced if the most significant bit of the sequence number field is set.", so it is optional, anyway. All I do is to move the flag from sequence number to version number. The blocksize debate shows how a permanent softfork may cause trouble later. We need to be very careful when doing further softforks, making sure we will have enough flexibility for further development. Mark Friedenbach 於 2015-08-08 14:56 寫到: > It is not a bug that you are unable to selectively choose these > features with higher version numbers. The version selection is in > there at all because there is a possibility that there exists already > signed transactions which would violate these new rules. We wouldn't > want these transactions to become unspendable. However moving forward > there is no reason to selectively pick and choose which of these new > consensus rules you want to apply your transaction. > On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev" > wrote: > >> BIP68 rules and some of the BIP62 rules are applied only if the tx >> version is >=2 and >=3 respectively. Therefore, it is not possible >> to create a tx which follows BIP62 but not BIP68. If we introduce v4 >> tx later, BIP62 and BIP68 will all become mandatory. >> >> Some rules, e.g. "scriptPubKey evaluation will be required to >> result in a single non-zero value" in BIP62, will cause trouble when >> we try to introduce a new script system with softfork. >> >> I suggest to divide the tx version field into 2 parts: the higher 4 >> bits and lower 28 bits. >> >> BIP62 is active for a tx if its highest bits are 0000, and the >> second lowest bit is 1. >> >> BIP68 is active for a tx if its highest bits are 0000, and the >> third lowest bit is 1. >> >> So it will be easier for us to re-purpose the nSequence, or to take >> advantage of malleability in the future. If this is adopted, the >> nSequence high bit requirement in BIP68 becomes unnecessary as we >> could easily switch it off. >> >> The low bits will allow 28 independent BIPs and should be ample for >> many years. When they are exhausted, we can switch the high bits to >> a different number (1-15) and redefine the meaning of low bits. By >> that time, some of the 28 BIPs might have become obsoleted or could >> be merged. >> >> (I'm not sure if there are other draft BIPs with similar >> interpretation of tx version but the comments above should also >> apply to them) >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] > > > Links: > ------ > [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev