This is a useful and simple last-resort solution, but it may be dangerous, as it also removes (valid) unconfirmed transactions and meta-data like source account information.

Translations are very welcome, but can you do them in a separate commit?

Any good reason not to merge this?

By the way, the "full rescan" I suggested/implemented does not remove transactions from the wallet, only adds/updates them, so it's not a solution for doood's problem.

Sorry, did it myself already. https://github.com/bitcoin/bitcoin/pull/255

If you're able to build from source and trust me, you can try https://github.com/sipa/bitcoin/tree/rejectedtx.

It will detect transactions that conflict with the block chain, and mark them inactive.

Make sure you have a backup of wallet.dat, though.

It won't. It will see the spend on the network, and add a corresponding spending transaction to the wallet, bringing the balance to 12 BTC.


If you do manage to spend the 20 BTC from B, without it having noticed the spend by A, you've indeed brought you wallet in a corrupted state, since it contains a transaction that conflicts with the block chain. It's possible to detect this conflict (I wrote a patch for that), but it's not yet merged in mainline bitcoin.

Exactly, DNS seeding differs from IRC seeding, since the addresses in it can be edited by the maintainer. But the P2P protocol exchanges IP addresses internally as well, so you could say that the node(s) whose address the DNS seed resolves to plays the role of what used to be the IRC server.

Maybe we could make a specialized/simplified P2P node that only tracks accessible addresses (not necessarily keeping addresses open), instances of which could populate the DNS seeds.

See the -dnsseed option. It uses DNS records that resolve to many IP addresses as seed.

-rescan was only introduced in 0.3.20, and 0.3.21 does rescans automatically when needed (though you still need -rescan when upgrading from an older version)

Also, the fact that it wants to start wine seems to imply you downloaded the windows version.

You're right. -rescan only adds missing transactions to the wallet. It doesn't update wallet transactions with missing information from the block chain.

Maybe we need a separate -rescan-full, or change the meaning of -rescan to do this anyway, as a regular rescan is now done immediately anyway?

Care to give a pointer?

Yes, here: https://github.com/bitcoin/bitcoin/pull/220

Just checking upon import is fine. I suppose the easiest way would be extracting the private parameters, reconstructing the full private key from that, and check whether that results in a structure identical to the one imported. The pull request above contains code in CKey for doing those.

I have written a patch that allows extraction and insertion of bitcoin private keys in a custom base58-based format, only containing the secret parameters itself, without the field and curve parameters.

Import and export of DER-encoded keys would also be useful (I have code for export laying around somewhere) for certain purposes though. You should check whether the imported key is a real bitcoin key though, as the public keys and signatures over the network do net encode the field and curve parameters, and would be invalid if the corresponding private key doesn't match.

I've got 00-24.

As they should - they're the one who need it.


It wasn't a serious suggestion, but just trying to find enforceable solutions to the presented problem. On the other hand, technically it's quite simple to implement actually. The difficulty would be getting the changed rule accepted by the network.

No that's not it. An account is almost entirely disconnected from addresses. Accounts are intended to group transactions together, and see their balance. They are in no way an indication for what address those credits are currently associated with.

While re-reading this thread, I realized something. I didn't read it completely, so it may already have been implied by others, though.

When I pay a transaction fee, I pay for a level of security, like explained by Mike. If I don't fear reversal of my transaction, I have little incentive for getting it in the blockchain. However, security here consists of several things:

• 1. Gettting your transaction included in the block chain
• 2. Getting the chain your transaction is in to be extended
• 3. Getting this chain to grow as fast as possible

Your fee goes to the one who puts your transaction in a block, so you pay for #1. However, you don't pay any reward to those who extend that chain. The miner who put your transaction is a block has all incentive to keep mining on this chain, since it gave him a reward that would be reverted by a split, but this is not true for other miners. So you only pay partly for #2. Finally, you don't pay for #3 at all - as explained here earlier, one possibility is that miners turn off their hardware if not enough fees are accumulated. However, every second that mining hardware is off, gives attackers one second's worth of catching up.

I feel that this is at least part of the problem: we only pay for inclusion in a block, not for getting it buried in the block chain. The cost for burying it is carried by all who want additional transactions processed.

I wonder if this could be solved by modifiying the fee system. A miner cannot take all fees for himself, only N% of it (for example, 5% of it). Miners are however allowed to also take the difference between the previous blocks' input+coinbase and outputs as additional fee. This causes the actual fee paid by someone issuing a transaction to be distributed in an exponentially decreasing way over the miners of the first many blocks to come.

Accounts as currently implemented are purely an accounting feature. Some addresses are linked to an account, in a way that that account is automatically credited when payment arrives to that address, but they are by no means a way for knowing which address holds what amount of coins. Change transactions are always sent to addresses not shown in the user interface, by the way.

This should not be necessary anymore since 0.3.21, since information about the current best chain is stored in wallet.dat, and a rescan of the unknown part is issued when this does not wallet the block chain database. If either the last version to write to wallet.dat, or the version to restore with is older, -rescan is needed.

A wallet dump is a JSON formatted file, with the following definition:


wallet_dump :: object {
  "keys" : list of key_entry  // the key information itself
  "loc" : locator             // information about the currently best known chain
}

key_entry :: object {
  "sec" : string              // private key in base58 format
  "addr" : string             // address in base58 format (verified on input, but ignored)
  "label" : string            // label for the address corresponding to this key
  "height" : int              // first block height this key is known to have been used in
  "heightAvail" : int         // first block height this key is known to have been used in
                              // with a not-yet redeemed transaction output to this key's address
  "value" : string            // decimal representation of total BTC sent to this key's address
  "valueAvail" : string       // decimal representation of available BTC sent to this key's
                              // address
  "tx" : tx_table             // list of transactions
  "reserve" : int             // nonzero if tx is a reserve key
}

tx_table :: object {
  string : tx_entry          // key is txid, or txid:outputid
  ...
}

tx_entry :: object {
  id : string                // txid in hex format
  height : int               // height of block this tx is known to be placed in
  value : string             // decimal representation of BTC sent to the address corresponding to
                             // parent key_entry's private key by this tx
  spent : bool               // whether or not this tx is known to be spent
}

locator :: object {
  string : int               // key is blockid, value is block height
  ...
}


The "addr", "heightAvail", "value", "valueAvail" and "spent" fields are not used when importing.
The "height", "tx" and "loc" fields are used to determining what to rescan.
Only "sec", "label" and "reserve" contain actual data that is imported.
Only 'sec" is really required.