4 ms·

The problem with RBF is that (in some cases) it can allow double-spends with older receiving software. If the receiver accepts zero-confirmation transactions, t

by ggreer 11y ago

The problem with RBF is that (in some cases) it can allow double-spends with older receiving software. If the receiver accepts zero-confirmation transactions, the sender can send one transaction, wait for the receiver to accept it, then send another transaction with a higher fee and a different receiver. In other words: RBF may be opt-in, but it decreases security for wallets that don't support it. The problem with SegWit is that it isn't ready. A few days ago, SegWit caused testnet to fork. The cause has been identified and fixed, but it will still be months before SegWit is trusted enough for production use. While Bitcoin has never had an intentional hard fork, it has had an accidental one.[1] It was chaotic, but not world-ending. In contrast, Classic requires 750 out of the last 1000 mined blocks to trigger, and it has a month-long grace period before accepting larger blocks. It would be a well-known and predictable switchover. 1. https://bitcoin.org/en/alert/2013-03-11-chain-fork https://bitcoin.org/en/alert/2013-03-11-chain-fork

ikeboy 11y ago
Those types of transactions have been non-standard and non mined by default anyway. The opt in flag has been designated for replacing transactions from day one, and plenty of wallets will recognize it and warn. Individual merchants shouldn't be accepting zero conf anyway without risk assessment (it's been demonstrated how easy it is to double spend well before RBF), and if they use an external company to accept then that company will check for the flag. Re 75% is enough: remember the fork that happened just last year on a soft fork with 95%? https://bitcoin.org/en/alert/2015-07-04-spv-mining https://bitcoin.org/en/alert/2015-07-04-spv-mining
- ggreer 11y ago
  The cause of the fork you mentioned was not related to the threshold. Miners had software that falsely claimed to supported the new, stricter checks. Even if the threshold had been 100% of the last 1,000 blocks, the fork would have still happened. Unless you think no threshold is ever acceptable (because software can lie about its capabilities), your argument proves too much. I mentioned RBF as an example of Core adding complexities when they should be focusing on scaling. We can reasonably disagree as to whether RBF's advantages outweigh its disadvantages. I lean toward, "Not worth it." but debating RBF gets away from my main criticism of Core: That they are not being careful or conservative. They're just doing a terrible job of scaling Bitcoin.
  - ikeboy 11y ago
    I mentioned that fork because you implied that a 75% hard fork would be effectively riskless. There are all kinds of things that can go wrong, and not wanting a hard fork unless there are no other options is prudent. RBF helped the existing problem of transactions never going through. A fee market will need to develop eventually anyway (as nullc has said, there's an unlimited amount of data people would like to store for free), and allowing fee changes for transactions where zero conf acceptance is not required is a step towards making transactions easier in a fee market. Claiming that RBF is not careful is something I can't agree with. If wallet designers disregard a feature of Bitcoin that's been there from the beginning, and users accept zero confs without doing basic security checks, protecting them isn't more important than providing features to everyone else. First seen was never advertised as secure, and if you're too lazy to check for that flag I don't really care. Considering that double spends were still very possible previously, and the detection is one line of code, I'm not particularly worried. https://petertodd.org/2016/are-wallets-ready-for-rbf https://petertodd.org/2016/are-wallets-ready-for-rbf points out that none of the top wallets would detect a regular double-spend even without RBF.
    - ggreer 11y ago
      I'm not sure how you got that impression, but I certainly don't want to imply that Classic's method is effectively riskless. I'm saying that it's the best available option to help with Bitcoin's current scaling problem. Compared to SegWit, it's an absolutely trivial change. Adoption of it is predictable (750/1000 most recent blocks, plus a month grace period), giving everyone plenty of time to update their software. And most importantly, it's ready today. Even the most optimistic timelines put SegWit months out. You keep coming back to RBF, but it seems we only disagree on the magnitude of the disadvantages I highlighted, not their existence. The post you linked to shows that wallets really aren't ready for RBF. The author (who I now notice is a Bitcoin Core developer) is rather disingenuous. He neglects to mention that: • Without RBF, zero-conf double-spends have a success rate of around 50%. With RBF, this becomes a ≈100% success rate. • Without RBF, the success rate of a zero-conf double-spend decreases over time. As more nodes see the transaction, fewer will accept any future double-spend. With RBF, the double-spend success rate stays close to 100% until there is a confirmation. Again, reasonable people can disagree about whether RBF is good or bad. I only brought it up as an example of Core introducing complexity that is, at best, tangentially related to scaling.
makomk 11y ago
You really shouldn't be accepting zero-confirmation transactions that are marked as replaceable no matter how old your receiving software is. Even though it happens that most pools don't ever actually accept replacements for them, that's merely a policy decision on the part of the pools - the field marking them as replaceable has been there as long as Bitcoin's existed and I think a few pools do honour it.

by ggreer 11y ago

ikeboy 11y ago

Those types of transactions have been non-standard and non mined by default anyway. The opt in flag has been designated for replacing transactions from day one, and plenty of wallets will recognize it and warn. Individual merchants shouldn't be accepting zero conf anyway without risk assessment (it's been demonstrated how easy it is to double spend well before RBF), and if they use an external company to accept then that company will check for the flag. Re 75% is enough: remember the fork that happened just last year on a soft fork with 95%? https://bitcoin.org/en/alert/2015-07-04-spv-mining https://bitcoin.org/en/alert/2015-07-04-spv-mining

ggreer 11y ago
The cause of the fork you mentioned was not related to the threshold. Miners had software that falsely claimed to supported the new, stricter checks. Even if the threshold had been 100% of the last 1,000 blocks, the fork would have still happened. Unless you think no threshold is ever acceptable (because software can lie about its capabilities), your argument proves too much. I mentioned RBF as an example of Core adding complexities when they should be focusing on scaling. We can reasonably disagree as to whether RBF's advantages outweigh its disadvantages. I lean toward, "Not worth it." but debating RBF gets away from my main criticism of Core: That they are not being careful or conservative. They're just doing a terrible job of scaling Bitcoin.
- ikeboy 11y ago
  I mentioned that fork because you implied that a 75% hard fork would be effectively riskless. There are all kinds of things that can go wrong, and not wanting a hard fork unless there are no other options is prudent. RBF helped the existing problem of transactions never going through. A fee market will need to develop eventually anyway (as nullc has said, there's an unlimited amount of data people would like to store for free), and allowing fee changes for transactions where zero conf acceptance is not required is a step towards making transactions easier in a fee market. Claiming that RBF is not careful is something I can't agree with. If wallet designers disregard a feature of Bitcoin that's been there from the beginning, and users accept zero confs without doing basic security checks, protecting them isn't more important than providing features to everyone else. First seen was never advertised as secure, and if you're too lazy to check for that flag I don't really care. Considering that double spends were still very possible previously, and the detection is one line of code, I'm not particularly worried. https://petertodd.org/2016/are-wallets-ready-for-rbf https://petertodd.org/2016/are-wallets-ready-for-rbf points out that none of the top wallets would detect a regular double-spend even without RBF.
  - ggreer 11y ago
    I'm not sure how you got that impression, but I certainly don't want to imply that Classic's method is effectively riskless. I'm saying that it's the best available option to help with Bitcoin's current scaling problem. Compared to SegWit, it's an absolutely trivial change. Adoption of it is predictable (750/1000 most recent blocks, plus a month grace period), giving everyone plenty of time to update their software. And most importantly, it's ready today. Even the most optimistic timelines put SegWit months out. You keep coming back to RBF, but it seems we only disagree on the magnitude of the disadvantages I highlighted, not their existence. The post you linked to shows that wallets really aren't ready for RBF. The author (who I now notice is a Bitcoin Core developer) is rather disingenuous. He neglects to mention that: • Without RBF, zero-conf double-spends have a success rate of around 50%. With RBF, this becomes a ≈100% success rate. • Without RBF, the success rate of a zero-conf double-spend decreases over time. As more nodes see the transaction, fewer will accept any future double-spend. With RBF, the double-spend success rate stays close to 100% until there is a confirmation. Again, reasonable people can disagree about whether RBF is good or bad. I only brought it up as an example of Core introducing complexity that is, at best, tangentially related to scaling.

makomk 11y ago

You really shouldn't be accepting zero-confirmation transactions that are marked as replaceable no matter how old your receiving software is. Even though it happens that most pools don't ever actually accept replacements for them, that's merely a policy decision on the part of the pools - the field marking them as replaceable has been there as long as Bitcoin's existed and I think a few pools do honour it.