Sparrow Bitcoin Wallet

[cygan]

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

[satscraper]

New 2.4.0 feature-rich release.

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}.

[cygan]

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

[satscraper]

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.

[zabzob]

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.

[Cricktor]

...

• 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=...)

[zabzob]

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. 

[nc50lc]

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.

[zabzob]

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.

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.

[nc50lc]

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.

[satscraper]

...

• 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}.

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

[zabzob]

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 

Thanks for all the helpful and informative replies.

[nc50lc]

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  

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.