This allows to opt into RBF over the RPCs createrawtransaction
(wallet-less) and fundrawtransaction
(requires wallet).
API changes:
Bitcoin-Tx
This allows to opt into RBF over the RPCs createrawtransaction
(wallet-less) and fundrawtransaction
(requires wallet).
API changes:
Bitcoin-Tx
sequence
on inputs? That way we can do other things too?
342@@ -343,6 +343,8 @@ UniValue createrawtransaction(const UniValue& params, bool fHelp)
343 " ...\n"
344 " }\n"
345 "3. locktime (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs\n"
346+ "4. opt into RBF (boolean, optional, default=false) Allow this transaction to be replaced by a transaction with height fees\n"
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.
fundrawtransaction
it is different, as that is a wallet call (so the wallet will determine inputs for you). My comment just applies to createrawtransaction
.
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.
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.
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).
Added two bitcoin-tx related commits.
in=TXID:VOUT(:SEQUENCE_NUMBER)
)rbfoptin(=N)
command (mutate a tx and set the input N’s [or all] RBF flag)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.
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
.
createrawtransation
now can have a sequence
-value next to txid
and vout
.
343@@ -343,6 +344,8 @@ UniValue createrawtransaction(const UniValue& params, bool fHelp)
344 " ...\n"
345 " }\n"
346 "3. locktime (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs\n"
347+ "4. opt into RBF (boolean, optional, default=false) Allow this transaction to be replaced by a transaction with heigher fees\n"
348+
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.
rbfOptIn
does in a context of it being disabled on the CLI.
But is setting all inputs sequence to INT-MAX-2 an adequate API for creating a transaction that is suitable for RBF?
IMHO, yes.
Here again the API changes:
API changes:
Bitcoin-Tx
Thanks for reviews.
This will allow to add flags for RBF and other features
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).
jonasschnelli
dcousens
petertodd
laanwj
jgarzik
gmaxwell
morcos
Labels
RPC/REST/ZMQ
Milestone
0.13.0