Airbitz might interest you.

If you'd like to try to recover it yourself, here's the Quick Start for the open source (free) tool btcrecover: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#quick-start. It does take a bit of work to get it set up and running, though. (Full disclosure: I'm the author of that tool.)

If you have any questions about it, just let me know.

Although I've never dealt with Dave @ walletrecoveryservices personally, he's gotten nothing but good reviews from what I can tell, so that seems like a good option too.

In either case you'll need to have a good idea of what's in your password.

Plus a "checksum". Only half the 8-bit checksum (plus the entropy) would fit into 12 words, hence the need for a 13th which encodes just 4 bits. (Note that BIP-39 has a smaller 4-bit overhead for its checksum which does fit into 12 words.)

Yes, but only more efficient in the sense that there are no words which encode fewer than 11 bits; so better encoding efficiency. Since half of the 8-bit "checksum" wouldn't fit into 12 words, the choice was apparently made to reduce security by 4 bits post-2.7 so that now everything fits into 12.

Potentially, but it depends on how you call make_seed().

With post-2.7, calling make_seed() with 133 <= num_bits <= 143 gives you a wallet with 13 words and always 135 bits of security due to the rounding-up-to-improve-encoding-efficiency I mentioned. With pre-2.7, you'd get the exact same security level and word count by calling make_seed() with num_bits == 135.

The difference is that pre-2.7, num_bits was the desired security level you wanted, and could result in a mnemonic with an added word which encodes fewer than 11 bits. Post-2.7 num_bits is now a lower bound for the total number of bits you want to encode in the mnemonic including the "checksum". It's a bit confusing post-2.7 IMO.

Regardless, by default, make_seed() is called with num_bits == 128, which generates a 12-word 124-bit-security mnemonic with post-2.7, and a 13-word 128-bit-security mnemonic with pre-2.7.

To improve security if ECDSA is ever broken (given 160-bit RIPEMD)? I suppose, but practically speaking there are many other far more likely attack vectors, such as side channel attacks against Electrum/Python, the quality of the underlying OS's CSPRNG, the ability to see pubkeys in the mempool prior to being added to a block (bad if ECDSA is broken), etc.

Thanks!

There's really no single "best", or rather "best" is very much a matter of opinion.

There are at least three factors to consider when security is your most important goal: risk (of loss), convenience, and cost. There's no single solution which maximizes all three. (And of course there are plenty of other non-security-related factors, e.g. privacy, tx validation type, software license, protocol stance (block size/RBF/SegWit), etc.)

I'm not an Electrum expert, but I believe you'd have these five options: "standard" online; standard cold/watching-only; 2FA; multisig; and hardware. The breakdown in order of best to worst looks something like this (and even this is somewhat a matter of opinion):

Risk
Cold/watching-only & hardware > multisig > 2FA > online

Convenience
Online > 2FA > hardware > multisig > cold/watching-only

Per-tx Cost (least expensive to most)
Hardware, cold/watching-only & online > multisig > 2FA
(Of course, hardware wallets have a startup cost, and so might cold/watching-only, multisig, or 2FA if you don't already have spare hardware/phones available.)

So the best option for you is impossible for me to say, but if you have any specific questions about the above, ask away!

First off, it's great IMO to seeing people doing code reviews of Electrum, the more eyes the better!


In short, pre-2.7 seeds have slightly more entropy, but it probably doesn't matter.

     Prior to Electrum 2.7, Electrum encoded 136* bits of data into 13 or fewer mnemonic words using a wordlist of length 2048**. log₂2048=11, so each word is capable of encoding exactly 11 bits of data. This made Electrum perhaps not as efficient as it could have been, since 13 words (as you already pointed out) can store 143 bits of data, but it only needed 136 bits of storage.

*From the source:**Except for the Portuguese word list which has 1626 words in it, log₂1626≈10.67 bits per word.

     Prior to encoding, Electrum truncates any leading 0 bits, so if the 136 bits of data has 4 or more leading 0 bits (1 in 16 chance for random data), the resulting mnemonic would be 12 or fewer words. There's no loss of bit storage/security here, it's simply the equivalent of using a simple compression algorithm before encoding into words.

     These 136 bits are generated randomly by the OS (assuming no OS bugs), but are then incremented until an HMAC of these bits starts with the byte 0x01 to act as a sort of checksum. This effectively discards 255 out of 256 all possible seeds, which decreases the entropy by 8 bits (2⁸=256), resulting in a seed with about 128 bits of entropy.

     AFAIK, all versions of Electrum 2.x prior to 2.7 used this algorithm (assuming custom entropy wasn't added), but I could be mistaken.

     The commit you referenced makes two changes. First, instead of aiming to gather 136 bits from the OS, it aims for just 128 bits. Second, it rounds 128 up to remove the inefficiency I mentioned above so that the mnemonic's max possible length is fully utilized. 128 bits gets rounded up to 132 bits ( ⌈128/log₂2048⌉*log₂2048 ). The result, after removing the bits to account for the checksum, is 124 bits of entropy (≈120 bits for Portuguese).

     The second change makes sense to me, but I don't understand the reasoning behind the first. The commit message says in part "count prefix length as entropy" which I disagree is a valid thing to do.

     Does this commit matter practically? Not really IMO, 124 bits of seed entropy is still far beyond any practical ability to crack any resulting ECDSA keys.

OK (and wow! ), so I think you should be able to create an Electrum 2.7.x wallet with both master private keys that can finally spend your funds.

Download the latest Electrum (it must be at least Electrum 2.7, or maybe even later, I'm unsure, just grab the latest to be sure).
Create a new wallet, choose multi-sig, and choose 2 of 2 (which is the default).
Select "I already have a seed", and enter your Electrum seed. It will display an xpub which you can ignore.
For the cosigner, choose that you "Enter cosigner seed" (not "key").
Before entering a seed, click Options, and enable "BIP39 seed". Then enter your newly discovered Copay seed.
It will ask for an account number, accept the default of 0.

Hopefully that should be it, but I'm not 100% sure, so let us know. Incidentally it doesn't make much sense to use this wallet going forward; it will be a 2 of 2 wallet which creates larger txs (more fees) with none of the advantages of a 2 of 2 wallet (separate signing devices).

OK, so this is a 2 of 2 multisig wallet, and it has stored inside it only one of the two master private keys required to send transactions out of this wallet.

Back when you created this wallet, Electrum must have asked you for the cosigner master public key (which starts with xpub), there's no other way you could have created such a wallet (unless you happen to have a hardware wallet?).

Is it possible you entered the xpub from your Mycellium wallet when you created the Electrum 2 of 2 wallet? You can check to see if the xpub displayed in Electrum under Wallet menu -> Master Public Keys, the second/cosigner one, matches the xpub in Mycellium.

If not, do you know where else you may have gotten that xpub?

(I'm assuming that the 12-word seed you do have is the same one that's displayed when you go to Wallet menu -> Seed, correct?)

Glad to here it. Sorry if I implied earlier that you were trolling, but you're definitely mistaken.


To simplify a bit, creating a child key from a parent key involves two steps as per BIP32:

(for non-hardened keys) The second step looks more or less the same for both public keys and private keys:
...and the first step is to create the "temp" keys, which involves taking an HMAC_SHA512: where "index" is the child key number which increments for each new key.

The important part here is that we use HMAC_SHA512 to create the temp keys. This means that the temp keys look completely random and unrelated to one another, as do the resulting child keys. The only way to relate child keys with one another is to reverse the HMAC_SHA512, which is infeasible as long as SHA512 remains unbroken.

Of course if you have the parent key and chaincode, you can derive the children, but the parent key and chaincode never appear in the blockchain. They're stored in the MultiBit HD's encrypted wallet file.

No offense intended, but that's a matter of opinion.

Electrum has never used key stretching, which makes wallet files with shorter/weaker passwords in the realm of being brute-forcible. For example, an Electrum wallet with a password containing 8 lowercase letters or digits would cost somewhere around $100-$200 to brute-force (some back-of-the-napkin calculations can be found here).

Personally I'd avoid uploading my wallet to the cloud unless I was certain it had a strong password, or used an additional layer of encryption with strong key stretching such as Veracrypt as shorena mentioned.

That's a wallet dump from Bitcoin Core—there is no associated master public key.

Core uses an entirely hardened BIP-32 path, which makes it impossible to create a master public key or an HD watch-only wallet. (edit: at least at the moment, there does seem to be a desire to do so eventually)

Neither person has such an address in the sense that they have the private keys used to spend any funds sent to the address.

It's trivial to create any address (except for the last few characters and the first). It's trivial to send funds to such an address (poorly programmed wallets sometimes do so). It's not trivial to create a private key with an arbitrary address (hence vanitygen, which can "choose" a few characters in an address along with a private key, but not these addresses).

This is somewhat anecdotal, but it may be helpful anyways.

I had similar problems a few years back, and it turned out to be bad RAM.

I wasn't having any other PC-related problems; no crashing, no problems when gaming, just problems w/core. I eventually ran memtest86+, and discovered a single bit error (in all 16GB) which matched up perfectly with the single-bit error (in terms of its position in a 64-bit word) I had also tracked down in my block files.

Although I was surprised, perhaps I shouldn't have been. Unlike most software, Bitcoin does a whole lot of checking/hashing of its block data, so it's much more likely to uncover hardware problems on a PC than most any other non-diagnostic software.

Win 10 has a memory diagnostic tool built-in. Just click the Start, and type "diagnostic", and should show up (it will require a reboot). Memtest86+ is probably more thorough; it's a little harder to set up, but worth the effort IMO.

No practical limit, but (please correct me if I'm wrong) technically there's about a 2.1 billion address limit. Might be a problem for Amazon, but not for most anyone else.

With Bitcoin Core's current implementation, I believe it will wrap around once it hits that limit and begin producing non-hardened keys, and once those are exhausted it will loop infinitely. Not that I'm particularly concerned about that at the moment....

It sounds like you pretty much already know the answer, or maybe I don't understand the question?

On the secp256k1 elliptic curve used by Bitcoin, there is a point that's called the "base point generator", often denoted G. It was arbitrarily chosen (by Certicom I believe, or whoever defined the secp256k1 curve parameters).

A private key is simply a 32-byte (approx.) long integer. A public key is a point on the curve-- it is found by taking the point G multiplied by the private key (via the double & add method, or some other).

You misunderstood OP's issue.

You can create a wallet containing loose (non-HD) keys: create a "standard" wallet, select "Use public or private keys", and paste in one or more keys. Set a password when asked.

After creating the wallet, go to Wallet --> Private keys --> Import to import additional keys. Electrum will ask you for your password. In versions 2.7.9 and earlier, you could hit Cancel on the password prompt, but Electrum would still allow you to enter new private keys for import, and you'd end up with a wallet with the original keys encrypted, but the new keys in plaintext.

As I said above, this was fixed in 2.7.10.

It doesn't look like this was a known bug, but it was fixed here (as a result of fixing a related issue) in version 2.7.10 (current version is 2.7.11).

After upgrading, you'll still need to fix your wallet. Delete any affected addresses on the addresses tab, and import them again.

It sounds like you created a multisig wallet for some reason.

In Electrum, go to the Wallet menu and select Master Public Keys. How many are listed? If more than one is listed, how are the labeled (e.g. "x1/ (self)" and "x/2 (something)")?

Also, how many words are present in your seed (Wallet menu -> Seed)?

My apologies, that was a very poor choice of words on my part (I should know better). I should have written "different (and in some ways better) than BIP-39" or similar....

That's only for wallets which are restored from a BIP39-compliant mnemonic sentence created by some other not-Electrum software (Electrum currently supports this, but it may not always).

Wallets created by Electrum use Electrum's proprietary mnemonic-to-xprv algorithm, and use a path of m/c/i.

Electrum uses m/c/i, where c is 0 for external, 1 for internal (change), and i is the incrementing index.

For a summary of various wallets, see this spreadsheet.