You setup symlinks in the "default" locations, that point to somewhere else (ie. your external devices)...

so, things like this:

That would create a link from the "blocks" folder on your external ssd (ie. /mnt/bitcoin/blocks) to your ~/.bitcoin folder. Essentially, it is doing at the OS level, what the -datadir, -blocksdir and -wallet commands do at the application level... but it gives you extra flexbility... as you can link any folder or file and not just the ones that those commands allow you to.

For instance, I do something similar on a Windows machine to hold the "chainstate" on a fast SSD, while the block data lives on a slower "HDD". It provides a good speed boost without requiring an (expensive) SSD to hold mostly static block data.

The interesting thing about the PIN server... is that you can actually run your own. They do provide the code: https://github.com/Blockstream/blind_pin_server

Of course, there is no guarantee that the PIN server you are connecting to is actually running this code... unless you do run your own.

And I've no idea how easy it is to setup, resource requirements etc, but maybe it could be a nice little addition to something like a RaspiBlitz/Umbrel/MyNode setup.

The fact that an employee could casually copy/paste some private keys onto a USB drive and walk away with them is pretty damning evidence that their security protocols were poor to non-existent...

Well... you can try this script: https://github.com/HardCorePawn/dump_unenc_keys

Note that it requires Python 3.

Basically, it just hunts through the file looking for the old (unencrypted) private key marker and then dumps the next 32 bytes out as a private key and displays it on the screen. If the wallet.dat was unecrypted you might get lucky. Do you have any records of old bitcoin addresses so you can compare any extracted keys?

Alternatively... I have a script that can extract encrypted private keys, but I'm not sure how well they will work with a "corrupted" wallet.dat

To be difficult, this script requries Python 2 (it's untested with Python 3)... and obviously, you'd need to know the wallet password for it to work properly.

Ahhhh ok. Yeah, most external drives tend to be formatted for use with Windows by default. There are some exceptions where I have seen drives that are marketed as "OSX external drives" etc.

I actually purchased a fairly typical 1TB External HDD yesterday. Works fine with Windows, but when I connected it to the Pi it was completely unreadable unless I formatted the thing

Yay for "standards"

Yeah... they are basically making the suite available via a web interface in addition to the native desktop versions. I'm not entirely sure why to be honest? Perhaps it's for "portability", perhaps it folks who don't want to leave a trace on their desktop and having a website they can connect to enables that (although you still need Trezor Bridge installed).

Personally, I think it's just asking for endless phishing/fake websites to pop up with similar URLs trying to steal seeds etc...

Yeah... you'll see the same warnings in v0.21.0 as well... but if you upgrade to 0.21.1, that has the taproot activation code, those warnings will disappear.

As NotATether has mentioned, it's nothing to be concerned about... it's just related to the Taproot signaling... and won't prevent your node from operating properly.

If it is working with sudo, but fails when run as the normal user account, then it's quite likely just a permissions error of some description causing problems with one of the test suites...

Although, that is not likely going to be a problem with the app itself... you should be fine.

It's come in at a VERY competitive price ($39.99!!?! , sadly out of stock or I'd probably be ordering one to play with)... and the camera for QR code scanning is definitely a bonus.

I'm still not overly enthusiastic about the whole "blind server" thing... or the complexities involved with recovery... but it is at least possible to run your own server if you want.

Hopefully they get some more stock in the not too distant future, so I can actually get one and have a proper play with it.

It does? Damn... when did it start generating native segwit addresses for 2fa wallets?

ok... so I went and looked and it seems that support for segwit 2fa wallets was added back in 3.3.0!!?!

And I'm assuming the ability to generate "Legacy" 2FA accounts was also "hidden" along with "legacy" standard wallets starting from version 4.1.0 ?

I'm a little surprised that it is coming up as corrupted then... unless the drive is suffering from "bit rot", or the device was disconnected before the file was properly stored on the disk, it should have been "OK".

Do you know if the wallet.dat was encrypted with a password? If it wasn't, it might be possible to extract private keys "manually" by using a hex editor (or a script to scan the raw bytes of the file).

If it was encrypted, it's a lot more difficult.

Indeed... it seems that the information I was looking at is slightly outdated... I had read that using it headless required creating your own sdcard image. However, further investigation shows that you can use the default image and set it all up headless without issue. There is a fairly comprehensive guide here: https://armantheparman.com/raspiblitz/

And he even shows how to go headless AND use WiFi, if ethernet is not suitable: https://armantheparman.com/headless-wifi/


Meanwhile, I'm off to the store to buy a more reliable power supply for my Pi

Yeah, I assume the VFAT option was originally chosen for compatibility with Windows?

In any case, one of the more linux-centric filesystems is definitely the better option going forward (assuming you don't need the ability to read the drive on a Windows system)

Yikes... to my mind, all this password stuff has the potential to get quite messy

I can understand why the devs want to move to a unified password setup... I'm just not sure that this is the way to go about it, especially given that there is no "obvious" notification to the end user that the password model has changed.

That's good to know... I didn't think to try (actually, I was just too lazy to try because entering the words on the mobile is a pain in the ass! ) creating wallets using non-english BIP39 seeds on the mobile version.

I'll file that piece of info away for future reference

When you say you have to kill the sandbox to run Suite, is that just getting the app actually running in your VMs... or is it issues with it not working properly when it is running? i.e not being able to communicate with the device?

That is very bizarre... are you getting any error message or anything? It should do something... either show you a 12 word seed or output an error... what version of Electrum were you using when trying that command?



What was the work around?


Correct... the 2FA option generates a multisig wallet which is P2SH... and while it generates "3-type" addresses, they're not "Nested Segwit" addresses (aka P2SH-P2WPKH) which also start with "3".

Is there any reason why you can't use the 2FA option? Do you "require" segwit addresses for some reason?

What language is the seed in? You should be able to simply import the seed directly into Electrum, at least the desktop version, to recover your wallet... you'll then be able to send from Electrum to any wallet that you choose.

Choose "I already have a seed", enter the seed, click "options" select BIP39... you'll probably get the "BIP39: unknown wordlist" warning... click next, select "Legacy" (or click "detect accounts")... it should create the wallet with the same addresses as CoPay (assuming your CoPay wallet wasn't a multisig).

I've done some quick tests... and Electrum seems to support BIP39 seeds in any of the languages that the Ian Coleman tool can create seeds in:
- English
- 日本語
- Español
- 中文(简体)
- 中文(繁體)
- Français
- Italiano
- 한국어
- Čeština
- Português

I was able to generate a 12 word seed in ALL of these languages and the addresses created were the same as displayed on the Ian Coleman tool.

As mentioned by ranochigo... it's from version 4.1.0 onwards... as per the release notes:

If a website is saying your receive address from Electrum is invalid, then it is most likely that:

1. You have created a bech32 "native segwit" wallet in Electrum (this is the default from Electrum v4.1.0 onwards, see below)
2. The website you are attempting to withdraw from does not support bech32 "native segwit" addresses

Note that this is NOT a fault with Electrum... it is a fault with the website you are using. You should contact the support of the site involved and encourage them to update their systems to properly support SegWit.

---

As of version 4.1.0, you can no longer generate Legacy wallets using the "wallet creation wizard" in Electrum. You either need to use a pre-existing Electrum legacy seed, a BIP39 seed and select "legacy" or you have to use the make_seed() command on the console (or linux commandline) and set the seed_type as "standard" and then use that seed to "restore" the legacy wallet.