I finally have this implemented, see https://github.com/sipa/bitcoin/tree/rejectedtx

Initial testing shows that it can detect such conflicts, and store/restore correctly in wallet.dat.

The GUI will show rejected transactions, the RPC interface will hide them.

It still needs a way for permanently removing rejected transactions (default after X confirmations of the conflicting tx?), and a way to query them from RPC.

Strange indeed, this shouldn't happen. And it definitely shouldn't remain after a rescan. Couple of questions though:
* which version of bitcoin are you using
* you say "since this wallet is the recipient", so you're using an address from the new wallet as destination for a tx from the old one?
* did you only move wallet.dat aside, or the whole datadir?

Patch is here: https://github.com/sipa/bitcoin/commit/6e223c405988a1002eeeee69db88a1128a38b0a3

I implemented this in bitcoin using openssl libraries. I tested it on existing signatures (converting them to the 65-byte "compact" signature format described above), and that signatures are always valid for their corresponding recovered public keys (even when recovering from random data).

I benchmarked both signature verification and key recovery. On my system, signature verification takes around 650us, key recovery takes around 685us, so there is a 5% CPU penalty. Note that signing does have a larger overhead (around 150%)

That guy was even the first to respond in this thread

+1

A system like bitcoin which is based on strong cryptography cannot afford not having a certificate accepted by most browsers.

Can you elaborate?

Gold can be traded physically without the buyer needing to trust anyone - he can verify it himself (though it would require some tools, like a weighing scale)

Bitcoins can be traded electronically without the buyer needing to trust anyone - he can verify it himself (though it would require some tools, like a full bitcoin client)

Gold can be traded electronically by using digital tokens representing ownership of a physical amount of gold, but it requires trust in the issuer of the token.

Bitcoins can be traded physically by using physical tokens representing ownership of an electronic amount of bitcoins, but it requires trust in the issuer of the token.

A suggestion: introduce an additional OP_GENPUBKEY, which pops a signature and a 2-bit number from the stack (which states which of the 4 possible generated keys is the right one), and pushes the generated public key (for this transaction and signature) itself onto the stack. From then on, it can be processed by the existing infrastructure, such as checking it against a known value, or first hashing it using OP_HASH160 before comparing it to an address.

A typical scriptPubKey for consuming a spend-to-address would then become:

  OP_GENPUBKEY OP_HASH160 <address> OP_EQUALVERIFY

With corresponding scriptSig:

  <signature> <generatedId>

If we drop the DER-encoding of the signature and just give the 2 256-bit numbers, prefixed with a version byte maybe, this is a 24-byte scriptPubKey, and a 67-byte scriptSig (compared to a 25-byte scriptPubKey and a 139-byte scriptSig now)

As suggested by [mike], we could go for an even smaller but slightly less flexible OP_CHECKSPEND, that does everything:

  <address> OP_CHECKSPEND

Which is only 22 bytes. We could do without the generatedId (allowing a 66-byte scriptSig) in this case, but at a potentially increased verification cost (2 to 4 possible pubkeys need to be verified).

The amount of energy spent per day in an economically viable way (that is, excluding people who willingly burn more energy than what it gains them), is limited to block_subsidy*block_per_day*USD_per_BTC/USD_per_kWh.

Currently, this means around 50 * 144 * 1.7 / 0.11 kWh per day, or 111MWh/day, or 4MW power consumption. That is (currently) less than an accelerating eurostar train.

Note that assuming the block subsidy (including fees) and power price remain equal, this only depends on the bitcoin exchange rate, which may go up to 70 USD/BTC before it is economically viable to burn the equivalent of an average Boeing 747.

Also note that this is an upper limit - as long as miners want some profit, the total power consumption needs to remain below this number.

Hello all,

I recently read in the sec pdf file (see http://www.secg.org/download/aid-780/sec1-v2.pdf, pages 47-48, section 4.1.6) that it is possible to recover the public key used in an ECDSA signature. After an IRC conversation, this was implemented and tested by roconnor, and it seems to be possible indeed.

Currently, bitcoin txin's for spend-to-address transactions use a DER-encoded signature + DER-encoded public key, resulting in 139-byte scripts. Assuming we drop the DER-encoding (except for a version byte), we could reduce this to 65 bytes.

If the reason is purely psychological, you could create something like an "indexed bitcoin", where the client simply multiplies all numbers with 1.02^((months_since_jan_2009)/12) or something like that. The underlying properties of the system are not changed, but still things like decreasing wages can be avoided.

The wallet does not contain the coins. It contains the keys to spend coins which are assigned to the corresponding addresses. The coins themselves, if such a thing exists, are kept by the network.

If you try to spend a coin twice, the network will only accept the first transaction to do so.

It adds RPC calls dumpprivkey and importprivkey.

I have a patch in my walletdump branch that can export and import private keys. It is still dangerous to do so, including a chance of corrupting your wallet if keys are used in several place at the same time.

See https://github.com/sipa/bitcoin/tree/walletdump

And there is another nonce inside the coinbase transaction, which is updated every time the nonce in the header overflows. Furthermore there is added entropy using the timestamp, and the public key of the miner.

Remove your previous obj/*.o files.

Also see http://bitcointalk.org/index.php?topic=423.msg3819#msg3819 and other ideas in that thread.

Maybe, but you'll need to be careful.

• If there was a problem with the inputs (already spent eg.), the correction tx won't be accepted either (and you definitely don't want a correction tx for a correction tx).
• If the problem was with the output (eg. non-standard script), a correction tx that does a simple spend-to-self may get you certainty, by seeing the correction tx end up in a block sooner than the original
• If the original tx never reached the network, a retransmit is the best thing to do, but a correction tx won't harm

So, implementation-wise, i suppose it should be a kind of spend-to-self tx, which is by default not assumed to be active, until it is seen in a block.