For more visibility... You might want to create a "Scam Accusations" thread (if you haven't already), with details of the original scam and all the other bits of info you have collected.

They're actually pretty difficult to hard "brick"... and if you have your 24 word seed, then you still have a safe full wallet backup which will enable you to recover your funds if something does go wrong.

If you're concerned about using Windows 7, you could always try and use a live linux distro... run Ubuntu from a "live" USB drive and connect/update your Ledger that way. Might be "safer" than trying to run Ledger Live on an unsupported OS and have it crashing unexpectedly.

Creating/Running a live linux distro is relatively easy these days... refer: https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-windows

What are you talking about? The missing 4 words out of a 12 word seed mnemonic is relatively easy to bruteforce using seedrecovery (part of btcrecover package). You don't need to try and guess 20-40+ characters... you're guessing whole words from a known list of 2048 words. That is the same as guessing "4" characters (from an alphabet of 2048 characters).

The "dangers" of relying on digital storage are relatively well known... Bit rot is a reality.

Still, as long as you take adequate precautions to mitigate that sort of thing... storing your (encrypted) key on a USB drive is probably no better or worse than using paper and/or cryptosteel. At the end of the day, all these methods have various pros and cons... You just need to make sure you're aware of what the "cons" are and how to mitigate the issues associated with whatever method you choose to use.

bob123 was still correct tho... what you have described in the OP is not a cold wallet... the "highly secure" (ie. offline) computer would be the actual "cold wallet"... your USB drive would essentially be just a backup device.

Bars! orrr... something.

And based on some most of the content on YouTube... you don't need any talent or ability

The speed of recovery is also dependent on the user knowing an address (or addresses) that was generated from the seed mnemonic... without that, you'd need to start generating addresses and doing blockchain lookups to see if they were "used" etc which can be quite slow compared with simply generating an address and comparing to a given value.

But yes, 4 missing words is significantly easier to find that 5 missing words... the time required on fairly "average" hardware should be measured in days, as opposed to years.

You're definitely on the right track... your explanations are pretty close, especially with regards to the mnemonic generating the "global seed"... However, just to clarify a couple of points:


In theory, this is correct... however, it is not compulsory that a wallet follows a specific derivation path for a specific coin. In some instances (in the case of forks), you may actually need to follow a derivation path of a different coin so you can get the private keys you need to be able to access forked coins.


In the case of BTC and BCH yes.. but not necessarily for ALL coins/networks. It really does depend on the networks in question. In your instance, because BTC and BCH share a common base and use the same format of private key, then yes you can use the private keys from one (and generate public keys/addresses) on the other. However, this may not be true for ALL coins/networks.


It doesn't iterate through the derived addresses... it iterates through the "accounts" in a given derivation path.

The format for a BIP44 derivation path is: m / purpose' / coin_type' / account' / change / address_index

As you can see, there is an "account" value... so, in your ledger, when you first setup a BTC "account" it defaults to the one that uses the "0" account value... which starts with m/44'/0'/0' as the derivation path. So the path to the individual receive addresses in that account would be:
m/44'/0'/0'/0/0
m/44'/0'/0'/0/1
m/44'/0'/0'/0/2
...
m/44'/0'/0'/0/n


If you were to create a 2nd BTC "account", it would start generating addresses underneath the m/44'/0'/1' path. And the path to the BTC addresses in that "account" would be:
m/44'/0'/1'/0/0
m/44'/0'/1'/0/1
m/44'/0'/1'/0/2
...
m/44'/0'/1'/0/n

A 3rd account would be: m/44'/0'/2' with address paths:
m/44'/0'/2'/0/0
m/44'/0'/2'/0/1
m/44'/0'/2'/0/2
...
m/44'/0'/2'/0/n

etc etc.

As far as I'm aware, you can only import Master Private/Public Keys... or individual private keys... Mycelium doesn't see to support importing an actual seed... and only seems to support "importing" a mnemonic when you are first setting the app up (aka restoring your wallet).

I'm not sure if the devs read stuff here much any more... might be worth creating an "issue" on their github issues list and see if they plan on implementing such functionality.

That seems to be the latest versions of the BTG app and Ledger Live... So, when you attempt to add a BTG account in Ledger Live, what exactly is happening? How far through the process do you get before things don't work?

Do you get past the "Connect and unlock your Ledger device" and the "Navigate to the the Bitcoin Gold app on your Device" steps? Do you see it doing the "synchronising" step:


What does it say when it "finishes" this section... does it show any account?

Possibly because the QRcode was simply an encoding of the master private (xprv) or master public key (xpub) from the other wallet... And NOT a seed.

The master keys imply that a specific derivation path has already been used.

Technically, you'd need to import the "yprv/ypub" or "zprv/zpub" to get the correct P2SH-P2WPKH and P2WPKH versions of the wallet... But I'm not even sure of that is possible.

How about "Singularity"? Fits the "all in one" concept...

Haven't done extensive research, but I'm not aware of a wallet with that name... Although there was a "Singularity Coin" (long dead) and a SingularityNET token.

Still, proper branding/logo/marketing should assist in avoiding confusion with those projects.


Just out of curiosity, how is that shitposting? Bhinneka is Bahasa Indonesia and translates as "diversity". Seems somewhat appropriate given your requirements... And given the very large numbers of Indo users on bitcointalk, it'd probably prove quite popular!

Have a read of this: https://github.com/spesmilo/electrum/issues/3198

Essentially, due to Electrum's use of PyInstaller... several antivirus products seem to keep flagging it as "malware", due to "false positives".

Other users have had the same issue with ESET and Electrum: https://www.reddit.com/r/Electrum/comments/b6rewd/electrum_334_virus_detected_by_eset_internet/

If the installer that you downloaded was from electrum.org AND you have successfully managed to check the digital signatures, the chances of it being infected with malware a pretty much non-existant. Does ESET provide a way to exclude certain directories from scanning (or maybe that "Ignore" option)? If so, you could use that to prevent it constantly flagging this incorrectly... or perhaps contact ESET and tell them to fix their scanner?

Ahhhh ok. Now we're actually getting to the real issue...

In that case it is likely that:

a. the version of the BTG coin app that you have loaded on the device is "wrong".
b. the version of Ledger Live you're running isn't playing nicely with the BTG coin app on the device.

What version of Ledger Live do you have?
If you plug the Nano S in, unlock it, select the BTG coin app and then scroll down to "About"... what is the version number listed there?

If you still keep getting those errors even after a reindex, then the most likely culprit after that will be your storage drive (given that the RAM tested OK with MemTest)... I assume it's on a USB external HDD?

In Ledger Live... if you select your BTG account, then click the "spanner" icon next to send/receive to show the "Edit Wallet" settings, then click "advanced logs"... what is the "freshAddressPath" value? Is it "44'/0'/0'/0/x" or "49'/156'/0'/0/x"?

Go check out nullius' old "bech32" utility... https://bitcointalk.org/index.php?topic=2664728.0 written in C

Github repo here: https://github.com/nym-zone/bech32

Like I said... not very optimised! 

It's a python script... that builds up a 24 word mnemonic (from a given pattern of form "word1 word2 word3 ... word 19 x x x x x")... it then attempts to check that it is a valid mnemonic. If no exception is thrown by that function, it assumes it is a valid mnemonic.. and writes the mnemonic to a file.

I would expect that there is some significant savings to be made if custom coding and just doing the checksum calculation etc as opposed to using library functions that actually do the full conversion to a hex seed and relying on exception catching... and of course the writing out to a file is technically unnecessary at this point, but I was modifying existing code as opposed to starting from scratch... and well... #lazy 

Indeed, by cutting out a lot of the unnecessary and "time expensive" code (and without trying to custom write the checksum code), I got it down to under 2 minutes for 1,000,000 mnemonics... not too bad for a lazy "weekend warrior" coder  


Still even at 5 seconds for 1,000,000 mnemonics... you're going to be looking at ~20 years just to find the valid mnemonics... and then you have the conversion to hex seed + address generation/checking

Not outside the realms of possibility... so, I'd guess it's "a loong time"... rather than "a loooooooong time"

As per the OP:

No need for blockchain lookups or API calls...

I think the original calcuation of "1.4x10^14 combinations" is probably about right.

As the OP correctly identified a large percentage of combinations are invalid, because the mnemonic checksum will fail before you even get as far as calculating keys. That is to say, for a given set of 23 words... it seems that only around 8 (3 bits) out of the 2048 words in the BIP39 word list will actually be a "valid" 24th word.

The 'btcrecover' script can probably be leveraged as a starting point... although from memory I think it will only find up to 2 or 3 missing words at the most. If OP is sure that they have the first 19 words and needs to "only" find the final 5... well, it'll still take a "long" time. 3 missing words and I would have said you might have been "OK"... 4 and you'd be looking at a time measured in months if not years.

I dug up my old hacky script (find_missing_seed_word.py) that allows you to specify the words you know and put an 'x' in for missing words. On my system it seems to be able to "find" valid seeds (not even generating keys etc) at a rate of around 1,000,000 in 7-8 minutes... Granted, it probably isn't the most optimised script (it has file writes for logging etc) as my python skills are pretty poor, but it should be "ballpark"

Given the total possible number of valid seeds to find when missing 5 words is around 1.4*10^14... I think it'll take "quite a while"^[1] at that rate to go through all the valid seeds



[1] Some rough maths suggests that will be something like ~1864 years.

Yes...


Errr... NO!!?!

You should NEVER let the public mess with the core repository. By all means make the code viewable/downloadable etc by the public... but the main GitHub repo should still be locked down to the project owners/devs only... if the public want to make submissions, they should fork the repo, make their changes and then create a pull request.