MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 08 Aug 2015 14:51:17 -0400
From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <bcebe52e7f66f2065d48e089d773156b@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Subject: [bitcoin-dev] The use of tx version field in BIP62 and 68
Precedence: list

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)