Quote from: gmaxwell on February 20, 2016, 12:29:58 AM

Quote from: jl777 on February 20, 2016, 12:15:54 AM

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.)

Quote

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.

Quote

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.

Quote

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.

Quote

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