I'm pretty sure that's what Satoshi was saying in that quote - the software would automatically send all your money to the new address type we end up with. As ranochigo points out above, I don't think it is possible to leave coins on current addresses but transition to some form of "hardened ECDSA".

While you have the QR code on the screen, simply pressing the up or down arrows on your Passport should adjust the screen brightness. Alternatively, go in to the settings menu on your Passport and you should have an option there to adjust the screen brightness as well.

What model of webcam is it and what drivers are you using? If it is simply too bright then proper drivers or configuration software should be able to fix this as well.

A relevant quote:


Obviously it won't quite be as simple as everyone automatically upgrading when they run the new version of Bitcoin Core for the first time, given the number of different wallets in use these days, but the principle still stands.

Absolutely, but I will continue to argue it is preferable for some lost coins to be stolen and we all take a short term hit on the price than it would be to compromise one of the core principles of bitcoin by unilaterally deciding to freeze or seize some coins.

This is conjecture, not proven. But even if the total number of coins at risk does add up to several million, I maintain my stance above.

It's not about attackers hacking the log in credentials for your individual account, which can be made next to impossible by requiring a hardware 2FA key for example, but rather the security of the entire system.

I assume this Microsoft software is closed source, meaning you are trusting completely that it is encrypting your data properly, with a secure algorithm, with a secure key, without leaking anything, and then transferring it securely, and then storing it securely across multiple servers in multiple countries. You have no idea how good or bad that security is, no idea where these servers are, no idea who has physical access to these servers, and so on.

As I explained above, you can find many examples of failure somewhere in this process and data being leaked. Every big entity has experienced data leaks in the past - Microsoft, Google, Apple, Amazon, Meta, the lot. It would incredibly naive to think they won't experience data leaks again in the future.

I'm not about to trust the safety of my funds to a closed source process designed and implemented by a company which has a record of leaking data.

Does the coin control feature allow you to pick individual UTXOs, or just addresses? So if you had received bitcoin three times to the same address, can you pick exactly which output to spend?

Second question - if you can export transactions, can you import them too?

Kryptowerk has provided me with a TXID, which I will obviously not share here for his privacy. However, I will explain what we have figured out so far to see if anyone else can chime in.

The P2SH address is indeed set up very oddly as a 1-of-1 multi-sig. It is as follows:


I have advised Kryptowerk how to extract the public keys from the redeem script for each address which has previously been used. They are all compressed public keys. With this list of public keys, and I then suggested he use https://iancoleman.io/bip39/ offline to enter his seed phrase, select BIP32, and then experiment with various derivation paths to see if he could find any matching public keys. However, no luck so far.

Apologies. I should have prefaced that statement by saying I agree with everything you had written except for that one sentence.

Given the sheer volume of cloud storage hacks which happen on a constant basis, I don't think anyone should ever store anything truly sensitive on the cloud, especially nothing bitcoin related. And while I agree with everything else you said, I would stop short at making that recommendation. Yes, there is a trade off to be had between risk of accidental loss and risk of malicious access, but the risk of a third party accessing something stored on the cloud is so astronomically high that it is unacceptable.

Performing full client side encryption first with a strong algorithm and strong encryption key and so forth is all well and good, but the majority of people using cloud storage do not do this, and the people who are capable of doing this properly probably aren't using cloud storage in the first place. There are countless examples of cloud storage services which claim to encrypt all your files first doing so poorly, or incompletely, or insecurely, or leaking data on transfer, and so on. These services simply cannot be trusted. And if you have somewhere secure to back up your long and random decryption key, then why not just use that place to back up your passphrase in the first place?

If you really feel you cannot safely back up a seed phrase offline, then there are other options which are much preferable to cloud storage, such as a multi-sig distributed between multiple locations or multiple trusted friends or family members.

Even more likely, then, that we will proceed with the "do nothing" option, since that is what we will default to if we cannot reach some sort of consensus on what should happen to these vulnerable coins. And as I've argued previously, this is definitely the preferred option over allowing a small group of users to unilaterally decide that other people's coins should be locked, burned, or redistributed.

I've spoken about this before as well, and while it seems appealing, it is far from perfect. It provides no protection for any keys which are not part of an HD wallet (which likely includes all P2PK addresses as well as many regular P2PKH/P2SH/P2WPKH addresses), and by locking all such addresses pending a proof which cannot be provided, you will undeniably be depriving some users of their coins against their will, which is unforgivable as far as I am concerned.

Or simply just attempt to reorg out any block which claims a sizeable reward for another miner.

It looks like your webcam is simply not focusing properly, or is picking up a different object to focus on. Try obvious stuff like making sure the lens is clean or trying it in a different USB port. Then explore whether there are more up to date drivers you can install.

Did you install any drivers at all or just plug it in and go?

Except that is not actually proof of anything. It is hope that A) I don't know the private key, which cannot be proven, and B) no one will ever know the private key, which also cannot be proven. If you want a proof of burn, then use OP_RETURN.

You have it backwards. SHA256 of the string comes first, and then RIPEMD160 of the output of SHA256. RIPEMD160(SHA256(string)).

There have been plenty of weak seed phrases created in the past, via poor, bugged, or malicious wallets or PRNGs.

I disagree. Just make your passphrase have a minimum of 128 bits of entropy, which is the same as 12 word seed phrases and the same amount of security provided by bitcoin private keys. This means 20 characters if you draw from the full set of 95 printable ASCII characters. The advantage of this is if an attacker finds one of your back ups. Let's say you have 5 seed phrases with 1 passphrase. If an attacker finds a back up, there is a 83.33% chance they find a seed phrase, which is immediately identifiable as a seed phrase, so they know to keep looking for other back ups or to target you specifically. If you have 1 seed phrase and 5 passphrases, if an attacker finds a back up then there is a 83.33% chance they find a passphrase, which could be absolutely anything. Bonus points if you have an encrypted file folding fake "sensitive" data locked by that passphrase which you can unlock to prove the passphrase has nothing to do with bitcoin.

There is also the issue of plausible deniability. Having multiple decoy passphrases you can hand over in the case of a $5 wrench attack to protect your real stash is preferable to only having a single passphrase holding everything.

I still haven't got round to trying Jam because I have no need to given I've been running JoinMarket with no issues for years, but my understanding is that it still is not average user friendly in the same way that Samourai or Sparrow is. If you aren't running Umbrel, Raspiblitz, or similar (which average users aren't), then the manual installation is still too complicated.

For example: https://jamdocs.org/software/installation/#with-docker-image

There is a big knowledge difference required between these instructions and running a simple app.

If privacy is your goal, you will achieve absolute nothing doing this. Everything done via THORChain is fully public and traceable by anyone. THORChain even admit this themselves:

Of note, any Electrum seeds generated with version 4.1.3 or later will never also be a valid BIP39 seed phrase. If the seed Electrum generates by chance is also a valid BIP39 seed phrase (which has a 1 in 16 chance of happening given the 4 bit checksum), then Electrum will discard that phrase and keep incrementing until it finds another which passes the Electrum version check while also failing the BIP39 checksum. This helps to avoid confusion of people not knowing where their coins are when their seed phrase is both a valid Electrum and BIP39 seed phrase.

Here is the relevant commit: https://github.com/spesmilo/electrum/commit/29d13eb32f2ed26b426aef7f3ed1ddcd93a6135d

There is no check in the other direction, though, and any valid BIP39 seed phrase also has a 0.44% chance of being a valid Electrum seed phrase.

So yeah, it's not a simple nested segwit address at all. Would you be willing to PM the transaction ID so I can look at the script and see what it does exactly? The next step would be to extract the public key hash from the script and see if we can generate the matching private key from your seed phrase.

It wouldn't tell you anything about the derivation path, but it would tell you if you are indeed looking for a standard nested segwit address. If you are, then we can tackle finding out the derivation path. If the script is something different, then checking derivation paths as you are doing with Electrum or similar will get you nowhere.

Find one of your addresses from the mSIGMA wallet which has sent coins out from it, and grab the TXID. Head over to https://mempool.space/ and look up that transaction. Click on where it says "Details" on the right hand side. Underneath your address the first field should be titled "ScriptSig (ASM)". Hopefully next to that it says "OP_PUSHBYTES_22", followed by "0014" and then 40 random characters. If it does, then you've got a nested segwit address. If not, then you've got something different.

No, don't do this! Every coin which is sent to such an address permanently bloats the UTXO set that every node on the planet must store. Every node must forever keep a record of those coins in their UTXO set in case they are spent in the future, since no one has any idea what you do not know the private key to this address.

If you want to burn coins, then send them to an OP_RETURN output, which permanently removes them from the supply and does not bloat the UTXO set. It also allows you to prove the coins are burnt, which you cannot do by sending them to an address you have deleted the private key for.

You cannot send bitcoin to that address because the checksum is invalid. The network will reject your transaction.

Assuming you have sent bitcoin to a valid address, then yes. It will sit there unspent until such a time someone generates the necessary private key to unlock those coins, although if you have simply picked a random address with an unknown public key then the chances of that happening are essentially zero.

None of these seeds are valid BIP39 seed phrases as you say, but the addresses OP is looking at were not generated by using them as BIP39 seed phrases. If you ignore the checksum and import them as BIP39 seed phrases you get empty wallets. Rather you reach these funded addresses only if you import those seed phrases in to Electrum and let Electrum assume they are old style Electrum seed phrases, bearing in mind of course that Electrum seed phrases existed for 2 years before BIP39 seed phrases.

Old style Electrum seed phrases originally used this word list of 1626 words: https://github.com/spesmilo/electrum/blob/18cf546aab7d1a4d122a85ae2b49935cf64c9510/electrum/old_mnemonic.py#L31. There are quite a few words on that list which are not on the BIP39 word list, so OP might find even more such seed phrases from word on that list, too.

The bitcoin network has absolutely no concept of whether an address has been "created" or not. As long as the address is of the correct format with a valid checksum, then you can send coins to it. I can generate a million addresses on a permanently airgapped computer, and no one in the world except me will know about them.

This is not strictly true. The only coins which are truly lost forever are ones which are provably burned and cannot be spent by any means, such as those in OP_RETURN outputs or those behind invalid locking scripts. Coins sent to address with unknown private keys could still be recovered in the future with sufficient advances in computing, especially if the address was generated from a known public key, such as 15wJjXvfQzo3SXqoWGbWZmNYND1Si4siqV which was generated from the public key 020000000000000000000000000000000000000000000000000000000000000000.

For legacy addresses. Segwit addresses are different and their checksum guarantees detection of any error affecting up to 4 characters, with a 1 in a billion chance of failing to detect an error affecting 5 or more characters.

Generally speaking, yes, but as odolvlobo has explained above these days that process is usually performed by the mining pool coordinator, which then sends out block headers to the individual miners to be hashed. Also note, it's not a case of choosing which transactions will be added to a block once it is mined. Rather, the transactions are chosen first and the candidate block is assembled from these transactions before it is attempted to be mined. When a miner successfully mines a block, the transactions in it are already fixed. If you want to include different transactions, then you need to the mining pool coordinator to assemble a new candidate block.

I'm not sure where you got Javascript from, but that has nothing to do with what's being discussed here. Individuals run nodes; nodes download and validate blocks and transactions, and nodes store a memory pool of unconfirmed transactions.