jdillon



Offline



Activity: 70

Merit: 10







MemberActivity: 70Merit: 10 Initial replace-by-fee implementation is now available on testnet May 09, 2013, 09:59:57 AM #1



-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256



After some consultation with affected sites by myself and Peter we have decided

to release an initial replace-by-fee implementation and setup a server using

those rules on testnet. This implementation does not include recursive fee

evaluation, and is therefore vulnerable to DoS attack, so hopefully that will

continue to allow adoption to proceed gradually. We can-not recommend mining on

mainnet with it. It does not include an "undo" RPC command or an adjust fees,

and Peter says he has not implemented one yet. Patches are welcome.



Specifically there were requests from vulnerable parties, which interestingly

included a site that knew they had bugs related to replacement but not

financial vulnerabilities, to put up a server on testnet to check wallet code.

The vulnerable requested to remain undisclosed. An additional consideration was

the upcoming anti-dust rules which are yet another example of why zero-conf is

so much more dangerous to accept than single-conf. Two of the people contacting

us brought up that issue in fact.



The code is on github:



https://github.com/petertodd/bitcoin/tree/replace-by-fee



and a replace-by-fee server operating on testnet is available at

testnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use the

raw transaction API and manually create the replacement transaction. Do note

that your wallet will retain the existing one and no mechanism yet exists to

delete the old transaction from your wallet. Again, a certain amount of

"cludgyness" to this is intentional to discourage premature non-testing use.





Regarding the reward, I've decided Peter will collect the full amount even

though the work is not %100 complete (the mempool aspect) due to his concern

about staging an implementation properly, working with vulnerable sites, and

overall genuine interest in the actual issues at hand rather than the reward.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.11 (GNU/Linux)



iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz

6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu

41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDq

J/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUuj

Fgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4A

GtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug=

=M1mj

-----END PGP SIGNATURE-----

(reposting the bitcoin-development email for visibility)-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256After some consultation with affected sites by myself and Peter we have decidedto release an initial replace-by-fee implementation and setup a server usingthose rules on testnet. This implementation does not include recursive feeevaluation, and is therefore vulnerable to DoS attack, so hopefully that willcontinue to allow adoption to proceed gradually. We can-not recommend mining onmainnet with it. It does not include an "undo" RPC command or an adjust fees,and Peter says he has not implemented one yet. Patches are welcome.Specifically there were requests from vulnerable parties, which interestinglyincluded a site that knew they had bugs related to replacement but notfinancial vulnerabilities, to put up a server on testnet to check wallet code.The vulnerable requested to remain undisclosed. An additional consideration wasthe upcoming anti-dust rules which are yet another example of why zero-conf isso much more dangerous to accept than single-conf. Two of the people contactingus brought up that issue in fact.The code is on github:and a replace-by-fee server operating on testnet is available attestnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use theraw transaction API and manually create the replacement transaction. Do notethat your wallet will retain the existing one and no mechanism yet exists todelete the old transaction from your wallet. Again, a certain amount of"cludgyness" to this is intentional to discourage premature non-testing use.Regarding the reward, I've decided Peter will collect the full amount eventhough the work is not %100 complete (the mempool aspect) due to his concernabout staging an implementation properly, working with vulnerable sites, andoverall genuine interest in the actual issues at hand rather than the reward.-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.11 (GNU/Linux)iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDqJ/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUujFgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4AGtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug==M1mj-----END PGP SIGNATURE-----

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 06:55:35 PM #8 Quote from: jonytk on May 09, 2013, 06:46:26 PM To be sure: this only adds priority to a transaction right?

it doesn't modify the outputs?



because if not, someone could just fork the client to make an alt-coin that allows you to pay a fee to replace a transaction.

hence why they are paying for this...



Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.



Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet. Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

jonytk



Offline



Activity: 106

Merit: 10









MemberActivity: 106Merit: 10 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 07:14:15 PM #9 Quote from: retep on May 09, 2013, 06:55:35 PM Quote from: jonytk on May 09, 2013, 06:46:26 PM To be sure: this only adds priority to a transaction right?

it doesn't modify the outputs?



because if not, someone could just fork the client to make an alt-coin that allows you to pay a fee to replace a transaction.

hence why they are paying for this...



Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.



Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet.

Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet.

But then anyone can send a transaction to satoshidice and then, if he loses, send another transaction with more fees sending the coins to himself???



Can't wait to see the hundreds of noobs complaining, "i sent xcoin to a trader when i show the btc coming at blockchain but they never arrived!!"



Or the merchants saying "this destroy instant payments, unless you reduce your 10 min confirmation to 2 we're moving to ltc..."



etc... or am i wrong? But then anyone can send a transaction to satoshidice and then, if he loses, send another transaction with more fees sending the coins to himself???Can't wait to see the hundreds of noobs complaining, "i sent xcoin to a trader when i show the btc coming at blockchain but they never arrived!!"Or the merchants saying "this destroy instant payments, unless you reduce your 10 min confirmation to 2 we're moving to ltc..."etc... or am i wrong? Mine at Cex.io

Gavin Andresen





Offline



Activity: 1652

Merit: 1066





Chief Scientist







LegendaryActivity: 1652Merit: 1066Chief Scientist Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 07:19:55 PM #10 I think this is a terrible idea.



If it was "higher fee with superset of outputs of first spend" then that'd be fine.



Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.

How often do you get the chance to work on a potentially world-changing project?

jonytk



Offline



Activity: 106

Merit: 10









MemberActivity: 106Merit: 10 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 07:32:44 PM #12 Quote from: Gavin Andresen on May 09, 2013, 07:19:55 PM I think this is a terrible idea.



If it was "higher fee with superset of outputs of first spend" then that'd be fine.



Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.





yes, what is the idea of the patch?, i thought it was to make transactions stuck on limbo ( because of lack of insufficient fees) to go thru.

the fee , and the change, should be the only thing changed here.



Otherwise you are implementing charge-back, and for that, wouldn't it be easy-er to just make the bitcoin-qt wait, by default, internally 1 minute before really sending the transaction to the network?



Let the problem be solved client-sided? there you have your cancel button!





Who is this johndillion? Could it be the Chinese-man moving around 500 bitcoins all the time against SD ?

:S yes, what is the idea of the patch?, i thought it was to make transactions stuck on limbo ( because of lack of insufficient fees) to go thru.the fee , and the change, should be the only thing changed here.Otherwise you are implementing charge-back, and for that, wouldn't it be easy-er to just make the bitcoin-qt wait, by default, internally 1 minute beforesending the transaction to the network?Let the problem be solved client-sided? there you have your cancel button!Who is this johndillion? Could it be the Chinese-man moving around 500 bitcoins all the time against SD ?:S Mine at Cex.io

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 07:40:21 PM #13 Quote from: Gavin Andresen on May 09, 2013, 07:19:55 PM I think this is a terrible idea.



If it was "higher fee with superset of outputs of first spend" then that'd be fine.



Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.



I see this by analogy to security research vulnerability disclosure.



Right now, tons of people* are acting as if they were safe, when they really are not. They've been warned, over and over again. Until the tool gets posted to metasploit for one-click use, they will not really accept that they are in danger.



I'm pretty sure there have been other bitcoin patches accepted or rejected on the basis of avoiding lulling users into a false sense of security. In the end, it doesn't matter. Eventually, the network will operate on the principle embodied in this patch. The miners that aren't already using their own tools for block generation can get this if they want it.



That said, I'm not sure that I'd want to sign off on this either. Inevitable or not, it does kinda feel icky.



* I don't believe that tons of people are actually accepting zero confirmation transactions. I suspect that there are a dozen people on these forums (incorrectly) whining about this patch making 0-conf unsafe for every person actually accepting them. I see this by analogy to security research vulnerability disclosure.Right now, tons of people* are acting as if they were safe, when they really are not. They've been warned, over and over again. Until the tool gets posted to metasploit for one-click use, they will notaccept that they are in danger.I'm pretty sure there have been other bitcoin patches accepted or rejected on the basis of avoiding lulling users into a false sense of security. In the end, it doesn't matter. Eventually, the networkoperate on the principle embodied in this patch. The miners that aren't already using their own tools for block generation can get this if they want it.That said, I'm not sure that I'd want to sign off on this either. Inevitable or not, it does kinda feel icky. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 07:52:18 PM #14 Quote from: kjj on May 09, 2013, 07:40:21 PM I'm pretty sure there have been other bitcoin patches accepted or rejected on the basis of avoiding lulling users into a false sense of security. In the end, it doesn't matter. Eventually, the network will operate on the principle embodied in this patch. The miners that aren't already using their own tools for block generation can get this if they want it.



Yup.



Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise, and all the ways to do that involve ad-hoc secondary consensus mechanisms that make the network more fragile, and make it harder to run a profitable mining pool on a limited budget. Remember that there is no magic way to know if a transaction is a double-spend - you're limited network bandwidth can easily mean you just don't see the original transaction where a bigger, more centralized mining pool with a fast network connection will maintain a more view of the mempool that is more consistent with other large pools.



Quote from: kjj on May 09, 2013, 07:40:21 PM That said, I'm not sure that I'd want to sign off on this either. Inevitable or not, it does kinda feel icky.



Indeed. Part of the reason why I decided I'd write the patch and collect the reward was because I knew if I did so I would have some control over how it was "released into the wild" - someone else might just want to for the money and not bother to do responsible disclosure. Heck, I was thinking of turning down the reward, but with John also donating to my blocksize video... well, Bitcoins are fungible. In any case I'm pretty sure his intentions are honorable after the discussions I've had with him. Yup.Also, if the networkoperate on this principle, it will be because we've implemented ways to punish those who do otherwise, and all the ways to do that involve ad-hoc secondary consensus mechanisms that make the network more fragile, and make it harder to run a profitable mining pool on a limited budget. Remember that there is no magic way to know if a transaction is a double-spend - you're limited network bandwidth can easily mean you just don't see the original transaction where a bigger, more centralized mining pool with a fast network connection will maintain a more view of the mempool that is more consistent with other large pools.Indeed. Part of the reason why I decided I'd write the patch and collect the reward was because I knew if I did so I would have some control over how it was "released into the wild" - someone else might just want to for the money and not bother to do responsible disclosure. Heck, I was thinking of turning down the reward, but with John also donating to my blocksize video... well, Bitcoins are fungible. In any case I'm pretty sure his intentions are honorable after the discussions I've had with him. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

d'aniel



Offline



Activity: 461

Merit: 250







Sr. MemberActivity: 461Merit: 250 Re: Initial replace-by-fee implementation is now available on testnet May 09, 2013, 09:41:08 PM #18



Quote from: jgarzik on May 09, 2013, 09:17:04 PM Use a service layered on top of bitcoin, that provides the instant+secure guarantees you want.

Wouldn't bitpay, for example, lose the universality of the Bitcoin payment network by switching to something like this? Part of what makes them so convenient is that customers don't have to sign up for special accounts. Businesses that accept zero-confirmation transactions are surely quite aware that they are not perfectly safe, but some (e.g. bitpay IIRC) still find it in their interest to accept them anyway, and incorporate the risk of loss into their prices. Simply assuming they're stupid to do so in order to justify unintentionally harming their business model seems a bit... insensitive.Wouldn't bitpay, for example, lose the universality of the Bitcoin payment network by switching to something like this? Part of what makes them so convenient is that customers don't have to sign up for special accounts.