[Tutorial] BlueWallet - Bitcoin Wallet Discussion

[hosemary]

Interesting case. Wasn't one of those transactions dropped though and its block orphaned in the end? Two separate chains existed for a couple of hours and we had a fork. The double spent transaction was against OKPAY and affected them due to some peculiar circumstances that happened at that time.

Yes. That was the case, I think.
If I got it correctly, it was caused due to some configuration introduced in bitcoin version 0.8 and that was not due a 51% attack or any other malicious attempt.

OKPAY received the transaction and credited the deposit since it was confirmed, but the block including that transaction orphaned later.

[Lucius]

Regarding double-spend, if a BTC transaction has 1 confirmation, then it is not possible to do it - although for some larger amounts, it is recommended that the number of confirmations be at least 3, and for extra valuable ones at least 6. I think it's related to the 51% attack option where an attacker could reverse any transaction that doesn't have at least 6+ confirmations.

Technically, it can be done if a chain reorganization happens. But that's not something that a regular user like you and me can affect. If a reorg happens, the confirmed transaction goes back to the mempool to wait to be confirmed. The sender could then doublespend it, paying a higher fee and hoping nodes will pick up the new transaction instead of the first one. I don't think Bitcoin has ever experienced a case where a confirmed transaction was successfully doublespent though.

However, various payment processors have requirements that the transaction must have at least 3 or even 6 confirmations in order to be valid, so for a less knowledgeable user, paying with BTC can sometimes be quite confusing, especially if he has the misfortune that the time between blocks is unusually long.

I can still understand that for large amounts it makes sense, but for some smaller transactions worth a few tens or hundreds of $, nothing more than a maximum of 2 confirmations makes sense.

[Pmalek]

However, various payment processors have requirements that the transaction must have at least 3 or even 6 confirmations in order to be valid, so for a less knowledgeable user, paying with BTC can sometimes be quite confusing, especially if he has the misfortune that the time between blocks is unusually long.

I can still understand that for large amounts it makes sense, but for some smaller transactions worth a few tens or hundreds of $, nothing more than a maximum of 2 confirmations makes sense.

The misconfiguration that hosemary mentioned happening more than a decade ago lasted for a few hours. The problematic transaction was valid for multiple blocks before the block was finally orphaned. It's safe to assume that it had the needed 3, 6, or x confirmations. An orphaned block in itself isn't that big of a deal. The transactions that made it into that block go back to the mempool, waiting to be confirmed again. People don't necessarily lose the bitcoin they previously had. They just have to wait for confirmations again. Unless, of course, someone doublespends the coins.

[Charles-Tim]

The transactions that made it into that block go back to the mempool, waiting to be confirmed again. People don't necessarily lose the bitcoin they previously had. They just have to wait for confirmations again. Unless, of course, someone doublespends the coins.

Almost all the transactions in the orphaned block will be on the block that has the longest chain that remains valid. Maybe just few transactions will not be on the block that has the longest chain and which will be back into the mempool and which will likely be confirmed again unless the sender double spend it.

Sometimes I think about if the mempool suddenly become congested and the purging fee increased more than the fee used by the sender. Although, if the sender do not spend the coin again, the transaction may still likely be confirmed because some nodes settings are different from the default and the node runners make some changes to the settings.

[aylabadia05]

I'd like to announce that v7.2.0 was released last week.

The version 7.2.0  update dependency react-native-svg to v15.12.0, Allow screenshots option not working, , and updating AndroidManifest.xml

Source here -> https://github.com/BlueWallet/BlueWallet/releases/tag/v7.2.0

[Pmalek]

I'd like to announce that v7.2.0 was released last week.

Blue Wallet promised they would start to support below 1 sat/vByte transactions mid-July. I can see in the release notes that this PR has been included in the 7.2.0 release. They have also fixed a fee display bug that showed the fees in an untraditional format. I guess the version is being rolled out in stages because I still haven't received the update for my Android phone. I am not in a hurry. It will be there.

[_act_]

Blue Wallet promised they would start to support below 1 sat/vByte transactions mid-July. I can see in the release notes that this PR has been included in the 7.2.0 release.

But won't it lead to frustration of unconfirmed transaction? Because lmost all nodes have 1 sat/vbyte and that is how it is in their default settings. If someone wants to make less than 1 sat/vbyte as the fee, nodes will reject it but if there is a node that accepts it, it can lead to longer wait before confirmation if the transaction is not dropped out of memory pool, but it can drop out of memory pool.

They have also fixed a fee display bug that showed the fees in an untraditional format. I guess the version is being rolled out in stages because I still haven't received the update for my Android phone. I am not in a hurry. It will be there.

I also went to their GitHub to know if they have it there, but version 7.1.8 is still only the last version for Android. Only iOS latest release is there.

[hosemary]

But won't it lead to frustration of unconfirmed transaction? Because lmost all nodes have 1 sat/vbyte and that is how it is in their default settings. If someone wants to make less than 1 sat/vbyte as the fee, nodes will reject it but if there is a node that accepts it, it can lead to longer wait before confirmation if the transaction is not dropped out of memory pool, but it can drop out of memory pool.

Many miners are accepting transactions paying less than 1 sat/vbyte as fee and most probably, more and more miners will do the same thing soon.
Just check mempool.space or any other block explorer. You can find many blocks with transactions paying less than 1 sat/vbyte as fee.

[_act_]

Many miners are accepting transactions paying less than 1 sat/vbyte as fee and most probably, more and more miners will do the same thing soon.
Just check mempool.space or any other block explorer. You can find many blocks with transactions paying less than 1 sat/vbyte as fee.

Just like block 910264, there are 2531 transactions there but there are only four transactions that have fee below 1 sat/bytes which is very small to me. Maybe this will increase if more wallets are supporting fee below 1 sat/vbyte.



I think such little will be from full nodes but maybe I am not correct. I will try to use below 1 sat/vbyte immediately Bluewallet version 7.2 is available on Android.

[aylabadia05]

They have also fixed a fee display bug that showed the fees in an untraditional format. I guess the version is being rolled out in stages because I still haven't received the update for my Android phone. I am not in a hurry. It will be there.

I also went to their GitHub to know if they have it there, but version 7.1.8 is still only the last version for Android. Only iOS latest release is there.

On the Android version, the update to v7.2.0 isn't yet available, and it's still at v7.1.8 as the latest version. When we visit the official website and click on the Play Store, there's no update yet. On the iOS version, version 7.2.0 is already available.

Yesterday, when I opened the website and clicked on the App Store, the update prompt was available. It's different when I opened Android and v7.2.0 wasn't available yet.
Perhaps we need to be patient, as they'll roll it out to Android as soon as possible.

[hosemary]

Just like block 910264, there are 2531 transactions there but there are only four transactions that have fee below 1 sat/bytes which is very small to me. Maybe this will increase if more wallets are supporting fee below 1 sat/vbyte.

I just checked the most recent block.
Block number 910280 has included 5,026 transactions and 3,853 out of them have been made with the fee rate of less than 1 sat/vbyte.

Not all miners accept transactions paying less than 1 sat/vbyte as fee. That's why some blocks include those transactions and some don't.

[Pmalek]

But won't it lead to frustration of unconfirmed transaction? Because lmost all nodes have 1 sat/vbyte and that is how it is in their default settings. If someone wants to make less than 1 sat/vbyte as the fee, nodes will reject it but if there is a node that accepts it, it can lead to longer wait before confirmation if the transaction is not dropped out of memory pool, but it can drop out of memory pool.

There are enough nodes that accept below 1 sat/vByte transaction for them to propagate properly and reach the nodes of the leading miners. I have broadcasted such transactions through Mempool.Space and recently via Electrum.

Just like when transaction fees were high, you will have to determine how much to pay and what your approximate waiting time will look like. If you pay the lowest current fee, which is 0.10 sat/vByte, you will wait a long time. Mempool.space currently shows that your transaction would confirm in 18 blocks at best but it can also be much longer than that. On the other hand, if you paid 0.25 sat/vByte right now, the first confirmation seems only 1-2 blocks away. 

I also went to their GitHub to know if they have it there, but version 7.1.8 is still only the last version for Android. Only iOS latest release is there.

You are right. There are no .apk files available for download for Android phones.

Just like block 910264, there are 2531 transactions there but there are only four transactions that have fee below 1 sat/bytes which is very small to me.

When that block was mined, there were enough transactions that paid over 1 sat/vByte to fill most of the block. The miner then took only a handful of sub 1 sat/vByte transactions to fill the remaining block space. But there are also miners who still reject these low-paying transactions, so they end up with blocks that are only 20% or 30% full. That makes no sense to me because miners want to make as much as possible. Sub 1 sat/vByte transactions are now a reality. Excluding them is leaving money on the street. It's not a lot, but still why throw it away!? 

[Charles-Tim]

Bluewallet 7.2.1 is now out for Android users. People can now send less than 1 sat/vbyte in their bitcoin transaction. You can see how I did it here: https://asktom.cf/index.php?topic=5556044.msg65860312#msg65860312

[cygan]

a new 7.2.2 version has been available since yesterday
the most important new feature is that taproot is now fully supported in this version!
the complete changelog is available at the following link: https://github.com/BlueWallet/BlueWallet/releases/tag/v7.2.2

[Lucius]

a new 7.2.2 version has been available since yesterday
~snip~

The release notes say : fix "better electrum fee estimation",  and now finally the fees that are offered correspond to the real state of the mempool. As far as I can see, behind this wallet is a really active team and it is obvious that they listen and read user suggestions.

[Forsyth Jones]

-
the most important new feature is that taproot is now fully supported in this version!
...

I struggled a bit trying to create a BIP86 taproot wallet in Bluewallet.

When importing an existing wallet, I go to the 3 dots > Wallet Type, select the Taproot option and even then the app creates/import a wallet in the BIP84 standard and not a taproot one.

To create a Taproot wallet, you must click on 'custom derivation path' before the app creates a wallet in the standard BIP84 format.

Only in 'custom derivation path' will you have the opportunity to select the 'HD Taproot (BIP86)' option and then Import.

When you see your balance surrounded by a purple background, it's because it's a Taproot wallet.

I didn't post an image because Bluewallet doesn't let me take screenshots of the interface.

I tested it on my Android device.

[nc50lc]

I didn't post an image because Bluewallet doesn't let me take screenshots of the interface.

You can temporarily disable that screenshot protection under your wallet's "General->Privacy" settings: "Allow Screen Capture".
But that's only in the current session when you enabled the setting.
Once you close Blue wallet, it'll turn-off by itself.

I take that you're planning to create a tutorial for it?

[Husna QA]

the most important new feature is that taproot is now fully supported in this version!

I struggled a bit trying to create a BIP86 taproot wallet in Bluewallet.

When importing an existing wallet, I go to the 3 dots > Wallet Type, select the Taproot option and even then the app creates/import a wallet in the BIP84 standard and not a taproot one.
-snip-

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.

I didn't post an image because Bluewallet doesn't let me take screenshots of the interface.

As mentioned above, the Allow screen capture setting is only temporary, as explained under that option.

[nc50lc]

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.

[Pmalek]

I struggled a bit trying to create a BIP86 taproot wallet in Bluewallet.

When importing an existing wallet, I go to the 3 dots > Wallet Type, select the Taproot option and even then the app creates/import a wallet in the BIP84 standard and not a taproot one.
...

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.