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-08 16:36:32 +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-04-07 15:47:02 -07:00 committed by GitHub
parent db279eede3
commit 9d1ee11bfb
1 changed files with 113 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

127
5_2_Resending_a_Transaction_with_RBF.md
View File

@ -8,44 +8,44 @@ If your Bitcoin transaction is stuck, and you're sender, you can resend it using
## Opt-In for RBF
RBF is an opt-in Bitcoin feature. Transactions are only eligible for using RBF if they've been created with a special RBF flag. This is done by setting their sequence number (which is typically set automatically, so that it's more than 0 and less than 0xffffffff (4294967295).
RBF is an opt-in Bitcoin feature. Transactions are only eligible for using RBF if they've been created with a special RBF flag. This is done by setting their sequence number (which is typically set automatically, so that it's less than 0xffffffff-1. (4294967294).
This is simply done by adding a `sequence` variable to the vins:
```
$ rawtxhex=$(bitcoin-cli -named createrawtransaction transactions='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "sequence": 1 } ]''' outputs='''{ "'$recipient'": 2.9, "'$changeaddress'": 1.0 }''')
$ rawtxhex=$(bitcoin-cli -named createrawtransaction transactions='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "sequence": 1 } ]''' outputs='''{ "'$recipient'": 0.1, "'$changeaddress'": 0.9 }''')
```
You should of course sign and send your transaction as usual:
```
$ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex')
$ bitcoin-cli -named sendrawtransaction hexstring=$signedtx
4075dbf84303c01adcb0b36cd2c164e2b447192c2d9fbf5fde3b99d0ac7e64b6
7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2
```
Now, when you look at your transaction, you should see something new: the `bip125-replaceable` line, which has always been marked `no` before, is now marked `yes`:
```
$ bitcoin-cli gettransaction 4075dbf84303c01adcb0b36cd2c164e2b447192c2d9fbf5fde3b99d0ac7e64b6
$ bitcoin-cli -named gettransaction txid=7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2
{
"amount": -2.90000000,
"amount": -0.10000000,
"fee": 0.00000000,
"confirmations": 0,
"trusted": true,
"txid": "4075dbf84303c01adcb0b36cd2c164e2b447192c2d9fbf5fde3b99d0ac7e64b6",
"txid": "7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2",
"walletconflicts": [
],
"time": 1491597044,
"timereceived": 1491597044,
"time": 1491603320,
"timereceived": 1491603320,
"bip125-replaceable": "yes",
"details": [
{
"account": "",
"address": "n2eMqTT929pb1RDNuqEnxdaLau1rxy3efi",
"category": "send",
"amount": -2.90000000,
"amount": -0.10000000,
"vout": 0,
"fee": 0.00000000,
"abandoned": false
}
],
"hex": "020000000100e3da9fa8b5368dd383ebabb820ae257d8f19bb1a9e3fb36f6c3e1b83e6d0f3000000006b483045022100950af7346a5bff5546627b6e9379573cb7e56420d6187f90a8b7aab8fcad730502200c4e66b96b499fec020f9397861bda765c29ec873fc8e61f85a32c73e650173b0121031008e55d06d25bb2acdf85395fe4c2df28492325d8ffc3734a2dc372436b6a330100000002800c4911000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac00e1f505000000001976a914d83b41b8f67b31310bb487b66d859a6d0a92682c88ac00000000"
"hex": "02000000014e843e22cb8ee522fbf4d8a0967a733685d2ad92697e63f52ce41bec8f7c8ac0010000006b483045022100834731cd64efcc078d6c3e59cf0963599ffbc44722b7851b0404bb68e4a1fec70220759a0887ea791592c8119bbe61842eb3850a20cdf8433b4ba00d4ead752facfe012103456575f59a127a4c3e79c23f185899fa0a9ccd40162d05617fb112fa31bd14e5010000000280969800000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac804a5d05000000001976a914c101d8c34de7b8d83b3f8d75416ffaea871d664988ac00000000"
}
```
The `bip125-replaceable` flag will stay `yes` until the transaction receives confirmations. At that point it is no longer replacable.
@ -60,17 +60,116 @@ walletrbf=1
```
Once you've done this (and restarted your `bitcoind`), then all transactions should have a lower sequence number and be marked as `bip125-replaceable`.
[[THIS NEEDS TO BE FURTHER TESTED; APPARENTLY DOESN'T WORK WITH walletrbf=1 ... haven't checked with the flag]]
> **VERSION WARNING:** The walletrbf flag require Bitcoin Core v.0.14.0.
## Understand How RBF Works
The RBF functionality is based on [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), which lists the following rules for using RBF:
> 1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
We've already done this by setting our sequence number to less than 0xffffffff-1. (4294967294).
> 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.)
> 4. The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
> 5. The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
_What is a BIP?_ A BIP is a Bitcoin Improvement Proposal. It's an in-depth suggestion for a change to the Bitcoin Core code. Often, when a BIP has been sufficiently discussed and updated, it will become an actual part of the Bitcoin Core code. For example, BIP 125 was implemented in Bitcoin Core 0.12.0.
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 which are promised as part of the BIP.
_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 in 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 it if you meet the specific criteria laid out by BIP 125.
## 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: (1) that replaces a previous raw transaction that opted-in to RBF and that is not confirmed; (2) that reuses one or more of the same UTXOs; (3) that includes a higher sequence number than the previous use of the UTXO; and (4) that increases fees.
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:
```
$ rawtxhex=$(bitcoin-cli -named createrawtransaction transactions='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "sequence": 2 } ]''' outputs='''{ "'$recipient'": 0.1, "'$changeaddress'": 0.89 }''')
```
We of course my resign it and resend it:
```
$ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex')
$ bitcoin-cli -named sendrawtransaction hexstring=$signedtx
959b0b0f4c8350e9038279dfe0f5ae7b165660cc1281e37bea08d0bd084edb39
```
After several blocks have been created, the original transaction continues to hang around:
```
$ bitcoin-cli -named gettransaction txid=7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2
{
"amount": -0.10000000,
"fee": 0.00000000,
"confirmations": -5,
"trusted": false,
"txid": "7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2",
"walletconflicts": [
"959b0b0f4c8350e9038279dfe0f5ae7b165660cc1281e37bea08d0bd084edb39"
],
"time": 1491603320,
"timereceived": 1491603320,
"bip125-replaceable": "yes",
"details": [
{
"account": "",
"address": "n2eMqTT929pb1RDNuqEnxdaLau1rxy3efi",
"category": "send",
"amount": -0.10000000,
"vout": 0,
"fee": 0.00000000,
"abandoned": false
}
],
"hex": "02000000014e843e22cb8ee522fbf4d8a0967a733685d2ad92697e63f52ce41bec8f7c8ac0010000006b483045022100834731cd64efcc078d6c3e59cf0963599ffbc44722b7851b0404bb68e4a1fec70220759a0887ea791592c8119bbe61842eb3850a20cdf8433b4ba00d4ead752facfe012103456575f59a127a4c3e79c23f185899fa0a9ccd40162d05617fb112fa31bd14e5010000000280969800000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac804a5d05000000001976a914c101d8c34de7b8d83b3f8d75416ffaea871d664988ac00000000"
}
```
Note that `bitcoin-cli` recognizes that there's a conflict with another transaction in the `walletconflicts` section. Also note that it's listed with _negative confirmations_, which marks how long it's been since the double-spend was confirmed.
Meanwhile, the new transaction worked fine:
```
$ bitcoin-cli -named gettransaction txid=959b0b0f4c8350e9038279dfe0f5ae7b165660cc1281e37bea08d0bd084edb39
{
"amount": -0.10000000,
"fee": -0.01000000,
"confirmations": 5,
"blockhash": "00000000000006eeb468791e5ee0d86613c03acd871ef7d89c25fd28474754d5",
"blockindex": 20,
"blocktime": 1491603862,
"txid": "959b0b0f4c8350e9038279dfe0f5ae7b165660cc1281e37bea08d0bd084edb39",
"walletconflicts": [
"7218b78ad4853eb957b610033b8e1ef48b01d948e0ec5dbf79f12caebc2b17e2"
],
"time": 1491603673,
"timereceived": 1491603673,
"bip125-replaceable": "no",
"details": [
{
"account": "",
"address": "n2eMqTT929pb1RDNuqEnxdaLau1rxy3efi",
"category": "send",
"amount": -0.10000000,
"vout": 0,
"fee": -0.01000000,
"abandoned": false
}
],
"hex": "02000000014e843e22cb8ee522fbf4d8a0967a733685d2ad92697e63f52ce41bec8f7c8ac0010000006a47304402207fea4a11db8576257b9d9e104aa07cb3d3ae6a42e38dd7126111276ca5b45daa0220594a3553cc278c43fd015b35029d5b9596d4ac9f36d3d20fb1a8c9efface5c50012103456575f59a127a4c3e79c23f185899fa0a9ccd40162d05617fb112fa31bd14e5020000000280969800000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac40084e05000000001976a914c101d8c34de7b8d83b3f8d75416ffaea871d664988ac00000000"
}
```
Our recipients have their money, and the original, failed transaction will eventually fall out of the mempool.
## Replace a Transaction the Easy Way: By bumpfee
> **VERSION WARNING:** The bumpfee RPC require Bitcoin Core v.0.14.0.
### Use RBF Wisely
-low to high transaction fees
-combine transactions
It doesn't solve the same problem. Core devs are looking for compressing transactions, not necessarily adding fees alone.
## Replace a Transaction the Easy Way: By bumpfee
> **VERSION WARNING:** The bumpfee RPC require Bitcoin Core v.0.14.0.