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