MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 24 Aug 2015 03:00:37 -0400
From: jl2012@xbt.hk
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAOG=w-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
	<CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com>
	<CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com>
	<CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com>
	<55DA6470.9040301@thinlink.com>
	<CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com>
	<85537faedb1e601d243e3edb666fa844@xbt.hk>
	<CAOG=w-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com>
Message-ID: <d7ba4da921d3ab55dc774dbd78c21744@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
 relative locktime
Precedence: list

Your proposal also permanently burns a sequence bit. It depends on how 
we value a nSequence bit and a nVersion bit. I think there is a 
trade-off here:

1. nSequence is signed by each TxIn individually, while all TxIns must 
share the same nVersion

2. If nVersion is used to indicate the meaning of nSequence (as I 
suggested):
Pros:
It saves a nSequence bit and allows more space for redefining the 
nSequence
Cons:
It burns a nVersion bit.
All TxIns in a tx must share the same meaning for their nSequence

3. If nSequence is used to indicate the meaning of itself (as you 
suggested):
Pros:
It saves a nVersion bit
Different TxIn may have different meaning with their nSequence
Cons:
It burns a nSequence bit, thus less space for extension

I don't think there is a perfect choice. However, I still prefer my 
proposal because:

1. nSequence is signed by each TxIn individually and could be more 
interesting than nVersion.
2. If nVersion is expected to be a monotonic number, 2 bytes = 65536 
versions is enough for 65 millenniums if it ticks once per year. 4 bytes 
is an overkill. Why don't we spend a bit if there is a good reason? Most 
softforks (e.g. OP_CLTV, OP_CSV, BIP66) are not optional. These kind of 
optional new functions would not be common and should never use up the 
version bits. (or, could you suggest a better use of the tx version 
bits?)


Mark Friedenbach 於 2015-08-23 22:54 寫到:
> Sorry this was meant for the list:
> 
> There are only 32 bits in the version field. If you're going to spend
> a bit for perpetuity to indicate whether or not a feature is active,
> you'd better have a good reason to make that feature optional.
> 
> I haven't seen a compelling use case for having BIP 68 be optional in
> that way. As you note, BIP 68 semantics is already optional by
> toggling the most significant bit, and that doesn't permanently burn a
> version bit.