public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Vincent Truong <vincent.truong@procabiak.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Use CPFP as consensus critical for Full-RBF
Date: Sun, 29 Nov 2015 12:55:08 +0100	[thread overview]
Message-ID: <CABm2gDq_KKhtvgvT6G=rpsv28acV7pDX1cR6Gd5gpNNofm3wKQ@mail.gmail.com> (raw)
In-Reply-To: <CACrzPe=LMGW6HGoUii4pog0Ezn3kEv9_US==0XPUXHp1ivzuuw@mail.gmail.com>

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

      reply	other threads:[~2015-11-29 11:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-29  3:50 [bitcoin-dev] Use CPFP as consensus critical for Full-RBF Vincent Truong
2015-11-29 11:55 ` Jorge Timón [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDq_KKhtvgvT6G=rpsv28acV7pDX1cR6Gd5gpNNofm3wKQ@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vincent.truong@procabiak.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox