Again, completely normal.

This happens when a block is found very quickly (within a second or two) after the previous block. For these couple of seconds, the mining pool is busy verifying every transaction in the block they have just received, updating their mempools to remove all the transactions which have just been confirmed, and then building a new candidate block filled with transactions to send to all the miners in their pool to start to attempt to mine. For those few seconds, rather than having all their miners sitting idle, they simply attempt to mine an empty block. Very occasionally they are successful in these couple of seconds, and so they mine an empty block. Although they will earn no fees, they will still earn the block subsidy.

If mining pools did not verify all the transactions in the block they just received before having their miners work on the next block full of transactions, then they would very likely try to include transactions which had just been mined, meaning their block would be invalid.

The wallet should not be a descriptor wallet. Try deleting the one you have made and recreating it with descriptors turned off.

From your log, it looks like EPS is failing to import the necessary xpub in to Bitcoin Core (Importing 0 watch-only addresses). I assume the issue is the descriptor wallet.

But still, public key hashes provide no real benefit. You are first assuming that a quantum computer capable of solving the ECDLP suddenly appears out of nowhere and we have no time to react. This is highly unlikely to happen, given we are all aware of quantum developments and discussions regarding quantum proof algorithms are already ongoing. What is far more likely is that we will transition to a quantum proof algorithm long before the first private key is attacked.

And if a computer which can break ECDLP does pop up out of nowhere, then as I've explained above the majority of coins are in addresses with revealed public keys. Having your bitcoin secured behind a hash is little consolation if the network collapses because 10 million bitcoin have been stolen.

If pubkey hashes actually provided any meaningful security, then we wouldn't be moving away from them with taproot addresses, which reveal the public key just from the address.

They are 100% insolvent right now:


Insolvent simply means they are unable to pay all their debts. If they can only afford to cover 50% of the losses, then it means they do not have enough to pay all their customers all the money they are owed. They cannot pay their debts, and therefore they are insolvent.

It worked for Bitfinex. The only reason their centralized shitcoin UNUS SED LEO even exists was to bail them out after they were hacked for 100,000+ bitcoin back in 2016. And today it has a market cap of over $3 billion. Bitfinex have of course suffered further hacks since then, but now they just print more Tether out of thin air to cover up their losses instead of launching more shitcoins. And I don't need to tell you just how widespread Tether is.

There is no shortage of people who will buy whatever centralized shitcoin Mixin create to bail themselves out.

There is currently in the region of 200,000,000 unspent UTXOs. With optimally somewhere around 10,000 outputs being spent per block, then we are looking at 20,000 blocks which is ~139 days of no other transactions to move everything to a quantum resistant algorithm, assuming all outputs were being moved to the new algorithm. If you want to move every coin to the new quantum proof address at once like this, then yes, that's a real concern.

There are a number of caveats to this, though, which mean in reality it won't be as bad as this. Assuming we will have plenty of time (in the order of several years) to move across to the new algorithm, then it easy for a large part of this to take place passively with no additional load on the mempool. That is to say, whenever in the next few days, weeks, months, or years, I plan to spend certain outputs, then I simply direct any change to a new quantum proof address instead of back to an old address. Any transactions which are going to be happening anyway, such as depositing coins to an exchange or paying a service, can similarly take up no additional block space once those exchanges and services move to the new algorithm. Indeed, given enough time, then the only coins we need to consider are dormant coins being held long term, since all coins being actively transacted will end up on the new algorithm anyway.

And even then there are proposals for other things we can do for those dormant coins to stop them being stolen should we run out of time. One such proposal is to lock any coins before they become vulnerable to theft, but provide a mechanism for the true owner to access them by proving a zero knowledge proof of (for example) the seed phrase or master chain code involved in the generation of these addresses.

No problem.

Here is an example of transaction I just pulled from a recent block spending coins from a standard P2PKH (pay to pubkey hash) output - https://mempool.space/tx/ec8d6d318f0a73423782074cc1e73f8675af47b4f7fe574745c6cb1d2f95480d. If you click on "Details" and then look at the "Previous output script", you'll see the following:

To spend such coins, your wallet will provide a signature for this address followed by the original unhashed public key. This set of instructions will first duplicate the public key (OP_DUP), then pass it through two hash functions (OP_HASH160). It will then verify that this hash value is equal to the hash value given above (OP_EQUALVERIFY). If it is, then it will check the signature you provided against the unhashed public key (OP_CHECKSIG). If the signature is valid, then the transaction can be broadcast and mined.

Here is an example of transaction spending coins from a P2PK (pay to pubkey) output - https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16. (This is actually the first bitcoin transaction from Satoshi to Hal Finney.) Again, if you click on "Details", you'll see the following:

To spend such coins, all you need to provide is a signature. The string in the locking script above is the public key, and so you do not need to provide the public key as you did with a P2PKH output. Just provide a signature and OP_CHECKSIG will check your signature against the public key which is already there.

P2PK outputs are very rarely used these days, but there remains several million bitcoin on dormant on such outputs from the early days of bitcoin. But yes, public keys and public key hashes are different things which need to be unlocked with different scripts.

Lol. Still bleating on with this nonsense soundbite? Because Wasabi is the only solution for privacy, and if we don't use Wasabi we forgo privacy entirely? Please.

The only thing you are leading is the funding of blockchain analysis.

Using pubkey hashes provides little realistic security when it comes to quantum computers. Public keys are meant to be public. That's the whole point. No wallet, software, or service treats and handles public keys securely as it does with private keys. There are dozens of reasons your public keys will already be exposed, from transactions, signing messages, light wallets syncing with third parties, address reuse, multi-sig, taproot, use in BIP32, use in descriptors, and so on. And even if you personally keep your public keys completely secure on an airgapped machine and only use addresses in a watch only wallet, probably the majority of bitcoin out there is in addresses with public keys which have been revealed one way or another.

Quantum resistance will come from forking to a quantum resistant algorithm and depreciating ECDLP altogether, not from using public key hashes.

Provided your passphrases are strong enough. You strike me as someone who does indeed use long and complex passphrases, but as we know many people use weak passwords, use names or dates, reuse passwords across multiple accounts, and so on, and the same applies to wallet passphrases as well.

It would also be the last thing I worry about, not because I use metal but because I know I have other back ups off site. Should your house burn down, are you going to sit and sift through the debris looking for your steel plate back up? Will it be safe to do so? Will the fire service or similar even allow you to do that? What about if you live in an area prone to flooding or hurricanes, and your steel plate back up ends up a few kilometers away? How are you ever going to find it? An off site back up is significantly more important than using metal over paper.

No, it isn't. It is a hashed version of the public key. Coins sent to a public key and coins sent to a public key hash have completely different unlocking scripts.

P2SH (pay to script hash) addresses are hashes of a script, not necessarily hashes of a public key.

Hashing is not the same as encryption. Pubkey hashes are not encrypted public keys.

This is not a valid public key.

This is unnecessary.

For all the qualities of the metal we are interested in for our purposes here - durability, strength, malleability, reactivity, melting point - then titanium is better than stainless steel, which is better than copper, which is better than aluminum. If a piece of aluminum will survive certain conditions, you can be certain the same sized piece of stainless steel would also survive those conditions and more.

I've said this before, but I think people who use these metal options generally worry about the wrong things. Far more important than having one super durable metal back up, is having two back ups. I'd much rather have two paper back ups in separate locations than one metal back up stored in the same place as my wallets themselves (i.e. at home), which in reality is no back up at all.

House fires hit around 1000 Celsius, so you are quite safe with either stainless steel or titanium.

There is nothing unusual here. The numbers you are looking at are the median fee per block. If a number of higher fee paying transactions have been broadcast since the last block, then they will skew the median to be higher. Once these transactions are mined, the median will move back down again. If it takes longer to find a block, then there will be more higher fee transactions in the mempool and so again the median will be higher.

All you are seeing here is normal variation between blocks. Look at the fee ranges, and you will see they are very similar.

Better than aluminum, worse than stainless steel. Copper's melting point, reactivity, and durability, all lie between the relevant numbers for aluminum and stainless steel.

Here's a copper product which Lopp tested: https://jlopp.github.io/metal-bitcoin-storage-reviews/reviews/safe-seed/

As you can see, it does show far more damage than a stainless steel product, but the data was still readable. Although that might not be the case depending on how you stamp/engrave/whatever your data, though.

I just did a quick eBay search and found a 10cm x 10cm x 4mm titanium plate for $20. That's even cheaper than I imagined. I'm sure you can probably find similar.

Aluminum is a very poor choice, and I wouldn't recommend ever using it for this purpose. It is weak and highly malleable, meaning it is easily deformed, bent, or broken. It has a low melting point, well below temperatures reached in an average domestic fire. It is highly reactive and very prone to corrosion.

Have a look at how aluminum based devices fared with Lopp's stress tests: https://jlopp.github.io/metal-bitcoin-storage-reviews/reviews/ellipal-mnemonic-metal/

Good quality stainless steel is the best trade off between price and durability. If price is no object, then go for titanium.

Any decent hardware store should either have something in stock, or be able to order/cut something to your specifications. I prefer to use a local store, but even the generic big brand stores here will have something suitable: https://www.lowes.com/search?searchTerm=metal+plate

Don't know where you live, but I would assume most people would have a store somewhere in their local area which could provide a suitably sized piece of stainless steel. And if not, then I guess you could order one of the proprietary devices: https://jlopp.github.io/metal-bitcoin-storage-reviews/

They paid 100 users to use and review their service. Did not a single one of these users continue to use the service afterwards? That's a pretty big red flag.

If they had been, then it is highly unlikely they would have been hacked. By all accounts, they were simply in a hot wallet, and a hot wallet stored in the cloud, no less.

Why? It happens on a near enough weekly basis. This hack is what, not even two days old, and already we've had another hack with Huobi losing $8 million in ETH. All centralized exchanges are the same. Rather than spend time, money, and resources to implement good security protocols, they play fast and loose with the security of your coins and the security of your data because they don't give a shit if you end up losing everything, as long as they line their pockets in the process.

This is unfortunately nothing new. Here's a post I made two years ago:


These kinds of opinions aren't just attacks on privacy, but they are attacks on bitcoin itself. Bitcoin was not designed to become another mass surveillance tool for the government to wield against us, and anyone proposing as much should be viewed as a malicious actor. It makes plenty of sense now that the same guy who thinks "the state should be able to monitor everything" is also a BSV shill and CSW cult member. BSV is already completely centralized and CSW and his buddies can seize any coins they want out of any wallet in existence.

In the article I linked to above, the CEO said that only half of users' deposits would be unaffected. So yes, users' funds have been lost, and Mixin Network are now insolvent.

Why would they be? I don't know of any centralized exchange or service (which Mixin Network clearly is, despite claims to the contrary) which timelocks their own funds. They need access to their funds to process withdrawals. It is user funds in Mixin Safe which are supposed to be timelocked. (I've still not seen anyone say if they can actually access their funds, though. Was nobody actually using Mixin Safe?)

You can ask of course why the funds were stored on a Google cloud server or why they weren't protected with multi-sig, but I don't think they would ever be timelocked.

Yup. I've been saying this for years:


This is also true of other terms such as "trustless" and "private/anonymous", and very worryingly now apparently "open source" as well. My point was more that even when you directly point out how services are in fact none of the things they claim to be, people just don't seem to care that they are being lied to their face and will continue to use those services, often ending in disaster.

The whole point of this "Mixin Safe" was that the recovery key held by Mixin themselves was only usable after a 90 day timelock, and that the owner of the safe could use the 2 keys available to them to move their funds at any time. Therefore this hack, loss of funds, and suspension of withdrawals and deposits should not affect Mixin Safe in any way. If it does, then someone has been lying at some point. Can anyone who is actually using Mixin Safe verify they can still access their coins?

Also, does someone want to explain how a "decentralized network" can have a single centralized database stored on Google's servers? I did point out earlier in this thread how basing this whole thing on a centralized altcoin was a bad idea, but no one seemed to care: https://bitcointalk.org/index.php?topic=5459401.msg62581204#msg62581204

Looks like they are going to launch another centralized shitcoin in order to cover the losses: https://www.theblock.co/post/252716/mixin-network-founder-says-just-half-users-assets-are-safe-after-200-million-hack