-
Notifications
You must be signed in to change notification settings - Fork 600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
listsinceblock
lists additional transactions in category send
#273
Comments
I checked on the various block explorers and that address currently has a "balance" of zero (addresses don't have balances, but bear with me), so for every received output in the recv category (or immature, generate, etc.) there should also be a send category, since it was included as an input in another transaction. |
Were all the redeeming transactions created by the same wallet? Because btcwallet will still create results in the "send" category when any output is redeemed, even if it did not author and send the transaction. |
For every outgoing transaction, btcwallet also lists a 'send' transaction that matches the data of the input spend. Example:
The second item is the output towards a wallet address, listed as 'receive transaction'. This is correct and also given by bitcoin core. The first item is the wrong 'spend transaction' that appears once the output given in the second item is spend. Note that the values seem to be the same as for the second item, except an inverted amount and the category. This bug is independent from whether there is change towards the wallet or not. Also change to same or another address doesn't not affect this bug. Maybe this helps. |
I've gone back and took another look at how core is doing it, and I believe the added objects are the same but the order is different. In core, for each transaction, for each non-change output, if the transaction debits from the wallet, each output is added as sent, and then each received output is added as received. Our code is alternating between adding send and receive categories for each unspent output, instead of looping twice over the outputs. |
Sorry for late feedback, I was travelling. Any news on this? If I understand correctly, your last remark doesn't explain why there are additional objects in btcwallet's output, only why there's a different order, no? |
I'm not yet sure why it's adding additional objects. I'll compare against bitcoind behavior later today. |
Let me know if I can help with anything. |
Remove duplicate NeutrinoClient interface Merge btcsuite#265 cache+neutrino: add new cache module by @Roasbeef Merge btcsuite#261 cache+neutrino: update existing Cache interface to use type parameters by @Roasbeef Merge btcsuite#268 cache: add deletion and iteration methods by @yyforyongyu Merge btcsuite#279 lru: add methods to range with orders by @yyforyongyu Merge btcsuite#278 pushtx: map different backend err to internal err by @ziggie1984 Merge btcsuite#273 query+neutrino: use query dispatcher for GetBlock and GetCFilte by @ellemouton Merge btcsuite#274 multi: introduce a batch filter writer by @ellemouton Merge btcsuite#275 rescan: use batch filter fetching by @ellemouton Merge btcsuite#283 blockmanager.go: use btcd libs to validate headers by @guggero Merge btcsuite#288 neutrino: Added ResetRanking method to PeerRanking by @Chinwendu20 Merge btcsuite#293 & btcsuite#294 Fix typos by @vuittont60 Merge btcsuite#297 query: fix retry query case by @ziggie1984
So, this is the bug I've mentioned in #263:
listsinceblock
lists additional transactions that are not present in the bitcoin core result.I now realized that all additional transactions reported have the category
send
even when they haven't been sent from an address in the local wallet. Sorry for not spotting this earlier, but this seems to be a real bug (TM).Example transaction: http://tbtc.blockr.io/tx/info/0154b341c081a35c316554e1f628919232bbf3769e4ca63188997200b1e5bee7
migiScBNvVKYwEiCFhgBNGtZ87cdygtuSQ
is in the wallet, all others are not. btcd correctly returns the receive transaction, but also lists it again as a send.The text was updated successfully, but these errors were encountered: