If *anyone* forks off an older part of the block chain, to erase your precious transactions, the whole bitcoin community will notice. Many things can happens surrounding the block chain and the bitcoin's value, but it won't go unnoticed. Furthermore, even if that would happen, and allowed to pass, your own transaction that credited your offline address isn't necessarily invalid.

You're not rescanning - you're just redownloading the block chain. It will take a while, but don't worry.

Next time, leave blk0001.dat and blkindex.dat in place - since 0.3.21 that should work fine.

Of course it is. That's not what I meant. What you are doing is useful, but it does not have the same security guarantees. Right now, through hardcoded block hashes in the client, the maintainer has the ability to force a particular chain onto you, but that chain must still exist and be valid. If the hash of the entire block file is hardcoded in the client, the maintainer can effectively make you get an invalid block database.

It stores some hashes of blocks in the current tip of the block chain in the wallet file. On startup, the latest common ancestor of the block chain database and the wallet file is searched for, and a rescan starting at that point is performed.

I believe this was added in 0.3.21 or 0.3.22.

It is very unlikely that -rescan helped - all recent versions of bitcoin do rescanning automatically when necessary.

My guess is that you switched to the second wallet before the transaction from the first wallet made its way into the block chain. When switching back, it resubmitted, and the second wallet got it.

Assuming QC "suddenly" appears, and ECDSA is instantaneously crackable using Shor's algorithm, and SHA256/RIPEMD160 become vulnerable to Grover's algorithm:

• Every unspent coin, sent to an address whose pubkey is not yet revealed, is somewhat safe (80 bit security left, instead of 160 bit)
• The block chain is quite safe (128 bit security left, instead of 256 bit)
• Transactions to new quantum-computing-based addresses with corresponding keys, are safe
• ... only unspent coins sent to reused addresses will be trivially claimable by any attacker (a few bits of security left, instead of 128 bit)

This sounds like the wrong way to go for me.

If there is a need for transaction identifiers beyond using a different address per usage, we should move to OP_DROP id's in transaction scripts or something similar, instead of hacking it inside the amount field.

-rescan does not revalidate the block chain. It only synchronizes the block chain with the wallet, adding missing transactions to it.

And indeed, most of the time is spent validating the block chain, not downloading. Before 0.3.24, larger blocks often caused disconnects when sending because of an anti-spam measure. That is/was also a cause of delay when starting up, but is slowly improving, as more nodes (and thus potential download partners) upgrade to 0.3.24.

That said, a -fastboot argument that takes a URL or filename to import a blockchain from may be useful in certain situations.

Right, of course. I just generalized things a bit.

If you're talking about private keys, the distiction remains: either you want to export/import what is in an already encrypted wallet (useful for backup), or you want to do encryption separately. The intent here seems to be the second case, which is fine. It just means you'll need to both the wallet passphrase and the key password ready if you want to import.

Also, considering the used version byte, could you follow this thread? I'd say encrypted privkeys form a new data class.

I'm not sure what your use case is here. Encrypted dumps of the wallet are obviously useful, but I think they come in two categories:

1) combined with encrypted wallet, just a dump of the encrypted keys therein. This would allow you to export and import dumps without providing a password. I believe this is the safest option, but it would be inherently implementation-specific (the encryption inside bitcoin, as planned for 0.4.0, uses EVP-SHA512 keys derived from a password, used to encrypt a 256-bit master key using AES256-CBC, the wallet keys themselves are encrypted using this master key using AES256-CBC, with the hash of their pubkey as IV).

2) a portable format for exchanging wallets (hopefully between several applications). if the encryption is independent from that of the wallet storage itself, that means exporting requires knowledge of the wallet passphrase + another key to encrypt the dump with. Although there is definitely merit in doing this inside bitcoin itself, i don't think there is anything better than doing a normal wallet dump + GPG/OpenSSL/... encrypting it.

It is possible - i implemented a proof of concept for this some months ago (seemy rejectedtx branch on github, pull 195). It marks wallet transactions which depend on inputs spent by other transactions that are in the blockchain as inactive.

It takes more time to get it in a mergable condition though...

There is no need to put these in the block chain.

As the exchange is inherently centralized, you lose nothing by publishing the exchange rate data through http or whatever out-of-p2p protocol, possibly mirrored by those who find it interesting enough, if you care about availability.

The data itself can still be signed by a private key held by MtGox, whose address is publically known.

If it were to reuse addresses for change, it would be trivial to find out which of both outputs is change and which is payment.

And a new reserve address is generated each time one is used.

It's far from optimal, but we need some measure to prevent sybil attacks. The problem is the diversity of the IPv6 network... in some ranges the user-specific part is below /48, in others it is below /16.


Such nodes will still get IPv4 nodes from IRC, and connect to those. It will also advertize its own IPv6 address on the network, which will hopefully propagate that address (current clients don't). Eventually, its address will hopefully end up in DNS seeds, where it can be found by all IPv6-capable nodes.

That's a reason for wanting the whole world to decrease their mining income, but those who do will only be screwing themselves.

Yes, that is possible, and the block will be accepted.

They're lost forever.

No.

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

General changes (even when IPv6 support is not compiled in):

• Valid, routable IPv6 addresses are stored and forwarded
• Name lookups are done using the general getaddrinfo() call
• The detection system for the local address is improved. (addresses are classified according to their 'reachability', and the most reachable local address encountered is used).
• The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
  • IPv4 addresses are grouped in /16 blocks
  • IPv6 addresses are grouped in /32 blocks
  • Tunneled IPv6 addresses use the encapsulated IPv4 address (teredo, 6to4, SIIT, well-known prefix)
• Hostnames can be given using the "[host]:port" format.
• Support for the "checkorder" message was removed (obsolete, and not worth porting)

Behaviour changes when IPv6 support is enabled:

• DNS lookups also return IPv6 matches
• The listening socket is bound to the IPv6 ANY address (::/128) instead of the IPv4 ANY address (0.0.0.0)
• Connections to non-IPv4 addresses are attempted, using IPv6 sockets (connections to IPv4 addresses still use IPv4 sockets)
• A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).

For internal changes, see the commit message.

Maybe you could follow this idea: http://forum.bitcoin.org/index.php?topic=8773.0

In short: allow anyone to publish an time-dependent exchange rate to another currency through https, and map changes in the exchange rate to virtual "interest" transactions in the client view.

I believed the bug reported here was already fixed, but this thread made me suspicious.

It seems it was indeed fixed here, but lost in a code reorganization somewhat later (here).

My apologies to those who have lost coins - the issue will be fixed in the next release.

It seems there was a bug: keys were not removed from disk, so re-adding them failed. This should be fixed now - could you test again?


Well, removing addresses from accounts is just not supported yet. It may cause inccorrect account balances, but not invalid total balances