[Tutorial] BlueWallet - Bitcoin Wallet Discussion

[Husna QA]

Is the Taproot feature only available on the Android version of Blue Wallet? I'm using the iOS version (Blue Wallet 7.2.2) and I couldn't find the Taproot option when creating a new address or when attempting to import a wallet.

Just continue on that import step,
you may have to untick that "Search accounts" toggle so it wont auto-create in the step below. (happened to me a few times)

Then, it'll auto 'discover' in the next window, but immediately tap "Use Custom Derivation Path" below and there should be an "HD TapRoot (BIP86)" option there.
It wont be clickable until it finished scanning for transactions, but empty (Not Found) result will still enable you to restore the wallet.

Thank you for the guidance. I saw your reply a few days ago, but I only had the chance to try it on BlueWallet today. Here are the results:

-snip-

I don't have an existing Taproot wallet that I could try to import into Blue Wallet to check the steps, but at least creating a new Taproot wallet is easy.

You pretty much covered the steps:
Give the wallet a name, tap the three dots in the top right, click "wallet type" and switch from "Best practice" to "Taproot". Click on the "Create" button, make a backup of your seed, and you are done.

When I created a new wallet in BlueWallet, I did not find any option to choose the wallet type, nor an option to change the wallet type to Taproot.

I managed to create an imported HD Taproot wallet using the seed phrase that I obtained when I previously created a Bech32 native wallet in BlueWallet. Therefore, you do not need to use a seed phrase from a Taproot wallet specifically; seed phrases from other Bitcoin wallet types can also be used.

[Pmalek]

When I created a new wallet in BlueWallet, I did not find any option to choose the wallet type, nor an option to change the wallet type to Taproot.

Are you using an Android phone or an iPhone? The option should be there for Android. Have you updated the app to version 7.2.3?

Immediately after you click the "Add Wallet" button in Blue Wallet, you will see the same as shown on the screenshot below. Click on the three dots in the top right and select "Wallet Type." Then switch from "Best practice" (native segwit) to "Taproot." That's all it takes.

[Husna QA]

When I created a new wallet in BlueWallet, I did not find any option to choose the wallet type, nor an option to change the wallet type to Taproot.

Are you using an Android phone or an iPhone? The option should be there for Android. Have you updated the app to version 7.2.3?

I am using the iOS version of BlueWallet with automatic app updates enabled in the App Store. On December 7, I took a screenshot and at that time it was still version 7.2.2. However, when I checked again just now, the app has already been updated to version 7.2.3.

Immediately after you click the "Add Wallet" button in Blue Wallet, you will see the same as shown on the screenshot below. Click on the three dots in the top right and select "Wallet Type." Then switch from "Best practice" (native segwit) to "Taproot." That's all it takes.

Thank you. I previously did not realize that the option to select the wallet type was hidden in the menu (three-dot icon) at the top right corner. Below is how it appears:



It appears that the menu in the version of BlueWallet I’m using includes more options than the version you mentioned above.

[aylabadia05]

When I created a new wallet in BlueWallet, I did not find any option to choose the wallet type, nor an option to change the wallet type to Taproot.

Are you using an Android phone or an iPhone? The option should be there for Android. Have you updated the app to version 7.2.3?

Immediately after you click the "Add Wallet" button in Blue Wallet, you will see the same as shown on the screenshot below. Click on the three dots in the top right and select "Wallet Type." Then switch from "Best practice" (native segwit) to "Taproot." That's all it takes.

In bluewallet version 7.2.3 on Android, when adding a wallet after pressing + then ... in the right corner, the type wallet option will appear as you showed, displaying best practice, legacy, taproot, and lightning.
However, if the user chooses to press provide entropy via dice rolls, two options will appear, namely 12 words and 24 words.



This is good news for users looking for a wallet with extensive support.

[Husna QA]

-snip-
However, if the user chooses to press provide entropy via dice rolls, two options will appear, namely 12 words and 24 words.


-snip-

As I guessed earlier, the option to choose a 12-word or 24-word seed should also be available in the Android version of BlueWallet. It’s just that the menu placement might be a bit different compared to the iOS version.

Even though BlueWallet first launched on iOS back in 2017 and even has an Apple Watch version, the core features on Android are usually the same. That’s because both versions are built using React Native*, so the features across platforms are pretty similar.

* https://github.com/BlueWallet/BlueWallet




https://github.com/topics/react-native

[nc50lc]

That’s because both versions are built using React Native*, so the features across platforms are pretty similar.

Now that you mentioned it,
There's news about possible vulnerability in apps using React.

There's even one thread in this board that's mentioned it: /index.php?topic=5568640.0

But there's no posted security advisory in BlueWallet's GitHub repository so I guess it's not affected or something. (/BlueWallet/security)

[Husna QA]

That’s because both versions are built using React Native*, so the features across platforms are pretty similar.

Now that you mentioned it,
There's news about possible vulnerability in apps using React.

There's even one thread in this board that's mentioned it: /index.php?topic=5568640.0

But there's no posted security advisory in BlueWallet's GitHub repository so I guess it's not affected or something. (/BlueWallet/security)

I have read the thread and also checked the link posted by @ABCbits regarding React: /index.php?topic=5568640.msg66183223#msg66183223.

I then tried to look into whether the Critical Security Vulnerability in React Server Components has a direct impact on applications like BlueWallet, which uses React Native.
Based on what I found, in general, this issue does not directly affect React Native applications that run purely on the client side (mobile), unless the application also uses a server-side architecture that is vulnerable by default. -CMIIW-

Additionally, one of the podcasts from a channel I follow also discussed the latest React security issues;
https://www.youtube.com/watch?v=b0hl23ksWIQ

https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

Note regarding React Native as mentioned in the security issue:

However, discussing it further here would likely be a bit off-topic for this thread.

[Pmalek]

The next release of Blue Wallet will add support for Coldcards and their Bitcoin QR code standard, BBQR. This has been announced by their team at X. I haven't kept track of how many software wallets have added support for the BBQR standard since its creation, but it's good for Coldcard users that we will soon have another one.

[LayerzWallet]

Should be available soon on Layerzwallet too 

[aylabadia05]

The BlueWallet app has released version 7.2.6. In release v7.2.6, there are only three changes, namely:
1. Support for BBQR with Coldcard
2. Simpler Settings
3. Dates on transaction list

Source: Releases v7.2.6
This release was just announced (3 hours ago) based on this post, which I am sharing as an update to the information announced on gitub.com BlueWallet.



As a reminder, security should not be overlooked because it concerns your assets.

[Forsyth Jones]

Bluewallet's dev is testing a new transaction screen, and one of the details that has caught the most attention is a fee estimate widget similar to the block explorer mempool.space. This adds an incredible modern touch and improves the UX experience.

There is no release date yet for the new UI.

See a preview on X: https://x.com/bc1nuno/status/2023111365481902232

[Lucius]

@Forsyth Jones, that would be a great addition to their wallet, because I personally always check that source before making a transaction to adjust the transaction fee. I hope we won't have to wait too long for a new improvement.

[zabzob]

Hey, running BlueWallet on iPhone. I'm having an issue trying to use the coin-control feature to send a tx using several small utxo's as inputs. When I try to send, I get this error message: "the transaction was rejected by network rules. dust, tx with dust output must be 0-fee."

I'm getting this error message even when I consolidate enough dust utxo's to have a big enough change output to not itself be dust. Make sense? Not sure I'm explaining it clearly. No matter how many small utxo's I select as inputs in coin control, and now matter how small the output, I keep getting this message. I even get it if I use a bigger utxo as input, and combine one or more dust utxo's with it. So effectively, it's impossible for me to spend my dust utxo's with my bluewallet. The error message doesn't seem to make sense, since the dust dust utxo's are inputs, not outputs.

I've tried a bunch of different servers, so I don't think the issue is server-specific. Is there any way to do this? Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

I'm also wondering why BlueWallet has this rule? Requiring a 0-fee tx is equivalent to banning that type of transaction altogether, since it will probably never get a confirmation. What's the deal??

[Karl_3000]

I've tried a bunch of different servers, so I don't think the issue is server-specific. Is there any way to do this? Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

They may be low to the extent they are dust and bitcoin nodes are rejecting the transaction. If the nodes are rejecting the dust coin, you do not need to import the wallet seed phrase into sparrow or any other noncustodial wallet, the nodes there will also reject the dust coins.

[zabzob]

I've tried a bunch of different servers, so I don't think the issue is server-specific. Is there any way to do this? Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

They may be low to the extent they are dust and bitcoin nodes are rejecting the transaction. If the nodes are rejecting the dust coin, you do not need to import the wallet seed phrase into sparrow or any other noncustodial wallet, the nodes there will also reject the dust coins.

I'm running my own node on Sparrow, would that be a way around other nodes rejecting the tx?

[Cookdata]

I've tried a bunch of different servers, so I don't think the issue is server-specific. Is there any way to do this? Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

They may be low to the extent they are dust and bitcoin nodes are rejecting the transaction. If the nodes are rejecting the dust coin, you do not need to import the wallet seed phrase into sparrow or any other noncustodial wallet, the nodes there will also reject the dust coins.

I'm running my own node on Sparrow, would that be a way around other nodes rejecting the tx?

The problem might not be coming from the node, it could be from blue wallet.

Since you run your node, you can connect sparrow to your node and give it a try.

By the way, have you check the inputs if they are less than dust limit? Check this quote and compare your inputs if they are above the dust limits.

If you are interested to know why these are the limits, you can read the relevant code starting here: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L26

The dust limit is 3000 sat/kvB, or 3 sats/vbyte, of the minimum amount of data required to spend that type of output.
For a legacy P2PKH transaction, then an input is 148 bytes, and an output is 34 bytes, giving (148+34)*3 = 546 sats.
For a segwit v0 P2WPKH transaction, then an input is 67 bytes and an output is 31 bytes, giving (67+31)*3 = 294 sats.*

For any script hash or taproot outputs, however, then the size of the input is not known in advance, since the locking script is not revealed until after the transaction is made. So instead we use the size of a standard input, and the size of the specific output.
So for a taproot P2TR transaction, then an input is assumed to be 67 bytes and an output is 43 bytes, giving (67+43)*3 = 330 sats.

*This should actually be 297 sats in reality, but a rounding error means that 67.75 is rounded down to 67 instead of up to 68.

[zabzob]

I've tried a bunch of different servers, so I don't think the issue is server-specific. Is there any way to do this? Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

They may be low to the extent they are dust and bitcoin nodes are rejecting the transaction. If the nodes are rejecting the dust coin, you do not need to import the wallet seed phrase into sparrow or any other noncustodial wallet, the nodes there will also reject the dust coins.

I'm running my own node on Sparrow, would that be a way around other nodes rejecting the tx?

The problem might not be coming from the node, it could be from blue wallet.

Since you run your node, you can connect sparrow to your node and give it a try.

By the way, have you check the inputs if they are less than dust limit? Check this quote and compare your inputs if they are above the dust limits.

If you are interested to know why these are the limits, you can read the relevant code starting here: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L26

The dust limit is 3000 sat/kvB, or 3 sats/vbyte, of the minimum amount of data required to spend that type of output.
For a legacy P2PKH transaction, then an input is 148 bytes, and an output is 34 bytes, giving (148+34)*3 = 546 sats.
For a segwit v0 P2WPKH transaction, then an input is 67 bytes and an output is 31 bytes, giving (67+31)*3 = 294 sats.*

For any script hash or taproot outputs, however, then the size of the input is not known in advance, since the locking script is not revealed until after the transaction is made. So instead we use the size of a standard input, and the size of the specific output.
So for a taproot P2TR transaction, then an input is assumed to be 67 bytes and an output is 43 bytes, giving (67+43)*3 = 330 sats.

*This should actually be 297 sats in reality, but a rounding error means that 67.75 is rounded down to 67 instead of up to 68.

Thanks for this helpful reply. I checked and all of my small inputs are above that limit of 294 sats (all my tx's are segwit). The smallest one is 3xx sats, and the rest are over 1000 sats. I'll try with Sparrow and see if that works

[nc50lc]

Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

I'm running my own node on Sparrow, would that be a way around other nodes rejecting the tx?

Or instead of importing the whole wallet, just export the signed transaction from Blue wallet from "Details" button when sending.
And then broadcast it with your Bitcoin Node via sendrawtransaction command.

[zabzob]

Or will I have to import the wallet into Sparrow to be able to sweep up the dust?

I'm running my own node on Sparrow, would that be a way around other nodes rejecting the tx?

Or instead of importing the whole wallet, just export the signed transaction from Blue wallet from "Details" button when sending.
And then broadcast it with your Bitcoin Node via sendrawtransaction command.

Thanks, I'll try this