Skip to content

Conversation

@jonasschnelli
Copy link
Contributor

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
Copy link
Contributor

dcousens commented Dec 3, 2015

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo "with height fees"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@laanwj
Copy link
Member

laanwj commented Dec 3, 2015

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
Copy link
Contributor Author

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
Copy link
Member

laanwj commented Dec 3, 2015

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
Copy link
Contributor

jgarzik commented Dec 3, 2015

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

@gmaxwell
Copy link
Contributor

gmaxwell commented Dec 3, 2015

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
Copy link
Member

laanwj commented Dec 3, 2015

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
Copy link
Contributor Author

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 jonasschnelli force-pushed the 2015/12/rpc_rbf branch 2 times, most recently from 34bbc8c to f84a91b Compare December 3, 2015 15:44
@jonasschnelli
Copy link
Contributor Author

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
Copy link
Contributor

morcos commented Dec 11, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@jonasschnelli
Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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.

luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
This will allow to add flags for RBF and other features

Github-Pull: bitcoin#7159
Rebased-From: cde33d3
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Feb 13, 2016
@laanwj laanwj added this to the 0.13.0 milestone Apr 1, 2016
@jonasschnelli
Copy link
Contributor Author

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
Copy link
Contributor

jgarzik commented Apr 4, 2016

ut ACK

@jonasschnelli
Copy link
Contributor Author

Closing in favor of #7865.

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 28, 2016
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants