No, it won't say anything. There is no singular mempool - every node has its own mempool. Some have dropped it already, some will drop it eventually, some may never drop it at all.

It's already stuck. It's been stuck for three weeks. You should be contacting the sender and asking them to replace the transaction with one paying a higher fee.

Correct, but you are still calculating multiple events multiple times. For each of the five scenarios where you can lose 4 keys, you are calculating each one four times, and the final scenario where you can lose 5 keys is being calculated ten times. Therefore your final value will be wrong.

Your equation is also still multiplying each possibility instead of summing them, which I've already discussed above.

Even better - install a good Linux distro which will be more secure and more private than any Windows system (as well as being open source). You might also find that lots of modern wallet software won't run properly on old versions of Windows.

Why would an old PC not be functional? I have computers which are 20+ years old and still run just fine, whereas you can find reports of hardware wallets having their screens die after just a few years.

Agree with ETFbitcoin - use btcrecover.

If your address is BIP44 then it should start with "1", and if it's BIP49 then it should start with "3". If you don't know the address at all then you'll need to use an address database to check against: https://btcrecover.readthedocs.io/en/latest/Creating_and_Using_AddressDB/

If you have already calculated all the possible valid seed phrases from your words, then you can use the --seedlist command to avoid having btcrecover calculate them all again: https://btcrecover.readthedocs.io/en/latest/BIP39_descrambling_seedlists/#seedlists

Is the screen bright enough that you can still make out the menus and such? If so, then you can try to address the websocket error with these instructions: https://support.ledger.com/hc/en-us/articles/360014056220-WebSocket-error-in-Ledger-Live

Also make sure you have closed down any other software which might be trying to access your USB ports, make sure your USB drivers are up to date, and try different USB ports.

In terms of the screen itself, you'll either need to replace it or buy a new hardware wallet. All OLED screens degrade over time.

If my security, privacy, process of making transactions, etc., are all perfect (they aren't, and neither is anybody else's), then I would be completely happy having all my funds in a single wallet. The risk of an accidental or brute force collision is zero. While theoretically possible, even if the entire human race diverted all its power and resources to nothing but generating new bitcoin addresses until the death of our sun in ~5 billion years' time, we still wouldn't see an address collision.

Having said all that, I absolutely would not recommend keeping all your coins in a single wallet. Not because I am in the least bit concerned about address collisions, but because nobody's OPSEC is perfect regardless of how hard you try or how good you think it is. Different wallets, different devices, different mediums, different back ups, and so on.

I've already explained above why that equation doesn't work.

If you calculate A*B*C when there are 5 variables, then you aren't just including the situation where you lose those three keys. You are calculating the probability of losing any of the following:
ABC
ABCD
ABCE
ABCDE

If you do the same for ABD, then you are calculating all of the following:
ABD
ABCD
ABDE
ABCDE

You've just calculated ABCD and ABCDE twice. Compound that over your 10 calculations, and you end up calculating the same possibility many times, meaning your final equation is way out.

What you need to calculate is P(A ⋂ B ⋂ C ⋂ D' ⋂ E') for each of your ten possibilities (i.e. A * B * C * Not D * Not E), and then do the same for the five scenarios where you can lose 4 keys, and again for the final scenario where you can lose all 5 keys, and then sum your results.

Connecting to more nodes wouldn't make a difference in the case where the transaction was above the default purge limit when it was broadcast, only if you now tried to broadcast a transaction below the default purge limit. If you only broadcast to nodes which won't relay your transaction, then the nodes with the higher limits will never learn of it.

Who is the original sender? Someone somewhere has the ability to replace this transaction with one paying a decent fee. Who is that person?

Either you wait until the fee rate drops enough that it will be confirmed, or whoever sent you that transaction will use those inputs in another transaction and invalidate your transaction meaning you will never receive your money.

You've missed a lot of occurrences of this from your table.

The difficulty of the new epoch will not necessarily be 1. Rather, the difficulty adjustment for the new epoch will be made from a baseline of 1. So, if the difficulty adjustment was supposed to be -10%, the difficulty would be 0.9, but since 1 is the minimum it will be 1. However, if the difficulty adjustment was supposed to be +10%, then the new difficulty will be 1.1.

You can see this most recently happening just a couple of months ago at epoch 1,212. Epoch 1,211 took 12 days, 2 hours, and 42 minutes. This is 290.7 hours, which would be 1744.2 blocks. 2015/1744.2 = 1.156. And so if you look at the difficulty for epoch 1,212, it is 1 * 1.156 = 1.156.

Since the most the difficulty can change by in one retarget is a factor of 4, then any epoch with a sudden drop in difficulty to between 1 and 4 will be a result of this phenomenon.

Every node which is connected to the network will receive the transaction within, at most, a minute or two of each other, so this will make no difference to OP.

As Charles-Tim has pointed out, the transaction is already older than the default expiry time, and pays a fee lower than the default purge limit. All default nodes will have dropped it already. And yet, we can still see it on almost any block explorer that you check. There are more and more nodes running with much larger limits than the default, so you can no longer rely on transactions being dropped at all.

Instead, given that full RBF is now commonplace, the sender of this transaction could easily replace it with a higher fee paying transaction, even though it is not opted in to RBF.

The legacy output address belongs to the exchange CoinSpot, so I assume they are the ones who sent the transaction. The only thing OP can do is contact them and request they replace the transaction.

Where in BIP32 is double SHA256 used (outside of calculating the checksum for the address, which is not relevant here)? Or do you mean the double hash taking place within each HMAC function? If that's the case, then given the output is 512 bits would you not expect to still be able to reach every 256 left bits and therefore every valid private key? And even if your HMAC-SHA512 did output the same 256 left bits as elsewhere, you would be adding those 256 bits to a different parent private key and so your child key would still be different anyway.

Knight Hider is correct. A single seed phrase of any length can be used to (almost certainly) generate every possible bitcoin address. This is thanks to derivation paths.

When you use a seed phrase to generate an address, then most wallets will start to do so at a derivation path such as m/84'/0'/0'/0/0. Each address you generate from the same seed phrase will have a unique derivation path. So, just how many different derivation paths can you have?

Well, as per BIP32, extended keys have 1 byte for the level they are at. 0x00 for the master key, 0x01 for the first level, 0x02 for the second level, and so on, up to 0xFF. This means you can have a total of 255 levels after the m. It also allows 4 bytes for the index. This means a total of 2³² possible indices for each of those 255 levels. So a single seed phrase can generate (2³²)²⁵⁵ + (2³²)²⁵⁴ + (2³²)²⁵³ + (2³²)²⁵² + .... private keys. This number works out at 2.5*10²⁴⁵⁶, which is many orders of magnitude higher than the set of all possible private keys (a little less than 2²⁵⁶). This means that not only can any seed phrase (almost certainly) generate any private key at the right derivation path, but any seed phrase can generate any private key billions and billions of times over at many different derivation paths.

Yes. As above, a single 24 word seed phrase will fully cover the entire address space on its own.

At the right derivation path, then yes, two seed phrases will generate the same address. But in reality such a collision will never happen.

The mining pool could quite easily keep it for themselves. They haven't done anything wrong, and are just keeping the fee for a transaction which was broadcast to the network. Similarly, the mining pool could be anonymous, or it could have already distributed it to all its miners. Good luck contacting hundreds of anonymous miners and begging them to each give back 0.01 BTC.

Returning an overpaid fee should very much not be treated as the norm. Otherwise I could just overpay any transaction I need confirmed and then claim back the fee after it is confirmed? I suspect F2Pool only did it because PayPal and Paxos are the kind of scummy, ammoral entities to start blaming others for their own mistakes and start legal proceedings against these completely innocent third parties.

Wait, what? This whole time we've been pedaling away, you've been sitting on gallons of superfluid which we could have used to lubricate up everything and ride around effortlessly!?

Do you have any idea how thick my glutes and quads are after cycling non stop for 4 years... oh wait I get it. Very clever.

Legend has it that someone already picked the mystery box, and may have released a pandemic of all-enveloping deadly mist across the entire planet...

Sounds familiar...

Not really.


Here is an example for a 3-of-5 multi-sig. If you simply calculate P(A ⋂ B ⋂ C), you'll end up calculating this area:



This will give you the chance of losing ABC, with no regard to what is happening with DE.

If you want to extend this to the chance of losing any 3 keys, though, what you actually want to calculate the area P(A ⋂ B ⋂ C ⋂ D' ⋂ E'):



If you don't do this, and just calculate P(A ⋂ B ⋂ C) for each set of three keys, then you will end up with a huge number of overlapping areas which you are counting 2, 3, 4, or even 5 times, instead of just once, and your final answer will be grossly inaccurate.

There is no one formula for any m-of-n. You'll need to create a formula which considers every m or more subset of your n keys, which will very rapidly become a very long equation. So for a 3-of-5, you would need to sum the probabilities of each of the ten ways to lose 3 keys, each of the four ways to lose 4 keys, and the one way to lose all 5 keys.

It depends. There are three things you can work out here.

1.

P(A ⋂ B ⋂ C')
This is the probability of losing only A and B, while not losing C.


2.

P(A ⋂ B ⋂ C)
This is the probability of losing A and B, and also losing C at the same time (i.e. losing all three keys).


3.

P(A ⋂ B)
This is the probability of losing both A and B, regardless of what happens to C.


If you are only interested in the probability of losing A and B, then you would use the third example above, P(A ⋂ B). In this scenario, you don't pay any attention to C at all, and only work out the probability of losing A and B. However, if you are now interested in the probability of losing any two keys, you run in to a problem. Let's calculate the same area for losing keys B and C:


P(B ⋂ C)

You can look at the pictures for P(A ⋂ B) and P(B ⋂ C), you'll see you've now included the middle intersect twice. If you then do the same for P(A ⋂ C), you will include the middle intersect three times, which is obviously wrong.

So you have two solutions to this. My solution above is as follows:
P(A ⋂ B ⋂ C') + P(A ⋂ B' ⋂ C) + P(A' ⋂ B ⋂ C) + P(A ⋂ B ⋂ C)
This solution calculates the first picture above for each combination (i.e. missing out the middle intersect all together), and then adds the middle intersect at the end.

Saint-loup's solution is as follows:
P(A ⋂ B) + P(A ⋂ C) + P(B ⋂ C) - 2P(A ⋂ B ⋂ C)
This solution calculates the third picture above for each combination (and includes the middle intersect three times), and then subtracts the middle intersect twice to get back to the desired one inclusion.

Those two equations are identical, just written in different formats, and it is easy to turn one in to the other as Saint-loup has nicely outlined in this post.

It isn't, because you have included the same event multiple times. Just as you can't lose A twice, you can't "not lose A" twice. You either lose it or you don't.

No. As I've already said above:

Probability of losing all three keys = P(A ⋂ B ⋂ C) = P(A).P(B).P(C)

So the probability to not lose all three keys is simply 1 - P(A).P(B).P(C)

You multiply within each pair, for example P(A).P(B), as you are considering the probability of losing both Key A and also losing Key B.

You do not then multiply pairs together as you have done, as that doesn't make sense. You aren't considering the possibility of losing the pair A and B, and also losing the pair A and C. How would that even work? You lose all three keys but you lose A twice? You are considering losing pair A and B OR losing A and C, so you add the probabilities of each pair together.

I'm afraid you haven't calculated any real world scenario. You cannot lose A&C when you've already lost A&B. A is already lost. You can't lose it twice.

0.098 or 9.8% is the correct answer. Plug those numbers in to an online probability calculator to confirm, such as this one: https://www.calctool.org/math-and-statistics/probability-three-events

Here is your equation:

I'm afraid it simply doesn't make sense.

Why are you multiplying the probabilities together? You are not looking for the probability you lose P₁&P₂ AND P₁&P₃ AND P₂&P₃, but rather you are looking for the probability you lose P₁&P₂ OR P₁&P₃ OR P₂&P₃. And as Saint-loup has pointed out, you are counting the middle intersect three times here, meaning you either have to subtract it twice at the end as they have done in their equation, or you need to modify each equation with respect to not losing the third key as I have done in mine.