Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch April 18, 2013, 11:46:01 AM

Last edit: August 31, 2013, 07:33:18 AM by retep #1





Someone by the name of John Dillon (



Quote In any case, the more pressing issue re: replacement is changing fees attached to transactions after they have been broadcast. Lots of users are getting their transactions stuck with few options to fix them.



The more I think about the issue the more I think we should nip this zero-conf madness in the bud: change the relay rules so that transactions are replaced based on fees regardless of how that changes transaction outputs. Of course, this does make double-spending an unconfirmed transaction trivial. On the other hand, this makes changing fees after the fact trivial, and it lets us implement a limited 'undo' button for when people screw up. It also allows for many of the applications transaction replacement was meant for in the first place anyway, and all the applications where it's actually secure.



We keep saying over and over again to stop accepting zero-conf transactions, but people do it anyway because it seems secure. 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.



Some thought is required as to exactly what "replace by fees" looks like, economically optimal is a bit complex due to it's dependency on overall mempool backlog, but a rough first version should be easy to hammer out.

-Re: [Bitcoin-development] [bitcoin] Enable tx replacement on testnet. (#2516)



Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency. The blockchain and the proof-of-work system is how Bitcoin comes to a consensus about which transactions are or are not valid; trusting anything else is dangerous.



When you accept a zero-conf transaction the method of determining consensus basically comes down to hoping that all miners implement the default "no-replacement" rules, rules that can fail due to a bunch of other reasons like propagation failures. Mining pools these days are run by individuals as a (serious) hobby, and are usually hosted on insecure VPS services. The security of zero-conf transactions can change overnight by one of those pools getting hacked, or anyone with hashing power deciding to change the relay policy they use; about 10% of all blocks have unknown origins.



Trying to bolt on a second consensus mechanism, like nodes rejecting blocks if there are transactions in them that they haven't seen before, or conflict with existing transactions, is dangerous. That second consensus mechanism becomes a way to attack Bitcoin, and it can be as simple as just broadcasting different transactions to different miners so they don't know what transaction was first.



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



EDIT: EDIT: As it turns out replace-by-fee will eventually allow for fairly safe zero-confirmation transactions, ironic really: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189 Someone by the name of John Dillon ( john.dillon892@googlemail.com emailed the bitcoin-development email list earlier this morning offering a $500USD reward to anyone who implements a transaction replacement-by-fee patch. That's an idea I posted on the email list two days ago:Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency. The blockchain and the proof-of-work system is how Bitcoin comes to a consensus about which transactions are or are not valid; trusting anything else is dangerous.When you accept a zero-conf transaction the method of determining consensus basically comes down to hoping that all miners implement the default "no-replacement" rules, rules that can fail due to a bunch of other reasons like propagation failures. Mining pools these days are run by individuals as a (serious) hobby, and are usually hosted on insecure VPS services. The security of zero-conf transactions can change overnight by one of those pools getting hacked, or anyone with hashing power deciding to change the relay policy they use; about 10% of all blocks have unknown origins.Trying to bolt on a second consensus mechanism, like nodes rejecting blocks if there are transactions in them that they haven't seen before, or conflict with existing transactions, is dangerous. That second consensus mechanism becomes a way to attack Bitcoin, and it can be as simple as just broadcasting different transactions to different miners so they don't know what transaction was first.Full disclosure: I'm considering writing that patch and collecting that $1000 reward myself.EDIT: reward has increased BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 12:14:51 PM #3 Quote from: Remember remember the 5th of November on April 18, 2013, 11:50:53 AM In a nutshell, what does this mean?



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. 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. 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF

Zeilap



Offline



Activity: 154

Merit: 100







Full MemberActivity: 154Merit: 100 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 12:47:03 PM #6 Quote from: TradeFortress on April 18, 2013, 12:21:31 PM



Quote change the relay rules so that transactions are replaced based on fees regardless of how that changes transaction outputs.

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

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.

With the same inputs, the total value of the transaction is the same. Changing the fees means that the total value must be redistributed in a different way to before. Thus some outputs must get less if the fees are to get more.

I'm assuming he doesn't mean to allow adding or removing outputs. With the same inputs, the total value of the transaction is the same. Changing the fees means that the total value must be redistributed in a different way to before. Thus some outputs must get less if the fees are to get more.I'm assuming he doesn't mean to allow adding or removing outputs.

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 01:00:32 PM #7 Quote from: TradeFortress on April 18, 2013, 12:21:31 PM



Quote change the relay rules so that transactions are replaced based on fees regardless of how that changes transaction outputs.

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

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



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. 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. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

amincd



Offline



Activity: 772

Merit: 500







Hero MemberActivity: 772Merit: 500 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 03:01:10 PM #9 Quote from: retep Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency.

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.



Quote and it lets us implement a limited 'undo' button for when people screw up.

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

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 03:19:40 PM #11 Quote from: amincd on April 18, 2013, 03:01:10 PM Quote from: retep Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency.

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.



Quote and it lets us implement a limited 'undo' button for when people screw up.

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.

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. 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. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

justusranvier



Offline



Activity: 1400

Merit: 1006









LegendaryActivity: 1400Merit: 1006 Re: Reminder: zero-conf is not safe; $500USD reward posted for replace-by-fee patch April 18, 2013, 11:29:01 PM #15 Quote from: retep on April 18, 2013, 11:46:01 AM When you accept a zero-conf transaction the method of determining consensus basically comes down to hoping that all miners implement the default "no-replacement" rules, rules that can fail due to a bunch of other reasons like propagation failures. Mining pools these days are run by individuals as a (serious) hobby, and are usually hosted on insecure VPS services. The security of zero-conf transactions can change overnight by one of those pools getting hacked, or anyone with hashing power deciding to change the relay policy they use; about 10% of all blocks have unknown origins. 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. 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.