{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:Yes, FSS RBF is far better.\n\n\nOn Fri, Jun 19, 2015 at 6:52 AM, Chun Wang \u003c1240902 at gmail.com\u003e wrote:\n\n\u003e Before F2Pool's launch, I performed probably the only successful\n\u003e bitcoin double spend in the March 2013 fork without any mining power.\n\u003e [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad\n\u003e the full RBF is. We are going to switch to FSS RBF in a few hours.\n\u003e Sorry.\n\u003e\n\u003e On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:\n\u003e \u003e\u003e It is disappointing that F2Pool would enable full RBF when the safe\n\u003e \u003e\u003e alternative, first-seen-safe RBF, is also available, especially since\n\u003e the\n\u003e \u003e\u003e fees they would gain by supporting full RBF over FSS RBF would likely be\n\u003e \u003e\u003e negligible. Did they consider using FSS RBF instead?\n\u003e \u003e\n\u003e \u003e Specifically the following is what I told them:\n\u003e \u003e\n\u003e \u003e\u003e We are\n\u003e \u003e\u003e interested in the replace-by-fee patch, but I am not following the\n\u003e \u003e\u003e development closely, more background info is needed, like what the\n\u003e \u003e\u003e difference between standard and zeroconf versions? Thanks.\n\u003e \u003e\n\u003e \u003e Great!\n\u003e \u003e\n\u003e \u003e Basically both let you replace one transaction with another that pays a\n\u003e \u003e higher fee. First-seen-safe replace-by-fee adds the additional criteria\n\u003e \u003e that all outputs of the old transaction still need to be paid by the new\n\u003e \u003e transaction, with \u003e= as many Bitcoins. Basically, it makes sure that if\n\u003e \u003e someone was paid by tx1, then tx2 will still pay them.\n\u003e \u003e\n\u003e \u003e I've written about how wallets can use RBF and FSS-RBF to more\n\u003e \u003e efficiently use the blockchain on the bitcoin-development mailing list:\n\u003e \u003e\n\u003e \u003e\n\u003e http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html\n\u003e \u003e\n\u003e http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html\n\u003e \u003e\n\u003e \u003e Basically, for the purpose of increasing fees, RBF is something like %50\n\u003e \u003e cheaper than CPFP, and FSS-RBF is something like %25 cheaper.\n\u003e \u003e\n\u003e \u003e In addition, for ease of implementation, my new FSS-RBF has a number of\n\u003e \u003e other restrictions. For instance, you can't replace multiple\n\u003e \u003e transactions with one, you can't replace a transaction whose outputs\n\u003e \u003e have already been spent, you can't replace a transaction with one that\n\u003e \u003e spends additional unconfirmed inputs, etc. These restrictions aren't\n\u003e \u003e \"set in stone\", but they do make the code simpler and less likely to\n\u003e \u003e have bugs.\n\u003e \u003e\n\u003e \u003e In comparison my previous standard RBF patch can replace multiple\n\u003e \u003e transactions with one, can replace long chains of transactions, etc.\n\u003e \u003e It's willing to do more computation before deciding if a transaction\n\u003e \u003e should be replaced, with more complex logic; it probably has a higher\n\u003e \u003e chance of having a bug or DoS attack.\n\u003e \u003e\n\u003e \u003e You've probably seen the huge controversy around zeroconf with regard to\n\u003e \u003e standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,\n\u003e \u003e it also doesn't make it any more dangerous, so politically with regard\n\u003e \u003e to zeroconf it makes no difference. You *can* still use it doublespend\n\u003e \u003e by taking advantage of how different transactions are accepted\n\u003e \u003e differently, but that's true of *every* change we've ever made to\n\u003e \u003e Bitcoin Core - by upgrading to v0.10 from v0.9 you've also \"broken\"\n\u003e \u003e zeroconf in the same way.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Having said that... honestly, zeroconf is pretty broken already. Only\n\u003e \u003e with pretty heroic measures like connecting to a significant fraction of\n\u003e \u003e the Bitcoin network at once, as well as connecting to getblocktemplate\n\u003e \u003e supporting miners to figure out what transactions are being mined, are\n\u003e \u003e services having any hope of avoiding getting ripped off. For the average\n\u003e \u003e user their wallets do a terrible job of showing whether or not an\n\u003e \u003e unconfirmed transaction will go through. For example, Schildbach's\n\u003e \u003e Bitcoin wallet for Android has no code at all to detect double-spends\n\u003e \u003e until they get mined, and I've been able to trick it into showing\n\u003e \u003e completely invalid transactions. In fact, currently Bitcoin XT will\n\u003e \u003e relay invalid transactions that are doublepsends, and Schildbach's\n\u003e \u003e wallet displays them as valid, unconfirmed, payments. It's really no\n\u003e \u003e surprise to me that nearly no-one in the Bitcoin ecosystem accepts\n\u003e \u003e unconfirmed transactions without some kind of protection that doesn't\n\u003e \u003e rely on first-seen-safe mempool behavior. For instance, many ATM's these\n\u003e \u003e days know who their customers are due to AML requirements, so while you\n\u003e \u003e can deposit Bitcoins and get your funds instantly, the protection for\n\u003e \u003e the ATM operator is that they can go to the police if you rip them off;\n\u003e \u003e I've spoken to ATM operators who didn't do this who've lost hundreds or\n\u003e \u003e even thousands of dollars before giving up on zeroconf.\n\u003e \u003e\n\u003e \u003e My big worry with zeroconf is a service like Coinbase or Shapeshift\n\u003e \u003e coming to rely on it, and then attempting to secure it by gaining\n\u003e \u003e control of a majority of hashing power. For instance, if Coinbase had\n\u003e \u003e contracts with 80% of the Bitcoin hashing power to guarantee their\n\u003e \u003e transactions would get mined, but 20% of the hashing power didn't sign\n\u003e \u003e up, then the only way to guarantee their transactions could be for the\n\u003e \u003e 80% to not build on blocks containing doublespends by the 20%. There's\n\u003e \u003e no way in a decentralized network to come to consensus about what\n\u003e \u003e transactions are or are not valid without mining itself, so you could\n\u003e \u003e end up in a situation where unless you're part of one of the big pools\n\u003e \u003e you can't reliably mine at all because your blocks may get rejected for\n\u003e \u003e containing doublespends.\n\u003e \u003e\n\u003e \u003e One of my goal with standard replace-by-fee is to prevent this scenario\n\u003e \u003e by forcing merchants and others to implement ways of accepting zeroconf\n\u003e \u003e transactions safely that work in a decentralized environment regardless\n\u003e \u003e of what miners do; we have a stronger and safer Bitcoin ecosystem if\n\u003e \u003e we're relying on math rather than trust to secure our zeroconf\n\u003e \u003e transactions. We're also being more honest to users, who right now often\n\u003e \u003e have the very wrong impression that unconfirmed transactions are safe to\n\u003e \u003e accept - this does get people ripped off all too often!\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am\n\u003e \u003e waiting to get some feedback:\n\u003e \u003e\n\u003e \u003e     https://github.com/bitcoin/bitcoin/pull/6176\n\u003e \u003e\n\u003e \u003e Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm\n\u003e \u003e working on porting it to v0.10.2, and once that's done I'm going to put\n\u003e \u003e up a bounty for anyone who can find a DoS attack in the patch. If no-one\n\u003e \u003e claims the bounty after a week or two I think I'll start feeling\n\u003e \u003e confident about using it in production.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e 'peter'[:-1]@petertodd.org\n\u003e \u003e 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\n\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc.      https://bitpay.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/2897fe9a/attachment.html\u003e"}