From github: "Although encryption of private keys in memory can be very useful on
desktop systems (as some small amount of protection against stupid viruses), on
an RPC server, the password is entered fairly insecurely.
Is this because the connection between client/app and the RPC server is in plaintext? Is there a forum discussion on the encrypted wallet implementation? It is because if someone manages to get access to a server's wallet.dat file, they are quite likely to be able to dump the passphrase from memory as well. |
|
|
|
Can anyone help a git and github newbie like me figure out how to get a diff from the pull request? Just pointing me towards relevant documentation would be fine... I'm just having trouble finding it. I'm using linux.
git clone git://github.com/bitcoin/bitcoin
cd bitcoin
git remote add sipa git://github.com/sipa/bitcoin
git fetch --all
git diff master..sipa/showwallet
|
|
|
|
Currently, it is difficult to import the private key into bitcoin. Sipa's showwallet branch has a new command called "importprivkey" that accepts the base-58 encoded private key. Vanitygen has been tested to work with that version of bitcoin, although it had to be restarted to get the imported vanity address to show up on the list in the GUI. I've just pushed a bugfix, and can't reproduce the problem now. Could you try again? PS: yes, it's quite normal your code is a lot faster - the vanity patch just tried generating random keys until a match was found, requiring generating 256 random bits + an EC multiplication per attempt. Your code only needs an EC addition per attempt. |
|
|
|
Will the new release update my current wallet in regards to C4 change?
The on-disk wallet format did not change, only the code to manage it did. |
|
|
|
|
The wallet.dat file has always been backward-compatible, and usually also forward-compatible. You should be able to install a new version without doing anything special. Always make sure you have a backup though.
|
|
|
|
|
If you just drop a few digits from the private keys, it's trivial to crack, as an exhaustive search will retrieve them easily from a leaked wallet.dat file.
If you drop a lot of digits from the private keys, it's not better than a passphrase-encrypted wallet (as will be supported by 0.4.0), and a whole lot less user-friendly.
|
|
|
|
|
blkidex.dat and blk0001.dat only contain the block chain.
If something happens to those files, you can regenerate them from the network itself. Just delete all files in your bitcoin directory except wallet.dat (make a backup though), and restart the client.
|
|
|
|
If I make a transaction on one computer will it update on the other?
Not automaticly, at least not yet. Yes it will, since 0.3.21. |
|
|
|
|
Since 0.3.23, -rescan will also update unconfirmed transactions already in your wallet.
If you haven't upgraded to 0.3.23, I'd suggest to do so, and try starting it with -rescan on the command line.
|
|
|
|
|
If there is one animal worthy of becoming a bitcoin mascot, it is the alpaca.
|
|
|
|
You can change everything.
This is not true. All prevouts must remain identical and none may be removed or added, for a transaction to be considered a new version of another. Input scripts may be changed, though. For outputs, you can change everything. |
|
|
|
FFS, don't gox your own derivation scheme...
We didn't. It uses OpenSSL's EVP_BytesToKey routine with a standard hash function. ... especially not one with a fixed difficulty ...
It's not, the number of iterations is stored in the file. The implementation will probably try to iterate for 0.1s, which gives already >100000 iterations on my system here. 25000 is just a minimum/default. ... especially one that the current miners can attack (low asymptotic hardware cost).
We specifically don't use SHA256 for that reason. The disk format has an "derivation method" field, which is currently always zero (meaning EVP+SHA512), but may in the future be extended to support other methods. This is done with the intention to support more derivation methods in the future, including scrypt, which looks really nice and aplicable here. I'm not sure scrypt is not "too young" to trust right now, though. You can find some of the discussion about the system here: http://forum.bitcoin.org/index.php?topic=8728.20Note that the resulting hash of the passphrase is never stored directly or indirectly, and the only thing encrypted with it is a random 256-bit AES key, so a rainbow-table attack is not possible. |
|
|
|
Great work. How computationally expensive is the algorithm that converts the passphrase to the key that decrypts the private keys? What I'm worried about is a trojan that captures the encrypted private keys and plaintext public keys (or hashes), and then knows how many BTC each wallet holds. He can then try to brute force the wallets with the most coins using compromised machines to do the brute forcing.
You can find some technical details here: https://github.com/TheBlueMatt/bitcoin/commit/9914f01fac25ff3891c3af8ac76c3ad5d6c3e9c6 |
|
|
|
To give a small update about the encryption system currently implemented and being tested for the bitcoin client: - Only private keys are encrypted, and you only need the private key to do transactions.
- The GUI currently only has one way for unlocking a wallet, namely by entering a passphrase. The disk format does support several independent passphrases, although adding a second one is currently not implemented. In the future, this may allow a "generate unlock code" wizard or something similar.
- There are almost no restrictions on what the passphrase can be, although the GUI will encourage you to choose a long one.
- Attempts are made to use mlock() and similar calls to prevent the memory pages containing passwords and encryption keys to leak to swap, but this is not in general possible (as it needs cooperation from openssl and graphic libraries).
|
|
|
|
You changed the code to vch.insert(vch.end(), vch.begin(), vch.end()); The secret "vchSecret" was never being used. Sorry, I must have been tired. Thanks for spotting the typo! |
|
|
|
|
So, 128 bits of nonce and 512 bits of signature, add another checksum and version byte, and we get 680 bits, or 117 base58 characters?
|
|
|
|
|
Private keys are 256 bit, public keys are 512 bit, signatures are 512 bits.
Encoded private keys are 279 bytes, encoded public keys are 65 bytes, encoded signatures are 72 bytes.
My showwallet branch has a patch that adds dumpprivkey and importprivkey commands, using base58 encoded private keys (only the actual 256 bit, plus 8 bits version number and 32 bits checksum), resulting in 51 characters.
|
|
|
|
"9. Reject if any other tx in the pool uses the same transaction output as one used by this tx, and has a greater or equal transaction fee"
+1. The "low/no fee" transaction should of course be dropped by miners when a high fee transactions comes in. I think this is the most elegant solution to the fee problem. In the general case, it is impossible to use the same outputs, as you may need more/different inputs to pay the fee, resulting in a different change, implying different outputs. It is not possible to detect which outputs are change, so you can't in general detect whether one transaction would be allowed to replace another one. |
|
|
|
|
Bitcoin counts blocks are 'worth' as much as the statically expected number of hashes that have been performed to generate it. As far as I can see, that's the theoretically best criterion possible.
|
|
|
|
What would it take to put in separate passwords for each wallet 'account'?
So that for multiple user systems each user can access their own account details and functionality without affecting or having access to others accounts.
And yes, with the ability to put in a 'master' password for global wallet access?
Yeah, that would be really great. For my online-wallet I'd also like the keys for each user to be encrypted separately. Would there be problems with bitcoin trying to use transactions from different accounts as inputs? What about change? Would it be difficult to modify the sending code to choose only inputs from the given account and also use a change address from this account? Has this been discussed already, or does it warrant a new thread? You essentially want separate wallets, which is a very useful feature, but not really what accounts are intended for. I think we should rather try to move to a general system where the client can open more than one wallet file at the same time, and provide built-in possibilities to move coins from one wallet to another. |
|
|
|
|
Show Posts
