Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <jgarzik@bitpay.com>) id 1Z5ySP-00075y-C2 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:43:53 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.218.46 as permitted sender) client-ip=209.85.218.46; envelope-from=jgarzik@bitpay.com; helo=mail-oi0-f46.google.com; Received: from mail-oi0-f46.google.com ([209.85.218.46]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5ySN-0005hr-Do for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:43:53 +0000 Received: by oiax193 with SMTP id x193so82669714oia.2 for <bitcoin-development@lists.sourceforge.net>; Fri, 19 Jun 2015 08:43:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pG67pVksL5PGeIgA/xyFdtcLTIOugwTMSAw1Yqhjjg0=; b=Ij3bjMcfqLXwvYa18DFuBpbhNIb9/TSLMyUHapFIGnJjjWjysXR6q98EReLC0s+w4c czeYOAT1Bhix/sGHb/5x6cv+Y+JlfS1+7gsEu7L0VFRMvzJcMdB3PtcWu/szLoAT8l8t glXeW/PdwXBqchC/9KlHBmy880W8bO6LRPAg+GfdTDvWb7s7sG91k8XetC14zYOKFY2c mEoeyv6EsSD7MtDC5RympRzGoJwneVUo+OMYmuLDRyBOEj6qR81nm0eR1PRjAb73+KWF Fx7axHVE3A5jesYic3SRLM3DhcDOHPT6g63xWQj72NXNLkjx8YlRccYCOA65EzikdIiC pxTg== X-Gm-Message-State: ALoCoQkB6Ag0C2ykRfZL95NGKDmYD2BfPcm6TB5FeQyViIp5Idl/lfAAPCQJW5xg2M2/kFsEiRhl X-Received: by 10.202.55.7 with SMTP id e7mr13364692oia.56.1434728625965; Fri, 19 Jun 2015 08:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Fri, 19 Jun 2015 08:43:25 -0700 (PDT) In-Reply-To: <CAFzgq-zbcARe4ePj_3wA9mEzKE3PsGQ3Kb0-ALyTk054uzrrTA@mail.gmail.com> References: <20150619103959.GA32315@savin.petertodd.org> <CABHVRKR7bXfDX0_frAv_Ph4Saz3SXwXeZae1DEokorvekPeinw@mail.gmail.com> <20150619134408.GB27280@savin.petertodd.org> <CAFzgq-zbcARe4ePj_3wA9mEzKE3PsGQ3Kb0-ALyTk054uzrrTA@mail.gmail.com> From: Jeff Garzik <jgarzik@bitpay.com> Date: Fri, 19 Jun 2015 08:43:25 -0700 Message-ID: <CAJHLa0M-u=x-TN-1G8PPzDy=uSxGwhbgMEzK_DCfAfOkfsA-AQ@mail.gmail.com> To: Chun Wang <1240902@gmail.com> Content-Type: multipart/alternative; boundary=001a113cea2619a6b90518e0ca91 X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5ySN-0005hr-Do Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net> 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: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Fri, 19 Jun 2015 15:43:53 -0000 --001a113cea2619a6b90518e0ca91 Content-Type: text/plain; charset=UTF-8 Yes, FSS RBF is far better. On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang <1240902@gmail.com> wrote: > 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 <pete@petertodd.org> 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 > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --001a113cea2619a6b90518e0ca91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Yes, FSS RBF is far better.<div><br></div></div><div class= =3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 19, 2015 at 6:5= 2 AM, Chun Wang <span dir=3D"ltr"><<a href=3D"mailto:1240902@gmail.com" = target=3D"_blank">1240902@gmail.com</a>></span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex">Before F2Pool's launch, I performed probably the only = successful<br> bitcoin double spend in the March 2013 fork without any mining power.<br> [ <a href=3D"https://bitcointalk.org/index.php?topic=3D152348.0" rel=3D"nor= eferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D152348= .0</a> ] I know how bad<br> the full RBF is. We are going to switch to FSS RBF in a few hours.<br> Sorry.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <<a href=3D"mailto:pete@pete= rtodd.org">pete@petertodd.org</a>> wrote:<br> > On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:<br> >> It is disappointing that F2Pool would enable full RBF when the saf= e<br> >> alternative, first-seen-safe RBF, is also available, especially si= nce the<br> >> fees they would gain by supporting full RBF over FSS RBF would lik= ely be<br> >> negligible. Did they consider using FSS RBF instead?<br> ><br> > Specifically the following is what I told them:<br> ><br> >> We are<br> >> interested in the replace-by-fee patch, but I am not following the= <br> >> development closely, more background info is needed, like what the= <br> >> difference between standard and zeroconf versions? Thanks.<br> ><br> > Great!<br> ><br> > Basically both let you replace one transaction with another that pays = a<br> > higher fee. First-seen-safe replace-by-fee adds the additional criteri= a<br> > that all outputs of the old transaction still need to be paid by the n= ew<br> > transaction, with >=3D as many Bitcoins. Basically, it makes sure t= hat if<br> > someone was paid by tx1, then tx2 will still pay them.<br> ><br> > I've written about how wallets can use RBF and FSS-RBF to more<br> > efficiently use the blockchain on the bitcoin-development mailing list= :<br> ><br> > <a href=3D"http://www.mail-archive.com/bitcoin-development@lists.sourc= eforge.net/msg07813.html" rel=3D"noreferrer" target=3D"_blank">http://www.m= ail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html</a>= <br> > <a href=3D"http://www.mail-archive.com/bitcoin-development@lists.sourc= eforge.net/msg07829.html" rel=3D"noreferrer" target=3D"_blank">http://www.m= ail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html</a>= <br> ><br> > Basically, for the purpose of increasing fees, RBF is something like %= 50<br> > cheaper than CPFP, and FSS-RBF is something like %25 cheaper.<br> ><br> > In addition, for ease of implementation, my new FSS-RBF has a number o= f<br> > other restrictions. For instance, you can't replace multiple<br> > transactions with one, you can't replace a transaction whose outpu= ts<br> > have already been spent, you can't replace a transaction with one = that<br> > spends additional unconfirmed inputs, etc. These restrictions aren'= ;t<br> > "set in stone", but they do make the code simpler and less l= ikely to<br> > have bugs.<br> ><br> > In comparison my previous standard RBF patch can replace multiple<br> > transactions with one, can replace long chains of transactions, etc.<b= r> > It's willing to do more computation before deciding if a transacti= on<br> > should be replaced, with more complex logic; it probably has a higher<= br> > chance of having a bug or DoS attack.<br> ><br> > You've probably seen the huge controversy around zeroconf with reg= ard to<br> > standard replace-by-fee. While FSS RBF doesn't make zeroconf any s= afer,<br> > it also doesn't make it any more dangerous, so politically with re= gard<br> > to zeroconf it makes no difference. You *can* still use it doublespend= <br> > by taking advantage of how different transactions are accepted<br> > differently, but that's true of *every* change we've ever made= to<br> > Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "b= roken"<br> > zeroconf in the same way.<br> ><br> ><br> > Having said that... honestly, zeroconf is pretty broken already. Only<= br> > with pretty heroic measures like connecting to a significant fraction = of<br> > the Bitcoin network at once, as well as connecting to getblocktemplate= <br> > supporting miners to figure out what transactions are being mined, are= <br> > services having any hope of avoiding getting ripped off. For the avera= ge<br> > user their wallets do a terrible job of showing whether or not an<br> > unconfirmed transaction will go through. For example, Schildbach's= <br> > Bitcoin wallet for Android has no code at all to detect double-spends<= br> > until they get mined, and I've been able to trick it into showing<= br> > completely invalid transactions. In fact, currently Bitcoin XT will<br= > > relay invalid transactions that are doublepsends, and Schildbach's= <br> > wallet displays them as valid, unconfirmed, payments. It's really = no<br> > surprise to me that nearly no-one in the Bitcoin ecosystem accepts<br> > unconfirmed transactions without some kind of protection that doesn= 9;t<br> > rely on first-seen-safe mempool behavior. For instance, many ATM's= these<br> > days know who their customers are due to AML requirements, so while yo= u<br> > can deposit Bitcoins and get your funds instantly, the protection for<= br> > the ATM operator is that they can go to the police if you rip them off= ;<br> > I've spoken to ATM operators who didn't do this who've los= t hundreds or<br> > even thousands of dollars before giving up on zeroconf.<br> ><br> > My big worry with zeroconf is a service like Coinbase or Shapeshift<br= > > coming to rely on it, and then attempting to secure it by gaining<br> > control of a majority of hashing power. For instance, if Coinbase had<= br> > contracts with 80% of the Bitcoin hashing power to guarantee their<br> > transactions would get mined, but 20% of the hashing power didn't = sign<br> > up, then the only way to guarantee their transactions could be for the= <br> > 80% to not build on blocks containing doublespends by the 20%. There&#= 39;s<br> > no way in a decentralized network to come to consensus about what<br> > transactions are or are not valid without mining itself, so you could<= br> > end up in a situation where unless you're part of one of the big p= ools<br> > you can't reliably mine at all because your blocks may get rejecte= d for<br> > containing doublespends.<br> ><br> > One of my goal with standard replace-by-fee is to prevent this scenari= o<br> > by forcing merchants and others to implement ways of accepting zerocon= f<br> > transactions safely that work in a decentralized environment regardles= s<br> > of what miners do; we have a stronger and safer Bitcoin ecosystem if<b= r> > we're relying on math rather than trust to secure our zeroconf<br> > transactions. We're also being more honest to users, who right now= often<br> > have the very wrong impression that unconfirmed transactions are safe = to<br> > accept - this does get people ripped off all too often!<br> ><br> ><br> > Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am<br> > waiting to get some feedback:<br> ><br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/= 6176" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitco= in/pull/6176</a><br> ><br> > Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm<= br> > working on porting it to v0.10.2, and once that's done I'm goi= ng to put<br> > up a bounty for anyone who can find a DoS attack in the patch. If no-o= ne<br> > claims the bounty after a week or two I think I'll start feeling<b= r> > confident about using it in production.<br> ><br> ><br> > --<br> > 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferre= r" target=3D"_blank">petertodd.org</a><br> > 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab<br> ><br> </div></div><div class=3D"HOEnZb"><div class=3D"h5">> ------------------= ------------------------------------------------------------<br> ><br> > _______________________________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo= pment" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/l= ists/listinfo/bitcoin-development</a><br> ><br> <br> ---------------------------------------------------------------------------= ---<br> _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/= listinfo/bitcoin-development</a><br> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= <div class=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and op= en source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https:/= /bitpay.com/" target=3D"_blank">https://bitpay.com/</a></div> </div> --001a113cea2619a6b90518e0ca91--