From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D61A59B for ; Sun, 29 Nov 2015 11:55:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 154C8154 for ; Sun, 29 Nov 2015 11:55:09 +0000 (UTC) Received: by vkha189 with SMTP id a189so87947284vkh.2 for ; Sun, 29 Nov 2015 03:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uAyqoAloaIKO8hVzNTv3eVnUH+rvxV5m2mF5YgvdD9s=; b=B3nzcB0y0DgkhYeM96JEk8AKDHpnakfvS3BcSukXHMUbSYzo6QbH5rYHT3wATOEUDd R0cmjh4hoiAzfVKIbR/SjOjjYSURiiXNAJyBvdJp4mnqNFwGqtyYKwD4BIQCo5UCyhpb JR+hdJe+09lLR63s2wBH1tuViEiJaP1RJBeGXanOecuF7ou8+zNkWegJTSJzVsyk03vw 4Ya/qssneQxAQh2hoUjWJCB0/P1K0A9zno7u3MB8vwP6OlXPoHmGp0ZMNeeEsS7Arxnd 0YbsK/QRqfSQSm/lBWmQ+QPcS2WX9yBr2D7/SB80bTy/9MbRR4RXpdw0ASSoezWtfyDg uIMw== 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:date :message-id:subject:from:to:cc:content-type; bh=uAyqoAloaIKO8hVzNTv3eVnUH+rvxV5m2mF5YgvdD9s=; b=Lo6ilicuj9dNQPC+66oU5IP9D60maCHDkH9C+Infb/4RgnPdEBfdOYkhhNYQU0DTrH +YIJOvl03DmXxy4cn80gP8vvDOEN+sUpEge1z+QTVnWo55Rle5H5eGIycFYZFU8RMeZp 9trV/EGTbw8P+FNflbP9N6WwUj1wbS6TEn0nAon81YQtYFcXP8z93qBzqXwcOwV+AUA7 WnyZYGTOI/+VLkkFNxnEBotm2+0y2AegZUdOLjg8jje1BSSOJNh9jDm0fyCrDV3yQI/F j0zm7FmeDizjc73jTBoPQQt1X/UkB1dDa8HEg8Oe50yCqj4YlUFaygiwwjwDr0vCdgd/ DkVQ== X-Gm-Message-State: ALoCoQnKIq/8JDevmg64xq0DVIT4+THtxUbvStISbdub7dgZ5CF5a1+CFi07MALTrgsM9re5AgKm MIME-Version: 1.0 X-Received: by 10.31.16.197 with SMTP id 66mr48706650vkq.143.1448798108286; Sun, 29 Nov 2015 03:55:08 -0800 (PST) Received: by 10.31.236.70 with HTTP; Sun, 29 Nov 2015 03:55:08 -0800 (PST) Received: by 10.31.236.70 with HTTP; Sun, 29 Nov 2015 03:55:08 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Nov 2015 12:55:08 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Vincent Truong Content-Type: multipart/alternative; boundary=001a114363789898780525ac9860 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 29 Nov 2015 14:36:47 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Use CPFP as consensus critical for Full-RBF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 11:55:10 -0000 --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

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's in the blockchain.

On Nov 29, 2015 5:33 AM, "Vincent Truong vi= a bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:

(I haven't been f= ollowing this development recently so apologies in advance if I've made= assumptions about RBF)

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'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'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'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/3= ul1kb/slug/cxgegkj

Going to chime in my opinion: opt-in RBF eliminates the trus= t required with miners. You don't know if they'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.

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'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'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 n= ot 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 be= ing seeing its purpose. And this makes RBF much safer to use by combining t= he two.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a114363789898780525ac9860--