MIME-Version: 1.0
In-Reply-To: <CACrzPe=LMGW6HGoUii4pog0Ezn3kEv9_US==0XPUXHp1ivzuuw@mail.gmail.com>
References: <CACrzPe=LMGW6HGoUii4pog0Ezn3kEv9_US==0XPUXHp1ivzuuw@mail.gmail.com>
Date: Sun, 29 Nov 2015 12:55:08 +0100
Message-ID: <CABm2gDq_KKhtvgvT6G=rpsv28acV7pDX1cR6Gd5gpNNofm3wKQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Vincent Truong <vincent.truong@procabiak.com>
Content-Type: multipart/alternative; boundary=001a114363789898780525ac9860
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Use CPFP as consensus critical for Full-RBF
Precedence: list

--001a114363789898780525ac9860
Content-Type: text/plain; charset=UTF-8

Both CPFP and RBF are relay/mining policy and cannot be made consensus
rules because you cannot know which transactions have been received by a
givrn peer and which have not (or at what time). Consensus rules can only
validate information that's in the blockchain.
On Nov 29, 2015 5:33 AM, "Vincent Truong via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (I haven't been following this development recently so apologies in
> advance if I've made assumptions about RBF)
>
> If you made CPFP consensus critical for all Full-RBF transactions, RBF
> should be safer to use. I see RBF as a necessity for users to fix mistakes
> (and not for transaction prioritisation), but we can't know for sure if
> miners are playing with this policy fairly or not. It is hard to spot a
> legitimate RBF and a malicious one, but if the recipient signs off on the
> one they know about using CPFP, there should be no problems. This might
> depend on the CPFP implementation, because you'll need a way for the
> transaction to mark which output is a change address and which is a payment
> to prevent the sender from signing off his own txns. (This might be bad for
> privacy, but IMO a lot safer than allowing RBF double spending sprees... If
> you value privacy then don't use RBF?) Or maybe let them sign it off but
> make all outputs sign off somehow.
>
> Copy/Paste from my reddit post:
>
> https://www.reddit.com/r/Bitcoin/comments/3ul1kb/slug/cxgegkj
>
> Going to chime in my opinion: opt-in RBF eliminates the trust required
> with miners. You don't know if they're secretly running RBF right now
> anyway. Whether Peter Todd invented this is irrelevant, it was going to
> happen either way either with good intentions or with malice, so better to
> develop this with good intentions.
>
> Perhaps the solution to this problem is simple. Allow Full-RBF up to the
> point where a recipient creates a CPFP transaction. Any transaction with
> full RBF that hasn't been signed off with a CPFP cannot go into a block,
> and this can become a consensus rule rather than local policy thanks to the
> opt-in flags that's inside transactions.
>
> > P.S. (When I wrote this, I'm actually not sure how the flag looks like
> and am just guessing it can be used this way. I'm not familiar with the
> implementation.)
>
> CPFP is needed so that merchants can bear the burden of fees (double
> bandwidth costs aside, and frankly if RBF is allowed bandwidth is going to
> increase regardless anyway). That's always the way I've being seeing its
> purpose. And this makes RBF much safer to use by combining the two.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a114363789898780525ac9860
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Both CPFP and RBF are relay/mining policy and cannot be made=
 consensus rules because you cannot know which transactions have been recei=
ved by a givrn peer and which have not (or at what time). Consensus rules c=
an only validate information that&#39;s in the blockchain.</p>
<div class=3D"gmail_quote">On Nov 29, 2015 5:33 AM, &quot;Vincent Truong vi=
a bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attri=
bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">(I haven&#39;t been f=
ollowing this development recently so apologies in advance if I&#39;ve made=
 assumptions about RBF)</p>
<p dir=3D"ltr">If you made CPFP consensus critical for all Full-RBF transac=
tions, RBF should be safer to use. I see RBF as a necessity for users to fi=
x mistakes (and not for transaction prioritisation), but we can&#39;t know =
for sure if miners are playing with this policy fairly or not. It is hard t=
o spot a legitimate RBF and a malicious one, but if the recipient signs off=
 on the one they know about using CPFP, there should be no problems. This m=
ight depend on the CPFP implementation, because you&#39;ll need a way for t=
he transaction to mark which output is a change address and which is a paym=
ent to prevent the sender from signing off his own txns. (This might be bad=
 for privacy, but IMO a lot safer than allowing RBF double spending sprees.=
.. If you value privacy then don&#39;t use RBF?) Or maybe let them sign it =
off but make all outputs sign off somehow.</p>
<p dir=3D"ltr">Copy/Paste from my reddit post:</p>
<p dir=3D"ltr"><a href=3D"https://www.reddit.com/r/Bitcoin/comments/3ul1kb/=
slug/cxgegkj" target=3D"_blank">https://www.reddit.com/r/Bitcoin/comments/3=
ul1kb/slug/cxgegkj</a><br></p>
<p dir=3D"ltr">Going to chime in my opinion: opt-in RBF eliminates the trus=
t required with miners. You don&#39;t know if they&#39;re secretly running =
RBF right now anyway. Whether Peter Todd invented this is irrelevant, it wa=
s going to happen either way either with good intentions or with malice, so=
 better to develop this with good intentions.</p>
<p dir=3D"ltr">Perhaps the solution to this problem is simple. Allow Full-R=
BF up to the point where a recipient creates a CPFP transaction. Any transa=
ction with full RBF that hasn&#39;t been signed off with a CPFP cannot go i=
nto a block, and this can become a consensus rule rather than local policy =
thanks to the opt-in flags that&#39;s inside transactions.</p>
<p dir=3D"ltr">&gt; P.S. (When I wrote this, I&#39;m actually not sure how =
the flag looks like and am just guessing it can be used this way. I&#39;m n=
ot familiar with the implementation.)</p>
<p dir=3D"ltr">CPFP is needed so that merchants can bear the burden of fees=
 (double bandwidth costs aside, and frankly if RBF is allowed bandwidth is =
going to increase regardless anyway). That&#39;s always the way I&#39;ve be=
ing seeing its purpose. And this makes RBF much safer to use by combining t=
he two.</p>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>

--001a114363789898780525ac9860--