If I tell my client to pay you, you will receive notification of that transaction from the network.

This means that my transaction has flooded the network, and more importantly, flooded to all miners.

If I then send a transaction that spends the input back to myself, the network won't relay it and miners will ignore it.

So, if you receive the transaction from lots of neighbors, you can be reasonably sure I broadcast it to the network.

The proposal allows replacement of transactions.  If I resend the transaction, but with a higher fee, it is replaced with the new transaction.  This doesn't allow me to reverse the transaction though.

In addition, the proposal, lets me change the outputs, as long as I up the fee.

This means I can send a tx to you with 0.01 fee and then revers with with a 0.02 fee.

All this requires that it hasn't been incorporated in a block.  Once it is in a block, then it is locked down (unless that block is orphaned).

Full replacement allows people to update a transaction if it is not being included in the chain.  It would also act to discourage people accepting transactions, until at least one block confirmation happens, since until it is confirmed, it is easy to reverse.

Isn't this already done?


John Dillon seems to want to make it so that clients won't check outputs are the same before replacing the transaction.

TX replacement of any form is currently disabled.

I previously proposed a safe version that would only add additional inputs and outputs to a transaction, never changing the existing output set, and only if no transactions existed that spent any output of the transaction being replaced. Since no outputs can be replaced, you can't double-spend effectively.

The problem is, since no outputs can be replaced, if you need to change the fee again the transaction gets bigger each time. (making it public knowledge which existing output is change would break privacy) You also can't implement an 'undo' function so users can fix accidental mistakes like cutting and pasting the wrong address.

My second pure replace-by-fee proposal, which I believe is what John Dillon is willing to fund, would replace any unconfirmed transaction with another one if doing so would gain the miner higher overall fees, regardless of the circumstances. A miner following those rules acts in a perfectly economically rational way, at least in the short term. It's been argued that miners have an incentive to not mine double-spends, but I'm unconvinced; each individual miner has nothing to lose by mining a double-spend, and an immediate gain from the fee they collect. It's vastly weaker than the 'suicide-pact' rational miners have to follow the Bitcoin rules, where any deviation means every other node will reject your blocks. On the other hand, the block reward is so high right now miners have little incentive to do anything but use the reference client as-is.

I also wrote on the email list how with 1MB blocks it's pretty safe to assume that broadcasting a transaction means all miners have a copy of it within a few seconds. On the other hand, if we raise the blocksize that assumption isn't going to be true anymore - transaction load will be high enough that nodes have to drop transactions some of the time, which means not all miners will have a copy of every transaction broadcast. Thus it becomes much easier to broadcast a second copy later, double-spending the first.

So you want to make it easier to pull off a double spend on a zero-confirmation transaction?

Being able to rely on the zero-confirmation transaction "no-replacement" rule is extremely important for the usability of bitcoin. I think it would take a big hit if it were eliminated.

It would basically mean that unless you can rely on the spender being honest, you cannot accept a zero-conf transaction from them. Right now, all you need to be able to trust is that most miners are honest and are using the standard bitcoin client software with the no-replacement rule. It's been working so far, so I don't see the point of changing it.

What's the worst that can happen if the rule is not revoked? Someone pulls off a double spend? OK, then people will stop relying on zero-conf txs. The price of not doing any thing is possibly a few double spend attacks, probably with a combined value of less than the $500 John Dillon is offering as a bounty. The price of doing something is that people are guaranteed to not be able to use zero-conf txs any more, which would remove millions, if not hundreds of millions of dollars worth of value from bitcoin.

There could also be possible solutions to making zero-conf txs safer from double spends, and by eliminating them altogether, we'll never be able to try them and find out. This proposal is completely unnecessary.


If you want an undo button, add a feature in the client where after a user presses 'send', a timer starts, that after 10 minutes, fires off the transaction, and an 'undo' button on that timer, that if clicked before the timer reaches zero, cancels the countdown. No need to make double-spending zero-conf transactions trivial.

A timer is useless because a new block could be found in the next second, or next hour. Anyway, an undo button would be useful.

And this will also solve the SD problem.

Sorry, but I've got to stop this right here before this idea gets out of hand.

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

Tell me, what applications would this allow that a more locked-down transaction replacement system doesn't?

That's because it is somewhat secure! Consider the case where zero-confirmation transactions take the place of existing credit card transactions. A determined attacker can reverse 100% of their credit card transactions, but they would only be able to reverse a small percentage of their zero-confirmation transactions. This would allow casual attackers to reverse most of their zero-confirmation transactions, whereas they can't do that with credit cards as a casual attacker.

We have the Bitcoin Foundation, don't we? One of their goals should be educating businesses about the responsible handling of zero-conf transactions.

Yes, but you're confusing absolute security with "good-enough" security. Hence why people still accept credit cards.

I agree, but they may be other options that we haven't considered.

As you eluded to, they can increase the fee by adding a fee to a dependent transaction. As far a breaking privacy, here are a few ideas of preventing that. First, you have to consider the future where merchants would be the one adding the fee, as Mike Hearn has often suggested would happen. In that case, who added the fee? The user, or the merchant? If that's not good enough for you, we can add a third output that is fairly small and use that to add dependent fees.


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, unlike when we were in the age of GPU mining. Miners have an interest in having Bitcoin be used in as many use-cases as possible.

Again, thanks to ASICs, mining is a serious operation. Miners will hold onto as many transactions as possible, and they will use enterprise-grade equipment to do so.

Your description of the problem contains within it the solution you are ignoring or not seeing.

Because the mining pools are run by individuals, and because merchants have an economic incentive to avoid double spending attacks, and because the individuals operating mining pools like money, there is a way for the merchants and the pool operators to work out an arrangement that is beneficial to all parties.

It's you've spent too much time playing The Sims and forget that both merchants and pool operators are sentient, intelligent beings instead of automatons.

If the risks of zero conf double spends are worth expending resources to reduce or eliminate then the merchants will find a way to get it done. There exists nothing that would make a solution impossible, so it will be implemented when it makes sense economically.

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.

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.