Sparrow Bitcoin Wallet

a few minutes ago the 2.3.1 version of the Sparrow wallet was released
several bugs have been fixed and it is now possible to restore the bip32-derivatives for consolidation payments in psbts

complete change log: https://github.com/sparrowwallet/sparrow/releases/tag/2.3.1

New 2.4.0 feature-rich release.

Quote from: https://github.com/sparrowwallet/sparrow/releases/tag/2.4.0

I would highlight the addition of support for Trezor Safe 7 and Ledger Nano Gen 5.

Also, I like that development continues to improve Sparrow’s Silent Payments capability. In particular, this release adds new PSBT data fields that hardware wallets need in order to sign Silent Payment transactions correctly.

I can hardly wait for Sparrow to become fully Silent Payment compatible ^{meaning it will not only send to Silent Payment addresses, but also generate them and scan for them}.

a new 2.4.1 version was released a few minutes ago.
the excessive cpu usage on some platforms (due to a problem with the screen layout) has been fixed. it is now also possible to configure a user-defined wallet directory in order to open a wallet from a non-default location

the complete changelog/dl-files can be found under this link: https://github.com/sparrowwallet/sparrow/releases/tag/2.4.1

Looks like developer woke up after the long winter sleep and started churning out new releases.

I generally prefer not to rush into installing new update unless it addresses the security issue or improves security. The same goes for bugs, i.e. if none of them are critical and the ones being fixed don’t interfere with my system or setup I usually wait for the next release. Wink

I'm having a weird issue with a Tx sent through my Sparrow wallet. I sent it yesterday with a fee below 1 sat/vByte, and it hasn't confirmed yet. It looks like it hasn't even appeared in the mempool yet, because I get "Transaction not found" when I search for it on mempool.space.

I'm running my own full node on Core 30.0. I have recently sent numerous transactions with fees even lower than this one, and they all confirmed quickly. Considering the mining fees are currently low, I'm wondering what the issue is with this Tx. Should I cancel it and send a new one? I could raise the fee if necessary, but would rather avoid that if possible.

Quote from: zabzob on February 23, 2026, 06:46:42 PM

...

Quote from: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-30.0.md#policy

The default minimum relay feerate (-minrelaytxfee) and incremental relay feerate (-incrementalrelayfee) have been changed to 0.1 satoshis per vB. They can still be changed using their respective configuration options, but it is recommended to change both together if you decide to do so. (#33106)

Other minimum feerates (e.g. the dust feerate, the minimum returned by the fee estimator, and all feerates used by the wallet) remain unchanged. The mempool minimum feerate still changes in response to high volume.

Note that unless these lower defaults are widely adopted across the network, transactions created with lower fee rates are not guaranteed to propagate or confirm. The wallet feerates remain unchanged; -mintxfee must be changed before attempting to create transactions with lower feerates using the wallet. (#33106)

First, you could have been unlucky with your node's peer that none of them were configured to relay sub-1sat/vB fee rate transactions. Though, I somewhat doubt this would be the case, unless your node was unluckily connected to only a few other "stubborn" nodes when you tried to broadcast your transaction.

Second, did you adjust -mintxfee option when invoking your Core node OR do you have an appropriate setting in your bitcoin.conf file?

Here's what I have in my bitcoin.conf file:

Code:

...
# Fee rate (in BTC/kB) used to define cost of relay, used for mempool limiting and BIP 125 replacement.
incrementalrelayfee=0.000001

# Fee rates (in BTC/kB) smaller than this are considered zero fee for transaction creation
mintxfee=0.000001

# Fee rates (in BTC/kB) smaller than this are considered zero fee for relaying, mining and transaction creation.
minrelaytxfee=0.000001
...

(Comments copied partly from following source: https://jlopp.github.io/bitcoin-core-config-generator/#config=...)

Thanks for this detailed reply. My understanding is that Core 30.0 is configured by default to allow fees well bellow 1 sat/vByte (as I believe you note in your post, if I understood you correctly). And this must be the case, since I have been able to send several Tx's with fees in the 0.2 sat/vByte range without issue, and had not made any changes to the config file since then.

I did try adding the following line to my bitcoin.config file: minrelaytxfee=0.1

But this did not change anything, and the Tx remains unconfirmed. So maybe I did just have the bad luck of sending to "stubborn" nodes that are still refusing lower fees.

I guess the thing to do now is to withdraw the Tx (if possible) and just try again.

Quote from: zabzob on February 24, 2026, 03:11:42 AM

I did try adding the following line to my bitcoin.config file: minrelaytxfee=0.1

That did the opposite, the value is in BTC/kvB unit so you actually set it higher instead.
Check Cricktor's config for the correct values.

However, since you're using Bitcoin Core v30.0, that shouldn't be required as you mentioned.
Reference: /policy.h#L66

Don't forget to restart Bitcoin Core when changing anything in the config file.

Quote from: nc50lc on February 24, 2026, 03:40:12 AM

Quote from: zabzob on February 24, 2026, 03:11:42 AM

I did try adding the following line to my bitcoin.config file: minrelaytxfee=0.1

Ah, then I ended up setting the minimum fee to an insanely high price. But, as you said, it shouldn't have been necessary to change anything in Core 30, considering how the other Tx's went through without issue. (And I did restart Core after editing the config file.) I'll just re-comment that line and try to re-broadcast the Tx.

Quote from: zabzob on February 24, 2026, 03:55:49 AM

I'll just re-comment that line and try to re-broadcast the Tx.

While you're at it.
Use getconnectioncount and getnetworkinfo commands after waiting for a few minutes (about 5~10) or an hour and include it to your next reply.
In the latter, you only need the "relayfee" value.

Quote from: Cricktor on February 23, 2026, 09:10:05 PM

Quote from: zabzob on February 23, 2026, 06:46:42 PM

...

Quote from: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-30.0.md#policy

The default minimum relay feerate (-minrelaytxfee) and incremental relay feerate (-incrementalrelayfee) have been changed to 0.1 satoshis per vB. They can still be changed using their respective configuration options, but it is recommended to change both together if you decide to do so. (#33106)

Other minimum feerates (e.g. the dust feerate, the minimum returned by the fee estimator, and all feerates used by the wallet) remain unchanged. The mempool minimum feerate still changes in response to high volume.

Note that unless these lower defaults are widely adopted across the network, transactions created with lower fee rates are not guaranteed to propagate or confirm. The wallet feerates remain unchanged; -mintxfee must be changed before attempting to create transactions with lower feerates using the wallet. (#33106)

First, you could have been unlucky with your node's peer that none of them were configured to relay sub-1sat/vB fee rate transactions.

Another possibility is that their node was surrounded by peers that intentionally eclipsed it. I remember experiencing the similar issue about two years ago ^{when the fee were much higher than 0.1 sat/vB}.

Quote from: https://ieeexplore.ieee.org/document/10872918

After I manually changed my peer connections everything started working smoothly again. So situations like this can eventually happen to any node.

Weirdly enough, the Tx went through on its own before I got a chance to withdraw it. So the issue is resolved, whatever it was Huh

Thanks for all the helpful and informative replies.

Quote from: zabzob on February 24, 2026, 03:38:38 PM

Weirdly enough, the Tx went through on its own before I got a chance to withdraw it. So the issue is resolved, whatever it was Huh

Those several days must have refreshed some of your peers,
Your watch-only "cormorant" wallet in Core also re-broadcast its 'unconfirmed (not in mempool)' transactions on restart.
(except when you had a very high minrelayfee setting)

There's not enough information to pinpoint the cause but if you're fine with just having the issue solved, then let's leave it like that.

sparrow is releasing another new version today... the 2.4.2 version includes many upgrades and bug fixes like eg. the transaction editor now supports v3 transactions
the complete changelog/dl-files can be found under this link: https://github.com/sparrowwallet/sparrow/releases/tag/2.4.2

I’m impressed by the long list of library upgrades used by latest Sparrow. In my view, the upgrade of the Bouncy Castle library is the most important one, since this cryptographic library handles all critical operations such as key generation and signing. The most threatened ^{among all known} issues for older versions of this library is " denial of service vulnerability discovered in the Bouncy Castle Java Cryptography APIs." . So updating to new version is meaningful security improvement

Argon2 JVM upgrade is also highly important, as this library is responsible for password hashing.

Usually, I don’t rush to update wallets immediately, but in this case I have to say that upgrading to version 2.4.2 is the first thing everyone should do in the morning.

Quote from: https://github.com/sparrowwallet/sparrow/releases

Sparrow released an impressive new update today!
with the new 2.5.0 version, it is now possible to receive silent payments directly to your wallet. numerous improvements, upgrades and bug fixes have been released, which you can view at the following link: https://github.com/sparrowwallet/sparrow/releases/tag/2.5.0

Quote from: cygan on May 21, 2026, 11:59:45 AM

Nice, this release makes Sparrow the first and only multisig coordinator that fully supports Silent Payments, a really huge milestone achieved by its developer. The only thing left for me personally is to wait for Foundation to finally add the long‑promised Silent Payment support to Passport Core so I can start testing this feature in multisig setup^{of course, first on testnet}.

Great news, Sparrow Wallet already has Bech32m (Taproot) and now has Silent Payments for receiving payments. I hope this helps increase SP adoption of Sparrow Wallet and creates ripple effect (more and more wallets implementing it).

Quote from: cygan on May 21, 2026, 11:59:45 AM

Sparrow Wallet added https://bitview.space/ as a new blockchain explorer and fee rates source. I haven't heard of this service before but it looks interesting. They show blocks as cubes in a vertical line, with the most recent block in orange. There is plenty of data to read and investigate on the right. There is also a lot of market related data on the website about the network, mining, investing, etc.

Still, I think mempool.space has become the go-to blockchain explorer for many people and it will be difficult to remove them from the first place.

a new version was released today... the new 2.5.1 includes two bug fixes and an update.
you can see exactly what they are by visiting the following link: https://github.com/sparrowwallet/sparrow/releases/tag/2.5.1