Again, the words aren't picked. Entropy is used to generate a random number, and that random number is encoded as a seed phrase.

If the random number is generated in a cryptographically secure way, then yes, the probability is the same. The point I am making is that I don't believe the Javascript function crypto.getRandomValues within a browser environment (as is the case with Ian Coleman) will generate truly cryptographically secure numbers.

Yes, it absolutely does. If I have 256 bits of random entropy sourced from /dev/urandom, and you have 256 bits of entropy sourced from your browser fingerprint, then your seed phrase is exponentially weaker than mine and exponentially more likely to be broken.

Yes. It all depends on the entropy used to generate those words in the first place.

There is nothing preventing repeat words, and the last words contains a checksum, so as above there are 2²⁵⁶ combinations, not what you have written.

Picking random words yourself from the word list is widely recognized as highly insecure and one of the worst possible ways to generate a seed phrase. This is also absolutely not what Ian Coleman's software is doing. What Ian Coleman is actually doing is generating a pseudo-random number via crypto.getRandomValues and then encoding that in to a seed phrase. Your browser is simply not a very good source of entropy for this process. Compare this to Bitcoin Core, for example:


It is fine to not fully understand the process behind seed phrase generation or the risks which need to be considered and mitigated against. Most people don't. But you should at least try to realize this and stick to the tried, tested, and recommended methods instead.

If you are dead set on using a webpage to generate your seed phrase then ultimately, we can't stop you. But you are taking on unnecessary risk by doing so, especially when there are much safer alternatives available.

It is only possible when the same private key has reused the same r value.

The equation you are interested in is as follows (all equations mod n):

s = (z + x*r)/k

Where z is the message hash (usually a hash of part of the transaction data) and x is your private key.

Let's say you have two transactions using the same private key and the same k value. You now have following two equations:

s₁ = (z₁ + x*r)/k
s₂ = (z₂ + x*r)/k

This can be reformatted as:

k = (z₁ - z₂)/(s₁ - s₂)

Given that you know both s values and both z values from the transactions themselves, you can calculate k. Once you know k, you can go back to the initial equation and calculate x, the private key.

If, on the other hand, the private keys (x) are different, then you have the following transactions:

s₁ = (z₁ + x₁*r)/k
s₂ = (z₂ + x₂*r)/k

Reformat that, and you end up with the following:

k = ((z₁ - z₂) + r(x₁ - x₂))/(s₁ - s₂)

Given that you have two unknowns in this equation (x₁ and x₂), you cannot calculate k.

The issue is it uses Javascript.

Did you read the post hosseinimr93 linked to above? The bottom line is using Javascript is insecure and does not guarantee your safety. If you are going to all the hassle of using a live OS to set up genuine cold storage, then why would you want to use insecure code to generate your seed phrase?

Use good quality, reputable, open source wallet software such as Core, Electrum, or Sparrow. Review the code yourself if you have the ability to do so. Verify all downloads (this includes your downloads of Tails).

Yes. Tails comes with Electrum already installed, so this is very easy to do.

The Wasabi team are obviously free to continue to create and promote their anti-privacy, pro-surveillance, and pro-censorship wallet. And we are similarly free to call them out for being anti-privacy, pro-surveillance, and pro-censorship. That includes amending recommendations such as that on bitcoin.org which were written before Wasabi started funding blockchain analysis.

Relying on a third party to sync your wallet and your wallet actively paying blockchain analysis firms to spy on you are entirely different issues. If bitcoin.org can warn about the former, then they should also warn about the latter.

As I said above: "Then shut down your service. Selling out your users and directly funding entities which actively undermine bitcoin and attack everything it stands for just so you can continue to make profit for yourself is disgusting."

Yes. An attacker could potentially link your transactions to your IP address. See here for more info: https://en.bitcoin.it/wiki/Privacy#Tor_and_tor_broadcasting

To avoid this, you can either run your node via Tor, or you can choose to run your node via clearnet but broadcast your transactions via Tor. For this second option, you need to do two things:

1 - Add walletbroadcast=0 to your bitcoin.conf file. This will stop your node from broadcasting your own transactions.
2 - In your EPS config.ini file, navigate to where it says broadcast_method = tor-or-own-node and change it to broadcast_method = tor.

Any transactions you make via Electrum via EPS will now be broadcast to random nodes over Tor only.

Electrum in 2017 did not generate 16 word seed phrases. The seed phrase would have been 12 words long if Electrum generated it itself, or 12/15/18/21/24 words long if you imported it from somewhere else.

Regardless, if you don't have it then it is useless to you. Your only other option will be to bruteforce your password, but this will only be possible if either you can remember some information about the password or you used a very short and weak password.

If we took that line of thinking with every issue then CSW would currently reign supreme and bitcoin would have died a long time ago. Bullshit needs to be called out as bullshit whenever and wherever it comes from. A wallet directly funding blockchain analysis while styling themselves as the ultimate privacy solution is a prime example of such bullshit.

We don't know the criteria involved in the blacklists Wasabi implements, because they won't tell us. (They may not even know themselves, and just do what their blockchain analysis buddies Coinfirm tell them to.) Who gets to decide what is classified as a "nefarious source"? Certainly not us. Lots of people think bitcoin itself is nefarious. What about porn sites? Gambling/casinos/sportsbooks? What about peer to peer loans? What about non KYCed coins? What about peer to peer transactions not involving a centralized third party which can automatically track and report everything to your government? All of these things are classed as "nefarious" by various governments.

I really hope I don't need to point out on bitcointalk of all places why implementing government blacklists is antithetical to the very purpose of bitcoin.

That case is long finished. Cobra refused to dox himself and so the whitepaper is no longer available via bitcoin.org if you are in the UK.

Yes. They should also have the same privacy warning applied regarding cooperating with blockchain analysis and surveilling all their users.

This is part of the reason I now almost exclusively use self built airgapped, encrypted, cold storage. No third parties to suddenly start cooperating with blockchain analysis or extract my seed phrase via a so called recovery feature.

I think your article is spot on. I've raised pretty much all of the exact same points you have at various times over the last few years in this thread:

---

I think there are other fairly concerning aspects to this device you didn't touch on, such as their social recovery, which is just as easily fooled or attacked as Ledger's KYC based recovery service. The part of your article that I hadn't considered is the privacy implications for anyone else. As you point out, if I want to send money to a Bitkey user then I have to visit the Bitkey website in order to obtain their address, giving Bitkey the capability to link my transaction to my device identifiers, browser fingerprint, and IP address. That's utterly horrendous.

Guess I won't be transacting with anyone who uses this wallet, just as I don't transact with any merchant who uses BitPay.

The latest stupidity I heard was CeDeFi - centralized decentralized finance. Apparently the term was first used by CZ in 2020 in relation to Binance Smart Chain. So, in other words, 100% centralized trash.

Just like CZ pretends his centralized bullshit is decentralized, Wasabi pretend that their pro-surveillance bullshit is private.

Then shut down your service. Selling out your users and directly funding entities which actively undermine bitcoin and attack everything it stands for just so you can continue to make profit for yourself is disgusting.

I think it is exponentially more likely that they are just greedy scammers. More intelligent than you average "Enter your seed phrase on this website" phishing email type scammers, but greedy scammers all the same.

We saw it endlessly during the ICO craze. Any scammer with the ability to launch a useless ICO did just that, made a few million from the gullible, and then exit scammed and disappeared. It's a bit harder to do the same with a centralized exchange, but the gains are far greater. People like Mashinsky or SBF are exactly the type of people you can see launching their own ICO back in 2017 and promising that it is the next bitcoin killer or some other such bullshit.

I've only ever paired Sparrow with a node running on the same device, but in this set up anything I've done on Sparrow has been pretty much instant. The only downside is of course if you import a wallet with historical transactions in to Sparrow then you have to rescan, just as if you imported a wallet with historical transactions in to Core. This is obviously not the case if you were running a full Electrum server, but of course Sparrow can connect to those too.

Verified.

The address above (bc1q7vr2ge5392zp3rwn6q60skp98dlce7au8qaztv) spends its output in this transaction: https://mempool.space/tx/1d686510d1cf9d0f2445fac24b15d8e679f17b0a3291d87c7fc41dc95e4f168b

This transaction is a Tx0 from either Samourai or Sparrow, enrolling the coins in to Whirlpool coinjoin's 0.001 BTC pool. He creates seven such outputs ready to be coinjoined, one change output, and one output paying the coinjoin fee of 5,000 sats. The OP_RETURN output is part of the Whirlpool protocol to allow the coordinator to know which outputs to enroll in a coinjoin.

For some reason, before any of these outputs are actually coinjoined, he instead consolidates them all in a single transaction depositing 0.007 BTC to Whirlwind (bc1qkf6knnzvnu2h47g8wa7h4hx7k3vm8tcqyc27xy), with one additional change output.

I can also verify the signature two posts above from the intermediate address bc1qzfmfzgtwyaqk6l0tedrx8kpe09xmxvs9l4j5ya.

The quote you shared says nothing about transactions being confirmed faster. It says transactions can be verified faster. This is the process by which each nodes checks each transaction and each block is valid, which is different to the process of transactions being mined in to a block. By making verification faster and easier, it reduces the strain and resource requirements on existing nodes and makes it easier for anyone to run a node with less powerful hardware.

Although in the case of multi-sig, Taproot transactions are much smaller since they only contain a single pubkey and a single signature instead of multiple of each, as discussed above, so you could argue they will confirm faster given the same absolute fee.

So the derivation path is used both in the generation of the xprvs/xpubs, and also in the generation of individual addresses from those xprvs/xpubs. Allow me to explain.

Take the following familiar derivation path: m/84'/0'/0'.

m stands for your master private key, which is generated from your seed phrase. Technically speaking, this is the only key which should ever be called your master private key, but a lot of people and software also use the term master private key to refer to your account extended private key (which I'll come to in a second).

The next three numbers are, in order, your purpose, coin type, and account. 84 is the number assigned to P2WPKH segwit addresses. 0 is the coin type for mainnet bitcoin. The next 0 simply means the first account. As I explained previously, that derivation path tells your wallet software to generate the extended key at the 85th hardened index,* use that to generate the extended key at the 1st hardened index, and then use that to generate the extended key at the 1st hardened index. The extended key you end up with after doing all that is your account extended private key. Account because it is at the account level, extended because you have an extra part which allows you to continue to derive at further levels. But as I said above, lots of places incorrectly refer to this key as your master private key. When you extract an xprv from a wallet, it is almost always this key that you are extracting - your account extended private key.

Now, to get actual addresses from that key, we need to derive through a further two levels. The derivation path of the very first address in your wallet will look like this: m/84'/0'/0'/0/0. The first extra zero is change (0 for not being a change address, 1 if it is a change address), and then the second extra zero is in the index of the individual address itself.

m/84'/0'/0'/0/0 - 1st non-change address
m/84'/0'/0'/0/1 - 2nd non-change address
m/84'/0'/0'/1/0 - 1st change address
m/84'/0'/0'/1/3 - 4th change address
And so on.

Note that multi-sig sometimes add in an additional field called the script type, so instead of something like m/84'/0'/0' you would have m/48'/0'/0'/2'. (48 is the purpose number for such multi-sig paths, and 2 is the script type for P2WSH.)

So, in the case of HD wallets, you can import keys in two ways. The first is that you can either import a seed phrase, and tell the wallet the exact derivation path you used to get the account extended private key. So for example I could give you the following seed phrase:
And tell you I used the derivation path m/84'/0'/0', meaning you can calculate the following xprv:
The wallet then knows to start there and add on the extra /0/0 derivations to reach individual addresses.

The second option is I can just give the wallet the xprv directly, and not tell it about the seed phrase or the derivation path I used to get to the given xprv. The wallet will take the xprv and add on the extra /0/0 as above, without knowing the derivation path used to reach that xprv.

Now let's say, for example, I'm setting up a 2-of-3 multi-sig. In this particular multi-sig, I'm using one seed phrase on my computer, and two hardware wallets. Let's say the seed phrase on my computer is using the derivation path m/48'/0'/0'/2'. Great. So my software knows to use this deviation path to calculate the first xprv from the seed phrase it has, and the corresponding xpub. Now my two hardware wallets come along. For the sake of argument, the first uses m/84'/0'/0', and the second uses uses m/0'. What a nightmare! Each hardware wallets generates an xprv at the given derivation path, calculates the corresponding xpub for the xprv, and then feeds the xpub to the wallet software on my computer. Now, my wallet software has three xpubs, but it may or may not have any idea the derivation paths used to reach the two xpubs from the hardware wallets. But actually, it doesn't need to know. All it needs to do is calculate a child key at /0/0 for each one and combine them in to a multi-sig address.

So it can do seed phrase + m/48'/0'/0'/2'/0/0 to generate the first key itself, and then it can do hardware-wallet-xpubs/0/0 to generate the second and third keys. One it has all three keys at /0/0, it combines them to create an address. It does the same thing at /0/1 and combines the three keys to generate the second address, and so on.

---

*Hardened indices, indicated by the ' symbol, are actually the number you see plus 2³¹, but the reasons behind that are not relevant for this.

There are plenty of mitigations against this, such as UEFI secure boot. And even without these, an attacker would need to know exactly what they are looking for and would need access to your device undetected on multiple occasions, which should be easily prevented. If someone is willing to break in to your house more than once to do this, then they are probably also willing to just hit you with a $5 wrench.

Also, there have been many physical attacks demonstrated against a variety of hardware wallets, which only require access to the device once and while still technical probably require less expertise than compromising the bootloader on a fully encrypted device. One such example: https://blog.ledger.com/Unfixable-Key-Extraction-Attack-on-Trezor/

Exactly.

Who knows what three letter agencies are putting in the chips being supplied to hardware wallet manufacturers?

I don't disagree, and as I've said above there are still advanced features Sparrow doesn't offer that I use Electrum for (such as importing individual keys/addresses). But if you want to use Sparrow while connecting to a public server (as is the default in Electrum), again it is only three clicks (File -> Preferences -> Public Server). If you are a newbie looking to use a wallet privately, then Sparrow beats Electrum in terms of ease of use for not having to set up a server and just connecting directly to Core. I also can't think of any features that newbies would be interested in that Electrum has and Sparrow does not.

You might be interested in reading BIPS 340, 341, and 342, which all deal with Taproot and which explain this in greater detail.

At a very basic level, Taproot moves away from the usual ECDSA signatures which are used in other address types and instead uses Schnorr signatures. One of the advantages of Schnorr signatures is that you can combine multiple public keys into a single public key, and multiple signatures in to a single signature which remains valid for all the individual component signatures. This is known as key aggregation. So if you are using a 3-of-5 multi-sig (for example), instead of having to provide five public keys and three signatures which every other node has to verify, with Taproot you can provide a single public key and a single signature and every other node only has to verify this one signature.

There is another feature known as batch validation. Instead of each node having to individually verify the signature of every transaction in a block, with Schnorr signatures you can combine all the signatures in to one, even if you don't know the private keys. This allows each node to perform a single verification, rather than having to individually verify each and every transaction.