Topic: Penalizing double spends (Read 2658 times)

Not to mention it would punish those who just had a "network hiccup"...

Not all double-spends are done on purpose. Some are a result of the "system they run on".

Data can hop around, be delayed, be duplicated, or just be "present due to processing".

Not to mention that there are physical "delays" across a network, even in perfect order. As well as no true standard "time".

If the "system" allows double-spends, then that is something that the "system" should be charged for, not the user. If my bank charged me because they failed to track my money correctly, that should be them who pays for the loss, not me.

bumped here: https://bitcointalksearch.org/topic/making-0-conf-txs-relatively-safe-again-208167

this is only about 0-conf tx

to declare a block invalid because a tx was double spend outside the block would be a little... extreme

yes they should if they can take the risk. imho it is an important feature. your software should protect you from accidental double spends.

this

and this


It would not help against the Finney attack but other double spending attempts would become much less rewarding.

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.

Double spends also happen by accident and the only people that you want to protect are people that accept 0-confirmation-transactions and people shouldn't do that anyway.

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.

Am I missing something?
The same block can't have transactions that amount to what you're describing. A double-spend has to be achieved by two different miners ... never the same miner (or at least the same block).

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.

have transactions also include a block number they expire by, then if you send a transaction that does not go through you know how long to wait before resending.

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...

Would this incentivize miners to do tricks with fees that are harmful to the health of the network? Currently, if you don't include enough fees in a transaction for the big miners to pick it up you have to wait for the old transaction to be forgotten and resend it with the same prevouts. If miners can steal coins that are double-spent in this way, they may have an incentive to deliberately delay transactions in the hope that the sender resorts to resending with larger fees, allowing them to steal the coins.

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.)

I'd say confiscate everything, the amount promised is always going to be bigger than what is currently at the address. Now with multiple inputs, where not all of them overdraw, I can't really see where a regular user would be hurt by it so you might as well confiscate them too just to increase the risk of double spending.

When an attack is happening the attacker will have control of a lot of mining resources, so if they decide to abandon the attack they can use this mining power to try to reclaim the confiscated bitcoins. So if they have 30% of the network and it all goes to the next block, they have a 30% discount to their double spend penalty. By staggering the payouts it would require sustained mining power over a longer period of time, making receiving their confiscated bitcoins even more expensive. Also when the increased block payments are known in advance, it gives incentive for legitimate miners to come online and help strengthen the network.

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://bitcointalksearch.org/topic/m.48384 , 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.

Where do you get this idea that confirmed transactions can't be double spent?

Ever heard of 51% attack?  Finney attack?

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?

This would be easy to get around, and punish the wrong people.

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.

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.

I don't think double spends are a significant problem at the moment.  (Has anyone ever been double spent against?)  Keep thinking though!

I don't see how this would be possible.

Bitcoin does not track balances of addresses. It reasons in terms of "coins" (unredeemed transaction outputs), that are explicitly referenced when consumed.

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, the entire balance of the address is set to zero and the coins are passed back out. 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).

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.