The answer is no.

Child private key + parent master public key will let you find the parent master private key.

The code you have pasted is for the old pre-2.0 wallets (it's left in there for backwards compatibility)

No.

Comparing prime factorization (actually, just guessing primes and multiplying normally lol) to Elliptic Curve multiplication (which is actually like 20 multiplications, 15 divisions, and a bajillion mods for each operation) is like comparing apples and oranges.

128 bits of security for ecc is fine. It would take me millions of lifetime-of-the-universe-thus-fars to guess 128 bits with my computer.

In comparison, 128 bit RSA encryption would be a joke if anyone used it today.

There is a cap to the maximum security possible on secp256k1 at n/2 of key size.

256 bit keys therefore only provide 128 bits of security.

Anything more than 128 bit for bitcoin is just "feel good" territory.

1. Download the latest translations from https://crowdin.com/download/project/electrum.zip (If you would like to contribute your translation to the project, sign up for free with crowdin to translate directly to the project. https://crowdin.com/project/electrum )

2. Open any of the current languages files from the electrum-client folder in poeditor (Every po file contains the English strings in it) and change the language setting to the language you want to translate into, then edit each string.

3. In ./lib/i18n.py (you will need to run Electrum from source) you must modify the languages dict at the end to include your language. Then you must include your language's folder and electrum.po file in the ./locale directory.

Then you should be able to run Electrum in your language.

But like I said before, it would be much easier for you to contribute by just translating your language on Crowdin. We would greatly appreciate it.

Never said 100%.
third party banks and national currencies are proven to not be 100% safe either.

If anyone is looking for a 100% safe thing in life, they're in for some big disappointments.

Stop relying on others to validate your transactions and watch the blockchain for you.
Also, (this is the biggest one) don't categorize transactions based on transaction ID, then store them away and never check them again.

It's not that hard. But it's hard when the wallet is already built from the ground up under the assumption that "Once we see a transaction, even with 0 confirmations, it's as good as done."

Stop making that assumption, and code your wallets accordingly.

Also, there needs to be vigilance on the user side as well.

If you spend unconfirmed change, you are risking the chain being broken.
If you accept unconfirmed transactions with unconfirmed inputs, you are at a large risk of being double spent if you don't wait for at least one confirmation.

The only sure-fire way to prevent becoming a victim is to wait for confirmations.

This is my fault:
I sorted the list BEFORE NFKD normalizing it.
Sorting again AFTER NFKD normalizing it will produce the results mentioned.

When I first made the pull request, I was under the mistaken impression that the lists were not to be NFKD normalized, and all NFKD normalization would occur in the apps... but someone corrected me, and I fixed the NFKD normalization of the list... however, it seems the order should have been changed too.

Unfortunately, there are people using phrases generated with this word order.

BIP39's weakness: the checksum depends on the order of the wordlist... therefore requiring the wordlist... but the BIP says "not require wordlist" while at the same time "require check the checksum" (which requires knowing the wordlist lol)

I can understand why ThomasV removed BIP39 functionality from Electrum now...

Represent the number of "multiple pending transactions" you mention as x.

Calculate the fee as:


Let's call the number of this result y.

Now do the following: (Make sure the preferences states to "Check transaction before broadcasting")

1. In the "Addresses" tab click the arrow next to "Change" to show your change addresses.
2. Find the Address in your change addresses which contains the change from your MOST RECENT UNCONFIRMED TRANSACTION. (Find this by right clicking the transaction and checking the details window and look at the addresses and amounts of BTC at the bottom window to find your change address)
3. Right click the change address in your "Addresses" tab, and click "Send From." This will take you to the send tab.
4. Set the Fee box to y that we calculated. The unit is BTC.
5. Send the remainder of the bitcoins in that address to another address of yours.
6. Click Button to sign and check transaction. (There should be no error, as it is not being sent)
7. On the check transaction window, Click save. Then save the file somewhere.
8. Open the file, and find the looooong string of hex characters between quotes.
9. Copy the string (like 01000000bef39df829...00000000)
10. Paste it into http://eligius.st/~wizkid057/newstats/pushtxn.php but wait on clicking the button.
11. Click "Broadcast" on the Electrum transaction checking window.
12. Wait about 20 seconds. (or if an error message pops up in Electrum, just go straight to the next step)
13. Click "OK" on the website to push the transaction.

If the website gives an error like "already in mempool" or something like that, then your transaction propagated fine... but if not, then you'll probably have to wait until Eligius mines a block.

This will confirm all your transactions at once.

If you want them to be confirmed quickly, with all this congestion I would recommend 0.001 BTC/kB

Including 0.0001 BTC x number of transactions will not get you confirmed for a while.

http://webbtc.com/script/455e64c2ffaf40ba8b1d2f0443f7ddb880bd2251431480a31faa7009041e60d2:0

This is a draw out for anyone interested.

5K2YUVmWfxbmvsNxCsfvArXdGXm7d5DC9pn4yD75k2UaSYgkXTh
          vvvvvvvvvvvvv
https://github.com/Bit-Wasp/bitcoin-lib-php/blob/master/src/BitcoinLib.php#L568
          vvvvvvvvvvvvv
https://github.com/Bit-Wasp/bitcoin-lib-php/blob/master/src/BitcoinLib.php#L430
          vvvvvvvvvvvvv
https://github.com/Bit-Wasp/bitcoin-lib-php/blob/master/src/BitcoinLib.php#L389
          vvvvvvvvvvvvv
1HKqKTMpBTZZ8H5zcqYEWYBaaWELrDEXeE

After doing this, remember to delete the command history from your electrum config file.

On Windows:

Go to C:\Users\<User>\AppData\Roaming\Electrum and open up "config" file with a text editor.

Search for "pw_decode(" without quotes and you should find something that looks like the below...


Delete that from your config file so that the commands before and after are properly serapated by commas.

In the above example you want to delete the following:


Which will leave you with

the ... are the commands you performed before and after.

Then after you deleted, save the file.

If your password is good enough, then you could send me the file and I can check to see what format it is in etc. to help you get an idea of whether it's recoverable or not.

If your password is weak, then you might not want to trust anyone with your file.

You need to create a "Watch-only" wallet first.

Then the Send button will be replaced.

GPG pubkey and the Electrum pubkey are COMPLETELY DIFFERENT in format.

ELECTsUM must not check for the correct format, and somehow is generating a weird wallet... don't know how.

Contact the ELECTsUM developers and ask how the MPK is derived when an incorrect format is input.

Maybe they generate the master private key from the hash of the test if it's incorrect or something, you'll never know unless you ask them.

Not using the same address over and over is a huge plus for privacy.

Disabling change addresses means that bitcoin sent from address "1ABC..." will ALWAYS send change to "1ABC..." only.

So I can 100% certainly know your entire balance whenever I want.

If you send to a new address each time, I can guess. I can maybe guess with a high amount of certainty, but I will never know 100% that the second address in the transaction is yours.

a P2SH is exactly that: PAY TO SCRIPT HASH.

In other words, the script is set in stone the second you fund it.

If you don't fund it... there's nothing to sign.



So in other words, no, you can not do the situation you described.

The flow works like this:

I make a P2SH multisig that is m of n.

I gather the pubkeys of the other n - 1 participants, and I use their pubkeys along with mine to generate the script, and hash it.

I then get a P2SH address. (which is a hash, so unchangeable once finalized)

Then I send bitcoins to that address. At this point the n, the m, and each individual pubkey are set in stone. I can not change the pubkeys out with other ones, I can not change the number of signs required... because the hash already has bitcoins sent to it...

the script that you are hashing has m, n, each pubkey, and the checkmultisig op code in it.

Just to clarify, what exactly do you want the video to show?

Taking the MPK and the encrypted seed and attempt passwords on it to check if the password is correct?

Is that it?

No, not by the encrypted seed alone.

First, understand what AES encryption does. It takes input data and jumbles it up into random looking data... When you test a password, the only way you can know if it's the right password is if you get back the original message.

Why does this matter?

With Electrum 1.x, the "message" being encrypted is 16 random bytes of information (the decoded seed)... so the only way to know whether you got the password correct or not is to do the following:

1. Decrypt with AES and your password attempt.
2. Hash the result with itself 100000 times.
3. Use that final hash as a private key and find the x and y values of the public key.
4. Compare the x and y values to your wallet's MPK (master public key) and if they are equal, then your passphrase was correct.

So as I have shown in step 4, you ALSO need the MPK (it should be 128 character hexidecimal (0-9A-F) string) of the wallet that contained that encrypted seed.

1.x wallets store the MPK as

If you would like to make a script that tests many passwords, you will first have to understand how to derive from the decoded seed to the master public key.

Clearing up misinformation that Mycelium finds it ok to spread. Their feature is not "spending from cold storage," it's *AT BEST* "spending from a paper wallet" which does not imply cold storage.
If I spend coins from a paper wallet and send the change back to the same paper wallet, it is no longer cold. As my pubkey is exposed on the blockchain, and my private key has been exposed to an online device. The exact antithesis of cold storage.

Sure, maybe you can understand the intricacies of what's going on and you can understand that your paper wallet is no longer cold at all, and you accept that risk, but someday, someone won't, and they'll lose bitcoins with "no one to blame but themselves" (the chant everyone begins when someone not understanding every single aspect of Bitcoin loses coins due to error)

To answer your question:

Mycelium has no feature to spend from a BIP32 HD wallet xprv, nor exists there any protocol for encrypting an xprv like BIP38 (which only encrypts single private keys in WIF format (Starting with 5 or K or L))

This will likely never happen, as there are way too many factors of an HD wallet that are not encoded into the xprv that are needed to recover coins (like which path was used, which gap limit was used, etc. BIP44 aims to create a standard for all of these factors, but adoption by wallet apps is weak at best.)

However, this is also not a good idea either, as swiping a BIP32 key and sending change back to it would do that same thing that swiping a paper wallet and sending change back to it; give a false sense of security, when in actuality your setup is the same as a normal hot wallet.

If you think it's a great idea, bring it up on the bitcoin-development mailing list and see if anyone agrees with you. They'll give you a BIP number and everything.