Adam, The remaining 14 bits can be used to soft fork in finer granularity in the future. Alex On Thu, Oct 15, 2015 at 12:37 PM, Adam Back wrote: > Does that pre-judge that block interval would never change from > 10mins? Eg say with IBLT or fountain codes etc and security arguments > for the current limitations of them are found, such that orphan rates > can remain low in a decentralised way with 1min blocks, then the > locktime granularity would be coarse relative to the block interval > (with 512s locktime granularity. > > Adam > > On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev > wrote: > > Alex, > > > > I am sorry for not communicating more clearly. Mark and I discussed your > > concerns from the last meeting and he made the change. The BIP text still > > needs to be updated, but the discussed change was added to the PR, albeit > > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits > with > > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and > > SEQUENCE_LOCKTIME_GRANULARITY in the PR > > https://github.com/bitcoin/bitcoin/pull/6312. > > > > /* If CTxIn::nSequence encodes a relative lock-time, this mask is > > * applied to extract that lock-time from the sequence field. */ > > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; > > > > /* In order to use the same number of bits to encode roughly the > > * same wall-clock duration, and because blocks are naturally > > * limited to occur every 600s on average, the minimum granularity > > * for time-based relative lock-time is fixed at 512 seconds. > > * Converting from CTxIn::nSequence to seconds is performed by > > * multiplying by 512 = 2^9, or equivalently shifting up by > > * 9 bits. */ > > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; > > > > I am also much happier with this last tightening up of the specification > > because it removes ambiguity. 512s granularity makes sense within the > > context of the 10 minute block target. > > > > Thank you for spending so much time carefully considering this BIP and > > reference implementation and please let me know if there there are any > > remaining nits so we can get those addressed. > > > > > > > > > > > > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev > > wrote: > >> > >> Mark, > >> > >> You seemed interested in changing BIP 68 to use 16 bits for sequence > >> number in both the block and time versions, making time based sequence > >> numbers have a resolution of 512 seconds. > >> > >> I'm in favor of this approach because it leaves aside 14 bits for > further > >> soft forks within the semantics of BIP 68. > >> > >> It would be nice to know if you're planning this change, and perhaps > >> people can hold off on review until things are finalized. > >> > >> I'd cast my "vote" against BIP 68 without this change, but am also open > to > >> being convinced otherwise. > >> > >> What are other peoples opinions on this? > >> > >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev > >> wrote: > >>> > >>> Peter Todd writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev > >>> >> writes: > >>> >> > However I don't think we've done a good job showing why we need to > >>> >> > implement this feature via nSequence. > >>> >> > >>> >> It could be implemented in other ways, but nSequence is the neatest > >>> >> and > >>> >> most straightforward I've seen. > >>> >> > >>> >> - I'm not aware of any other (even vague) proposal for its use? > >>> >> Enlighten? > >>> > > >>> > There's three that immediately come to mind: > >>> > > >>> > Gregory Maxwell has proposed it as a way of discouraging miners from > >>> > reorging chains, by including some of the low-order bits of a > previous > >>> > block header in nSequence. > >>> > > >>> > A few people have proposed implementing proof-of-stake blocksize > voting > >>> > with nSequence. > >>> > >>> Excellent, thanks! It's good to have such ideas as a compass. PoS > >>> voting seems like it won't be a problem in 5 bits. > >>> > >>> The "prevbits" idea would want more bits; naively 64 would be good, but > >>> I think there are some tricks we can use to make 32 work OK. We would > >>> have to then split between nLocktime (if available) and multiple > >>> nSequence fields, and it would weaken it for some txs. > >>> > >>> There is one easy solution: change the BIP wording from: > >>> > >>> -For transactions with an nVersion of 2 or greater, > >>> +For transactions with an nVersion of 2, > >>> > >>> And on every tx bump, we decide whether to keep this scheme (mempool > >>> would enforce it always). > >>> > >>> Cheers, > >>> Rusty. > >>> _______________________________________________ > >>> bitcoin-dev mailing list > >>> bitcoin-dev@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > >> > >> > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >