--fee-rate not respected

[casey]

We had a user report that the --fee-rate option was not being respected.

The command was:

ord wallet inscribe --fee-rate 6.0 INSCRIPTION.png

Transaction: 7acd66e6f673e82999cedd37de5a4cbe41f217ae6f1dbf26a1ddfd6ef5488051

Which paid a fee rate of 16.0 sats/vB

I saw a screenshot of the inscribe command output, and it showed fee of 7392. The commit and reveal transactions paid 4928 + 2464 = 7392, so ord wallet was reporting the correct feerate.

[casey]

This is not actionable at the moment, because we haven't been able to reproduce it. Please let us know if you run into this!

[casey]

This is the same underlying problem as #1597, we don't pass a fee to the send RPC command. Easy fix:

1. Write a failing test that shows that the ord wallet send <AMOUNT> command doesn't respect --fee-rate
2. Fix it by passing the correct fee rate to sendtoaddress

[casey]

I believe this is now fixed.

[papiro]

In trying to get to the bottom of something, I came across this thread. Not sure if I did something wrong since I am fairly new at this, but I specified a fee-rate of 16 and it used 16 for the commit transaction, but went ahead and spent the rest of my UTXO in the reveal bringing the fee rate to 18.8 for the reveal.

The command I ran: ord wallet --server-url=http://localhost:8080 --name=ord inscribe --fee-rate=16 --file=5.txt

5.txt is 136 bytes. My wallet had 15000 sats in it in a single UTXO.

Commit & reveal transactions: https://mempool.space/address/bc1pp3ytujrdsv72aak3rytme3x90awujaz4rq8442msf5wdx5qzsjzqqzhs8a

When I do the math, I should have gotten at least something back (in addition to the ordinal with the postage), but more specifically about 533 satoshis back. Instead, all I got was the ordinal with postage (10000 sats).

:~/inscriptions: ord wallet --server-url=http://localhost:8080 --name=ord inscribe --fee-rate=16 --file=5.txt 
{
  "commit": "52ff7cc56b5b837b46fed7e0af1f8a8f88521beb54f67b1b305714f54fbda844",
  "commit_psbt": null,
  "inscriptions": [
    {
      "id": "480179128feb8035ed9199f2d240134146167327869a1ba16bff5fa2df2abf22i0",
      "location": "480179128feb8035ed9199f2d240134146167327869a1ba16bff5fa2df2abf22:0:0"
    }
  ],
  "parent": null,
  "reveal": "480179128feb8035ed9199f2d240134146167327869a1ba16bff5fa2df2abf22",
  "reveal_psbt": null,
  "total_fees": 5000
}

So it did report the total_fees correctly in my case as well... interesting!

[casey]

@papiro Thanks for the report! Can you open a separate issue? I think that this is working as intended. I believe that either ord or bitcoind notices that the excess sats are worth less than the additional fees that would need to be paid to add an additional output to get the sats back. I want to double check that this is the case, but I won't be able to look for a few days.

[papiro]

Ooof, you're totally right. After so much research and thinking, I suspected something like that was the reason. That is great news! I thought something was broken or there was a bug or something, but when I increase the outputs to 2 in this calculator it indeed would have cost more than the 15000 I put in :). Thanks a lot!

[casey]

Nice! You bet!