1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D61A59B
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 29 Nov 2015 11:55:09 +0000 (UTC)
Received: by vkha189 with SMTP id a189so87947284vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CACrzPe=LMGW6HGoUii4pog0Ezn3kEv9_US==0XPUXHp1ivzuuw@mail.gmail.com>
References: <CACrzPe=LMGW6HGoUii4pog0Ezn3kEv9_US==0XPUXHp1ivzuuw@mail.gmail.com>
Date: Sun, 29 Nov 2015 12:55:08 +0100
Message-ID: <CABm2gDq_KKhtvgvT6G=rpsv28acV7pDX1cR6Gd5gpNNofm3wKQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Vincent Truong <vincent.truong@procabiak.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<p dir=3D"ltr">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.</p>
<div class=3D"gmail_quote">On Nov 29, 2015 5:33 AM, "Vincent Truong vi=
a bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attri=
bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">(I haven't been f=
ollowing this development recently so apologies in advance if I've made=
assumptions about RBF)</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">Copy/Paste from my reddit post:</p>
<p dir=3D"ltr"><a href=3D"https://www.reddit.com/r/Bitcoin/comments/3ul1kb/=
slug/cxgegkj" target=3D"_blank">https://www.reddit.com/r/Bitcoin/comments/3=
ul1kb/slug/cxgegkj</a><br></p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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>
<p dir=3D"ltr">> 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.)</p>
<p dir=3D"ltr">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.</p>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>
--001a114363789898780525ac9860--
|
