I don't think there is anything inherently wrong with using paper instead of metal. The majority of my back ups are on paper.

Indeed, I think using metal can sometimes lead users astray. They create a single metal back up and assume that they are completely safe, even though they are still at risk of losing it, theft, natural disasters, and so on. I would much rather have two paper back ups in separate locations than one metal back up, especially if that one metal back up is stored in the same place as my wallets themselves (i.e. at home). As the old saying goes "Two is one, one is none".

Wrong message.

What we should be saying is "Be careful using centralized exchanges", or better yet "Never complete KYC anywhere." Mixing is not the problem. Coinjoins are not the problem. If anything, knowing how draconian the government is being with trying to surveil you and your coins, you should be mixing and coinjoining more, not less. Stay private, and stop using services which sell out your privacy at the drop of a hat and work in cahoots with your government to surveil, monitor, and control you.

You are either free, or you comply. You can't be both.

So does the internet. Shall we ban that too?

As the figures I've outlined above show, even by FinCEN's own research, the amount of illicit money being moved through mixers is absolutely minuscule. Like, we are talking less in the last decade than fiat banks launder in a few days.

As pointed out by BHC above, these calculations are for unscrambling known words. While this is possible for a 12 word seed phrase, unscrambling a 24 word seed phrase even when you know all 24 words is impossible. Brute forcing a 24 word seed phrase from scratch is several trillion trillion trillion trillion times harder than that.

Passphrases do not encrypt seed phrases. They are used as a salt in the HMAC-SHA512 function which turns your seed phrase in to your master keys.

It is neither less secure nor more secure.

The thing to remember is that the words are simply an encoding of (in this case) 132 bits of entropy. The entropy is generated first. It is then encoded in to words primarily to make it human readable and easier to back up. You can encode the entropy any way you like - binary, hex, Base58, BIP39 wordlist, any other wordlist, and so on. The entropy doesn't change, only the way it is represented.

It is not encryption, it is simply representing the same data in a different format. But again, the security doesn't change.

In this scenario we are talking about using a custom wordlist to generate a seed phrase. But in general you are right - seed phrases are almost always generated using the fixed BIP39 wordlist, while passphrases are generated using any words, symbols, or strings we want.

So 12,356,630 "words" gives 23.56 bits per word. 132/23.56 gives 5.6, which means 6 word seed phrases.

The important point to note is that an Electrum seed phrase is not converted back in to the entropy which generated it, or broken down in to bits, at any point. Unlike BIP39 which does require a fixed and known wordlist so it can convert your words back in to bits in order to verify the checksum, Electrum's version system simply hashes your words as they are and uses the first 8 or 12 bits of that hash.

After this, in order to actually start generating private keys, the next step (for both BIP39 and Electrum) is to feed your words as they are in to HMAC-SHA512, alongside salt of the word "mnemonic" (for BIP39) or "electrum" (for Electrum) concatenated with any passphrase. So again, no need for Electrum to convert your words back in to bits. (This is also why you can import BIP39 seed phrases with unknown wordlists in to Electrum. Electrum will warn you it is an unknown wordlist and it cannot verify the checksum since it cannot convert your words back in to bits in order to verify the checksum as I've explained above, but it can still feed those words in to HMAC-SHA512 and generate master keys and subsequent child keys.)

But yes, I'd highly recommend nobody does this. Understanding the principles of what is going on is all good, but you should always stick to the standardized methods.

Doesn't matter for Electrum seed phrases  - Electrum does not need to know the wordlist used. For BIP39, even if every copy of the BIP39 wordlist was lost forever, you could still recover BIP39 seed phrases, you just wouldn't be able to verify the checksum.

Certainly it's been possible at least since Electrum moved away from using their own wordlist and moved to mirroring the BIP39 wordlist.

The math is quite interesting, if you want to work it out. Given a word list of 466k, then each word can encode log₂(466,000) = 18.83 bits of entropy. For a 132 bit seed phrase, this needs 132/18.83 = 7.01 words, which has to be rounded up to 8. If you used a wordlist of 474,861 words, then you could generate a 7 word seed phrase for 132 bits.

Alternatively, you can go the other way and give Electrum a wordlist of two words, say 0 and 1, and it will generate a 132 "word" seed phrase.

You can see where Electrum works it out here: https://github.com/spesmilo/electrum/blob/6dfbdec73e97231c01b1a813ae293083a3dbd1cd/electrum/mnemonic.py#L208. Takes the length of the wordlist and calculates the log in base 2, giving the value bpw, or bits per word.

I think we are disagreeing on semantics here rather than the underlying principles.

Of course you are correct in that you don't want a process which can easily be repeated to achieve identical results. But conversely, I do know exactly why Electrum picked each word in the seed phrase it generates for me - it uses randrange which in turns sources entropy from /dev/urandom. The entropy it receives from /dev/urandom will indeed be a cryptographically secure pseudorandom number, but I also know the processes that my OS uses to seed /dev/urandom.

Yes indeed! I just like to read, learn, and tinker.

Radioactive decay is indeed a truly random process. We know from Bell's theorem that radioactive decay is not governed by "local hidden variables". In other words, we know that there are not events or process happening which we cannot measure or don't even know exist which are determining when such atoms decay. The decay of such atoms is indeed truly random, with the likelihood of decay at any given time dictated only by the half life of the isotope in question. The decay of such isotopes follows a Poisson distribution, the same as bitcoin mining.

I would disagree with this. Not knowing how something happens or what logic it follows does not make it random. Rather, the opposite is true. We need to know exactly how it is generating entropy so we can confirm that it is indeed random (or at least, pseudorandom).

It's easily done. Just navigate to your Electrum installation folder, and go to \electrum\wordlist. First back up "english.txt", and then edit the original with your own wordlist. Job done.

I just pulled the wordlist from here and gave it a shot: https://github.com/dwyl/english-words. It has 466k words, and it worked just fine. I generated the following seed phrase:


Thanks to how Electrum works, you don't need to know my wordlist to recover that above seed phrase. You can import it in to any copy of Electrum just fine and recover the same wallet, which will give you the following address first:


However, doing this completely misses the point. The above seed phrase has exactly the same entropy as a seed phrase using the default wordlist - 132 bits. Increasing the size of the wordlist does not change the underlying entropy used to generate the seed phrase.

Correct. The number of provably lost bitcoins, such as those sent to OP_RETURN outputs, those sent to invalid locking scripts, those which miners failed to claim in the first place, etc., is very small, and numbers around 2,828 BTC. But we frequently see the figure of around 4 million "lost" bitcoin be thrown around on this forum, on Reddit, on Twitter, on various crypto blogs and clickbait sites, and so on. It is a widely held belief, even if it is completely incorrect.

And so I have no doubt that if a signed message appeared from the genesis block public key which included a recent date, lots of people would panic sell and the price would indeed fall.

Many people operate under the mistaken premise that any coins which have not moved in x number of years are permanently lost, and therefore removed from the supply. Many people also assume that Satoshi owns in excess of 1 million bitcoin. A message signed from the genesis block public key would lead many people to realize that assuming coins are lost with zero proof is a mistake, and worry that in excess of a million coins could be about to be sold, leading to them selling their own coins for fear of the price falling. I don't agree with this logic, but many people do.

I believe this is what pawel is referring to above.

This.

This isn't an attack against mixers - this is attack against bitcoin itself, against privacy itself. Here is how they are defining "mixing" for the purposes of this report:

This essentially makes illegal everything except fully KYCed bitcoin held on centralized exchanges which report every single deposit, trade, and withdrawal to the US government. Mixers fall under (1). Coinjoins fall under (2). Casinos and sportsbooks fall under (1). Any non-KYC exchange falls under (1) and (5). Any kind of decentralized or peer to peer trading falls under (5).

And most importantly, simply owning your own coins, holding them in your own wallet, and using them as you like falls under (3) and (4). "Creating and using single-use addresses", for fuck sake! You know, the entire way bitcoin is supposed to be used in the first place.

This needs fought against, hard.

---

Re-reading the proposal in more depth, and here's another piece worth highlighting:


So $20 billion in volume over a 12 year period, 13% of which was from illicit activities. So a grand total of $2.6 billion of illicit money over 12 years. Let's put that in to context. Danske bank laundered $230 billion through their branch in Estonia. Wachovia laundered $390 billion for drug cartels. Standard Chartered laundered $265 billion for Iran and other sanctioned nations. 18 of the world's biggest 20 banks have been fined for money laundering - and these are only the cases we know about. By FinCEN's own research (which just so happens to be a black box like all bullshit chain analysis - I wonder why? ), a single money laundering incident involving a single fiat bank is responsible for more than 100x all illicit mixer use over the last 12 years. Once you combine the hundreds of fiat bank money laundering incidents, then this $2.6 billion attributable to cryptocurrency becomes completely irrelevant.

Ask yourself again why they care about this minuscule fraction so much while turning a blind eye to the fiat banks, which are multiple orders of magnitude worse.

There are hundreds of bots out there monitoring millions of easily hacked addresses waiting to sweep deposits the instant they show up. We've seen it countless times with brain wallets. Brain wallets generated from easy to guess phrases, such as common words, phrases, quotes, lyrics, etc., have any funds sent to the derived addresses stolen in under a second. These same bots are almost certainly also watching the addresses from any and all publicly revealed seed phrases, and any weak seed phrases, such as the same word repeated 23 times.

This is of course completely separate to a seed phrase including the same word twice or even three times, and these seed phrases are no easier to brute force than any other randomly generated seed phrases.

There is absolutely nothing stopping the same word for appearing multiple times in a seed phrase. I've answered this before:


Here are some more numbers:

The chance of a 12 word seed having the same word at least twice : 3.18% (1 in 31)
The chance of a 12 word seed having the same word at least three times: 0.0052% (1 in 19,128)
The chance of a 12 word seed having the same word at least four times: 0.0000057% (1 in 17,407,725)

The chance of a 24 word seed having the same word at least twice: 12.65% (1 in 8)
The chance of a 24 word seed having the same word at least three times: 0.048% (1 in 2,089)
The chance of a 24 word seed having the same word at least four times: 0.00012% (1 in 814,729)

No. There isn't a "higher possibility" of words being repeated - there is the exact same possibility as any other word. If my first word is "zoo", then my second word has the exact same possibility to be "zoo" as it does to be any other specific word. Indeed, if we introduced code to prevent a word from appearing more than once, then you would actually be decreasing the final entropy of your seed phrase, since by the time you get to the 23rd word in your seed phrase, you no longer have 2,048 possibilities for that word but only 2,026, since you could not repeat any of the 22 words you had already used.

Either you wait for the mempool to empty, or as DaveF says, you increase the fee and your transaction will evict some other lower paying transaction from these nodes' mempools.

10 outbound connections by default, but up to 115 inbound connections by default. Note that apart from the 2 block-relay connections, outbound and inbound connections are functionally identical - it's only the way the connections are established which are different.

It isn't. Anyone can increase their transaction's fees and gain access to a mempool which is already at its limit by evicting other transactions. Since mempools are run locally, it is always in miners' best interests to do this, since it allows them to maximize their profits.

Looking at the time this happened, you simply got unlucky with when blocks are mined. Keep in mind blocks are mined on average every 10 minutes, but this can vary from a few seconds to over an hour in reality.

Block 812,957 included transactions with a fee of 3 sats/vbyte. At this point, mempool.space was probably recommending a fee at around 5 sats/vbyte, and appropriately so. However, it then took 42 minutes to find the next block, by which point the minimum fee had increased to 24 sats/vbyte. Because of this backlog which was created during this 42 minute time period, it then took the network to block 812,970 to mine transactions at 5 sats/vbyte and include your transaction in a block. This had nothing to do with mempools being full - indeed, if nodes were rejecting your transaction then it would never have been mined at all. This is simply a quirk of how bitcoin works and it happens all the time.

As far as the coin goes, it makes no difference. The coin doesn't remember the previous result, and so previous tosses have no bearing on future tosses.

As far as you go, then the solution is as above. If you don't learn the outcome of the first toss, then it cannot bias any subsequent tosses.

Is it possible? Sure. Is it likely? Definitely not.

Trezor is open source, so if there was something shady in the code you would hope (but can't guarantee) that someone in the community would have picked it up and publicized it. If you aren't able to examine the entire source code yourself, then this is the best you can hope for.

In terms of the "stolen" reviews you have found - do any of them actually provide any details? It is easy for a competitor to post fake reviews, and we've also seen countless users on this forum make posts blaming their hardware wallet for the funds being stolen, and it almost always turns out to be a mistake the user has made instead (such as storing their seed phrase in their emails). I wouldn't pick a Trezor device for many reasons, their anti-privacy and pro-censorship stance being the main one, but I also doubt any of these "stolen" reviews are true.

It uses unix time, which is what the bitcoin network uses as well to avoid issues with timezones, otherwise many nodes would incorrectly reject blocks from elsewhere in the world since their timestamps could differ by many hours.

Unix time is based on UTC time. Most block explorers will also show times based in UTC for this reason. Unix time is the number of seconds since 00:00 on 1st January 1970, UTC.

Seems like that was probably the issue then. Keep an eye the next time you make a transaction and check that it behaves as expected!

Yeah, so it seems like it has finished loading your saved mempool from disk. I'm not 100% sure on the behavior of Core, but I would guess your mempool wouldn't update with new transactions while it was still loading from disk, which is why you didn't see your previous transactions until they confirmed. No idea why it took so long to finish loading in your case, though.

If you run getmempoolinfo again, has the size of your mempool increased (and continues to increase between blocks)? That would be a good indication you are syncing unconfirmed transactions properly again.