'gettransaction' returns empty details for some wallet transactions but not others
'gettransaction' returns empty details for some wallet transactions but not others
Loading saved threads...
cviii · External communityPost link
External question — Bitcoin Stack Exchange
Author: cviii
Original post: https://bitcoin.stackexchange.com/questions/131000
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Bitcoin Knots 29.3, single descriptor wallet managed by Sparrow, four 2-of-3 multisig wallets registered in it.
Three transactions from one multisig don't appear in the Knots GUI transaction list. Ten from another, created the same way a day later, display normally. All are self-transfers between two wallets in the same node wallet.
Comparing
gettransaction
output for a working and a non-working transaction: every top-level field matches in shape — same
fee
value,
amount: 0
, empty
walletconflicts
and
mempoolconflicts
,
bip125-replaceable: no
, correct confirmations. The only difference in the entire object is that
details
is populated on one (a
send
and a
receive
entry) and
[]
on the other.
The fee is correct on both, which I take to mean input ownership was resolved. That's the part I don't understand — how does the wallet compute a fee and then produce no detail entries?
Other checks on the non-working wallet:
getaddressinfo
on the destinations:
ismine: true
,
iswatchonly: false
,
solvable: true
,
desc
and
parent_desc
both present
listdescriptors
: correct receive/change pair, matching timestamps, next index matches usage
UTXOs present in
listunspent
with correct amounts
rescanblockchain
from a height before the transactions — completed, no change
balances reconcile; Sparrow displays everything correctly
One unexplained difference: the working wallet has one descriptor with
active: true
; the non-working wallet has both
active: false
. Closing and reopening only the non-working wallet in Sparrow didn't change that.
What populates
details
, and what would leave it empty for a transaction the wallet otherwise fully recognizes?
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External question — Bitcoin Stack Exchange Author: cviii Source score (net votes, not local likes): 0 Original post: https://bitcoin.stackexchange.com/questions/131000 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Bitcoin Knots 29.3, single descriptor wallet managed by Sparrow, four 2-of-3 multisig wallets registered in it. Three transactions from one multisig don't appear in the Knots GUI transaction list. Ten from another, created the same way a day later, display normally. All are self-transfers between two wallets in the same node wallet. Comparing gettransaction output for a working and a non-working transaction: every top-level field matches in shape — same fee value, amount: 0 , empty walletconflicts and mempoolconflicts , bip125-replaceable: no , correct confirmations. The only difference in the entire object is that details is populated on one (a send and a receive entry) and [] on the other. The fee is correct on both, which I take to mean input ownership was resolved. That's the part I don't understand — how does the wallet compute a fee and then produce no detail entries? Other checks on the non-working wallet: getaddressinfo on the destinations: ismine: true , iswatchonly: false , solvable: true , desc and parent_desc both present listdescriptors : correct receive/change pair, matching timestamps, next index matches usage UTXOs present in listunspent with correct amounts rescanblockchain from a height before the transactions — completed, no change balances reconcile; Sparrow displays everything correctly One unexplained difference: the working wallet has one descriptor with active: true ; the non-working wallet has both active: false . Closing and reopening only the non-working wallet in Sparrow didn't change that. What populates details , and what would leave it empty for a transaction the wallet otherwise fully recognizes?
Checking account access…