Topic: Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch - page 6. (Read 18302 times)

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

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

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.

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.

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?

Those are very good points.


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.


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.


Good point. Warnings would be welcome.


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.

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.

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?

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.

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?

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.

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.

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.

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

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.

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.

-1 on this idea.

Also bribing miners to replace a TX is a horrible precedent.

retep: To clarify the $500USD reward is meant to be for a proof-of-concept implementation. To collect it you do not need to implement unit-tests or recursive fee computation. You also do not need to make the undo RPC command do anything more than broadcast a replacement with a single output going to yourself. It is OK if the wallet code doesn't handle the undo nicely. I will consider offering further rewards if the initial one works out.

maged: I'm not offering this reward because I think an undo button is important. That feature is just an interesting side effect and yes it's one that users will likely misunderstand. The problem is people like you justus and Mike Hearn will be more than happy to screw up Bitcoin in a desperate attempt to stop double spends when it becomes a big issue. You all have this vision of mining pools signing each others blocks, making commitments to only mine chains with certain transactions and other centralized crap. If achieving consensus in a distributed fashion was that easy Bitcoin wouldn't need a proof-of-work system.

By breaking zero-conf security now there won't be pressure to implement all that crap. The most badly affected will be Satoshidice and they should not be using the blockchain the way they do.

retep and others have pointed out a few times that ASICs are actually more cost effective for small scale mining than large. You are also naive for thinking that some up-front investment will somehow make people act altruistically.

justusranvier: Zero-conf double spends will be fixed but not by screwing up Bitcoin's decentralization.

I don't think allowing to change the original output is a good option (adding new ones is fine), other than that i think it's a good proposal.