When does it become fraud? The ethics of bitcoin mining and zero-confirm TXs

[Peter R]

Regarding the miner, if he is knowingly facilitating fraud, yes, he is an accomplice to the fraudulent double spender.

If there are legitimate reasons to double spend, and he is simply offering a service which the protocol allows, without knowing the intentions of the double spender, then no.

I am in agreement with what you said.  And I agree with Grau that "there are no good and bad motives in absence of extra information."  But usually we will have extra information:

Now what if the miner knows that 90% of the double-spend transactions going through his "OOB double-spend service" are for the purpose of defrauding a merchant (possibly from statistics compiled from payment providers such as BitPay).  If he considers a single double-spend request in isolation, the miner cannot say for sure that that transaction is fraudulent, but using this to legitimize his service seems disingenuous if, statistically, it is known that most of the transactions are fraudulent (and he just can't tell which ones).  

[flower1024]

No
0-conf should only be trusted for small amounts or digital goods which are revokeable (eg usenetprovider).

[StarfishPrime]

We shouldn't lose sight of the fact that tx replacement issues were considered and accounted for at the very beginning, by Satoshi himself:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions currently being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

A race conditon between maliciously broadcast double-spend tx's will always be a function of how well connected the initial receiving nodes are, and the timing of the double spend tx broadcast. There's really no way around waiting for confirmations for absolute transaction certainty.

Best practice should be to always reject an incoming tx if it already has a counterpart in the mempool, where sequence == UINT_MAX. This is currently considered normal behavior and is probably the only thing that saved the network from being overwhelmed by the large scale TM attack in early Feb.

Non-conforming nodes are simply not following the protocol (i.e. they are disregarding the sequence parameter).

[Lauda]

Let me pour a bit more oil to the fire:

What if one broadcasts a double spend of a confirmed transaction with a fee that provides enough incentive not to mine on top of the chain but to fork it just before the confirmation?

Is it ok to accept the bribe?

It's never okay to accept bribe.

[HorseCoin]

i don't know  

http://i1.ytimg.com/vi/v7BkdARYNAE/maxresdefault.jpg

[BTC_Learner]

Let me pour a bit more oil to the fire:

What if one broadcasts a double spend of a confirmed transaction with a fee that provides enough incentive not to mine on top of the chain but to fork it just before the confirmation?

Is it ok to accept the bribe?

Does the miner know the intention of the broadcaster?

No. The miner has only publicly available information accessible to all other miner: that is the block chain and a double spend attempt on the network.

Then I would say there is nothing wrong with attempting to grab these coins. There is also nothing wrong with the rest of the network ignoring your fork should they choose.

I'm a beginner. Can someone help me understand how this works?

The original transaction--buyer sending coins to seller--got confirmed, and the bitcoins have moved to the address of the seller. The miner then forks the chain, at the point just before that confirmation. He is successful (which if I understand correctly, means that he mined the next block, forked the chain, AND that everyone else on the network accepted his chain as valid).

Does this mean that the coins that had showed up in the address of the seller are simply no longer there? They just look in their wallet, and the coins they had just received are now missing?

Also, can someone shed some light for me in terms of HOW other miners/nodes on the network 'choose' between the original chain and the forked chain? What types of validations are the other nodes doing to try and determine which chain is legitimate? Are these validations manual or automated?

[BTC_Learner]

We shouldn't lose sight of the fact that tx replacement issues were considered and accounted for at the very beginning, by Satoshi himself:

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions currently being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

A race conditon between maliciously broadcast double-spend tx's will always be a function of how well connected the initial receiving nodes are, and the timing of the double spend tx broadcast. There's really no way around waiting for confirmations for absolute transaction certainty.

Best practice should be to always reject an incoming tx if it already has a counterpart in the mempool, where sequence == UINT_MAX. This is currently considered normal behavior and is probably the only thing that saved the network from being overwhelmed by the large scale TM attack in early Feb.

Non-conforming nodes are simply not following the protocol (i.e. they are disregarding the sequence parameter).

This was helpful. Some questions for you on this, probably stupid ones.

When you say a transaction has a counterpart in the mempool, what defines a counterpart? What parameters indicate that a transaction is basically a replica of another? Is it just that the same number of coins are being sent from the same address (which may not represent a double spend, right?)? I'm guessing it has to be something more fundamental than that?

Second, also probably a dumb question. If sequence is the only thing that matters, then couldn't one increase the probability of successfully double spending by reversing the transaction order? Send the malicious TX first, and then the legitimate one? Appreciate someone filling in the blanks, because I'm sure I'm missing something!

[OnkelPaul]

The protocol is the protocol.  If it enables fraud, that is part of the protocol.  Thankfully, with a modicum of simple measures, it does not allow fraud.

The protocol is the protocol.  It doesn't care if your transaction is a double spend or if there's a fee or no fee or if it's non-standard or standard or if you accidentally send 0.01 bitcoins with a 300 bitcoin miner fee.

The protocol is the protocol.  You will relay any transactions you think should be relayed, just as others will do.  You will mine transactions you think should be mined, just as others will do.  Most people don't mine dust or non-standard transactions, some do.

The protocol is the protocol.  The protocol is amoral.  It doesn't care about what you use your bitcoins for, or if you are attempting to defraud somebody.  All it knows is that's a valid transaction.  And that's all it needs to know.

Yes. All true.

Anything allowed by the protocol is fair game.

No. (old rhetoric trick - slip in an innocent sounding misleading statement after a list of things everybody agrees to, and most of the listeners will nod in agreement)

Whether something is allowed by the protocol is completely irrelevant to the question whether it is ethical.
Is stealing bitcoins by planting a trojan on a victim's computer ethical? The protocol does not care, but the action is certainly theft.
Is deliberately staging a double-spend to defraud a merchant ethical? The protocol does not care, but the action is certainly fraud.
Is deliberatley offering services to support such activities ethical? The protocol does not care, but the action is certainly complicity in crime.

Onkel Paul

[Peter R]

When you say a transaction has a counterpart in the mempool, what defines a counterpart? What parameters indicate that a transaction is basically a replica of another? Is it just that the same number of coins are being sent from the same address (which may not represent a double spend, right?)? I'm guessing it has to be something more fundamental than that?

By "counterpart," he means another transaction that spends at least one of the outputs spent by the transaction in question.  Outputs can only be spent once (of course).  

Let's say you create a transaction that spends coins A and B and broadcast it to the network.  My node will check if coins A and B have been spent, and, if not, accept this transaction into my memory pool and relay it to my peers.  

Let's say you also create a transaction that spends coins A and C.  If my node learns of this transaction after it has accepted the A/B transaction, it will reject it.  That is, my node will not allow it to replace the A/B transaction and my node will not relay it to my peers.  It is because of this behaviour that zero-confirm transactions are reasonably reliable.  

If sequence is the only thing that matters, then couldn't one increase the probability of successfully double spending by reversing the transaction order? Send the malicious TX first, and then the legitimate one? Appreciate someone filling in the blanks, because I'm sure I'm missing something!

This would increase the chances of getting caught by the merchant.  The merchant (or their payment provider) will have listening nodes.  These nodes are well-connected to other important nodes across the network.  If you broadcast the double-spend (the one that signs the coins back to you) first, then the listening node will likely see this by the time you broadcast the legitimate transaction.  

It is also likely that the legitimate transaction sent later would be rejected by the network.  The first node you relay it to may immediately drop it because it is clearly a double-spend.  

[BTC_Learner]

Thank you, that's helpful.

The check the nodes perform that you're describing, it sounds like it's voluntary? It's just that it's common and ubiquitous on the network, and that's why double spends are typically unlikely to be successful?

Say I am trying to do two separate transactions that are both for 0.2 BTC, using an output that has 0.5 BTC total. In that case, would nodes view both those transactions as valid? In other words, is it only when the total attempted spend exceeds the amount in the output that one of the transactions would not be accepted by the other nodes?

[amspir]

A merchant should not rely on unconfirmed transactions ever.

For small purchases, this is impractical.   To require the customer to stand there and wait for the transaction to be confirmed by one block could take up to 30-45 minutes.

The merchant, or the payment processing system, would have to take a small loss due to fraudulent transactions, just like they do with the credit/debit card payment systems.

[Peter R]

The check the nodes perform that you're describing, it sounds like it's voluntary? It's just that it's common and ubiquitous on the network, and that's why double spends are typically unlikely to be successful?

Users are free to modify the software as they see fit.  Personally, I would never relay double spends and I don't believe the developers would ever release a version of bitcoin-qt that relays double spends.  Relaying double spends would also decrease network robustness against DoS attacks as multiple variants of transactions could be broadcast to flood the network.  But you could modify your node to do whatever you want.  

What matters is the emergent behaviour of the network as a whole.

Say I am trying to do two separate transactions that are both for 0.2 BTC, using an output that has 0.5 BTC total. In that case, would nodes view both those transactions as valid? In other words, is it only when the total attempted spend exceeds the amount in the output that one of the transactions would not be accepted by the other nodes?

Bitcoin isn't based on "balances."  It is based on destroying and creating outputs.  If you have a 0.5 BTC output in Address 1, and you want to send 0.2 BTC to both Address 2 and Address 3, you could do it as a single transaction:

    input    = 0.5 BTC coin from Address 1

    outputs = 0.2 BTC coin assigned to Address 2,
                  0.2 BTC coin assigned to Address 3, and
                  0.1 BTC coin (change) assigned back to Address 1.

Or, as you mentioned, you could do this as two transactions:

TX #1:
    input    = 0.5 BTC coin from Address 1

    outputs = 0.2 BTC coin assigned to Address 2,
                  0.3 BTC coin (change) assigned back to Address 1.

TX #2:
    input    = 0.3 BTC coin from Address 1

    outputs = 0.2 BTC coin assigned to Address 3,
                  0.1 BTC coin (change) assigned back to Address 1.

Both methods are valid and would be accepted by conforming nodes and miners.  

[Lethn]

Assuming this is even possible, yes it would be fraud, because the miner is claiming transactions have occurred that haven't, I'm not an expert in Bitcoin code so I couldn't tell you whether it's possible but this is the reason I believe the whole mining system of proof of work/stake was created in the first place. I guess whether or not the miner actually being involved in the fraud would depend on their knowledge of the glitch/exploit in the first place, it would be a bit like with somebody working at a company that is knowingly committing fraud and inadvertently helps them hide evidence or something because they kept it hidden from them.

[bountygiver]

to the 12 people who voted no, I am disappoint.
Willingly aiding any unlawful activity is as bad as doing the unlawful act yourself.

And if you want more people to accept the use of bitcoin, you better damn well make sure the currency is secure and they have reasons to put faith in it.

[grau]

to the 12 people who voted no, I am disappoint.
Willingly aiding any unlawful activity is as bad as doing the unlawful act yourself.

And if you want more people to accept the use of bitcoin, you better damn well make sure the currency is secure and they have reasons to put faith in it.

Bitcoin is not about faith or trust. Any assumption of fair play is wrong here. Any assumption that the network will play nice with you only leads to your loss.

This is a system for money, that has rules, you like or not and those rules have no moral, they are just rules.

[lnternet]

So for transactions above 25BTC, if my partner accepts 1 confirmation, I should try to rebroadcast the tx with 25.1 BTC miners fee and hope some miner forks the chain.

[btc_jumpnrl]

You shouldn't ever accept 0-confirms as receipt of payment. If you need instant-confirmations, you need to adapt your PoS (PointofSale) to accommodate this with external means.

[grau]

So for transactions above 25BTC, if my partner accepts 1 confirmation, I should try to rebroadcast the tx with 25.1 BTC miners fee and hope some miner forks the chain.

There is a short term incentive for miner to accept your bounty. It is not really a bribe since they would do nothing against the rules. They are free to mine on whatever block they like.

There is however a long term incentive for miner to keep the network reliable in its behavior, since that influences the value of their coins.

I guess 25.1 is not enough to override the long term incentive, but there is definitely a sum some would consider it.