ord
ord copied to clipboard
Allow fee-bumping transactions
Commit, reveal, and send transactions can all get stuck in the mempool. The wallet opts them into RBF, so they can be bumped, but we don't have any code to actually bump them. We should add this.
First step is a design. Does ord wallet bump TXID
work? that would be the simplest design, but if ord needs to do different things for commit, reveal, and send transactions, it would have to figure out which TXID was. Another option is ord wallet rescue TXID
, which will fee bump, not reveal inscriptions, and return the UTXO to your wallet to try again with a higher fee. If this is really simple, we might consider prioritizing it.
I have an inscription stuck in the mempool at 1sat/vB (I know I know, I should have used the fee_rate param but I was so excited and moving fast that I didn't rtfm). So, I started implementing this and quickly ran into an issue with bumpfee
:
Unable to create transaction. Transaction must have at least one recipient (code -4)
The reveal transaction doesn't seem to be eligible for RBF. Will continue digging but thought it worth mentioning.
Got into same situation but with transfer
, stuck with 1sat/vB. How do you even specify fee_rate
for transfers? The params are just recipient and inscription
Does this let transactions not in the mempool be bumped aswell? Have a bunch of funds & rare inscriptions just locked waiting to get broadcasted :(
Got into same situation but with
transfer
, stuck with 1sat/vB. How do you even specifyfee_rate
for transfers? The params are just recipient and inscription
My bad, there actually is --fee-rate
option for wallet send
command 😄 Well, now just need the bump-up feature to recover stuck tx
FYI - I have tried bumping up fee for my stuck inscription transfer via bitcoin-cli's bumpfee and it seemingly worked:
bitcoin-cli bumpfee <txid> '{"fee_rate": 100}'
The inscription is showing up in the target wallet (confirmed with ord wallet inscriptions
) and on Ordinals explorer.
NOTE - it was an inscription transfer fee bump (still need to test bumping up inscription creation)
FYI - I have tried bumping up fee for my stuck inscription transfer via bitcoin-cli's bumpfee and it seemingly worked:
bitcoin-cli bumpfee <txid> '{"fee_rate": 100}'
The inscription is showing up in the target wallet (confirmed with
ord wallet inscriptions
) and on Ordinals explorer.NOTE - it was an inscription transfer fee bump (still need to test bumping up inscription creation)
How? Did you use windows? I keep getting JSON errors in CMD and PowerShell using your command syntax.
sorry not sure about Windows version if it is different. I did it on Ubuntu, bitcoin-cli v24.0.1.
Btw, I checked it won't work for bumping up inscriptions because it is commit-reveal setup (commit tx with a dependent reveal tx), and bumping up tx with dependent txs is not supported by bitcoin-cli because it requires changing the whole batch (unlike for inscription transfers which is single tx). One way would be to force-replace the commit tx with higher fee rate (possibly via createrawtransaction > signrawtransactionwithwallet > sendrawtransaction
flow) which will rescue the UTXO and let you re-inscribe again (pretty much what @casey suggested above) I will test this concept and post here if it works
You are correct, the only way I was able to get unblocked was sending out the balance on my Ord wallet to a new Ord wallet via the bitcoin core gui. The ord cli was not allowing me to send out funds. Redoing inscribes with the --fee-rate flag now.
FYI - here is a detailed instruction on how to create a replacement tx with higher fee via createrawtransaction
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_2_Creating_a_Raw_Transaction.md
You are correct, the only way I was able to get unblocked was sending out the balance on my Ord wallet to a new Ord wallet via the bitcoin core gui. The ord cli was not allowing me to send out funds. Redoing inscribes with the --fee-rate flag now.
any chance you can clarify on how to do this? i have a send inscription and inscribe transaction stuck because i didnt set a fee rate.
Be careful with this bitcoin-cli
command above as the bitcoin wallet isn't aware of inscriptions so will likely use them as fee.. Just lost 3 inscriptions to the miners this way 😭
it also used the intended inscription as fee and sent a different inscription to the other person..
in summary: Do NOT use bumpfee
unless you know there are no other inscriptions in that wallet at risk
FYI - I have tried bumping up fee for my stuck inscription transfer via bitcoin-cli's bumpfee and it seemingly worked:
bitcoin-cli bumpfee <txid> '{"fee_rate": 100}'
The inscription is showing up in the target wallet (confirmed with
ord wallet inscriptions
) and on Ordinals explorer. NOTE - it was an inscription transfer fee bump (still need to test bumping up inscription creation)How? Did you use windows? I keep getting JSON errors in CMD and PowerShell using your command syntax.
this will cause you to lose your inscriptions...be careful, better would be if this is removed.
@casey any ETA on bump fee feature on ord wallet ? Using bitcoin ci to bump fee is risky... My transaction is stuck at 1sat/vbyte :(.
@casey any ETA on bump fee feature on ord wallet ? Using bitcoin ci to bump fee is risky... My transaction is stuck at 1sat/vbyte :(.
Did you fixed it? My inscribe stuck also with 1sat/vbyte :(. And no way error: wallet contains no cardinal utxos
to create new one because previous stuck?
+1 for this! goofed up and submitted an inscription at 1 sat/vB, not sure what to do as I don't want to accidentally spend one of my rares
yeah i recommend not burning rares its a real bummer
I goofed up with this as well. Now I got the first 5 ordinals in my projects collection stuck trying to mint one with 1sat/vbyte. Has anyone figure a way to get their BTC and ordinals back yet? Is this being worked on at all?
Lucky you, blocks are empty right now so you should be confirmed. To my knowledge, the only safe thing to do is to wait until you get confirmed; unless you're a deep ordinals hacker in which case you might be able to craft a raw transaction that manages not to spend any rares.
+1 Also got a stuck tx at 1sat/vbyte after not thinking too much when using ord wallet send :-P
Sry for being a n00b, but...
If a tx to send an ordinal is stuck due to a low fee, and I transfer out all other ordinals to another wallet first, and then run bitcoin-cli bumpfee
- would that be safe?
Or is there a risk that it somehow spends the very ordinal being transferred in the original tx when doing the bumpfee?
yeah I think there is a chance. When I did it there was 4 ordinals that ended up moving and the one I was trying to bump was one of the burned.
Sry for being a n00b, but...
If a tx to send an ordinal is stuck due to a low fee, and I transfer out all other ordinals to another wallet first, and then run
bitcoin-cli bumpfee
- would that be safe?Or is there a risk that it somehow spends the very ordinal being transferred in the original tx when doing the bumpfee?
if it's just a send transaction you can easily craft a raw transaction with reveal tx
as the input and the same target address but with lower output value using this guide: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_2_Creating_a_Raw_Transaction.md
I'm still interested in the original feature request of this issue: ord wallet bump TXID
should we offer a bounty? how can we push this forward?
I had a few stuck transactions due to low fees, and I ended up writing a script to free them up. While researching, I came across this issue, but unfortunately, I don't know Rust yet to be able to contribute. In any case, I'll share the Python solution I came up with as it might help others in a similar situation of stuck txs: https://github.com/drignads/restore-ord-txs
@ordinalsbot doubling-down for being a noob. Trying to craft a new raw transaction following the guide you linked in an attempt to bump an ord wallet send
transaction I gave a low fee-rate for. Currently stuck in mempool for 6 days.
utxo_txid
-> The txid/location of your ordinal (e.g. the inscription id minus the last 2 digits https://ordinals.com/inscription/670da24819e8e221eec3f49f77bd1ea779c1e2fb2e8da1df2ceba0ec2340201bi0 )
recipient
-> The same recipient your original send transaction was going to (this transaction https://mempool.space/tx/aa34c1b96700c4704fa54d5b047144f9b2d94409432ba221f677c63029bfc7e9)
utxo_vout
-> 0 (the last digit of the inscription id)
So for me I can set:
utxo_txid="670da24819e8e221eec3f49f77bd1ea779c1e2fb2e8da1df2ceba0ec2340201b"
recipient="bc1pcunwzvauqyupsdn4ke6ulquk7rlspzn6xpkq2tj09908mc4s2q9q57jnmp"
utxo_vout="0"
There are 10000 sats with the inscrintion (unspent UTXOs), so lets give it a fee of 2000 sats which means we set an amount of 8000 sats (0.00008 btc) to send (and the 2000 will be used as fee).
So I create raw transaction:
rawtxhex=$(bitcoin-cli createrawtransaction '''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'''
''{ "'$recipient'": 0.00008 }''')
Sign the transaction:
signedtx=$(bitcoin-cli signrawtransactionwithwallet $rawtxhex jq -r '.hex')
And send it:
bitcoin-cli sendrawtransaction $signedtx
Does that seem correct? I don't quite understand the amount, whether it needs to pull the fee from this UTXO or whether it is going to grab whatever funds from my wallet (other inscriptions included).
FYI, I ended up using the method propsed by the legend "Greg" on discord:
- Shut down
bitcoind
- Backup mempool.dat and your wallet.dat file, e.g:
mv .bitcoin/mempool.dat ~/Backup/
mv .bitocin/wallets/ord ~/Backup/
- (optional?) Restart
bitcoind
with-connect=0
(I hadbitcoind
freeze at "net thread start", so I did not include this.) - Restore your wallet from seed phrase
ord wallet restore "your seed words here"
- Rescan the blocks starting from the first inscription (or your first inscription)
bitcoin-cli -rpcwallet=ord rescanblockchain 767430
- Re-send with higher fee
ord wallet send --fee-rate 20 <orginal btc destination> <ordinal inscrion id>
@ordinalsbot doubling-down for being a noob. Trying to craft a new raw transaction following the guide you linked in an attempt to bump an
ord wallet send
transaction I gave a low fee-rate for. Currently stuck in mempool for 6 days.
utxo_txid
-> The txid/location of your ordinal (e.g. the inscription id minus the last 2 digits https://ordinals.com/inscription/670da24819e8e221eec3f49f77bd1ea779c1e2fb2e8da1df2ceba0ec2340201bi0 )recipient
-> The same recipient your original send transaction was going to (this transaction https://mempool.space/tx/aa34c1b96700c4704fa54d5b047144f9b2d94409432ba221f677c63029bfc7e9)utxo_vout
-> 0 (the last digit of the inscription id)So for me I can set:
utxo_txid="670da24819e8e221eec3f49f77bd1ea779c1e2fb2e8da1df2ceba0ec2340201b" recipient="bc1pcunwzvauqyupsdn4ke6ulquk7rlspzn6xpkq2tj09908mc4s2q9q57jnmp" utxo_vout="0"
There are 10000 sats with the inscrintion (unspent UTXOs), so lets give it a fee of 2000 sats which means we set an amount of 8000 sats (0.00008 btc) to send (and the 2000 will be used as fee).
So I create raw transaction:
rawtxhex=$(bitcoin-cli createrawtransaction '''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' ''{ "'$recipient'": 0.00008 }''')
Sign the transaction:
signedtx=$(bitcoin-cli signrawtransactionwithwallet $rawtxhex jq -r '.hex')
And send it:
bitcoin-cli sendrawtransaction $signedtx
Does that seem correct? I don't quite understand the amount, whether it needs to pull the fee from this UTXO or whether it is going to grab whatever funds from my wallet (other inscriptions included).
this is exactly right, since original tx signals RBF you can just sign tx with sequence=1 and a higher fee (your output being 8k sats so 2k sats for fee) and miners will mine the new one. Greg's method might work if you have a lot of time on your hands but we did so many of these, we had to automate it. I'll probably share a gist at some point.
But I don't want to derail this issue, we still need a native bump fee on the ord wallet.
@raphjaph @Psifour any comments please?
Commit, reveal, and send transactions can all get stuck in the mempool
Commit transactions are the hardest to replace. Typically the reveal tx is much bigger than the commit tx. When we attempt to replace the commit tx, the node rejects the replacement if the fee on the replacement tx is smaller than the sum of the fees on the existing commit and reveal txs, which it almost always will be. So in that case we either need to specify a huge fee rate for the new commit tx, which is a waste of sats, or use cpfp on the reveal output to increase the effective fee rate.
Would creating a send tx after the reveal with a high CPFP fee rate help an inscription get prioritized without increasing cost of inscription as much?
@MMCGW thank you man! it's working!