If I am a scammer, and I have 1 BTC in my account, and I want to buy a digital good that costs 1 BTC.
I make the purchase, and send my coin to the seller
I immediately post another transaction to a different address I control.
If an account spends its entire balance, where do you take the coins from?
Because transactions are not reversible, zeroing out an account that has just doublespent its last coin doesn't matter: it is already at zero.
What you are proposing sounds like you would confiscate the funds recieved by the seller (if he managed to receive them). There would be an approx. 50% chance that you would be taking from the legitimate owner, and 50% the scammer. Doesn't seem like a big improvement to me.
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.
Furthermore, there is currently no way to redirect a percentage of a transaction to the miner. Allowing someone to modify the recipient of a transaction has a number of potential security implications.
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.)
A system such that if a miner can include multiple transactions from the same address, with the same previous_output, that would overdraw the address
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.
the entire balance of the address is set to zero and the coins are passed back out.
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?
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).
What is the reasoning behind this? How would the coins be passed back to the attacker?
For a transaction that is already in the block chain when an overdrawing transaction shows up, if it is less than n blocks old reverse the transaction, zero the address, pass back out. Merchants wait n blocks before confirmation. If n was 3 it would force an attacker to have a fork that is at least 3 high before the transactions are made public to have a profitable double spend, and anything less will result in the loss of coins.
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?