Bitcoin Forum

We need to move away from the mindset that zero confirmation transactions are safe.

Miners will eventually start to prioritize what to include by the fee it gives them, which is exactly what they should be doing. Even if that were to nullify another unconfirmed transaction, the one which gives the most to the network (miners) is the one that should be included.

Simply knocking out unconfirmed tx from memory pool by another higher fee variant would enable the payor to cancel any payment before included in a block - by double spending to own account. This is a no-go.

I also think that block inclusion would better be simple fee/size order and that memory pool should expire somewhat faster than current 3 days.

Zero-confirm transactions are safe¹ for low-value purchases provided the transacation has been accepted by a significant fraction of network nodes and no double spends have been detected.  

To attempt a double-spend, you'd need to be in cahoots with a nefarious miner and pass your fraudulent transaction over a non-public back channel.  You'd only succeed with a probability equal to the nefarious miner's percentage of global hash power.


Why would you want to intentionally make zero-confirm transaction less secure?


¹Ignoring the malleability nuance related to accepting zero-confirm transactions built from unconfirmed change outputs that is being resolved. 

The thing about Bitcoin is that you can't rely on good behavior in the nodes. Just like there were griefers who set up tx mutation nodes for the hell of it, there could be nodes that are programmed to make double spending of 0 conf transactions easier.

Merchants need a better solution than "hope adversaries decide to play nice".

Maybe something along the lines of pools offering subscription services via which a merchant can obtain assurance the pool will not mine a conflicting transaction.

No, zero-confirm transactions should not be considered safe to any degree, because...


... this is ridiculously easy to do.

This has been debated endlessly.  It comes down to whether the expected losses from double spends are significant to the merchant's bottom line.  

Purchasing a latté from Starbucks is almost certainly fine, while purchasing 100 oz of gold will definitely require a few confirmations.  Purchasing $300 of groceries (low profit margin business), well, we'll have to see how the double spend statistics look.

Remember, the expected loss due to double spending on zero-confirm transactions is:

(% expected loss) = (% of people that will attempt to defraud you) x (% of global hash power controlled by fraudulent miners)

In a retail setting, I expect less than 5% of customers to attempt to defraud the merchant, and I expect less than 10% of global hash power to be nefarious. This gives an expected loss on zero-confirm transactions of less than 0.1 x 0.05 = 0.5%.  


EDIT: do you know of any mining pools that control a significant fraction of global hash power that current accept out-of-band knowingly-fraudulent transactions?

Give your customer a "loyalty card" if they provide some identifying information (so you can send them sales building promotions), and only accept bitcoin payments from members with a "loyalty card", and I'll bet you reduce that to below 0.1%

Ghash.io has been caught with their hand in the cookie jar. Other cloud mining operations that are coming online soon have the capability to do this with limited risk to themselves. A further 15% of the network is not identifiable and therefore would be able to do this with plausible deniability.

"Knowingly fraudulent" is not a phrase I would use. There is no way for 3rd parties to know with certainty which transaction came first, and therefore which one is the fraud. It's the nature of the bitcoin consensus system.

Interesting.  I had missed the news on this.  I'd certainly be interested in reading up about it.  Would you happen to have any links?

It was double-spends / rerolls against BetCoin.

"ghash.io betcoin" in google should get you some results.

Thanks for the info.  That is interesting.  Do you know how I could pass a double-spend to Ghash.io or one of the unknown miners?  I'd like to try to double-spend on myself, see how well it works, and report back.


There is an important subtlety.  To perpetrate a double-spend, the nefarious miner must agree to not broadcast the fraudulent double spend (otherwise the merchant's listening node would detect the attack).  If the transaction is legit, why not broadcast it publicly?

Similarly, if the miner receives the transaction long after the non-fraudulent transaction has been accepted by the majority of nodes in the network (and the merchant's node is no longer listening), then the miner would be knowingly complicit in the fraud if he accepts this clear double-spend into his memory pool.  

So I think the phrase "knowingly fraudulent" is accurate.  Do you still disagree?  

I do not think one can call a miner fraudulent if prefers a transaction with higher fee/kb above a lower variant. It is their freedom to mine whatever transactions they choose to.

The relay nodes are also free to relay or reject whatever they like. It is however beneficial to the network as a whole if relay nodes do not replace transactions with their double spend of a higher fee.

Nowadays relay nodes are quite homogenous and do not replace transactions, therefore unconfirmed double-spends are usually not making to the miner, this could however change. I guess merchants will feel the pain if so, and adapt.

 

If you peer with the merchant and miner directly, but the merchant and miner themselves are not peered, then it is relatively easy to perform a double-spend: as soon as the merchant's transaction hits the network, you send the double-spend to the miner. The merchant will not find out until it is confirmed because he already sent the first transaction to his peers, and so his peers will not relay the double-spend.

And @grau is spot on. It's the miner's freedom to mine whatever transactions they feel like, and they have no moral responsibility to include one over the other (especially because without additional information they can't tell which one is "correct"). If you are making any assumptions about how double-spends are relayed, or which transactions miners will include in blocks, you are in the wrong.

A miner also has the freedom to walk out on the street and kick some random guy in the nuts.

Just because a miner is able to replace a lower-paying transaction with a higher-paying variant, doesn't mean that doing so is not fraudulent in certain cases.  Most societies have laws against fraud and for good reason.  A common definition of fraud would be:

    fraud: wrongful deception intended to result in financial or personal gain

If a miner knowingly runs a service that accepts out-of-band double-spend transactions, then in most (all?) cases the purpose of doing so is fraudulent.  Typically, these miners would be accepting the transaction for a higher fee, from a user trying to deceive a merchant.  If this can be proven, then it's fraud.  If bitcoin gains widespread acceptance, I expect law enforcement to respond, making it difficult for this type of behaviour to flourish.  This, and social pressure to behave ethically, I believe will keep bitcoin fraud on most zero-confirm transactions below the loss percentages due to counterfeit bills, stolen credit cards, or chargeback fraud.  

That being said, I believe I do understand the bigger point you are making: the network can change and miners and nodes might not behave in the way we expect.  I agree with that statement.  Still, the risk of accepting zero-confirm transactions always comes down to the excepted loss statistics at that time.  But at least right now, I can walk down to Central Bistro in Vancouver, eat an expensive dinner, pay via BitPay, and leave before the first confirmation has arrived.  So far it's working.  

Bitcoin defines the order of transactions as they are in a valid block on the trunk with most work on it. There is no higher order truth or moral.

A miner does not need to have the information which of conflicting but otherwise valid transactions is the "right" one, therefore free to chose. It is the sender who commits/attempts the fraud by creating two valid but conflicting transactions. The miner is just a paid time stamping service, not the police or judge.
 

Consider two different scenarios:

a) A fraudulent customer pays for a product and broadcasts a double spend with higher fee.
b) A poorly written wallet sends a transaction with excessive fee, the developer notices and attempts to double spend it with a lower fee variant.

A miner receives any of the above transactions through relay nodes in random order. Which one should he chose to remain honorable?

If I was a local merchant, I would not accept zero-confirmation transactions for items over $50/value. That said, I might consider it for folks I know and can identify.

For an online retailer, waiting one hour isn't a real problem except in the case of digital asset sales. I'd still recommend waiting an hour regardless of the transaction.

Another way to get more comfort at local trade is to observe network propagation. The merchant can connect to a high number of nodes and observe if all of them echo the "right" transaction.

But observing propagation does not protect from a fraudster with a big miner buddy and is vulnerable to network isolation/siblings attack.

I think as the network matures merchants and their software will learn to combine evidences to a degree of trust. At the end nothing beats what is on the block chain, so for certainty one has to be patient.

Whichever one he receives first; but that's not the point and I agree that there are cases where it would be fine to choose either.  

I am talking about cases where the miner offers a service of accepting out-of-band transactions that are knowingly double-spent.  I am saying that if the miner offers this service for profit and if customers uses it to deceive merchants, then the miner is complicit in fraud.  

I started a poll here: https://bitcointalk.org/index.php?topic=502571.0

To sum up:

The order of transactions is exactly the problem that bitcoin was invented to solve.

The order presented in the blockchain is the only order with any meaning.
 - If you disagree with the order in the blockchain, you are wrong, not the chain.

If you are relying on the order of things not yet in the chain, you are wrong.
 - Bitcoin is not a coercive system.  No one can stop you from being wrong, but you do so at your own risk, and inevitably to your own peril.

If you have an opinion on what order things should be in when they are eventually included in the block chain, you are wrong.
 - Even if you guessed right.
 - Bitcoin is not a coercive system.  No one can force a miner to prefer any ordering over any other.


Not that one can't or even necessarily shouldn't take risks based on undefined future ordering.  The real problem is that some people don't understand the risks they are taking right now.  The network is fairly polite right now and it usually does what you think it will do.  But that politeness is not a property of the system, but an accident of history.

Miners should be viewed as profit driven entities.

They have a negative incentive to relay transactions, which means you can't depend on being peered with them to hear about transactions. A doublespend is as easy as sending one tx to the miner, and one to the merchant, the miner has no incentive to relay the transaction, so the merchant may never hear about it until it is in the blockchain, and they are out of a payment.

It is for this reason that it should be a standard to break trust in 0conf transactions, because eventually miners will stop relaying transactions so they alone are able to mine the fees.

So you would vote "NO" to my poll question here?: https://bitcointalk.org/index.php?topic=502571.0

Nodes? why would they?

Miners— well maybe some already are. How could you tell?

In case you had a legitimate reason to change the destination of your coins.

I just think there should be an official feature of the protocol that breaks trust in unconfirmed txs.

Because if mining nodes don't already behave this way, they most certainly will eventually. Better to ween the network off 0 confs early rather than later.

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which was implemented but is 'disabled' in BitcoinQT.

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 being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would not only be considered broken by Satoshi, it would introduce a huge and entirely unnecessary vulnerability to 0-conf transactions.

Replace-by-fee is a very bad idea.

but we cant force miners to do it. if i where still a miner i'd try to maximize my profits.

On the other hand, the possibility of being disconnected as a rogue/misbehaving node should be sufficient incentive to follow the protocol. Nothing minimizes profits like mining in your own little network of one.

How does that happen in practice? How do the other nodes in the network decide to ostracize a particular miner or node? And how is this done in a concerted fashion?

This was helpful. I'm trying to understand better how transactions get propagated on the network, and how that can be controlled.

How does one control who the transactions get relayed to, e.g., deliberately choosing to only send a transaction to a specific miner? Can this be done on any wallet application, or do most wallet apps automatically control the propagation of the transaction on the network? Also, is there a drawback to this, e.g., the fewer nodes that you send the transaction to, the lower the likelihood that the transaction gets picked up in the next block?

What you're describing almost makes double spends seem too easy! It's a little disconcerting, but agreed with your point about the importance of getting that first confirm. I suppose that's the lesson.

How does that happen in practice? How do the other nodes in the network decide to ostracize a particular miner or node? And how is this done in a concerted fashion?
[/quote]

Miners broadcast their solved blocks to the peers that they are connected to and rely on those peers to validate the block and relay it to additional peers.  Those additional peers validate the block before they relay it, and so on until the entire network has received and validated the block.

Contrary to popular misconception, bitcoin is a consensus system not a democracy.  Every block and every transaction is validated by every node on the system before sharing it with anybody else.  This means it is very difficult for a rogue miner or group of miners to modify how everyone else uses the system.

If a particular peer that you are connected to sends you an invalid block, your node should discard it and not relay it.  Nobody will hear about the block that the rogue miner created, and their block won't make it into the blockchain. If that same node repeatedly sends you bad blocks or bad transactions, why would you maintain a connection to a peer that clearly is not validating the information before relaying it?  Instead, your node can simply drop the connection to that node, and establish a new connection to a node that behaves properly.  If all nodes do this, eventually that rogue node is isolated.  Meanwhile, eve when not isolated from communicating, his blocks are isolated since no peers will relay them.

The average user currently relies on their wallet to handle this for them.

The typical wallet connects to peers and broadcasts the transaction to all connected peers. Then it relies on those peers to relay that transaction until the entire network has heard about it.


Some wallets will allow you to configure a specific list of peers to connect to.  Most wallets will search for peers automatically of you don't configure any.  Once you send a transaction, you have no control over whether or not the peer will relay it or who they will relay it to.


If you create a wallet that only sends the transaction to specific mining pools, and if you have an agreement with those mining pools such that they will not relay the transaction, then you are left waiting for your first confirmation until one of those specific pools happen to be lucky enough to solve a block. Meanwhile, the merchant will likely relay the transaction (he has no incentive not to).  So any pool that you don't have an agreement with will be trying to confirm the merchant's transaction.  If the merchant's transaction is confirmed before your secret transaction, then the merchant's transaction becomes valid, and your colluding miners will stop trying to confirm the secret transaction.


At the moment, most miners and pools seem to relay transactions. Therefore, it would require some conspiracy between yourself and the operators of the pools to pull off the double spend described.  There are no mainstream wallets that assist users in attempting to perpetrate such a fraud either, so you'd have to create your own wallet to do it. If you can convince the mining pool to risk the damage to their reputation for the increase in profit that you will share with them from your crime, and you can create a wallet that will give you the necessary control over the peers that you send the transactions to, then yes it is quite easy.  For this reason it is best to only accept 0 confirmation transactions if you have a trust relationship with the person you are receiving from, or you are willing to accept the risk of loss.

I've given thought on how to determine mining nodes, over the course of a couple hundred transactions and blocks, you should be able to determine with great confidence if a node is a miner or not.
By both listening for blocks and sending transactions, you should be able to determine a path of peers back to a mining node.

Like, listen for a few blocks and see which peer gives you blocks the fastest on average, then peer with their peers and repeat. Eventually you will have to start sending transactions (this part is under the assumption that mining nodes do not relay transactions) and see when they don't always get included in a block (telling you that you found a mining node, but it wasn't the one that mined the block).

This process would most certainly take more than a few days to complete, the more nodes you put out into the wild attempting it, the faster it would be accomplished.

Or, you could just assume that a miner's getwork is done directly on their node.

But either way, once you are peered directly with a miner, you are very likely to be able to doublespend under the current implementation of not relaying conflicting transactions.