I don't see how this would be possible.

We are never confiscating the money from the seller.
See, all transactions from untrusted addresses (non-green ones) always have to have block confirmations before they are properly registered by the seller. This is actually the whole and the only point of waiting for these block confirmations: to prevent double-spends.

If a transaction has been confirmed by a number of blocks, there can no longer be any working double spends.

A double spend is when there are two transactions in the network having the same input, each in a different part of the network. Once a block is generated, it spreads around the network, to all the nodes, and at that point no double spends can exist, because a block cannot be valid and have 2 transactions with the same input. At this point, if there ever were 2 such transactions, the one that got included in the block is considered valid, and the other one will be deleted by all of the nodes, because they will see that it uses an input which is now (after this last block) is invalid (already used).

Also note that this can be a little more complicated if two blocks are generated almost immediately, or the chain is split, but those difficulties are always ruled out by the network in the end.

Penalizing double-spends would mean to only penalize multiple transactions with the same input IF they are not too long apart. We would have to choose a number of blocks, after generating which a transactions with the same input would not be penalized anymore, but instead forfeited just like it is today.

no shit What TS is proposing implies a change to the protocol and clients of course.

unabridged, a great idea overall! The only problem as I see it is that it does involve modifying the protocol, and as such, will require ALL of the network to be onboard with it. Not that anybody would ever loose anything, but change is hard, especially, when any actual practical advantage of implementing it is questionable. (The network would become more safe, no doubt about it, but as RaggedMonk correctly noticed, double spends are not any real problem at the moment either.)

Just a small correction: it seems that you are not aware of a little detail of the protocol: as described in https://en.bitcoin.it/wiki/Transactions#Output an output can only ever be used once. If it is used twice, that is already considered a double spend, even if the number of bitcoins combined is indeed less or equal to the source output value.

What do you mean by "passed back out"?
To me it seems like a pretty reasonable thing to do is to just let the miner have all of it. However, this is where we could do things differently: either just let the miner have the output of that transaction, or let him have all of the previous transactions with outputs to this address, effectively setting a hypothetical "balance" of the address to zero. (Not that "balances" really exist in the protocol.) I mean, we already know that the owner if this address is an attacker, why not take everything from this address, not only the faulty transaction?

Upd: Also we have to figure out what to do if a transaction has multiple inputs, and only one of them is a double-spend. Confiscate everything from this tx? Or just the amount from the double-spended input?

What is the reasoning behind this? How would the coins be passed back to the attacker?

Sure, exactly my thinking, with setting a block count limit. Except for the "pass back out" thing again, what is that?

Just a small note: this feature would never hurt any honest user, because in no conceivable circumstance does an honest user send two transactions with the same input. And nobody else could, because they would have that addresses' private key, which if they had, they could simply steal the bitcoins anyway.
I guess a problem could hypothetically arise if there ever was some kind of error in the bitcoin client, which would broadcast a transaction into the network, and then crash, and after being started again would not see the transaction for some reason and the user would pay again really fast, but that is very unlikely. Transactions are not broadcasted at the same time as you click on the button, the client waits random time, plus that when you reconnect, in most cases you do receive your own transaction back from the network, either directly or inside a block, even if the program crash would not save it in the database directly. All in all, this is near to non-possible.

This is a kind of feature that should have been in the original satoshi client, it is only logical to have it. However, to implement it now, is still questionable, due to the things I talked about earlier.

unabridged, perhaps you should design this out more formally and submit as a BIP?

Block confirmations are right now used for preventing double-spending and having multiple confirmations of a transaction is considered just the "proof" that there is not double-spending. I say "proof", because they cannot actually prove anything, but they provide a plausible technical probability that there is no double-spend, and this is the reason there is no "universal" count after which a transaction is confirmed, even if most merchants use 6 I believe.

See 51precent attack as a form of "longer" chain split which I referred to. That is not a general case, and a 51 perecent attack is supposed to never happen, which is ensured (once again, probability based) by the mining and the humongous amounts of hashing power that leads to. (Although centralization of that power by the pools can become a problem).

To be more concise,
If a transaction is "confirmed", no matter the number of blocks we decide on that defines "confirmed", it must exist at least in one block.
And two transactions with the same input cannot exist in one single block. (Other nodes will not consider that block valid.)

If you need a source for this, check this out https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power
Notice how "include multiple transactions with the same input" is not in that list. Double-spending in the 51percent sense involves spending an input once, and then reversing that block (generating a longer chain of other blocks), with that same input being used somewhere else.

As for the Finney attack, if that is what is described here https://bt.irlbtc.com/view/3441.msg48384#msg48384 , the scheme proposed here would actually penalize the attacker in that case. (The seller would not get his money back either though.) However it involves accepting 0-confirmation transactions, which is of course unsecure, but we were talking about confirmed transactions.

So basically there are two forms of this attack that can be done:
1) an attacker just sends out two transactions, hoping that the seller will accept it before it is included in the block chain, or that the block chain is split somehow by dividing the network.
2) an attacker has 51% percent and doing this.
I think in both cases we should penalize in the same way, but it seems like in the second case, the system will probably not be able to do it at all. When having that power, attacker can reverse entire blocks and thus removing the faulty transactions from history.
On the other hand, if the attack does not take too much time, even when the blocks are reversed, maybe other nodes will have the old transaction anyways, and will rebroadcast them as well? This would make the penalty mechanism still work. But also, can't this harm honest users?
Because if I pay to someone using output X, and then next block a 51percent attack happens, and 5 blocks are reversed, my transaction is reversed as well. What happens now? Does my client just resend the transaction again, is it saved in its own database even after it was included in some blocks? If yes, that will be ok, but if no, I will probably use the same output again, to pay to the seller again, using output X again. This could make my 2 payments look to the network like it is a double spending attempt. (If they have saved my old transaction somewhere and rebroadcasted it to the network again after the block reversion.)

I see, this is the reasoning behind the spreading of paying back penalties. Makes sense.


Anyway, if how I described number 2) here is technically correct, it seems that the fact that this penalty will work on transactions attacked by a real 51% percent attack depends on this particular behavior of the current client (which may or may not be already there) (I don't think it's there, but don't have exact knowledge):

---
Even when a transaction (no matter, own or foreign) is included in the block, the client still keeps it in its own "buffer" for some time (a certain decided number of blocks), and if there is a reorg (a longer block chain is visible in the network, and some of the old blocks are thrown away), client is still rebroadcasting those saved-in-a-buffer transactions back to the network, even if they do not exist in this new block chain.
---
(This is an important point, if you don't see my thinking here or it is faulty, please let's discuss this explicitly.)

Like I said, I don't think it is yet implemented, but I also think it should be!
Because if the client was functioning like this, it would still not hurt any honest user, and if the number of blocks for this saving was high enough, it would make even a 51% attack ineffective! (Unless the attacker has that much resources for REALLY long time.) This does require the penalty mechanism in place, otherwise the rebroadcasted transaction will be just thrown away, as using an already used input.
When the 51% is one of the most feared of the theoretical attacks, a simple way to prevent it seems to be a reason enough to implement it!

Also, this particular quirk does not have to be implemented in ALL of the clients to function. If there are different clients out there that do this and do not do this, it would not split the chain. Heck, it's not really a change to the protocol even, so much as it is a change to the behavior of the client. (However as the whole idea still requires the penalty mechanism to be implemented (which IS a change to the protocol), everybody still has to be onboard with this, for the whole idea to work.)

Yep, sounds like a problem...
This "Maybe something like 5% to the miner who finds it, then 1% to the next 95 blocks (make it less likely for coins to passed back to attacker)." does decrease the effect of it, but still, sounds like it might give miners just too much power... gotta figure out something against this...

Just got this idea and googled this old thread.

still sounds like a good.

the fee problem mentioned above could be solved easily by allowing transactions with higher fees but otherwise the same.

One way to apply a penalty would be to allow double spends to be converted to transaction fees.

A miner would be allowed to include transactions that double spend, but are otherwise valid.  Any transaction which has a tx-in in common with any other transaction would be considered null.  However, all the double (or more) spent inputs would be converted into fees for the miner who found it.

So, if someone double spends and a miner gets both transactions, the tx-out can be claimed by the miner as a "network-protection" fee.

The moral being not to double spend a coin.  This would only be possible if the tx-out hasn't been spent in a previous block, so you can't use it to reverse transactions.

It would mean that if someone double spends, there is a high risk that the miner who mines the next block will simply claim the tx-out as a fee.

Ofc, that would be a hard-fork.

They can also happen if a transaction isn't propagated due to fee issues.  If there was a formal penalty, transactions would need to have a time to live field.

bumped here: https://bt.irlbtc.com/view/208167