It is an interesting talking point because it is exactly the same talking point that Square/Block have been using to promote their hardware wallet which has no seed phrases and shares custody of your back up with third parties.

For example, here is their business lead Lindsey Grossman using the 100 million figure, and then talking about her "friends and family": https://youtu.be/WbjzZQwDozw?t=355

Or, the incredibly simple solution which would have avoided literally all of this drama - create a new product called Ledger Nano R, which is the only product in their range which provides this Recovery nonsense. People who want third parties to store their seed phrase can buy the R, and everyone else with a shred of sense can stay away from it.

Not at all. If an unconfirmed transaction is opted in to RBF it is very easy to cancel it with a conflicting transaction. Full RBF is also being slowly enabled across the network, which will mean any unconfirmed transaction can be replaced.

That's incorrect. The recipient of a transaction has no power to reverse or cancel a transaction. Their abilities are limited to performing a CPFP in order to speed up the first confirmation.

Nodes generally only relay a transaction to other nodes when they first receive it. There is no reason for nodes to continuously broadcast every transaction in their mempool. So if one or two nodes are running with much higher limits and still have OP's transaction in their mempools, they will generally not rebroadcast it to other nodes which have dropped it unless they are told to do so. So when the majority of nodes have dropped OP's transaction, he can broadcast a different one spending the same inputs and it will be accepted.

It doesn't matter who broadcast the transaction; what matters is what wallet is receiving it. If it is being received in to a wallet where OP has control over the receiving address, such as Electrum, he can use that output to perform a CPFP. If it is being received in to a centralized wallet belonging to a third party, then OP has no control over that address and so cannot perform a CPFP.

This x1000. I do not believe that the Ledger team do not understand the difference between KYC on a centralized exchange where you already have zero privacy and zero security and are well aware the centralized exchange has complete control of your coins and is monitoring everything you do, versus KYC on a hardware wallet where the vast majority of people are going to want complete security and a reasonable amount of privacy. The vast majority of people do not want their hardware wallet addresses KYCed or their wallets linked to their real identity and that information shared with blockchain analysis companies, governments, and whoever else pays for the data.

I'm sure Ledger know this, but are being deliberately misleading in the defense of their new vulnerability feature.

There are two options you could use to decide which transaction has been waiting longer, and both are easily fooled/abused.

The first is that you say each node must keep a list of the order in which it saw individual transactions. Miners can them simply include any transactions they like (i.e. the high fee paying ones) and claim they either saw the low fee paying ones at a later date or even not at all. There would be no way for anyone to prove otherwise.

The second is that you use the nLockTime field in each transaction has a surrogate marker for when that transaction was first broadcast. I could sign a transaction today but back date the nLockTime field to a month ago, and again there would be no way for anyone to prove my transaction hadn't really been waiting for a month already.

In a decentralized network such as bitcoin, there is no concept of which unconfirmed transaction was broadcast "first" which would allow this to work. The whole point of a blockchain, which each block building on top of the previous block, is because you cannot rely on a timestamp or the first block you see actually being the first block which was broadcast. The time a transaction was first seen will vary between every node on the network, and at times like these when the mempool is full (which is the exact times you would want your suggestion to be used), transactions can be dropped and rebroadcast multiple times from different nodes at different times, making it impossible to keep track.

What are you even talking about? Trading peer to peer is the very essence of decentralization and not involving centralized third parties in your trades.

And what do you think happens to your privacy when you sign up for a centralized exchange, hand over your real name, address, email address, phone number, complete KYC, upload scans of your passport and other documents, upload a photo of your face, let them track your every trade, every click, every page view, and then sell and share that data with a bunch of third parties?

It won't change the fees at all.

The way Whirlpool coinjoins work(ed) is that they would always pick 2 fresh inputs from Tx0s, and 3 already mixed inputs from previous coinjoins. The 2 inputs from Tx0 were the ones which paid the fees. Every input which was already mixed gets unlimited free remixes. If you look at the 0.05 pool transaction I linked to above (https://mempool.space/tx/f4fd5cad5d4db3716fe2081d1bc20f0beb33a417adf22c8fcca131cb6249adb6), you'll see one input of 0.05014520 BTC and one of 0.05006037 BTC, and the others all of 0.05 BTC exactly. These two new inputs are created from an initial transaction called Tx0 which splits the amount of be coinjoined in to the needed denominations to join the chosen pool, along with a few extra sats in to each input to pay the fee for that first coinjoin transaction. This is obviously an estimate at the time given the current mempool conditions. None of this has changed.

When it comes around to actually joining a coinjoin, before it would always be 5 inputs and 5 outputs, and any extra sats on these two fresh inputs were simply paid as a higher transaction fee to miners. Now if this is the case, the protocol will add in one or more additional inputs/outputs in order to bring the transaction fee down to a more appropriate level.

Nothing changes for the users, except some of their coinjoins now benefit from larger anonymity sets.

At the very least there should be options somewhere in your Google account to turn off this kind of locations history. Personally I don't think it makes any difference. Google probably still collect that data, they'll just no longer show it to you in your account history.

I won't lie and say it easy to avoid all privacy invading companies and services, but it is certainly possible. For everything Google offers, there is a privacy respecting alternative. For Google Search - DDG, Startpage, SearXNG. For Chrome - Tor or Firefox. For Gmail - ProtonMail. And so on. Here are a couple of great resources to get you start on looking for alternatives:

https://prism-break.org/en/
https://www.privacyguides.org/en/tools/

Even if you don't go for maximum privacy like some of us, anything you can do limit your data being harvested is a good move.

Each node has its own mempool. Each mempool has limits as to how long it will keep an unconfirmed transaction in its mempool, or how large the mempool can be.

By default, a transaction will stay in a mempool for 336 hours (14 days) until it is dropped. Code here: https://github.com/bitcoin/bitcoin/blob/3132ec64d9e0f7af88e61ac35807f44315a5ca96/src/kernel/mempool_options.h#L23-L24

By default, the maximum mempool size is 300 MB. Code here: https://github.com/bitcoin/bitcoin/blob/3132ec64d9e0f7af88e61ac35807f44315a5ca96/src/kernel/mempool_options.h#L19-L20

For a node running these default settings (as the vast majority of nodes do), then if a transaction is unconfirmed for 14 days, the node will drop it from its mempool. Similarly, the transaction can be dropped out of the bottom of the mempool because the mempool is filled with 300 MB or more of higher fee paying transactions.

Nodes are free to change these limits, however, and some do, running with much higher limits so they rarely, if ever, drop transactions.

If a transaction is dropped from the majority of mempools, that doesn't make it invalid. It is still a perfectly valid signed transaction, just one that the network has forgotten about. Anyone who has a copy of that transaction (which includes each and every node which once knew about it) can rebroadcast it and try again to get it confirmed. Alternatively, if the transaction has dropped, the person who made that transaction could instead attempt to spend those coins in a new transaction. This new transaction would not be rejected as a double spend since the majority of the network has forgotten about the original transaction.

I wouldn't call it a reversal if a transaction permanently drops - more that the transaction never happened at all.

Then the seller is left out of pocket.

In OP's case here, a few days after he broadcast his transaction, all nodes running default settings would have dropped it out the bottom of their mempools as their mempools contained more than 300 MB of higher paying transactions. Yet we can still see it on every block explorer we check, meaning that at some point someone (probably Coinbase) rebroadcast it to the network.

The combined fee rate of your transaction and its unconfirmed parents is 14.1 sats/vbyte. This puts you around 33 MvB from the tip of the mempool at present. It's been over 3 weeks since we last processed transaction at this fee, and given the way the mempool is behaving right now, that's not going to change any time soon. Ordinarily when waiting this long the transaction would simply be dropped from the mempool and you would be free to make another transaction with a better fee, but Coinbase seem to have rebroadcast it after it was dropped. You could be waiting weeks unfortunately.

I have spoken at length on this forum about how nobody should trust Google for anything, ever. They will happily host and promote scams, phishing, malicious software, and worse, as long as they get paid. They will actively spy on all their users and sell/share your data with literally anyone who will pay for it. They are the antithesis of security and privacy.

Google are your enemy.

Nope, unless you are using their convoluted system to sign a message on a Bitkey hardware wallet to transfer to their server for verification and then have their server send the address directly to me. Although all that actually does is shift the attack surface from your phone/computer to Bitkey's server, which I imagine would become a very attractive target for attackers since they could potentially intercept and alter thousands of addresses at once.

And of course let's not forget that all of this (signing messages to prove they haven't been altered) can already be achieved trivially easily without the involvement of any third parties.

The "About Us" page on bitcoin.org explains it in great detail: https://bitcoin.org/en/about-us


The website is developed and maintained by a group of volunteers via GitHub: https://github.com/bitcoin-dot-org/Bitcoin.org

They explain in that third post that since a screen doesn't provide protection against the address or transaction being altered somewhere else than on the user's device or the hardware wallet, then screens are pointless. For example, if you send me an address to pay you some bitcoin, a screen on my hardware wallet does nothing to prevent clipboard malware on your computer from altering that address before I receive it. Which of course is true, but also completely misses the point. It's like saying "Well, a seat belt won't save my life if my engine bursts in to flames and explodes, so why bother wearing one at all?"

Just because something doesn't protect against all attack vectors doesn't mean it is pointless. Which they then discover by having to engineer a ridiculous system which requires the input of a centralized server in order for a user to simply verify an address.

On the back of Ledger's recent debacle, seems like a good time to bump this thread given this wallet is also based on relying on third parties to store your back ups.

Three new blog posts were published last week: https://bitkey.build/

The first post says nothing of any real note, apart from reminding people just how difficult it is to store a seed phrase.

The second one is filled with increasing amounts of nonsense:

In what world is writing down 12 worlds on a piece of paper either lengthy or complex? I can't wait to see how quick and easy their set up process is, given that you need to download an app, register an account, verify your identity, set up and link the hardware device, link it all to an online server, and then set up social recovery with a number of "trusted" contacts. You can do all that in less than the 30 seconds it takes me to write down and double check a seed phrase?

So they want to protect against social engineering and phishing by implementing social recovery which is possibly the highest risk method when it comes to protecting against social engineering and phishing. Ok.

They often disingenuously compare the worst practices with seed phrases against best practices with their device. People can be social engineered for the seed phrase, but apparently not for their social recovery system? They talk about how people back up seed phrases to the cloud, and that makes them insecure. And what is stopping someone backing up their Bitkey account details to the cloud as well? Or how people leave their seed phrase lying around where it could be found, but apparently no one ever does this with their phone or hardware device?

The third post is particularly interesting. After two previous posts talking about how seed phrases are super complicated and risky and their solution is going to be super simple, they have come up with the most over-complicated design possible to justify not having a screen on their wallet. Basically, every time you want to send or receive coins, your hardware wallet has to sign the sending or receiving address and then transmit that signed message to Block's servers, where they will verify the address has not been tampered with, and then send that address back to the relevant party to be used. The obvious flaws are that Block can spy on literally everything you do and that you have absolutely zero security from a bad actor in Block sending a malicious address. The less obvious flaws are that you now can't make transactions or even generate a new receiving address if Block's servers are down, and it opens a new attack vector for man-in-the-middle attacks if you rely on Block's servers telling you what addresses to use.

But don't forget guys, it's far simpler than just writing down 12 words!

Over the last few days, I've noticed a few of my Whirlpool coinjoins no longer being the usual 5-input-5-output transactions, and instead having more inputs and outputs. Turns out Samourai have implemented what they are calling "surge cycles": https://nitter.net/SamouraiDev/status/1658020576491978752

Essentially, if the total fee is more than is needed after selecting the two fee paying pre-mix inputs in order to perform a coinjoin, instead of enrolling three post-mix inputs as usual the coordinator will now enroll additional post-mix inputs. This makes the coinjoin transactions larger and therefore even harder to break, as well as increasing the throughput of remixes meaning everyone gets more free remixes faster, all for no additional cost to the users.

Here are a few such coinjoins from the last couple of hours, each with 8 inputs and 8 outputs instead of the usual 5:

0.001 pool - https://mempool.space/tx/d66520a1e4a38bbca788e70bce95803d62850441eab6ddee7645f6addbc25c48
0.01 pool - https://mempool.space/tx/7e0814e83270dc7c733b2a71308985419625a612d756852027d81a4c5490314d
0.05 pool - https://mempool.space/tx/f4fd5cad5d4db3716fe2081d1bc20f0beb33a417adf22c8fcca131cb6249adb6

You should create your own thread about this since it is off topic here.

The transaction will be unconfirmed because the fee is too low for it to have been included in a block yet. Depending on the fee and the specifics of the transaction your options are either to wait longer, or to use either RBF or CPFP to bump the fee.

RBF is the better option for bumping the fee, but whether or not you can use it depends on where you sent the bitcoin from and whether the transaction is opted in to RBF. You can easily use CPFP by spending the unconfirmed bitcoin in a new transaction back to yourself with a much higher fee, but this is obviously going to be very costly.

If you are happy to share your transaction ID, I can take a closer look for you.

Coinbase can't/won't fix it.

The two unconfirmed parents in OP's transaction are both not opted in to RBF, so they cannot be replaced via that. Further, they are both huge transactions, with weights of 19.4 kvB and 20.04 kvB respectively. Given the current fees already paid by the three unconfirmed transactions, to get the combined fee up to around 40 sats/vbyte any CPFP transaction would have to pay over a million sats in fees.

OP is simply going to be stuck until the mempool clears out to 14 sats/vbyte. Another strong argument for not using third party wallets where you cannot set your own fees.

Closed source.

Closed source.

Open source, but terrible fee estimation and doesn't even support RBF.

The only wallet in your list which is an actually good wallet is Electrum.

I think it's a great idea, provided you take the time to make sure you really know what you are doing so you don't make any mistakes in the process.

Yes, Electrum supports segwit addresses. In fact, it only creates segwit wallets by default now.

The biggest risk is accidentally turning your cold wallet in to a hot wallet. Your old laptop needs to be permanently airgapped. This means you don't connect to the internet just to download an update, or just to broadcast a transaction, or for any other reasons. Permanent means permanent. Even better if you can open up the laptop and physically remove the WiFi card so there is no risk of you accidentally connecting to the internet in the future.

Make sure you use a good open source Linux distro, and make sure you use full disk encryption. Obviously verify your copy of Electrum on your online computer before you transfer to your airgapped computer. I prefer to use QR codes to transfer unsigned and signed transactions back and forth to remove the risk of accidentally transmitting malware via a USB drive, but always double check your QR code decodes to what you are expecting before you sign or broadcast anything.

btcrecover benchmarks give 10,400 passphrases per second for a NVIDIA GTX 1660 Ti - https://btcrecover.readthedocs.io/en/latest/GPU_Acceleration/. Obviously your values will vary depending on your hardware. A very quick test shows I can get a little under this out of the box, so could probably get quite a bit over this with a little optimization.

Still, assuming 5 random characters from the set of lower case, upper case, and numbers, 10k attempts per second would only take a little over a day to exhaust the search space. Add in symbols and use the full 95 character ASCII set then you are still only looking at 9 days to perform a complete search, so 4.5 days on average to crack the passphrase.