From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <1240902@gmail.com>) id 1Z5wiu-0008IZ-7j for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:52:48 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.50 as permitted sender) client-ip=74.125.82.50; envelope-from=1240902@gmail.com; helo=mail-wg0-f50.google.com; Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5wis-0001sn-SV for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:52:48 +0000 Received: by wgfq1 with SMTP id q1so43672607wgf.1 for ; Fri, 19 Jun 2015 06:52:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.80.9 with SMTP id n9mr6897968wix.87.1434721960888; Fri, 19 Jun 2015 06:52:40 -0700 (PDT) Received: by 10.180.208.69 with HTTP; Fri, 19 Jun 2015 06:52:40 -0700 (PDT) In-Reply-To: <20150619134408.GB27280@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619134408.GB27280@savin.petertodd.org> Date: Fri, 19 Jun 2015 21:52:40 +0800 Message-ID: From: Chun Wang <1240902@gmail.com> To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (1240902[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (1240902[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z5wis-0001sn-SV Cc: bitcoin-development Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:52:48 -0000 Before F2Pool's launch, I performed probably the only successful bitcoin double spend in the March 2013 fork without any mining power. [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad the full RBF is. We are going to switch to FSS RBF in a few hours. Sorry. On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd wrote: > 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 > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >