Quote from: theymos on February 19, 2016, 08:26:51 PM

Quote from: jl777 on February 19, 2016, 08:02:28 PM

Does this mean that transactions that need to change nSequence so they can use CHECKLOCKTIMEVERIFY will be forced to enable RBF?

No, the special sequence value UINT_MAX-1 disables RBF but also allows CLTV. UINT_MAX disables both.

what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]

Why does it make sense to give RBF such a large range?

What about micropayment protocols that track transactions with sequenceid, or any other use of sequenceid.

I would suggest using the LSB as the RBF flag, so it only uses one bit, which would only cause issues for sequenceid used for relative blocks for small intervals (though that can be fixed by dividing the sequenceid by two for relative block addressing). its usage as timestamp wont suffer much being limited to just the even numbered timestamps.

It also says that if ANY of the inputs has such a sequenceid, the RBF is enabled. Does that mean for all outputs? What if it is signed as SIGHASH_SINGLE? If so, why does an unrelated input/output affect the others. Even if this case isnt broken, having any input affect all of them could break some coinshuffle protocols where the inputs and outputs are pretty independent.

RBF sounds like a nice option to have, but by it using up 2^32-2 out of 2^32 values, basically we are saying sequenceid is for use by RBF and it will override other uses of sequenceid.

James