Typically a tag is used as a way of advertizing compatibility with a particular feature. It's not meaningful to add it without also implementing the necessary logic changes.

It has nothing to do with that IP. There is no negotiation over this. All depends on how old and how large the coins you're using are.

As an anti-spam solution, many nodes in the network have rules that will limit or deny relaying free transactions under certain (rare) conditions. In particular very small amounts that were receive recently are likely to trigger this anti-spam mechanism.

When the client believes your transaction will cause this mechanism, it automatically includes a minimum fee (0.0005). If you use the GUI, it will ask you for confirmation first.

The 279-byte pattern for private keys is not used when the wallet is encrypted, so that could cause the problem. However, you would still expect to find certain strings inside...

I mailed about it to the -dev mailing list, without much response though.


Yes and no. The same private key now corresponds to two different pubkey/address pairs. Which one is used is determined at generation time. Since the wallet stores both pubkey and private key, the length of the pubkey is used to determined which pair is intended.


Good point. It will probably work, but the compressed pubkeys will be considered non-compressed ones by older versions, so they will probably miss transactions. Over time, the ledger seen by older clients and newer clients may diverge. I'll try to fix this before 0.6.0 final is released.


Sending from and to old and new addresses has been tested, and between old and new clients. As mentioned, I didn't test downgrading.


All testing is welcome, of course...

The "lastseen" value of the nodes your client knows about is 65000 hours in the future. My guess is that your system clock is set to somewhere in 2005.

Still, the client should warn you about this instead of having this erratic behavior.

Remember that miners are those who decide what makes it into the block chain, and are paid for it.

For everyone else, the size of the block chain is just a cost they are or are not willing to carry.

I'm not sure whether encouraging miners to put advertisements in the block chain is a good idea.

Your passphrase is strengthened and converted to a 256-bit key and IV using OpenSSL's EVP routines, using SHA512.

The wallet contains an "mkey" record, which contains a 256-bit randomly generated master key, encrypted using AES-256-CBC using the above key and IV.

Key entries in the wallet ("ckey") are a mapping from the pubkey to the AES-256-CBC encrypted 32-byte EC secret, using the master key as key, and the hash of the pubkey as IV.

Version 0.6 of the Satoshi client will have the exportprivkey RPC call, which can be used to extract the private key corresponding to an address. This should allow you to import it, but it requires probably too much manual work to retrieve all keys one by one. Also, you'd need to scan all transactions in the wallet to find out where they were first used.

Additionally, my showwallet branch allows exporting the entire wallet (organised in information per key, and optionally which blocks and/or transactions they were used in, in a human-readable JSON file format. It still needs a bit of work, but I hope to get this merged soon as well.

Finally, note that I recently sent a mail to the bitcoin-development mailing list about an extension to the base58 private key format to indicate compressed public key addresses, which will also be used as of the 0.6 release.

If one could obtain a private key from an address, Bitcoin and all public-key-cryptography was doomed.

The process is:

   private key  ->  public key  ->   address

Both arrows are irreversible.

That said, bitcoin 0.6 will have an RPC call by which you can ask bitcoin the private key corresponding to a given address, given that it is your own.

I commented on OP_NO_SKIP here: https://en.bitcoin.it/wiki/Talk:BIP_0017_DRAFT

This is correct, at least as long as the wallet is not locked.

If your wallet is encrypted, and not unlocked by the user (by providing the passphrase), any new key retrieved from the key pool will cause the generation of a fresh one.

I think you have a point. The current client hides many things from the user, which is probably a good thing for many people, but the fast that it hides the wallet concept completely creates confusion.

It does. You do need to unlock the wallet via RPC first though, via walletpassphrase().

Did you unlock your wallet? (walletpassphrase RPC command)

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

Explain?

Interesting, never knew about that variable!

Bitcoin does not track balances of addresses. It reasons in terms of "coins" (unredeemed transaction outputs), that are explicitly referenced when consumed.

Not true, you don't need a rescan to find an arbitrary transaction, if you have the block chain database. It's just not implemented.