[bitcoin-dev] Use CPFP as consensus critical for Full-RBF

[bitcoin-dev] Use CPFP as consensus critical for Full-RBF

[Vincent Truong]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

(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.

[-- Attachment #2: Type: text/html, Size: 2432 bytes --]

Re: [bitcoin-dev] Use CPFP as consensus critical for Full-RBF

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 3456 bytes --]