jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 05:46:03 PM |
|
hey folks...
So i'm trying to send 1 BTC from a cold wallet following these instructions:
[Online PC] Go to the send tab and make a transaction. Instead of sending it, Electrum will detect a seedless wallet and query for a location to save the transaction. Select your USB-Key. [Offline PC] Go to Settings -> Import/Export -> "Load raw transaction". Select your transaction from the USB-Key. It will detect it's not signed and will prompt you to do so now. Fill in your password and sign the transaction. Save the new, signed, transaction to your USB-Key. [Online PC] Go to Settings -> Import/Export -> "Load raw transaction". Select the signed transaction and it will ask you if you want to broadcast it.
However, when I create the unsigned transaction for 1 BTC, I see 2 outputs, one for 1 BTC, and another for 40.003 BTC. Why is this happening?
I didnt send it yet, i dont want to send 40 coins!
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 05:48:50 PM |
|
Bitcoin works on the concept of inputs and output. The inputs of a tx reference the unspent outputs of a prior tx. You can't spend "part" of an output.
So if you have an unspent output (of a previous tx) with a value of 41.003 BTC then that becomes your input. If you want to "spend" 1 BTC, the only way to do so is to create a tx which has two ouputs, 1 BTC to the receiver and 40.003 BTC back to yourself. The address of the 40.003 BTC output should be an address in your wallet.
|
|
|
|
dabura667
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 05:52:54 PM |
|
To add to the above post:
The second address where the 40 BTC is going should be under the Change tab on your Receive menu.
Click the arrow next to "Change" and the first or second address that shows up should be the address the 40 BTC is trying to be sent to.
Edit: Here's my way of thinking about it.
Every transaction you receive is a single bill. Like in USD we have $1, $5, $10, $20... etc.. but in Bitcoin, your "bills" are the transactions you receive.
ie. if you receive 123 BTC in one transaction to your one address... you should have a sinlge 123BTC bill to use.
When you try to spend ANY money at all... you only have a 123BTC bill, so you have to make change. In America someone would give you back 4 $1 bills if you bought a 1 dollar thing with a $5 bill.
In bitcoin you have to send YOURSELF the change. so your client makes 2 outputs. 1 to your sender for the amount, and 1 to yourself for the remainder (change) minus the miner fee you chose.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 05:54:12 PM |
|
thanks guys... yeah i was aware of the input and output idea, but did NOT see the address on the my wallet, so i was quite weirded out...
expanding the change tab reveals that address now.
THANK YOU BOTH!
|
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 06:00:02 PM |
|
follow-up question:
The several different receiving addresses in the wallet all have their own inputs and outputs right? Will Electrum let me choose which address I want to create the transaction from?
Although I can choose which address to receive to, I don't see how to choose which one I want to send from. What am I missing?
|
|
|
|
dabura667
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 06:08:29 PM |
|
Right click on any address on the receive tab.
Click freeze
Now Electrum will not use any outputs on that address.
This can be utilized to control which outputs get used.
As far as using multiple inputs on the same address, electrum is currently first in first out.
You use them in the order you got them... not the most efficient way, but hopefully the logic will be fixed down the line.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 06:27:36 PM |
|
thanks again. very interesting. slowly but surely mastering electrum.
|
|
|
|
dabura667
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 06:33:03 PM |
|
It's nowhere close to 41 BTC, but my precious BTCs are in an offline electrum wallet. It's great to be able to send funds to it and manage public keys without having to worry about my seed being stolen.
Good luck!
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 06:41:50 PM |
|
ya its very cool. i still would like to more about this: https://bitcointalk.org/index.php?topic=516834.0perhaps i would need to dive into the source code to better understand how the electrum seed relates to the private keys. as an early adopter, I also think I should review the source code as well to ensure backdoors aren't placed into electrum (someone's gotta do that right?)
|
|
|
|
mr_burdell
Newbie
Offline
Activity: 20
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 19, 2014, 10:57:44 PM |
|
Another way to send from a certain address or addresses is to right click and "send from". You can do this by selecting multiple addresses at once and using "send from".
|
|
|
|
dabura667
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 04:21:07 AM |
|
ya its very cool. i still would like to more about this: https://bitcointalk.org/index.php?topic=516834.0perhaps i would need to dive into the source code to better understand how the electrum seed relates to the private keys. as an early adopter, I also think I should review the source code as well to ensure backdoors aren't placed into electrum (someone's gotta do that right?) Trust me, there are a lot of people who have verified the current build, and are religiously watching each commit to the master git. Also, if you open up /lib/account.py and start following from the module "get_private_key" under the class OldAccount, you'll find out how it works. Oh, and to get your mnemonic seed to the actual hexadecimal seed (the one used for "get_private_key") you use the mndecode module in /lib/mnemonic.py btw, there's a step that involves SHA256 hashing 100,000 times in a row (using a for loop) sooooo trying to verify it by hand is going to take a while. If you want to write your own script to verify it though, the above modules should point you in the right direction.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 04:47:53 AM |
|
Thx burdell.
Why do they hash 100,000 times?
|
|
|
|
dabura667
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 05:27:36 AM |
|
Why do they hash 100,000 times?
Because the person who made it decided it should be that way. I didn't make it, so I don't know... but I do know that BIP32 (the official Bitcoin Improvement Protocol that was created based on Electrum's method) hashes 200,000 times... so I guess they thought 100,000 wasn't enough? Maybe Thomas could ring in with the reason why it must be 100,000 times and not 2 times or 100 times.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 05:51:01 AM |
|
It is called key stretching. https://en.wikipedia.org/wiki/Key_stretchingMore iterations is better, it raises the cost of a brute force attack. The Bitcoin-Core wallet does something similar to provide brute force resistance for wallet passphrase.
|
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 06:00:55 AM |
|
It is called key stretching. https://en.wikipedia.org/wiki/Key_stretchingMore iterations is better, it raises the cost of a brute force attack. The Bitcoin-Core wallet does something similar to provide brute force resistance for wallet passphrase. So key stretching is part of bitcoin core....but then, why would it need to be part of electrum if an attacker was trying to brute force keys directly on the block chain? Or was developed first in electrum ?
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 07:27:59 AM |
|
In the past you could enter your own seed to create an electrum wallet. Since human beings are not very good at producing random numbers these human generated seeds afforded poor security. To alleviate that they introduced key stretching. There is a whole sticky about this here: https://bitcointalk.org/index.php?topic=153990.0Now most people are using the computer generated seed that electrum creates on startup. That has 128 bits of entropy. But the key stretching is still applied to it. There is this thread where people are saying that key stretching reduces entropy: https://bitcointalk.org/index.php?topic=330672.0Is the above correct? Is it a bad idea to use key stretching on computer generated random seeds?
|
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 01:28:48 PM |
|
In the past you could enter your own seed to create an electrum wallet. Since human beings are not very good at producing random numbers these human generated seeds afforded poor security. To alleviate that they introduced key stretching. There is a whole sticky about this here: https://bitcointalk.org/index.php?topic=153990.0Now most people are using the computer generated seed that electrum creates on startup. That has 128 bits of entropy. But the key stretching is still applied to it. There is this thread where people are saying that key stretching reduces entropy: https://bitcointalk.org/index.php?topic=330672.0Is the above correct? Is it a bad idea to use key stretching on computer generated random seeds? Wait, so simply brute forcing a priv key uses 256 bits, or 160 bits? Interesting thread the one you just posted. If true, we shouldn't be doing this way, but what is difference between key stretching electrum seed vs key stretching in bitcoin core. Both would lose entropy and have the convergence problem.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 03:58:44 PM |
|
256 bit ECDSA keys have 128 bits of key strength. It requires 2^128 operations to brute force the privKey from the PubKey. This assumes the PubKey is known. If it isn't the an attacker would need to attempt a hash collision against the PubKeyHash, looking for any privKey which produces the same PubKeyHash. That would require on average 2^160 operations. Yes the PubKeyHash is oversized. Bitcoin would have similar security (when PubKey is known) is the PubKeyHash was only 128 bits (i.e. RIPEMD-128 or XOR the left and right 128 bit sequence of SHA-256).
As for key stretching reducing entropy is depends on how it is implemented. I haven't looked at Electrum source code but PBKDF2 was created to remove the entropy loss associated with PBKDF1.
|
|
|
|
jonald_fyookball (OP)
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 04:27:46 PM |
|
256 bit ECDSA keys have 128 bits of key strength. It requires 2^128 operations to brute force the privKey from the PubKey. This assumes the PubKey is known. If it isn't the an attacker would need to attempt a hash collision against the PubKeyHash, looking for any privKey which produces the same PubKeyHash. That would require on average 2^160 operations. Yes the PubKeyHash is oversized. Bitcoin would have similar security (when PubKey is known) is the PubKeyHash was only 128 bits (i.e. RIPEMD-128 or XOR the left and right 128 bit sequence of SHA-256).
As for key stretching reducing entropy is depends on how it is implemented. I haven't looked at Electrum source code but PBKDF2 was created to remove the entropy loss associated with PBKDF1.
But each of those 2^128 (or 2^160) "operations" would actually be 100,000 rounds of hashing if I understand correctly. The electrum code appears to be doing a loop on the hash , but each iteration it is concatenating the output with the original seed. I don't know if this pbkdf2 (doesn't sound like it) but maybe that solves any entropy loss issue. Most probably it would, because on the last iteration you would still have all the entropy of the original seed, but you still have all those loops,to get through. Clever.
@classmethod def stretch_key(self,seed): oldseed = seed for i in range(100000): seed = hashlib.sha256(seed + oldseed).digest() return string_to_number( seed )
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 20, 2014, 05:38:31 PM Last edit: April 21, 2014, 01:30:42 AM by DeathAndTaxes |
|
It isn't standard PBKDF2 but it is injecting entropy back into the process. Generally I think it is a good idea to stick with standards but it doesn't appear to be broken. IIRC it is a good idea to also include the iteration count as part of the input for each round of the hash function, although I can't remember the rationale for that decision. But each of those 2^128 (or 2^160) "operations" would actually be 100,000 rounds of hashing if I understand correctly. Yup that is the whole point. Imagine you have a GPU rig (8 GPUs) which can hash 1 billion passwords per second. Using a key derivation function with 100,000 iterations chops that raw throughput to 10K passwords attempts per second. Another way to look at, is assume the attacker has sufficient hardware to brute force your single hashed password in 1 minute. The same password requiring 100K iterations would take take 100,000 minutes (or ~70 days). Usually in a key derivative function salt is also used to prevent a pre-computation attack, but as I understand it the seed in electrum is purely random thus not subject a a precomputation attack. If starting from a non-random source (i.e. Bitcoin QT wallet passphrase) a random salt should be used (it can be stored plaintext in the wallet).
|
|
|
|
|