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

["Jorge Timón" <jtimon@jtimon.cc>]

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