See https://github.com/bitcoin/bitcoin/pull/3461 and https://github.com/bitcoin/bitcoin/pull/3088 for work on changing this.

For the statistics: I just got a corrupted DB with this (Windows 8.0, 64bit version). I might have shut it down forcefully at some point though.

No, don't worry. The money is not lost. The transaction is not confirmed, so basically it is not "executed" -- and the money is still where it was initially.

The problem is that the transaction has a very small output; 0.00000001 BTC which is about 0.0005 cents.

The support of blockchain.info should be able to help you.

What happens here is that the transactions are malleable.

Roughly speaking, when you send a transaction, it has some data in it which is not really relevant to the transaction. This data can be changed, and the same transaction looks slightly different.

This would not really be a problem, but the effect is that the changed transaction gets a new txid. The effect is what you observed: two transactions with different txid's which really have the same inputs and outputs.

Obviously someone is changing the transactions and broadcasting them again (for kicks, or whatever).

From what I understand, the main idea of the paper is the change of selecting the "valid" blockchain.

Currently, when a new block arrives, figuring out whether the current valid blockchain changes costs O(1) processing time: for each block you need to remember what the cost of the chain is until this block. Right now, in your scheme, I do not see a way to improve on Theta(depth) processing time for each block which comes in. Just wondering: do you see a better way to do this? I wouldn't be surprised if an O(log(depth)) data structure exists.

Why not ask in a geocaching forum? They are experts in creating treasure hunts.

This is so boring. We haven't had any real movement for hours.

The following is an improvement on the above idea; the description here is self contained.

• A new opcode is introduced. Instead of OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG this should give a new standard transaction, where OP_CHECKSIG is replaced with the new opcode
• There are two ways to empty an such an account. First, it is possible to create a transaction which empties it immediately, and distributes the money evenly to the miners of the next 100 blocks. Second, one can withdraw it to a normal account, but that will take 10 blocks (i.e., think of it this way: a normal withdrawal needs to be announced 10 blocks before it can be executed).
• If a transaction of the first kind (distributing to the miner) is in a block which is at most 9 blocks later than a transaction of the second kind, the transaction distributing is valid, and the other transaction becomes a NOP.
  

Now, suppose I want to spend 1 bitcoin from account A without waiting for confirmations. I have 100 bitcoins on an account with the new opcode. I will give the vendor a transaction which of the second kind, which I manufactor that it becomes only valid if one can find a double spend of A.

If I now want to double spend A, I will lose 100 BTC to the miners.

I would guess that major miners already are, or will, at some point, communicate directly among each other. After all, you don't want to miss a block.

It is not clear to me if one could not have a convention to under which miners might ignore certain blocks though.

I agree there is work need, but it is clear that there is a way of doing an extension which does what I want: simply introduce an opcode which does exactly what you want (i.e., don't even run the scripts; instead, check whether they have exactly the form required, and if so accept everything). Of course, this would be a bad way of doing it.

I think the main question here is: how can one make the scripting language flexible enough to allow this kind of mechanism?

Whichever is mined. Note that the miner will probably take the one giving him more fee.

I agree that there is work needed there. It is, however, clear that one could in principle add an instruction to the scripting language which does exactly this. However, this would not be a good solution, and so work is needed to make the approach practical.

No, that's no problem: usually miners will not do this as they can earn more by using Tx3 (or else, the guy who double spends still pays the miner a lot of fees).

Do nodes currently not transmit tx's which are double spends, i.e., only keep the first one?

Yes, I am aware of that. My solution is only useful if you don't work with a miner which is very powerful (e.g., I wouldn't know how to do that).

Note also that in my solution, the miner makes much more money if he does not help the guy who double spends.

OK, I'll try.

Buyer B wants to buy an item with value 0.1 BTC from Merchant M. B has 20.4 BTC in total. These are stored in two transactions outputs B0, B1, both of the buyer.

B0: Transaction Output with 0.4 BTC, private key known to B
B1: Transaction Output with 20 BTC, private key known to B

Now, to buy the item, the buyer sends two transactions Tx2 and Tx3 to the merchant.  The merchant has address <addrM>

Tx2:
  Input B0
  Outputs
    1: 0.1 BTC to <addrM>
    2: 0.3 BTC to <addrB> (another address of B)

Tx3:
  Input B1
  Outputs:
    1: 0.1 BTC to <addrM>
    2: 9.9 BTC to <addrB>
       *only valid with two spends of B0*
 
the transaction Tx3 is special (this would need an extension of the scripting language). In order to use it, one needs to provide two *different* spendings of B0.

The merchant M gets both these transactions, waits 10 seconds, and then gives the item to B. If later another transaction of B0 shows up before transaction Tx2 is in a block, he can broadcast Tx3; and it will be worthwile for a miner to use it (note that it has 10BTC fee included).

The idea is as follows: to pay 1 BTC to V, you need to have an additional 10 BTC on a second address (like a deposit).

You then give V a normal transaction T1, and a second transaction T2. In case T1 is a double spend, V can use T2 to make 10 BTC go to the miner.

In the example you quoted, TX3Out needs to have at least 10.2 BTC in them (which are also owned by the person who wants to pay V).

Does that make the idea clear?

You can try that. But you risk losing 2 BTC to a miner who mines greedily, for a gain of just 0.1 BTC.

I don't see how why my proposed solution above doesn't work, and also why it should render the blockchain obsolete.

Maybe I wasn't clear enough; let me try again.

Say I am a customer, and want to buy a product from V for 0.1 BTC, double spend safe. I need to have *two* confirmed transaction for this purpose. Say I know the private keys for TX0out, which has 1 BTC, and for TX1out which has 3 BTC out. Both are deep in the block chain.

I will give a usual transaction to V which pays him 0.1 BTC, giving me 0.9 BTC change. But additionally I give him a transaction which says: "If you find two valid signatures for TX0out, this transaction gives the miner 2 BTC from TX1out, and 0.1 BTC to V".

Anyone care to explain to me why this would not work?

I suggested something similar (way later) here: https://bitcointalk.org/index.php?topic=196136

In fact, I think a reasonable solution could be implemented by adding a *single* instruction to the script language: suppose you have "OP_CHECKSIG_VAL val sig pub_key" which checks if sig is a valid signature of val under pub_key. Then you can create e.g. two transactions as follows:

• TX1: Take 1 BTC from TX0out, give 0.2 BTC to Addr1, 0.8 BTC to Addr2
• TX2: If you find a double spend of TX0out, give 0.2 from TX3Out to Addr1 and a fee of 10BTC to the miner

The buyer gives both transactions to a vendor who owns Addr1 who additionally checks that TX3Out really has 10.2 bitcoins and is still open. If at some point the vendor gets a double spend he can plug in the values into TX2 so that it becomes valid. Miners will be happy to mine a transaction with a 10BTC fee.

The suggestion in https://bitcointalk.org/index.php?topic=196136 is somewhat nicer because it increases the chance the vendor gets his money, but more complicated.

I wasn't thinking too much about alt coins: the idea was that currently we're telling people they cannot use bitcoins for immediate transactions, and I just wondered whether anything can be done about that.


I think we should keep in mind that if double spending becomes an actual problem one might do something about it. An alternative coin for studying it would be interesting, but I personally don't plan to implement one now.

By "users" I simply mean people who use the system. While you cannot know what user knows what address, and not every address maps to a single user, nevertheless there are people using it.


The old transactions would still be there, there would just be one more transaction type.

Essentially, the idea allows you to say: "I promise not to double spend the input of this transaction. If you catch me doing it, please pay this large fee to the miner."

Dear All,

I was thinking about an approach to prevent double spending, and I
think I found approach which I wondered about.  The approach assumes
that the miners are not trying to double spend. Nevertheless, I think
the approach makes double spending attacks much harder.

I want to set up a system with one goal in mind: If a user tries to
double spend, then *both* transaction will land in the blockchain in a
special way, which makes the user lose money. As a side goal: the
vendor should get his money even if the user tries to double spend.

More concretely, one could do this as follows: one would allow a new
transaction format, in which each outgoing address gets two amounts; a
"normal amount", and a "double spending amount". Such a transaction
would be considered valid only under two conditions: (1) there are
exactly two outgoing addresses, (2) the fee implied by the "double
spending amounts" is *more* than two times the fee implied by the
normal amounts.  A miner can then include a transaction T in this new
format in two different ways into a block.

  (A) Like a normal transaction, in which case the transaction is
      processed as normal; the amounts will be the "normal amount"s.

  (B) As a special "double spent transaction". In order to do this,
      the miner has to include another transaction T', which is not
      executed, but only serves as a proof that the creator of the
      transaction tried to double spend the money. Transaction T must
      be a transaction of the above kind here, but T' can be any
      transaction.

      In such a case, the transactions in T are executed with the
      "double spending amount". If there is money remaining, then it
      is split in 2 equal parts (up to some fixed rounding). Half goes
      to the miner, half goes to the address containing the *smallest*
      output in "normal amount" in T'. We will see in a moment why.

Suppose now a vendor V with address <V> wants to accept bitcoins from
a buyer B with address <B>. Suppose B wants to pay "val" to V, and add
transaction fee "fee". Given a transaction, the vendor will watch the
network for a few seconds, and check for double spendings.  Then, the
vendor accepts transaction T if it looks as follows:

(1) An incoming amount of I, I >= 3*val + 3*fee
(2) Two outgoing adresses; one is <V>, and another one, call it <B'>.
    There are no other outgoing addresses or entries.
(3) The "normal amount" and the "double spending amount" to <V> are
    exactly equal to val.
(4) The "normal amount" to <B'> is strictly bigger than val
(5) The "double spending amount" to <B'> is at most I - 3*val - 2*fee

In case a miner sees an attempt at double spending, he is supposed to
do the following.  First, pick the transaction Tmax with highest fee
in the double spending values. Second, take as a proof of double
spending the first alternative transaction Tfirst seen. Then, publish
these two transactions, Tmax with proof Tfirst. Note that the system
is set up such that this gives the miner the maximum profit.

Suppose now that V accepts transaction T which a user tried to double
spend, creating transactions T, T1, T2,... I claim that if transaction T
was the first one sawn by the miner, then V gets the money.

(A) Transaction T is processed as normal
(B) Transaction Ti is processed as normal
(C) Transaction T is a double spent transaction, Ti its proof
(D) Transaction Ti is a double spent transaction, T its proof

In case the miner uses (A), he gets fee. In case he uses (C), he gets
at least val+fee, because the difference between the left over part in
the double spending amounts of T is at least 2*val+2*fee.
Thus, we can assume that he uses (B) or (D) only if he gets also at
least 2*val+2*fee. Since (D) is always more valuable to the miner than
(B) -- otherwise the transaction Ti isn't valid -- he will use (A),
(D), or (C), in which case V gets his money.

There is another case: Ti could be a transaction in old style
format. In this case, the miner cannot use (D). So it might be
advantageous for the miner to use (B), and V will not get his money --
however, B still spends at least val+fee in fees, so this should not
happen too often (the vendor might want to increase the gap in T
somewhat so that B spends even more).

There would still be the issue what to do when some miners try to help
double spending; this isn't trivial and might be a real problem, but
still I think the system would be an improvement already: right now, a
double spending attack is something I can run on my own, however, I
don't have the computational power to do serious mining -- and
besides, if I did I wouldn't try to cheat vendors for US$20. Also,
maybe one can do something about that.

tl;dr Why not make transactions which have two values for each outgoing address, where the second one can only be used if the user tried to double spend?

Just be alert! Nobody knows what changes bitcoin how.