[RPC] Add RBF opt-in possibilities to rawtx functions

[jonasschnelli]

This allows to opt into RBF over the RPCs createrawtransaction (wallet-less) and fundrawtransaction (requires wallet).

API changes:

createrawtransaction [{\"txid\":\"id\",\"vout\":n, \"sequence\":},...] 
{\"address\":amount,\"data\":\"hex\",...} ( locktime ) ( opt into Replace-By-Fee )[bool]

fundrawtransaction \"hexstring\" ( includeWatching ) ( opt into Replace-By-Fee )[bool]

Bitcoin-Tx

in=TXID:VOUT(:SEQUENCE_NUMBER)

rbfoptin(=N)  Set RBF opt-in sequence number for input N (if not provided, opt-in all available inputs

[dcousens]

Perhaps just parameterize the setting of sequence on inputs? That way we can do other things too?

[petertodd]

Typo "with height fees"

[jonasschnelli]

Sorry.. meant to be "higher fees". Will fix.

[laanwj]

I tend to agree with @dcousens, maybe this is slightly more 'user friendly', but allowing setting the underlying values is more in the spirit of raw transaction usage.
Also bitcoin-tx needs a similar change.

[jonasschnelli]

Perhaps just parameterize the setting of sequence on inputs? That way we can do other things too?

For createrawtransaction this could make sense, although, I think both should be possible (a nSequence per input as well as a general RBF-opt-in). I prefer exposing relevant features (RBF is relevant IMO) over a clear interface. Manual setting the nSequence to int.max-2 is not user friendly and can be misunderstood (root cause is maybe the way how we use/extend existing consensus fields like nSequence).

For fundrawtransaction is disagree with exposing nSequence instead of a RFB-opt-in bool. Also i don't think we should pass around a vector of sequence number (per input) to CreateTransaction() (or similar).

Also bitcoin-tx needs a similar change.

Right. There I guess instead of a RFB opt-in we could offer a easy way to set the nSequence number per input.

[laanwj]

Sure, for fundrawtransaction it is different, as that is a wallet call (so the wallet will determine inputs for you). My comment just applies to createrawtransaction.

[jgarzik]

Don't extend createrawtransaction without also extending bitcoin-tx -- that's the preferred place for pure function work unconnected to wallet.

[gmaxwell]

Anti-sniping (which I think createrawtransaction should do by default) is an argument against bitcoin-tx; even absent that: the complete application of createrawtransaction is not pure function-- you had to get the txids for the coins from somewhere... but sure this should have parity in bitcoin-tx.

I think createrawtransaction should gain the ability to manually set sequences per input. No more parameters are needed: just add "seq" to the dictionary that takes the vin/txid fields now.

I don't see any harm in having a replacable flag that sets the default sequence to MAX-2.

[laanwj]

Anti-sniping (which I think createrawtransaction should do by default) is an argument against bitcoin-tx;

It's not an argument against bitcoin-tx. A program can get the current block number from anywhere and pass it to createrawtransaction or bitcoin-tx alike. No need to create a tight coupling. Some parts of transaction creation are not pure function, that doesn't mean that steps in the process cannot be.

[jonasschnelli]

IIRC createrawtransaction does not do the nLockTime anti-sniping (only CWallet::CreateTransaction() = RPC sendto* or fundrawtransaction does).

I agree with @jgarzik that bitcoin-tx should also support nSequence and/or RBF opt-in. I check now if it makes sense to extend bitcoin-tx within this PR (or if it require to much work in terms or parameter parsing and syntax).

[jonasschnelli]

Added two bitcoin-tx related commits.

1. Allow to provide a sequence number (optional) for the in command (in=TXID:VOUT(:SEQUENCE_NUMBER))
2. Add a rbfoptin(=N) command (mutate a tx and set the input N's [or all] RBF flag)

[morcos]

I think createrawtransaction should gain the ability to manually set sequences per input. No more parameters are needed: just add "seq" to the dictionary that takes the vin/txid fields now.

Are you going to add this? I think its a good idea.

[jonasschnelli]

I think createrawtransaction should gain the ability to manually set sequences per input. No more parameters are needed: just add "seq" to the dictionary that takes the vin/txid fields now.

Are you going to add this? I think its a good idea.

Rebased & added a commit that allows to set the sequence per input when using createrawtransaction.

[dcousens]

@jonasschnelli what is the syntax OOI? (haven't had a chance to read the impl. yet)

[jonasschnelli]

@dcousens: The inputs object in createrawtransation now can have a sequence-value next to txid and vout.

[dcousens]

This really isn't necessary, the RBF rules are very clear such that if sequence is specified at all (aka, < 0xffffffff - 2?), then it will be used.
Its as much work by the user to just add the sequence field per input, so we could just omit this opt-in RBF parameter entirely.

[dcousens]

It would also be less confusing what rbfOptIn does in a context of it being disabled on the CLI.

[jonasschnelli]

But is setting all inputs sequence to INT-MAX-2 an adequate API for creating a transaction that is suitable for RBF? IMO a clear Boolean should be preferred.

[dcousens]

But is setting all inputs sequence to INT-MAX-2 an adequate API for creating a transaction that is suitable for RBF?

IMHO, yes.

[jonasschnelli]

Here again the API changes:

API changes:

createrawtransaction [{\"txid\":\"id\",\"vout\":n, \"sequence\":},...] 
{\"address\":amount,\"data\":\"hex\",...} ( locktime ) ( opt into Replace-By-Fee )[bool]

fundrawtransaction \"hexstring\" ( includeWatching ) ( opt into Replace-By-Fee )[bool]

Bitcoin-Tx

in=TXID:VOUT(:SEQUENCE_NUMBER)

rbfoptin(=N)  Set RBF opt-in sequence number for input N (if not provided, opt-in all available inputs

Thanks for reviews.

[jonasschnelli]

Rebased.

IMO the fundrawtransaction and the bitcoin-tx are okay.
The only question is if we want the higher level function in createrawtransaction (setting the sequence-no per input is possible now).

[jgarzik]

ut ACK

[jonasschnelli]

Closing in favor of #7865.