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: contributor

@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

rpc: Wrong gettransaction info for a coinjoin #14136

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