Quote from: gmaxwell on February 19, 2016, 10:45:42 PM

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

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]

CSV doesn't exist yet; but sequence locks generally _require_ replacement in order to be usable: Otherwise someone could race with a less mature sequence and mempool preclude the more mature sequence.

I believe the rational in the design is that any transaction which is not marked _final_ will ultimately be subject to some kind of replacement. The conservative behavior for wallets that don't understand the details is that they should consider anything non-final ... as... non-final. As other use cases come up the policy could be further restricted to specify what kinds of replacement should happen in what cases. BIP125 is very generic, which means that further changes to limit it's behavior are less likely to create surprise exposure for anyone.

Confused...

CSV doesnt exist yet, but isnt there a BIP for it that is pending with high likelihood it will get adopted?

I didnt see anywhere in the CSV BIP that you can only use it with RBF enabled.

Is there any way to reserve more than just -1 and -2 as exempt from RBF. There is already a special case needed in the code, so there could be a constant you compare against

#define RBF_DISABLED_RANGE -65536

It just feels very lopsided to forever prevent any other sequenceids without RBF. maybe that is the intent? Even with 16 bits at the top, that provids some amount of flexibility. As I understand it, if things go live as it is, then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2.

James