Freedom of speech only means no law is allowed that would prevent people from expressing their opinions (afaik, ianal).

No problems here, during the past 10 hours, I had only 0.77% stale/invalid shares.

It's possible in theory, but it would require scanning the whole blockchain for unspent transaction outputs addressed to that particular address. It would take a while, and I don't think it's implemented anywhere.

Which version of bitcoin are you using?

On 0.3.21, it should have done a rescan automatically.
Earlier versions will need to be started with the -rescan switch once.

0.3.21 contains a patch that makes the client monitor the network for transactions both from and to its own keys. In theory, you can share a wallet.dat file between two systems, but you need to be very careful. The wallet.dat file contains 100 future keys, but this does mean that if you do transactions from both nodes, they will start to diverge, and after 100 transactions, they will start using different keys. Also, if you have done a transaction from one node, unknown by the others, there is a chance that you will do a double spend, and have a wallet with invalid change transactions in it (possibly leading to more transactions that never get accepted).

Actually, I just realized, there is an even easier way. After decrypting the private key, use CKey::GetPubKey() to get its public key, and see if it matches the pubkey stored in the entry's key.

It seems you are using EVP_BytesToKey, which is used to derive a key and an IV, for each encryption and decryption separately (which is very inefficient), and thereby overriding the passed IV (which is pubkey-dependant).

My suggestion would be to call EVP_BytesToKey once, in SetKey(), and store the key in a field, and discard the generated IV, since we have a better way of determining the IV ourselves. Inside Encrypt and Decrypt, you would derive the IV from the pubkey, and use the stored key.

Also, you don't need to initialize both encoding and decoding contexts when doing only one of these.

In general, bitcoin transactions do not have a "from" address. A transaction could be originating from one or from many addresses, or even from none at all, theoretically. What blockexplorer shows you is just the address the previous output was sent to, but you shouldn't rely on this information.

If you want to distinguish transactions from eachother, the advised way is to use a separate to address for each. In the future, it may be possible to add a memo field to a transaction output as well, but this is still being discussed.

Also, 0.3.21 will automatically rescan the necessary part of the block chain if you'd replace wallet.dat with an older copy.

By the way, would you consider using the compact signatures I proposed some time ago (http://bitcointalk.org/index.php?topic=6430.0)? This would alleviate the need for separately showing and passing the public key around.

This means the interface could become:

$ bitcoin signmessage <address> <message>
$ bitcoin verifymessage <address> <signature> <message>

I don't think that experimental (though tested) recover-public-key code should be included immediately, until it is at least verified by someone who knows more about cryptography, and there is a reasonable use case. However, somehow I think this message-signing feature would benefit from more compact signatures, allowing a signature+pubkey in 65 bytes (130 in hex, 89 in base58).

Alternatively, the same interface would be possible when using a single base58-encoded string that contains both the pubkey and the signature. When using the standard encodings (as used by Bitcoin now), it would require 190 base58 characters to store both (72 bytes signature, 65 bytes pubkey, maybe one or two length marked bytes, when using bitcoin's internal serialization functions).

See a problem description here: http://bitcointalk.org/index.php?topic=5920.0

This basically boils down to: what when you (accidentally) have a double-spending transaction in your wallet. The result is a possibly corrupted wallet, with spendings that are not accepted by the network, and change that is possibly impossible to spend as well.

Currently, this is a small problem, in the sense that it requires quite some hackery with copying wallet.dat files aroung to actually experience the problem, but as soon as import and export of wallets is implemented, it may become a much larger issue.

The patch below will detect transactions in your wallet that conflict with the block chain, and mark them rejected in the UI. They will be ignored for balance calculation and coin selection.

Pull request is here: https://github.com/bitcoin/bitcoin/pull/195

Updated.

Rescan is for searching the block chain for transactions that are from or to one of your addresses. A 0-confirmation transaction is one that never made it into the block chain. This could be because it was never transmitted, because it was ignored by miners for a while, or because it conflicts somehow with other transactions. If deleting and redownloading the block chain does make a difference, there is something seriously wrong, and we have a bug to fix.

There are 2^160 addresses, not all characters in the base58 representation are significant, as it also contains a version number and an error detection code.

I think that the ability to do a preimage attack on sha256 in a reasonable time is more or less the most conclusive way for "sha256 is broken".

Your argument seems to be (if I understood our discussion on IRC correctly) that even a preimage attack on sha256 is not yet immediately a problem for bitcoin, as created blocks or transactions with a given hash still need a lot of structure.

I'm not a cryptographer but I don't think we need to protect ourselves against such an attack - by that time, we should already have switched to another hashing algorithm anyway.

I do agree however that we do need to protect against the ability to do a signature of arbitrary data using the sign/verify system proposed here. I like the suggestion of using ecdsa(hash(address + fixed_string + message)) or something similar.

Hello,

I've created a pull request that adds support for DNS lookups in -addnode and -connect, as I think it's a very useful feature.

Apparently it is considered a security issue by some (including satoshi, I've been told), so by default it is disabled, and the command line option -dns needs to be passed to enable it (as suggested by jgarzic)

See https://github.com/bitcoin/bitcoin/pull/192

The keys are stored using the standard OpenSSL encoding for ECDSA private keys, which actually includes a copy of the field parameters, curve parameters and the public key as well. 279 bytes per key, in total. A lot of these bytes are constant (as they are fixed for secp256k1), so you could look for those, and recover the 279 bytes around it, and use the bdb library to recreate a wallet.dat file with those keys in it.

PS: I'm working on a wallet export/import to human-readable files, but it may still take a while.

There are separate programs that are much better at this, they support pool mining and are more efficient. If he really wants to join the lottery, he can do so doing those too, but at least he won't be assuming that he'll make money if he lets his computer run for a few hours.

The only reasons i see for keeping a CPU miner in the main client, are:

• A reference implementation for educational purposes
• A very easy way to generate coins on testnet (but not very quickly)

I'm in favor of moving all CPU mining code to eventually having a separately distributed reference RPC miner, but meanwhile, the main client shouldn't carry optimization attempts - there is competition out there even between CPU-only miners, and they are better at it.

Is there anyone objecting to this?