flywithu/Learning-Bitcoin-from-the-Command-Line
1
1
Fork 0
mirror of https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git synced 2025-06-07 16:06:26 +00:00
Code Issues Releases Wiki Activity

Update 5_2_Resending_a_Transaction_with_RBF.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-26 11:08:39 -07:00 committed by GitHub
parent 777da6dbce
commit 8ac120c470
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
5_2_Resending_a_Transaction_with_RBF.md
View File

@ -52,11 +52,13 @@ The `bip125-replaceable` flag will stay `yes` until the transaction receives con
_Should I trust transactions with no confirmations?_ No, never. This was true before RBF and it was true after RBF. Transactions must receive confirmations before they are trustworthy. This is especially true if a transaction is marked as `bip125-replaceable`, because then it can be ... replaced.
> **SEQUENCE NOTE (I):** This is the first use of the `nSequence` value in Bitcoin. You can set it between 1 and 0xffffffff-2 (4294967293) and enable RBF, but if you're not careful you can run up against the parallel use of `nSequence` for relative timelocks. We suggest always setting it to "1", which is what Bitcoin Core does, but the other option is to set it a value between 0xf0000000 (4026531840) and 0xffffffff-2 (4294967293). Setting to "1" effectively makes relative timelocks irrelevent and setting to 0xf0000000 or higher deactivates them. This is all explained further in [§9.3: Using CSV in Scripts](9_3_Using_CSV_in_Scripts.md). For now, just choose one of the non-conflicting values for `nSequence`.
### Optional: Always Opt-In for RBF
If you prefer, you can _always_ opt in for RBF. Do so by running your `bitcoind` with the `-walletrbf` command. Once you've done this (and restarted your `bitcoind`), then all UTXOs should have a lower sequence number and the transaction should be marked as `bip125-replaceable`.
Note the following example generated by `bitcoind`, where the UTXO uses a sequence number of "1":
Note the following example generated by `bitcoind`, where the UTXO indeed uses a sequence number of "1":
```
{
"txid": "d261b9494eb29084f668e1abd75d331fc2d6525dd206b2f5236753b5448ca12c",
@ -114,7 +116,7 @@ The RBF functionality is based on [BIP 125](https://github.com/bitcoin/bips/blob
> 1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
This means that the sequence number must be set to less than 0xffffffff-1. (4294967294).
This means that the sequence number must be set to less than 0xffffffff-1. (4294967294), or the same is true of unconfirmed parent transactions.
> 2. The replacement transaction pays an absolute higher fee than the sum paid by the original transactions.
> 3. The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.)
@ -125,19 +127,21 @@ _What is a BIP?_ A BIP is a Bitcoin Improvement Proposal. It's an in-depth sugge
The other thing to understand about RBF is that in order to use it, you must double-spend, reusing one or more the same UTXOs. Just sending another transaction with a different UTXO to the same recipient won't do the trick (and will likely result in your losing money). Instead, you must purposefully create a conflict, where the same UTXO is used in two different transactions.
Faced with this conflict, the miners will know to use the one with the higher sequence number, and they'll be incentivized to do so by the higher fees that are promised as part of the BIP.
Faced with this conflict, the miners will know to use the one with the higher fee, and they'll be incentivized to do so by that higher fee.
_What is a double-spend?_ A double-spend occurs when someone sends the same electronic funds to two different people (or, to the same person twice, in two different transactions). This is a central problem for any e-cash system. It's solved in Bitcoin by the immutable ledger: once a transaction is sufficiently confirmed, no miners will verify transactions that reuse the same UTXO. However, it's possible to double-spend _before_ a transaction has been confirmed — which is why you always want one or more confirmations before you finalize a transaction. In the case of RBF, you purposefully double-spend because an initial transaction has stalled, and the miners accept your double-spend if you meet the specific criteria laid out by BIP 125.
> **WARNING:** Some early discussions of this policy suggested that the `nSequence` number also be increased. This in fact was the intended use of `nSequence` in its original form. This is _not_ a part of the published policy in BIP 125. In fact, increasing your sequence number can accidentally lock your transaction with a relative timelock, unless you use sequence numbers in the range of 0xf0000000 (4026531840) to 0xffffffff-2 (4294967293).
## Replace a Transaction the Hard Way: By Hand
In order to create an RBF transaction by hand, all you have to do is create a raw transaction that: (1) replaces a previous raw transaction that opted-in to RBF and that is not confirmed; (2) reuses one or more of the same UTXOs; (3) includes a higher sequence number than the previous use of the UTXO; and (4) increases fees.
In order to create an RBF transaction by hand, all you have to do is create a raw transaction that: (1) replaces a previous raw transaction that opted-in to RBF and that is not confirmed; (2) reuses one or more of the same UTXOs; (3) increases fees; and (4) pays the minimum bandwidth of both transactions [which already may be taken care of by (3)].
The following example just reuses our existing variables, but increments the sequence number and decreases the amount sent to the change address, to increase the fee from the accidental 0 BTC of the original transaction to an overly generous 0.01 BTC in the new transaction:
The following example just reuses our existing variables, but decreases the amount sent to the change address, to increase the fee from the accidental 0 BTC of the original transaction to an overly generous 0.01 BTC in the new transaction:
```
$ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "sequence": 2 } ]''' outputs='''{ "'$recipient'": 0.1, "'$changeaddress'": 0.89 }''')
$ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "sequence": 1 } ]''' outputs='''{ "'$recipient'": 0.1, "'$changeaddress'": 0.89 }''')
```
We of course must resign it and resend it:
We of course must re-sign it and resend it:
```
$ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex')
$ bitcoin-cli -named sendrawtransaction hexstring=$signedtx
@ -222,7 +226,7 @@ $ bitcoin-cli -named bumpfee txid=4460175e8276d5a1935f6136e36868a0a3561532d44ddf
]
}
```
The result is the autmoatic generation of a new transaction that has a fee determined by your bitcoin.conf file:
The result is the automatic generation of a new transaction that has a fee determined by your bitcoin.conf file:
```
$ bitcoin-cli -named gettransaction txid=75208c5c8cbd83081a0085cd050fc7a4064d87c7d73176ad9a7e3aee5e70095f
{