rpc: Wrong `gettransaction` info for a coinjoin

RHavar commented at 3:00 am on September 3, 2018: contributor

Take a look at this transaction:

https://testnet.smartbit.com.au/tx/947ddb7d22b0c7e8edd3a56a92b8ec771aa8b18667ef508270f928b14821e924

I’ve double checked with getaddressinfo and only the first input is mine, and the second output is mine. So the transaction looks like

Inputs: [1.02 BTC mine, 1.1 BTC not-mine] Outputs: [0.10481803 BTC not-mine, 2.01 BTC mine]

So clearly this transaction makes me 0.99 BTC richer. (-1.02 + 2.01)

So now let’s look at what gettransaction returns:

 0{
 1  "amount": -0.10481803,
 2  "fee": 1.09481803,
 3  "confirmations": 0,
 4  "trusted": false,
 5  "txid": "947ddb7d22b0c7e8edd3a56a92b8ec771aa8b18667ef508270f928b14821e924",
 6  "walletconflicts": [
 7  ],
 8  "time": 1535929790,
 9  "timereceived": 1535929790,
10  "bip125-replaceable": "no",
11  "details": [
12    {
13      "address": "2N8qCRsKMJ3qNYo8LRb9kLpy3qiigAuedMT",
14      "category": "send",
15      "amount": -0.10481803,
16      "vout": 0,
17      "fee": 1.09481803,
18      "abandoned": false
19    },
20    {
21      "address": "2MzFcfPF56Jp6BC3FJk6yXwCY6FzhnbGt3o",
22      "category": "send",
23      "amount": -2.01000000,
24      "label": "",
25      "vout": 1,
26      "fee": 1.09481803,
27      "abandoned": false
28    },
29    {
30      "address": "2MzFcfPF56Jp6BC3FJk6yXwCY6FzhnbGt3o",
31      "category": "receive",
32      "amount": 2.01000000,
33      "label": "",
34      "vout": 1
35    }
36  ],
37  "hex": "020000000001022eb1b5698216f56eea3770c949a5d9555dcd1062571cc3113cae68132a5ba5660100000017160014f67a19d36a915d7e0360d3a66d1f055c7bd34687feffffffe165f072311e71825b47a4797221d7ae56d4b40b7707c540049aee43302448a401000000171600142fa1c410210f8228467e53f450c9e4e56337895ffeffffff028bf09f000000000017a914aaf6ba68cf6a2369445f119596adb84412d28d3a874004fb0b0000000017a9144cdbced31bab78d8a248204a961a4ad475d6b48a87024730440220724dbbdc278315ed367036b163749702c7810730dc2b17ba3226f72c7d0078ab02207945ffb8ffc78bcefa207ac8e172983b5c3d91f64c3cb869cdcd288e6c1d85610121037426b52590172ce72df80829e4a9f7530224306399c399080fc917d19ae44a72024730440220168c025d48f3ee4d626d37a85c92a75e778649e966d8f008caeed688cb6da73902202e00fb70c80e0ba591a12a8feb067cf3216eb054ac5059d0f38ce805bbdd478701210213be1638b4620ccacf4e1bec9748c3fc27561aa7169dbd1639be00bb20236ab800000000"
38}

Note the “fee” thing it has is pretty confused. The actual fee is: 0.00518197 BTC

Running on the 0.17 branch if it makes a difference.

RHavar commented at 6:03 pm on September 3, 2018: contributor

It’s even weirder from “the other side”. So this node’s has:

Inputs: [1.02 BTC not-mine, 1.1 BTC mine] Outputs: [0.10481803 BTC mine, 2.01 BTC not-mine]

So the transaction represents a loss of 0.99518197 BTC (-1.1 + 0.10481803).

But running gettransaction we see:

 0{
 1  "amount": -2.01000000,
 2  "fee": 1.01481803,
 3  "confirmations": 0,
 4  "trusted": false,
 5  "txid": "947ddb7d22b0c7e8edd3a56a92b8ec771aa8b18667ef508270f928b14821e924",
 6  "walletconflicts": [
 7  ],
 8  "time": 1535929758,
 9  "timereceived": 1535929758,
10  "bip125-replaceable": "no",
11  "details": [
12    {
13      "address": "2MzFcfPF56Jp6BC3FJk6yXwCY6FzhnbGt3o",
14      "category": "send",
15      "amount": -2.01000000,
16      "vout": 1,
17      "fee": 1.01481803,
18      "abandoned": false
19    }
20  ],
21  "hex": "020000000001022eb1b5698216f56eea3770c949a5d9555dcd1062571cc3113cae68132a5ba5660100000017160014f67a19d36a915d7e0360d3a66d1f055c7bd34687feffffffe165f072311e71825b47a4797221d7ae56d4b40b7707c540049aee43302448a401000000171600142fa1c410210f8228467e53f450c9e4e56337895ffeffffff028bf09f000000000017a914aaf6ba68cf6a2369445f119596adb84412d28d3a874004fb0b0000000017a9144cdbced31bab78d8a248204a961a4ad475d6b48a87024730440220724dbbdc278315ed367036b163749702c7810730dc2b17ba3226f72c7d0078ab02207945ffb8ffc78bcefa207ac8e172983b5c3d91f64c3cb869cdcd288e6c1d85610121037426b52590172ce72df80829e4a9f7530224306399c399080fc917d19ae44a72024730440220168c025d48f3ee4d626d37a85c92a75e778649e966d8f008caeed688cb6da73902202e00fb70c80e0ba591a12a8feb067cf3216eb054ac5059d0f38ce805bbdd478701210213be1638b4620ccacf4e1bec9748c3fc27561aa7169dbd1639be00bb20236ab800000000"
22}

fanquake added the label RPC/REST/ZMQ on Sep 6, 2018

maflcko renamed this:
~~Wrong `gettransaction` info for a coinjoin~~
rpc: Wrong `gettransaction` info for a coinjoin
on Dec 22, 2018

web3shannon referenced this in commit ab19bd8cdb on Jun 13, 2019

web3shannon referenced this in commit 60e872c90a on Jun 13, 2019

web3shannon referenced this in commit 33c3d84d6d on Jun 17, 2019

web3shannon referenced this in commit 610fe574cd on Jun 25, 2019

maflcko commented at 10:37 pm on May 8, 2020: member

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

maflcko closed this on May 8, 2020

maflcko commented at 11:13 pm on May 8, 2020: member

Yeah, still an issue. See #18919

maflcko reopened this on May 8, 2020

luke-jr commented at 3:57 am on January 11, 2022: member

I think this would require some way to flag the “foreign” outputs in the wallet file, and be incompatible with recovery of an old wallet.

Unless there’s a way to use “sign-to-contract” to designate our outputs? Might make [re]-scanning the wallet slower, but that’s probably better than losing the metadata entirely?

Or is it even worth the effort to try to save this metadata restoring from an old backup?

maflcko commented at 1:16 pm on March 21, 2022: member

There was a fix in #16199, but it needed rebase for a long time, so I closed it. If someone picks this issue up, it might be good to take a look at the closed fix as well.

willcl-ark commented at 2:44 pm on April 10, 2024: member

@achow101 is this still a problem with descriptor wallets?

maflcko commented at 2:46 pm on April 10, 2024: member

Yes, see https://github.com/bitcoin/bitcoin/pull/18919

pinheadmz commented at 7:08 pm on May 23, 2025: member

I’m digging in to this issue, it has two closed PRs: #16199 and #19002 and a test asserting the current, somewhat unexpected, behavior: #18919

There are two things to consider:

We don’t store input amounts in the wallet, only output amounts – and only output amounts we create. That means we can’t compute the fee for a tx unless we created all the outputs the tx is spending.
In the context of a coinjoin a “fee” field could refer to either the actual network fee paid to the miner, OR just the portion of that total fee that was deducted from the wallet.

Some solutions:

If the wallet did not create all inputs to a tx, the “fee” field in gettransaction response should be removed / null, like it is when we receive a transaction and none of the inputs are ours.
In addition to (1) we can start storing the mempool-computed fee along with the serialized tx in the walletDB (from now on…) and report it if it exists, (recommending a rescan if you do a lot of coinjoins?)
Like (2) we can store all input amounts (from now on…) and then offer the user two fields in gettransaction (i.e. "mempool_fee" and "wallet_fee")
If the user has -txindex we can compute the actual fee from historical output data

I think 1 & 4 is an ok place to start a PR, and something like 2 or 3 could be looked at in the future… maybe to avoid inconsistent results we just always do (1) unless the entire wallet has been upgraded and rescanned? @achow101

rpc: Wrong gettransaction info for a coinjoin #14136

rpc: Wrong `gettransaction` info for a coinjoin #14136