OLEDs have "better" power consumption characteristics... in that "Black" pixels don't consume any power at all. This is important for battery powered devices, and even more so with something like the Nano X that has very limited battery capacity.


I've certainly had that "countermeasure" on my Nano S for longer than I can remember... it's certainly not a new thing. Perhaps whomever it was that reported it had only just updated their firmware?

In any case, it's really only a theoretical attack... unless of course you think you wouldn't notice someone sitting next to you with an oscillioscope observing the power draw on the USB cable of your Nano X


As they mention in the article... it would probably be more cost effective and easier to set up a camera to capture the PIN input.

Did you get it all working? The Avalanche wallets currently require version 0.5.3 of the Avalanche app installed on your Ledger Nano S:



Once you have that, you just open the app on your Nano S and then you should be able to open your wallet using either:
https://wallet-beta.avax.network/access
or
https://wallet.avax.network/access

Note, it likely won't work if Ledger Live is still open and running, so make sure you have that closed when trying to access the Avalance website!


I've just tested this and was able to connect and open the wallet OK.

I would have to agree with Pmalek... if it's an ERC-20 token, I'd be inclined to stick with something like Metamask or MEW or MyCrypto. You can still use them in conjuction with a hardware wallet like a Nano S/X or a Trezor ONE/T, but they are much better equipped to deal with ETH/ERC-20 related matters.

Or to ask it in a slightly different way... what do you believe you will gain from this setup as opposed to the current setup?

It's not such much that the BitcoinSV Wiki is a scam site, per se... it's that some (a lot of?) people consider BitcoinSV as a whole to be a "scam", in that claims were made like "BitcoinSV is the one true Bitcoin" etc.

This website has a link to a few "DIY" hardware wallets based on microcontrollers: https://diybitcoinhardware.com/

They also have links to some libraries that might be of use to you like a version of secp256k1 for embedded systems. Perhaps a "hardware wallet" is not exactly what you were after, but there should be some crossover between the wallet functionality these devices try to provide and what it appears you are trying to.

I concur... the time it takes to check 12 passphrases on iancoleman is likely measured in single digit minutes. The time required to get Python downloaded and installed, btcrecover and the required libs downloaded and installed, a token file generated and then the bruteforce up and running is likely to be substantially longer than that.

Is it a long shot that one of those 12 passphrases is the correct one?... most likely, but you're hardly wasting much time compared to how long a bruteforce run in btcrecover is likely going to take.

A lot will depend on the passphrase that the OPs friend was using... and their method for constructing a passphrase. If they tend to use a "standard" format then it will make the key space likely to be quite small/simple. However, if they tend to use truly random characters including specials... the keyspace and required search time will be a lot larger.

Either way, it's impossible to know without more information... and anything here is just speculation at this point.

Where did this value of 1.2 BTC come from?

The Puzzle #64 address only has a balance of 0.64020585 BTC

Or is the 1.2 BTC the total value of all the "prizes" that have been claimed so far... and someone is theorising that an attacker may have attempted to setup a monitoring rig to try and steal all the prizes?

at some point you've also changed from using .crt/.key to using .pem...

Have you been experimenting with the way you were creating the ssl certs?

*ETH Gas fees have entered the chat*


Based on the fact that you mentioned Metamask... you might get hammered with some serious fees depending on how many different tokens you need to move around

You and me both...


I'm still confused as to how the address and/or balance would show up in the Trezor wallet (greyed out or otherwise) without being able to be to used and/or recreated when the wallet is restored.

Trezor, both the web version and the newer Trezor Suite, does NOT allow you to import addresses or private keys etc. You cannot create a wallet without the device. The web version would essentially recreate the wallet every time you started it up and unlocked your device.

It's certainly not something I've seen while using a Trezor... and I don't recall any similar cases either.

Because they (the original creator) are no longer supporting the software and they stopped development... so the only option is to use forks that are maintained by other developers.

Might be worth having a read of this: https://en.bitcoin.it/wiki/Change
and this: https://en.bitcoin.it/wiki/Coin_analogy

They help explain the fundamentals of how "change" works in Bitcoin.

The important thing to note is that for most modern wallets that are not "paper" wallets, you don't have a single address and single private key. You'll have multiple addresses and private keys... and they'll generally be split into "receive" and "change" address.

It seems that your system is still finding the older version of libstdc++.so.6, rather than the newer one that is required (and has GLIBCXX_3.4.20 and GLIBCXX_3.4.21)...

But this seems to indicate that you got Boost compiled:
If so, then you should be able to return to your step 4)... and start following the gist again to get it compiled... or is it still complaining that it cannot find Boost libraries?

I just did a test with Electrum. I created a wallet using the import key feature:

That is to say, I used the same private key to generate a Legacy, Nested and Native Segwit address:



I then created a test message using each "address"... they all created identical signatures:



Which isn't too surprising, I guess... given that the same private key should create the same public key... and it's just the different encoding of that public key that results in a different address. So, theoretically, a wallet would just need to check the specific encoding of the public key provided in the signature that matches the address type provided to confirm if the message is valid. ie. if the message uses an address starting with a "1", then use the P2PKH encoding of the public key, "3" = use the P2SH-P2WPKH encoding, "bc1" = use the P2WPKH encoding. Which is more or less what Electrum does. (It actually checks against each address type.)


So, I don't really understand why this is such an issue still? Is it because P2SH addresses may not even have a private key (ie. pure script) or may have several (ie. multisig)? Is it just that no-one really cares because they're busy implementing other things?

Perhaps I am not making myself clear. Again... it isn't an address "gap limit" issue. It's a Mycelium specific account "gap limit" issue... and I put "gap limit" in quotes because it isn't what we usually refer to as the "gap limit" (ie. check for X "unused" addresses before assuming there is no more transaction history to look for).

It would appear that initially, Mycelium had stopped syncing properly, and was not showing the transactions on his #4 Account, even though, according to the OP, they had been confirmed (and I assume they were showing on blockexplorers etc). So, OP then uninstalled and reinstalled the app, wiping all the data... after restoring from their seed, Mycelium was only showing the first 3 accounts... so, it was still not syncing the transactions from the #4 account properly... however, because of the account "gap limit" logic within Mycelium (ie. do not show an empty account on wallet restore), it didn't even show the #4 account as existing.

To illustrate... it sounds like the OPs Mycelium wallet looked like this...

Before uninstall:

After reinstall and restore:


That is to say, Account #4 was not recreated after the restore... as the app was still not syncing those transactions correctly. OP then manually created Account#4 and Mycelium magically synced the 2 missing transactions and displayed the correct balance.


At the end of the day... it's basically due to the relatively regular failing of Mycelium to sync properly. Whether this is a problem with the client or their backend server infrastructure is unknown. Personally, I suspect it is the backend server infrastructure, but I have no real proof of this.

I have to hand it to Trezor... their native desktop application is a pretty solid offering with built in TOR support, dark theme etc. The one thing that is missing for me, would be the ability to connect it to my own full node.

I would highly recommend you go with the "freeze" option if there are UTXOs that you know you'll never want to spend... this will prevent them from being accidentally used in any future transactions.

Note that it isn't "permanent", you can always "unfreeze" a frozen UTXO.

Ubuntu is as good as any other distro... plus it's basically available on the Windows App Store.

WSL is actually insanely easy to use... and it does nifty things like offer you /mnt/<windows drive letter>/ access, so you can easily access external drives and the like...

You might want to have a quick read of some of the basic stuff here: https://docs.microsoft.com/en-us/windows/wsl/

I believe so... this guide (which essentially follows the same flow of make and sudo make install says in the "Extra Guidance" section:


Ideally, as they suggest, you should probably rename the folder initially to something like "bitcoin-OLD", rather than deleting it... so if anything goes wrong, you can simply change the folder name back and you should still have it.