Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch

[etotheipi]

If thinking like this starts creeping in than we are on a slippery slope. Why not reverse a 1-Conf transaction, if the pay is good? I think we should try to nip it in the bud. Encourage good behavior by orphaning transaction reversal blocks.

Reversing 1-confirmation transaction is almost always economically unfavorable.  You don't need to discourage that, because miners are bleeding money for every second they aren't mining off the top block.  

And as I said ... you can encourage, wish, complain, etc, all you want, but if it goes against their bottom line, it's not going to make a bit of difference if they're acting within the prescribed rules of the system (which is that there is no economic incentive not to do this)  So it will be done.

On the other hand, if we implement something that makes it economically infeasible, then that's a different story.  But you can't regulate this problem away.  You have to adjust the rules of the system and let it reach equilibrium, which hopefully doesn't include that behavior.  But I'm not sure if this is something we can achieve.

EDIT: about your "orphaning transasction reversal blocks":  there's no way to do that with zero-confirmation transactions.  For 1-conf, it would be possible, and if you hit a critical mass of miners willing to reduce their effective hash rate, they might be willing to do it.  But again, all miners have the incentive to mine off the top block.  if they are not mining the top block, they are losing money.  (enter caveats about extreme circumstances like someone putting a 200 BTC fee on a tx to try to out-spend that economic motive).

[AlphaWolf]

If you accept zero-conf transactions, you're accepting the risk of being screwed.  Zero-conf is the equivalent of "The check is in the mail!".    It's worthless.  You accept the risk, you accept the consequences.

[Nagato]

Like jdillon, I believe that in the long term, many miners will allow paid replacements of transactions and zero-conf transactions will become as useless as what we're afraid of.  You can talk about ethics, and what's in the "best interest of miners", but that is just wishful thinking that in a completely-decentralized system everyone will have the same ethics and motives.  I'd rather just see it happen and let the ecosystem adjust to the loss of remaining zero-conf security/sanity, instead of naively hope that everyone will follow the same guidelines that are not bound to follow.  Especially when there is economic incentive to breaking these guidelines.  Not all miners are dependent on the security of zero-conf transactions.  Many of them will just do what's best for their bottom line.

I've seen the phrase "allow" when referring to miners replacing zero-conf transactions.  Above, im3w1l mentioned "setting a precedent".  This is meaningless, because no one has control over all the miners, and they don't need to seek anyone's permission to do something that is entirely within the rules of the system.  The best we can do is "recommend" guidelines by making it part of the default client, but that's it.  It's part of the blessing&curse of being decentralized.  Sure, a lot of miners won't do it.  But some will, and you only need any to do it, in order for it to dramatically degrade this system.

Therefore, we are adapting ourselves (and letting others adapt) to a false reality by designing systems with an assumption that there is some security in zero-conf transactions.  I'd much rather just write it off completely, and let businesses and users adapt to the idea that zero-conf transactions are basically useless for exchanges between untrusted parties.  Forget it.  If you don't trust the person, don't mess with zero-confirmation transactions.  Period.

This.

Ive always felt that some people on this forum live in a fantasy world and assume ethics and charity can make the world go round. Like Mike Hearn's belief that NACs can fund the security of a infinite-sized blockchain.

[jdillon]

Ive always felt that some people on this forum live in a fantasy world and assume ethics and charity can make the world go round. Like Mike Hearn's belief that NACs can fund the security of a infinite-sized blockchain.

What is so brilliant about Bitcoin is how when you use it you put the absolute minimum of trust in others. You validate everything on the network and the one thing you let others decide is the order of transactions, and that decision is done with a democratic vote. (an odd type of vote similar to the two-party system in dynamic behavior but it is a vote in essence) Having looked into this nSquence transaction replacement stuff I am not so sure Satoshi really understood what he created but never the less Bitcoin is what it is.

I and some partners have known about Bitcoin for some time and we have owned coins as a long term investment for almost as long. (for what it's worth: 2409f355c8910721fbbb5c54a01b8f9c692cfb292c3b4f7baf5b8151e44fef21 gmaxwell would understand) I have not participated much due other commitments. I also haven't been a programmer for quite awhile. But recently retep's posts about decentralization off-chain transactions and the blocksize have I guess woken me up. Replace-by-fee is just a small thing, but I see it as an important step to getting people to understand how Bitcoin really works. As etotheipi says it is the blessing and the curse of decentralization, but we can adapt and gain the benefits of true decentralization.

Having said that I have some advice for you Peter Todd: Write some code for once or people will never take you seriously. You appear to have an English degree rather than a Computer Science degree.

[TierNolan]

Not all miners are dependent on the security of zero-conf transactions.  Many of them will just do what's best for their bottom line.

The incentives might be fixable by a rule change.  For example, if the rule was to not build on a block that has a double spend for 30 seconds, unless the old transaction is at least 24 hours old, then miners who broadcast those blocks are hurt.  The incentives for a miner is to always include the transactions that they see first, since those are likely to to be one that the other miners saw first.  If anything it would create an incentive not to include either of them.

It also creates an incentive to distribute info about double spends between miners.

[amincd]

Ive always felt that some people on this forum live in a fantasy world and assume ethics and charity can make the world go round.

Why assume they won't? Let's assume nothing. So far, 4 years in, zero-conf transactions have been working. They might start to fail one day, they might not. Why not let the market decide whether to accept zero-conf transactions, rather than going out of our way to make zero-conf transactions unviable?

[Nagato]

Ive always felt that some people on this forum live in a fantasy world and assume ethics and charity can make the world go round.

Why assume they won't? Let's assume nothing. So far, 4 years in, zero-conf transactions have been working. They might start to fail one day, they might not. Why not let the market decide whether to accept zero-conf transactions, rather than going out of our way to make zero-conf transactions unviable?

I actually support the replace-by-fee feature as a usability enhancement(you sent to the wrong address accidentally and you can still attempt to undo that before it's inclusion in any block) instead of trying to change people's behaviour. I agree with you, the market will force people to adapt when people start double spending txns with or without this change.

[🏰 TradeFortress 🏰]

And this will also solve the SD problem.

What SD problem? More transactions is good for bitcoin..

no it isn't. the last thing we need is SD accounting for 50% of the transactions and slowing down the confirmation time of legitimate transactions.

Are you going to say the same thing when Western Union accepts bitcoin or what and they account for 50% of the transactions? Are they legitimate but SatoshiDice is?

[thanke]

Isn't replace-by-fee incompatible with miners grouping transactions and evaluating the group-fee (groups of transactions depending on each other)? Because the owner of any output of the transaction can easily and arbitrarily increase the group-fee associated to any of the previous versions of the transaction. Since group-fee evaluation is inevitable, I don't see how replace-by-fee can work.

[caveden]

It's a very dangerous situation because the security of zero-conf transactions can change overnight simply by some fraction of the hashing power implementing that exact change.

Therefore, we are adapting ourselves (and letting others adapt) to a false reality by designing systems with an assumption that there is some security in zero-conf transactions.  I'd much rather just write it off completely, and let businesses and users adapt to the idea that zero-conf transactions are basically useless for exchanges between untrusted parties.  Forget it.  If you don't trust the person, don't mess with zero-confirmation transactions.  Period.

Those are very good points.

Full disclosure: I'm considering writing that patch and collecting that $500 reward myself.

Such patch would not be that useful if it's not used by most relays and at least a few generators. But it's a start anyway.

Have you even thought through the implications of this? An "undo" button would train the users into thinking that:
1) Bitcoin transactions can be reversed for a few minutes after they send the transaction.
2) The reversal is guaranteed.

#1 isn't true at all, since any manner of variables can come into play that could ultimately make the undo button useless almost immediately. How would you explain to people that the undo button might work for anywhere between seconds and hours?

It's sort of like GMail undo when you click Send. You have a few moments to change your mind, but once the mail is gone, you can't bring it back.
An eventual undo button should be disabled as soon as a confirmation is seen.

As for #2, if a merchant is making a great deal of profit off the transaction, they could secretly pay certain miners to choose the original transaction over the undo transaction.

Good point. Warnings would be welcome.

Not at all, and you have the invention of ASICs to thank for that. Mining now requires a large up-front investment that would be completely useless if Bitcoin were to collapse

Come on, you must admit that some double-spent of 0-conf transactions would never make Bitcoin collapse, that's an exaggeration. Particularly if people understand that a 0-conf tx can be easily undone.

[xanatos]

What happens if a block becomes orphan? Its transactions are readded to the transaction pool, so they could be changed by the sender... So you would only need to wait for a split in the network to double spend your money?

[TierNolan]

Another compromise rule would be that double spending would result in both transaction being removed from the memory pool.  The one with the higher fee would be placed in a 1 hour delay queue before being included and the lower fee one would be forgotten after 1 hour (or maybe 6 - 10 blocks).

Both would still be propagated though, with the second one received being flagged as a double spend.  Therefore all nodes on the network would have both transactions removed from the main memory pool and placed in the pending/to be discarded memory pool/queue.

The disadvantage is that the 2nd transaction is propagated.  However, the merchant would have a chance to see the double spend notification.

[caveden]

What happens if a block becomes orphan? Its transactions are readded to the transaction pool, so they could be changed by the sender... So you would only need to wait for a split in the network to double spend your money?

I've never analysed the data myself, but I'd guess that honest splits tend to carry almost (if not exactly) the same transactions on each side of the split.

[dserrano5]

Another compromise rule would be that double spending would result in both transaction being removed from the memory pool.

1) Go to the counter
2) Get a Whopper®
3) Pay with bitcoin
4) Go out
5) Attempt a double-spend, now both txs are removed from the pool
6) Enjoy your meal

[kjj]

Not all miners are dependent on the security of zero-conf transactions.  Many of them will just do what's best for their bottom line.

The incentives might be fixable by a rule change.  For example, if the rule was to not build on a block that has a double spend for 30 seconds, unless the old transaction is at least 24 hours old, then miners who broadcast those blocks are hurt.  The incentives for a miner is to always include the transactions that they see first, since those are likely to to be one that the other miners saw first.  If anything it would create an incentive not to include either of them.

It also creates an incentive to distribute info about double spends between miners.

Better rule changes have been proposed for better reasons, all rejected.  Chain validation is very nearly stateless for a reason.

[TierNolan]

1) Go to the counter
2) Get a Whopper®
3) Pay with bitcoin
4) Go out
5) Attempt a double-spend, now both txs are removed from the pool
6) Enjoy your meal

It seemed like a good idea, at the time .

[jgarzik]

Not at all, and you have the invention of ASICs to thank for that. Mining now requires a large up-front investment that would be completely useless if Bitcoin were to collapse

Come on, you must admit that some double-spent of 0-conf transactions would never make Bitcoin collapse, that's an exaggeration. Particularly if people understand that a 0-conf tx can be easily undone.

More to the point, zero-conf transactions have been double-spent already.  It is proven they are not safe today, ignoring any proposed changes.

[justusranvier]

It is proven they are not safe today, ignoring any proposed changes.

Not safe compared to what?

Most merchants out in the real world already accept payment methods that can be trivially reversed and manage to make it work.

[kjj]

It is proven they are not safe today, ignoring any proposed changes.

Not safe compared to what?

Most merchants out in the real world already accept payment methods that can be trivially reversed and manage to make it work.

Not safe compared to how safe people think they are, of course.

[Mike Hearn]

I am not aware of any merchant that has ever been double spent with 0-conf transactions except the OKPAY example during the chain split. Which was almost certainly caused by mining nodes being restarted and not syncing their mempools - quite easy to fix.