Now for another piece of information: I run electrum from the console. I made a mistake during my initial use a couple of days ago: I cut and paste an address from the console and sent money to it, but it was one that Electrum had just a moment earlier decided to use for the "next change address" when I made a payment that moment earlier. This meant the receipt didn't show up properly in the Received tab as change addresses don't appear there. So I "was clever", and edited the wallet file, moving that address from the change address list to the address list, making it appear in the tab.
the software does not expect you to do this. this explains why your wallet's displayed balance is incorrect. |
|
|
|
- ecdsa.org is missing several transactions; all the other servers give a higher balance for my wallet, and it is ecdsa that is wrong. Is this your server?
you are right. thanks for reporting it. I am investigating it right now. |
|
|
|
So you just saying google predicted how many estimated titles their are? I can throw out a big number too (sarcasum)
So then the average user probubly have nothing to worry about as not many people to my knowledge have access to search against the google book database with bitcoin seeds and i doubt those who have the entire google book database will only attack those wallets with high amounts of value in it(which if this is the case i doubt someone/entity would use a sentence from a book and would instead use a randomly generated password that is like a million characters in length)
I am saying it is not safe to use a sentence from a book as your seed. Do not do that. Never. Anyone can access a digitized library, loop over all sentences, derive Bitcoin addresses from them, and check them against the Bitcoin database. It does not take a vast amount of resources, and time is on the side of the attacker. There is already an instance of Bitcoins that have been stolen because someone created an address derived from a short phrase (it was something like 'fuckyou' iirc). It only a matter of time until someone uses a large book database to feed their search algorithm. And, no, I was not throwing a big number. 130 million books is ridiculously small in terms of search. If we assume that each book contains on average 10000 sentences (a very generous estimate), we get around 10^15 sentences to test. In contrast, a random seed with 128 bits of entropy yield 3.4x10^38 combinations. Do you understand the difference between those numbers? Do not trust people who tell you that you can safely derive the seed yourself. Train your memory and learn a purely random seed. |
|
|
|
Not sure if it was discussed here or not,
but I think the easiest way to memorize your seed is to:
1) Pick up your favorite book
2) Remember the page number
3) Remember the number of the sentence from the top of the page
4) Compute md5 of that sentence and you got your seed!!!
So it comes down to remembering just two numbers and your favorite book instead of twelve random words.
this is not safe. An attacker can (and will) try all the sentences of the known litterature. That could be why is mentioned picking up your favorite book making the literature unknown(unless the attacker was there when you picked up the book to type in your sentence) |
|
|
|
Not sure if it was discussed here or not,
but I think the easiest way to memorize your seed is to:
1) Pick up your favorite book
2) Remember the page number
3) Remember the number of the sentence from the top of the page
4) Compute md5 of that sentence and you got your seed!!!
So it comes down to remembering just two numbers and your favorite book instead of twelve random words.
this is not safe. An attacker can (and will) try all the sentences of the known litterature. |
|
|
|
|
I'd like to know what Glenn exactly wears
|
|
|
|
|
I just released version 0.53
Changes:
- internationalisation.
Messages have been translated in 4 languages:
si :46/70
de :37/70
fr :45/70
vn :62/70
note: if you use the version from the git repo, run mki18n.py to generate the .mo files.
- The import of modules has changed a bit. It is now possible to run 'electrum' without having run the install script; this should make it easier for users trying to use Electrum on other platforms than Linux
- improved error messages
|
|
|
|
Trying to import some keys from an old wallet and all I get is "error". It is very likely it's just a duplicate key, but is there anyway to increase the debugging information?
yes, I just changed that |
|
|
|
Just curious, what's keeping this from working on a Mac?
I think you just need to have the right libraries installed. I run a Mac and after I installed the requisite libraries with macports, everything runs just fine. (I just installed the libraries listed as required for linux) Nice, perhaps the homepage could mention Mac support then? not as long as there is no easy to install solution for mac users |
|
|
|
I'm having trouble running Electrum on Windows -- anyone care to give some tips?
What I did:
-Installed Python 2.7
-Installed PyQt-Py2.7-x64-gpl-4.9.1-1
-Ran setup.py build. Seemed successful.
-Ran setup.py install. Got:
oh, the setup.py script has been designed for Linux; there is probably a way to adapt it for Windows, but I do not know how to do that |
|
|
|
Saw this featured hinted at in another thread...
How, exactly, does electrum monitor off-line address balances?
use 'deseed' if you want to watch an offline wallet if you want to monitor a random address, there's a script named watch_address |
|
|
|
... and I would guess we're now at somewhere around "5%" or so.
LOL |
|
|
|
Care to clarify on #4?
If it is just signed w/ hash of password well attacker can simply use the stored hash to sign any withdrawal as any user.
If it is signed by actual user password there is no way for the server to validate this as they don't have the actual password.
it is signed with a private key derived from the password (the private key is preferably derived on the client, so that the server never sees the password. in any case, the server does not store the private key) the server can validate because it stores the public key associated to the private key. |
|
|
|
|
the title of this thread remains true for today ;-)
|
|
|
|
|
Here is a set of rules designed to mitigate the effect of a server hack.
1. Cold storage. The amount of bitcoins stored on your public server (hot storage) should never exceed the capital owned by the exchange, so that if these Bitcoins are stolen the exchange can eat the loss without having to go fractional reserve.
2. To avoid breaking the above rule, Bitcoin deposits are sent directly to cold storage addresses. (for example, using deterministic generation and a master public key)
3. All transfers from cold storage to hot storage should be validated manually. For example, perform a bulk transfer every 24h, after checking that everything is normal on the server. I know that some intrusions might go unnoticed, but the most likely scenario is that an attacker would first steal the coins that are immediately available on the server, and this would not go unnoticed.
4. An attacker should not be able to disguise his theft as a set of withdrawals initiated by customers: withdrawals should be signed with a private key derived from the customer's password; during the daily manual check, compare [a hash of] the set of password-derived public keys in the server's database to [a hash of] the password-derived public keys in your database backup.
5. If the amount of withdrawal requests exceeds the amount available on the server (that is, the amount that the exchange can afford to lose), then users will have to _wait_ for the next manually validated transfer. What, waiting 24h for large withdrawals sucks? yeah, I know. That's life. As a customer, I prefer to know that my coins are safe.
6. Clone your database off server. An attacker gaining access to your server should not be able to delete your database backup.
7. Send digitally signed account statements to your customers on a regular basis. The key used to sign the statement should not reside on the public server.
Disclaimer 1:
I did not include any technical server security measures in this list (such as hashing & salting passwords, securing ports, controling access, etc)
This is because these rules are not about server security; they are about how to mitigate damage to your business should your server be compromised.
Disclaimer 2:
I have no experience running an exchange, therefore I might be wrong about what is possible and what is not. Please correct me and propose improvements.
|
|
|
|
Hmmm.
Now the volume is over 10700 btc.
Seems like a freak spike to me. Does anyone have actual insight on what is going on here? Seems strange that china - out of nowhere - becomes comparable to mtgox from one day to the next...
we don't know if this activity will remain sustained. and don't forget that mtgox's volume is relatively low today... |
|
|
|
your table has to make some sort of distinction btwn "server based" and "locally held clients".
i don't know Electrum as well as i should but i believe that the generation and encryption of deterministic wallets and the holding of private keys is on the client side. that is good. my only concern, which might be an invalid one, is that once private local keys are decrypted a malicious server could somehow upload the keys. someone correct me if i'm wrong.
i admittedly use and like Armory b/c of the offline tx signing which in my opinion is superior. again, correct me if i'm wrong.
I've put in a mention that Electrum relies on remote servers (which are open source as well). About the risk of a malicious server: the Stratum protocol doesn't allow for any executable code or scripts, so "uploading the keys" is impossible IMHO. The worst thing a malicious server could do, in theory, is lie about your balance. However, note that I'm not an expert in the Electrum technicalities, better ask ThomasV for an authoritative answer. Also Electrum DOES support offline transactions already, but only through the command-line at this time. Armory's GUI-based support for them is clearly more intuitive IMHO. you are right. There is no way a malicious Electrum server could steal your keys or passwords. The only malicious thing it can do is lie about your balance/history. There are 5 active servers at the moment, and they are identified by their domain name. As a user, you decide from which server you get that information, and you can also compare the answers of several servers if you have a doubt. Electrum does have offline signing and watching-only wallets. However, these functions require to use the command line. The command line options of Electrum are fairly comprehensive; they allow you to handle several wallets, and they give you full control on the transaction (choosing the change address, sending from an address) |
|
|
|
Yes that would help wouldn't it? Apologies for your waste your time to write all that, I'm usually better at question asking... Well mainly I just wanted to do a test send of 0.001 BTC & there is currently 0.1001 BTC ( http://blockexplorer.com/address/1oqzzEJKVyChXkgEWb6wkcWoWVPi9KsdN ) and the fee is currently set to the default have not touched it and in the code it seemed both of those payto and sendtx both relayed to sendtx function so i thought the issue might have been related. The reason there is a 0001 instead of a 0.001 is that was a copy error from the terminal. Both commands still give me the same errors previously posted above. Please, let me know if i left anything out. I cannot tell you what caused the first error; I would need to see the transaction. I guess it was not correctly written to your file concerning the second error: the default fee is a fee per tx input. the transaction you're trying to create has 2 inputs, so the fee would be 0.002 (unless you use the -f option). this explains the error. |
|
|
|
For some reason it thinks my balance is zero... ./electrum balance
Connected to electrum.bitcoins.sk:50001
0
~/electrum#
indeed, electrum.bitcoin.sk is having problems. you would see it with the gui ("server not ready") but the command line lacks a warning try with ecdsa.org |
|
|
|
I'm on angstrom still and when I followed the instructions found here: https://en.bitcoin.it/wiki/Electrum#How_to_send_a_transaction_with_an_offline_walletI get stuck at the sendtx command and get the following terminal output: (The file name is indeed called tx_file1 - not typo) :~/electrum# electrum sendtx `cat tx_file1`
Connected to electrum.bitcoins.sk:50001
Traceback (most recent call last):
File "/usr/bin/electrum", line 448, in <module>
r, h = wallet.sendtx( tx )
File "/usr/lib/python2.7/site-packages/electrum/wallet.py", line 813, in sendtx
tx_hash = Hash(tx.decode('hex') )[::-1].encode('hex')
File "/usr/lib/python2.7/encodings/hex_codec.py", line 42, in hex_decode
output = binascii.a2b_hex(input)
TypeError: Odd-length string
Thanks mate *Updated: I tried the payto command as well and got a different error electrum payto 17W7Hpno2CiD9Ma3YBrZfLaQrx61buFxXE 0001
Connected to electrum.bitcoins.sk:50001
Password:
Traceback (most recent call last):
File "/usr/bin/electrum", line 429, in <module>
fee = options.tx_fee, change_addr = change_addr, from_addr = from_addr )
File "/usr/lib/python2.7/site-packages/electrum/wallet.py", line 799, in mktx
raise BaseException("Not enough funds")
BaseException: Not enough funds
None
ok, can you first explain why you updated your first report with another one, completely different and seemingly unrelated? it might be that you solved the first problem and encountered another one, but if that is the case, it would be clearer to remove your first report completely. In the absence of information I can only make guesses as to whether your first problem is solved. Second, your 2nd traceback says "not enough funds". if you take the time to post this, I assume that it is because you think there is a bug here, and that it should have accepted the transaction. so, it would help me to know this: - did you notice the "not enough funds" message before you posted your bug report? - does your wallet actually have enough funds for the transaction? (1btc + fee) - is there a reason why you typed 0001 for the amount? looks like you mistyped a decimal point More generally, when posting a bug report, try to give comprehensive information about the situation. |
|
|
|
|
Show Posts
