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 5F1F9411 for ; Sun, 29 Nov 2015 03:50:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88535110 for ; Sun, 29 Nov 2015 03:50:15 +0000 (UTC) Received: by ioc74 with SMTP id 74so142914421ioc.2 for ; Sat, 28 Nov 2015 19:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=procabiak.com; s=procabiakindustries; h=mime-version:date:message-id:subject:from:to:content-type; bh=laxidY28zm3avuFN6uAwQR+zMms3pyYq74y3gHVGRnA=; b=YQF62DOm40DvMHKGY3fWfqc0E+CbpOban4YgciaJRcxU1wJgAmlmhtcoNXv7XhKkyz XkUEW+8wpgVA0KYOBIlJryP/BJS6aPbUojuU54agi/qpETannLFbULMfhwPMR22yfMeB jbF5qqs5/MFf9C4rJ/9Y46z9PhbUUnmcSi7p0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=laxidY28zm3avuFN6uAwQR+zMms3pyYq74y3gHVGRnA=; b=aMspLKGzWJ+Tpdb/QgfwfAosoRCFSrBUiRlIHCUoyQuo32mnkCgjG5KtlkcvJS71LU 6lljaVi4FwUqQoo66ds6lAW8Tbffze1iZ7MWIl/UcQF4T04Evrc63wwrMoGQvKR9gWzY hVtHoEJXNyysRh3zXrUJX0bIdgY2EvXsVVxkzAXpTOiMenwv5pvD+1N3UKJzrPrSBcvi i312B90thCxOCLmXupjvKormkN8Xxcexc7ADDGZ7/2PSCtFrYaQSCgNLPBEUJJDwiafD OuVwOe7VJIzxWEkAOzfcfyFmDs4Vp8jqfXFSa4nT5Pr598BwtjN/VYjRRQ7C2jpB7vf8 2BYg== X-Gm-Message-State: ALoCoQlgymao6NnvM6RvQ2jIOs1CQbGuqTzaRH5WaQidASsuFyUQ0AIaGd42s1spGW+nntDlR5Ng MIME-Version: 1.0 X-Received: by 10.107.47.66 with SMTP id j63mr31086192ioo.168.1448769014900; Sat, 28 Nov 2015 19:50:14 -0800 (PST) Received: by 10.36.129.10 with HTTP; Sat, 28 Nov 2015 19:50:14 -0800 (PST) X-Originating-IP: [14.202.127.219] Received: by 10.36.129.10 with HTTP; Sat, 28 Nov 2015 19:50:14 -0800 (PST) Date: Sun, 29 Nov 2015 14:50:14 +1100 Message-ID: From: Vincent Truong To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1136edec7ec8590525a5d2fd X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 04:32:48 +0000 Subject: [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 03:50:16 -0000 --001a1136edec7ec8590525a5d2fd Content-Type: text/plain; charset=UTF-8 (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. --001a1136edec7ec8590525a5d2fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

(I haven't been following this development recently so a= pologies 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/3ul1kb/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.

--001a1136edec7ec8590525a5d2fd--