listsinceblock and listtransactions report wrongly attributed "send" transactions #16040

Running bitcoind v0.18.0

I've set up a testnet bitcoind, received some coins via a faucet to the wallet, then used "sendtoaddress AddressX" to send 0.01 btc to another address in the same wallet and finally after waiting for a block to be mined, issued a "listsinceblock" with the block hash of the previous block to list all transactions that I just issued.

The result is one "send" and one "receive" transaction for AddressX. The "send" transaction is clearly wrongly attributed to this address, it could not have sent those funds as it was a fresh address with no coins in it.

If one were to track balances of addresses via "listsinceblock" as this is what I assume its intended usecase is, one would end up with completely wrong balances.

Here's the testnet data:

The send was done to address 2N2ueCZcbEfRDz1ahRQGBb8gtYspRyDRZWA Explorer: https://tbtc.bitaps.com/a97eedb300db7e295bbce33c3f4ed9c306fbe8c5e967e377f0396b035bec2842/2MwwifySPjzJkZkkxmtfX6pKvmoveGuiPyD

This sendtoaddress call resulted in 3 inputs going to 2 outputs.

2MwwifySPjzJkZkkxmtfX6pKvmoveGuiPyD 0.01000000

I can see two sensible ways to output this information:

1. List 5 transactions, one for each input and output. This is the most verbose and doesn't really reflect the unit of a single transaction. On the upside, this would not require changes to the json output schema.
2. List one transaction with 3 inputs and 2 outputs with their corresponding addresses and amounts. This is probably the most thruthful representation of the data. As a plus, it could be added as additional "inputs" and "outputs" attributes that would not break existing consumers of this RPC method.

Worryingly I noticed that the output of "listtransactions" is also wrong, listing the wrongly attributed "send" to the address that received the btc, same as "listsinceblock".

My intended usecase is to keep track of all incoming and outgoing transactions for addresses in my wallet inside a SQL database. The current behaviour of "listsinceblock" is unsuitable for this (and not sure what it is actually suitable for, maybe only monitoring receives or overall wallet balances but not on an address level?). What do people usually do to achieve such a goal? How do all the exchanges out there handle it?

Raw RPC response:

# bitcoin-cli -testnet listsinceblock 00000000000000e3d8ece06efdc70d9516efb330f388ac058ab6693ce3306d5f
{
  "transactions": [
    {
      "address": "2N2ueCZcbEfRDz1ahRQGBb8gtYspRyDRZWA",
      "category": "send",
      "amount": -0.01000000,
      "label": "",
      "vout": 0,
      "fee": -0.00000404,
      "confirmations": 6,
      "blockhash": "00000000000000ce854a9a5c46f5a94aa742882e2c90ebf2fac995816e9d7585",
      "blockindex": 84,
      "blocktime": 1558061471,
      "txid": "a97eedb300db7e295bbce33c3f4ed9c306fbe8c5e967e377f0396b035bec2842",
      "walletconflicts": [
      ],
      "time": 1558060647,
      "timereceived": 1558060647,
      "bip125-replaceable": "no",
      "abandoned": false
    },
    {
      "address": "2N2ueCZcbEfRDz1ahRQGBb8gtYspRyDRZWA",
      "category": "receive",
      "amount": 0.01000000,
      "label": "",
      "vout": 0,
      "confirmations": 6,
      "blockhash": "00000000000000ce854a9a5c46f5a94aa742882e2c90ebf2fac995816e9d7585",
      "blockindex": 84,
      "blocktime": 1558061471,
      "txid": "a97eedb300db7e295bbce33c3f4ed9c306fbe8c5e967e377f0396b035bec2842",
      "walletconflicts": [
      ],
      "time": 1558060647,
      "timereceived": 1558060647,
      "bip125-replaceable": "no"
    }
  ],
  "removed": [
  ],
  "lastblock": "00000000000001d79d962cacee38d477fcac0731f33b848c9e216153967e8aef"
}

send transactions list the address sent to. Receive transactions list the address received with.

And yes, all wallet RPCs give information on how transactions affect the wallet balance. They abstract away the individual coin movements. The listunspent and related RPCs let you observe individual coins, but there is no "address balance" concept supported anywhere.

Going to close. Any followup questions are likely better suited to the Bitcoin Stack Exchange.