path: root/59/15806981be5144caae86aa9b64dabc9a26f6fa

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">&lt;<a href=3D"mailto:1240902@gmail.com" =
target=3D"_blank">1240902@gmail.com</a>&gt;</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&#39;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 &lt;<a href=3D"mailto:pete@pete=
rtodd.org">pete@petertodd.org</a>&gt; wrote:<br>
&gt; On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:<br>
&gt;&gt; It is disappointing that F2Pool would enable full RBF when the saf=
e<br>
&gt;&gt; alternative, first-seen-safe RBF, is also available, especially si=
nce the<br>
&gt;&gt; fees they would gain by supporting full RBF over FSS RBF would lik=
ely be<br>
&gt;&gt; negligible. Did they consider using FSS RBF instead?<br>
&gt;<br>
&gt; Specifically the following is what I told them:<br>
&gt;<br>
&gt;&gt; We are<br>
&gt;&gt; interested in the replace-by-fee patch, but I am not following the=
<br>
&gt;&gt; development closely, more background info is needed, like what the=
<br>
&gt;&gt; difference between standard and zeroconf versions? Thanks.<br>
&gt;<br>
&gt; Great!<br>
&gt;<br>
&gt; Basically both let you replace one transaction with another that pays =
a<br>
&gt; higher fee. First-seen-safe replace-by-fee adds the additional criteri=
a<br>
&gt; that all outputs of the old transaction still need to be paid by the n=
ew<br>
&gt; transaction, with &gt;=3D as many Bitcoins. Basically, it makes sure t=
hat if<br>
&gt; someone was paid by tx1, then tx2 will still pay them.<br>
&gt;<br>
&gt; I&#39;ve written about how wallets can use RBF and FSS-RBF to more<br>
&gt; efficiently use the blockchain on the bitcoin-development mailing list=
:<br>
&gt;<br>
&gt; <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>
&gt; <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>
&gt;<br>
&gt; Basically, for the purpose of increasing fees, RBF is something like %=
50<br>
&gt; cheaper than CPFP, and FSS-RBF is something like %25 cheaper.<br>
&gt;<br>
&gt; In addition, for ease of implementation, my new FSS-RBF has a number o=
f<br>
&gt; other restrictions. For instance, you can&#39;t replace multiple<br>
&gt; transactions with one, you can&#39;t replace a transaction whose outpu=
ts<br>
&gt; have already been spent, you can&#39;t replace a transaction with one =
that<br>
&gt; spends additional unconfirmed inputs, etc. These restrictions aren&#39=
;t<br>
&gt; &quot;set in stone&quot;, but they do make the code simpler and less l=
ikely to<br>
&gt; have bugs.<br>
&gt;<br>
&gt; In comparison my previous standard RBF patch can replace multiple<br>
&gt; transactions with one, can replace long chains of transactions, etc.<b=
r>
&gt; It&#39;s willing to do more computation before deciding if a transacti=
on<br>
&gt; should be replaced, with more complex logic; it probably has a higher<=
br>
&gt; chance of having a bug or DoS attack.<br>
&gt;<br>
&gt; You&#39;ve probably seen the huge controversy around zeroconf with reg=
ard to<br>
&gt; standard replace-by-fee. While FSS RBF doesn&#39;t make zeroconf any s=
afer,<br>
&gt; it also doesn&#39;t make it any more dangerous, so politically with re=
gard<br>
&gt; to zeroconf it makes no difference. You *can* still use it doublespend=
<br>
&gt; by taking advantage of how different transactions are accepted<br>
&gt; differently, but that&#39;s true of *every* change we&#39;ve ever made=
 to<br>
&gt; Bitcoin Core - by upgrading to v0.10 from v0.9 you&#39;ve also &quot;b=
roken&quot;<br>
&gt; zeroconf in the same way.<br>
&gt;<br>
&gt;<br>
&gt; Having said that... honestly, zeroconf is pretty broken already. Only<=
br>
&gt; with pretty heroic measures like connecting to a significant fraction =
of<br>
&gt; the Bitcoin network at once, as well as connecting to getblocktemplate=
<br>
&gt; supporting miners to figure out what transactions are being mined, are=
<br>
&gt; services having any hope of avoiding getting ripped off. For the avera=
ge<br>
&gt; user their wallets do a terrible job of showing whether or not an<br>
&gt; unconfirmed transaction will go through. For example, Schildbach&#39;s=
<br>
&gt; Bitcoin wallet for Android has no code at all to detect double-spends<=
br>
&gt; until they get mined, and I&#39;ve been able to trick it into showing<=
br>
&gt; completely invalid transactions. In fact, currently Bitcoin XT will<br=
>
&gt; relay invalid transactions that are doublepsends, and Schildbach&#39;s=
<br>
&gt; wallet displays them as valid, unconfirmed, payments. It&#39;s really =
no<br>
&gt; surprise to me that nearly no-one in the Bitcoin ecosystem accepts<br>
&gt; unconfirmed transactions without some kind of protection that doesn&#3=
9;t<br>
&gt; rely on first-seen-safe mempool behavior. For instance, many ATM&#39;s=
 these<br>
&gt; days know who their customers are due to AML requirements, so while yo=
u<br>
&gt; can deposit Bitcoins and get your funds instantly, the protection for<=
br>
&gt; the ATM operator is that they can go to the police if you rip them off=
;<br>
&gt; I&#39;ve spoken to ATM operators who didn&#39;t do this who&#39;ve los=
t hundreds or<br>
&gt; even thousands of dollars before giving up on zeroconf.<br>
&gt;<br>
&gt; My big worry with zeroconf is a service like Coinbase or Shapeshift<br=
>
&gt; coming to rely on it, and then attempting to secure it by gaining<br>
&gt; control of a majority of hashing power. For instance, if Coinbase had<=
br>
&gt; contracts with 80% of the Bitcoin hashing power to guarantee their<br>
&gt; transactions would get mined, but 20% of the hashing power didn&#39;t =
sign<br>
&gt; up, then the only way to guarantee their transactions could be for the=
<br>
&gt; 80% to not build on blocks containing doublespends by the 20%. There&#=
39;s<br>
&gt; no way in a decentralized network to come to consensus about what<br>
&gt; transactions are or are not valid without mining itself, so you could<=
br>
&gt; end up in a situation where unless you&#39;re part of one of the big p=
ools<br>
&gt; you can&#39;t reliably mine at all because your blocks may get rejecte=
d for<br>
&gt; containing doublespends.<br>
&gt;<br>
&gt; One of my goal with standard replace-by-fee is to prevent this scenari=
o<br>
&gt; by forcing merchants and others to implement ways of accepting zerocon=
f<br>
&gt; transactions safely that work in a decentralized environment regardles=
s<br>
&gt; of what miners do; we have a stronger and safer Bitcoin ecosystem if<b=
r>
&gt; we&#39;re relying on math rather than trust to secure our zeroconf<br>
&gt; transactions. We&#39;re also being more honest to users, who right now=
 often<br>
&gt; have the very wrong impression that unconfirmed transactions are safe =
to<br>
&gt; accept - this does get people ripped off all too often!<br>
&gt;<br>
&gt;<br>
&gt; Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am<br>
&gt; waiting to get some feedback:<br>
&gt;<br>
&gt;=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>
&gt;<br>
&gt; Suhas Daftuar did find a pretty serious bug in it, now fixed. I&#39;m<=
br>
&gt; working on porting it to v0.10.2, and once that&#39;s done I&#39;m goi=
ng to put<br>
&gt; up a bounty for anyone who can find a DoS attack in the patch. If no-o=
ne<br>
&gt; claims the bounty after a week or two I think I&#39;ll start feeling<b=
r>
&gt; confident about using it in production.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferre=
r" target=3D"_blank">petertodd.org</a><br>
&gt; 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab<br>
&gt;<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; ------------------=
------------------------------------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <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>
&gt;<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--