keep the block transaction a transaction tab shows when its input transactions cannot be fetched, so its confirmation count follows new blocks
What the developer wrote
Authored by Craig Raw
keep the block transaction a transaction tab shows when its input transactions cannot be fetched, so its confirmation count follows new blocks
What changed, and why it matters
This small change fixes a UI bookkeeping bug in Sparrow Wallet. When you open a transaction in a tab, the wallet now properly stores the on-chain block information even if it could not fetch all of that transaction's input transactions. Previously, the block information may not have been saved in that case, so the confirmation count shown in the tab would not update as new blocks arrived. This is a correctness/fix for displayed state, not a vulnerability that lets someone steal funds or run code.
Treat as a routine bugfix. No urgent security action is warranted based on the diff alone. If triaging, verify that the confirmation count now updates correctly for transactions whose input transactions are unavailable, and consider including the fix in the next release.
Security signals we found
UI state consistency fix
No input validation or cryptographic boundary crossed
No privilege escalation, remote execution, or fund theft mechanism evident
Change is additive (two lines: comment + setter call)
Evidence from the diff
In HeadersController.blockTransactionFetched(), the code now calls headersForm.setBlockTransaction(event.getBlockTransaction()) before updateBlockchainForm() when a block transaction is received, including the case where the block hash is non-zero or no prior block transaction was stored. The prior code only updated the displayed form but did not persist the block transaction object on the form when input transactions could not be fetched. As a result, subsequent block-height updates had no stored block transaction to reference, so the confirmation count did not follow the chain tip. The patch ensures the block transaction is kept on the form so later block events can refresh confirmations.
Changed components
src/main/java/com/sparrowwallet/sparrow/transaction/HeadersController.javaTransaction tab confirmation-count displayInspect captured patch +2 / −0
### src/main/java/com/sparrowwallet/sparrow/transaction/HeadersController.java
@@ -1655,6 +1655,8 @@ public void transactionChanged(TransactionChangedEvent event) {
public void blockTransactionFetched(BlockTransactionFetchedEvent event) {
if(event.getTxId().equals(headersForm.getTransaction().getTxId())) {
if(event.getBlockTransaction() != null && (!Sha256Hash.ZERO_HASH.equals(event.getBlockTransaction().getBlockHash()) || headersForm.getBlockTransaction() == null)) {
+ //Kept as well as shown, including where no input transaction could be fetched, so that the confirmation count follows new blocks
+ headersForm.setBlockTransaction(event.getBlockTransaction());
updateBlockchainForm(event.getBlockTransaction(), AppServices.getCurrentBlockHeight());
} else if(headersForm.getPsbt() == null && headersForm.getBlockTransaction() == null && event.getPageStart() == 0) {
//Only the first page asks about the transaction itself, so only its silence says the transaction is not on chainWhy this scored 16/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.