{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:\n\u003e It is disappointing that F2Pool would enable full RBF when the safe\n\u003e alternative, first-seen-safe RBF, is also available, especially since the\n\u003e fees they would gain by supporting full RBF over FSS RBF would likely be\n\u003e negligible. Did they consider using FSS RBF instead?\n\nSpecifically the following is what I told them:\n\n\u003e We are\n\u003e interested in the replace-by-fee patch, but I am not following the\n\u003e development closely, more background info is needed, like what the\n\u003e difference between standard and zeroconf versions? Thanks.\n\nGreat!\n\nBasically both let you replace one transaction with another that pays a\nhigher fee. First-seen-safe replace-by-fee adds the additional criteria\nthat all outputs of the old transaction still need to be paid by the new\ntransaction, with \u003e= as many Bitcoins. Basically, it makes sure that if\nsomeone was paid by tx1, then tx2 will still pay them.\n\nI've written about how wallets can use RBF and FSS-RBF to more\nefficiently use the blockchain on the bitcoin-development mailing list:\n\nhttp://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html\nhttp://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html\n\nBasically, for the purpose of increasing fees, RBF is something like %50\ncheaper than CPFP, and FSS-RBF is something like %25 cheaper.\n\nIn addition, for ease of implementation, my new FSS-RBF has a number of\nother restrictions. For instance, you can't replace multiple\ntransactions with one, you can't replace a transaction whose outputs\nhave already been spent, you can't replace a transaction with one that\nspends additional unconfirmed inputs, etc. These restrictions aren't\n\"set in stone\", but they do make the code simpler and less likely to\nhave bugs.\n\nIn comparison my previous standard RBF patch can replace multiple\ntransactions with one, can replace long chains of transactions, etc.\nIt's willing to do more computation before deciding if a transaction\nshould be replaced, with more complex logic; it probably has a higher\nchance of having a bug or DoS attack.\n\nYou've probably seen the huge controversy around zeroconf with regard to\nstandard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,\nit also doesn't make it any more dangerous, so politically with regard\nto zeroconf it makes no difference. You *can* still use it doublespend\nby taking advantage of how different transactions are accepted\ndifferently, but that's true of *every* change we've ever made to\nBitcoin Core - by upgrading to v0.10 from v0.9 you've also \"broken\"\nzeroconf in the same way.\n\n\nHaving said that... honestly, zeroconf is pretty broken already. Only\nwith pretty heroic measures like connecting to a significant fraction of\nthe Bitcoin network at once, as well as connecting to getblocktemplate\nsupporting miners to figure out what transactions are being mined, are\nservices having any hope of avoiding getting ripped off. For the average\nuser their wallets do a terrible job of showing whether or not an\nunconfirmed transaction will go through. For example, Schildbach's\nBitcoin wallet for Android has no code at all to detect double-spends\nuntil they get mined, and I've been able to trick it into showing\ncompletely invalid transactions. In fact, currently Bitcoin XT will\nrelay invalid transactions that are doublepsends, and Schildbach's\nwallet displays them as valid, unconfirmed, payments. It's really no\nsurprise to me that nearly no-one in the Bitcoin ecosystem accepts\nunconfirmed transactions without some kind of protection that doesn't\nrely on first-seen-safe mempool behavior. For instance, many ATM's these\ndays know who their customers are due to AML requirements, so while you\ncan deposit Bitcoins and get your funds instantly, the protection for\nthe ATM operator is that they can go to the police if you rip them off;\nI've spoken to ATM operators who didn't do this who've lost hundreds or\neven thousands of dollars before giving up on zeroconf.\n\nMy big worry with zeroconf is a service like Coinbase or Shapeshift\ncoming to rely on it, and then attempting to secure it by gaining\ncontrol of a majority of hashing power. For instance, if Coinbase had\ncontracts with 80% of the Bitcoin hashing power to guarantee their\ntransactions would get mined, but 20% of the hashing power didn't sign\nup, then the only way to guarantee their transactions could be for the\n80% to not build on blocks containing doublespends by the 20%. There's\nno way in a decentralized network to come to consensus about what\ntransactions are or are not valid without mining itself, so you could\nend up in a situation where unless you're part of one of the big pools\nyou can't reliably mine at all because your blocks may get rejected for\ncontaining doublespends.\n\nOne of my goal with standard replace-by-fee is to prevent this scenario\nby forcing merchants and others to implement ways of accepting zeroconf\ntransactions safely that work in a decentralized environment regardless\nof what miners do; we have a stronger and safer Bitcoin ecosystem if\nwe're relying on math rather than trust to secure our zeroconf\ntransactions. We're also being more honest to users, who right now often\nhave the very wrong impression that unconfirmed transactions are safe to\naccept - this does get people ripped off all too often!\n\n\nAnyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am\nwaiting to get some feedback:\n\n    https://github.com/bitcoin/bitcoin/pull/6176\n\nSuhas Daftuar did find a pretty serious bug in it, now fixed. I'm\nworking on porting it to v0.10.2, and once that's done I'm going to put\nup a bounty for anyone who can find a DoS attack in the patch. If no-one\nclaims the bounty after a week or two I think I'll start feeling\nconfident about using it in production.\n\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/0ea5bf90/attachment.sig\u003e"}