RBF transactions to be enabled at the next core update

[jl777]

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

[gmaxwell]

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

There is a BIP... and no released software that implements it, no implementation of the soft-fork for it yet, etc.  (as you may note, the deployment section of the BIP is empty.)

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

Without replacement, someone could announce a inferior sequenced spend first and block the superior sequence spend; undermining the intended operation. The op_code would still "work" but wouldn't achieve the intended effect as reliably.

It just feels very lopsided to forever prevent any other sequenceids without RBF.

I think there might be misunderstanding on this point.  Opt-in replacement is just local node policy-- virtually every release of Bitcoin Core has twiddled policy in some way or another, local policy is invisible to the blockchain, and there is nothing forever about it in any way.

As I understand it, if things go live as it is,

It's already "live"; in that there appears to be a non-totally negligible amount of hashpower running it. There is no activation or enforcement of it-- it's inherently unenforceable as it is purely local policy.

then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2

No-- policy can, and is, pretty liberally changed between versions. It's generally more compatible and more safe to have things go from replaceable to non-replaceable; and every proposed usage of the sequence field (short of ones that turn stuff totally unrelated data into it) seen so far involves some kind of replacement (if not exactly the BIP125 kind).

[jl777]

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

There is a BIP... and no released software that implements it, no implementation of the soft-fork for it yet, etc.  (as you may note, the deployment section of the BIP is empty.)

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

Without replacement, someone could announce a inferior sequenced spend first and block the superior sequence spend; undermining the intended operation. The op_code would still "work" but wouldn't achieve the intended effect as reliably.

It just feels very lopsided to forever prevent any other sequenceids without RBF.

I think there might be misunderstanding on this point.  Opt-in replacement is just local node policy-- virtually every release of Bitcoin Core has twiddled policy in some way or another, local policy is invisible to the blockchain, and there is nothing forever about it in any way.

As I understand it, if things go live as it is,

It's already "live"; in that there appears to be a non-totally negligible amount of hashpower running it. There is no activation or enforcement of it-- it's inherently unenforceable as it is purely local policy.

then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2

No-- policy can, and is, pretty liberally changed between versions. It's generally more compatible and more safe to have things go from replaceable to non-replaceable; and every proposed usage of the sequence field (short of ones that turn stuff totally unrelated data into it) seen so far involves some kind of replacement (if not exactly the BIP125 kind).

Thanks, makes sense. I had some cases of wanting to store some arbitrary data in the sequenceid field, but it sounds like that is a bad idea

James