summaryrefslogtreecommitdiff
path: root/50/4c726403524dec7cd9253bcd122f34819f7f6a
blob: 8aefb917e22eac6feff8703e006cfd7ed0e7ee61 (plain)
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
Return-Path: <cryptaxe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5908FC9D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  5 Dec 2017 19:40:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com
	[209.85.128.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6939E411
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  5 Dec 2017 19:40:44 +0000 (UTC)
Received: by mail-wr0-f175.google.com with SMTP id x49so1513383wrb.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 05 Dec 2017 11:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=g9aBezQzXKn9ARRPls96oq4xGxM1g6B4amGmVp+3W0o=;
	b=RI8nMskXBTh0o8Vp/EbxMuBgOD7tIERaST72rTvrJUwE3JZJ6piRfDBLKgIfgsbjL4
	cE2u44ciWXTjMfdKBzNAtzYfoZHr0bqTebbL5Cyx9VXaJhs9oZoAF81TbuZN5awEuYj6
	GqvIMEQWwrAEmOzZ/cZbZA16XkI9zPp1dfSfmhfUdxmKnN2ClFe2jeVnBgGhqUA9ZxLP
	ASWN3EaAB/2F0HlSPpTi0TRFwnPH1l6IDTT2cL/wg0rDlLKeG4ShmP8IFsykheto24J2
	bRQccsLOJdNBgimYGwnkXpqR2fPnGZbARZkie32nBE5v3zPNAzhmfCKCHMYvqW1rmmSR
	SRyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=g9aBezQzXKn9ARRPls96oq4xGxM1g6B4amGmVp+3W0o=;
	b=GlEDzQdSnYtuLjPAshUFsBoYuKHBnNCq/8HYPtGj3+4bItA9CLprM8l9KVQacMFD5Y
	R4aiZicboQPlo7lTpR0AgUYm2lXdBP6vsNGV4F0bvXBBTlZK3YWVyOIP45rUjf9oz+Pb
	//soEa/w7fNksv+OaXe6otMvQ26aVlnT81XyR9TV7WMR5fMWhKO9tIePk5BtSjtNCBP9
	sPcrCu3d1z9Lz9/8SC0hLso6aiRAUysWTyYIxIcs2kvh3TowJgoTPZVrThyD1jrGtj2K
	WTDEXZPI8JqvYsnLsxtAoFvnnG7oeBQf7OnCE6Mc9U0nkUkTGHvf96l2jvu9nqKVg3Ll
	rxEQ==
X-Gm-Message-State: AJaThX7sPBgSS6NFRlWbDxwoFw4sVvjm9nCLm2ECSZdmrvGJps6jHjCS
	wpbXA2mr0qzHYZUcoUoOmMTWWgsVUV+NTfBDRX0=
X-Google-Smtp-Source: AGs4zMbrB4Sk8BG9FMi0SO2C7GiqjlJBNkVyNmkC0rY671MRe2cTa6dQdtC5dJ82OY85x9IVvfR7NwACEehMcjen7lQ=
X-Received: by 10.223.151.136 with SMTP id s8mr18270799wrb.94.1512502842996;
	Tue, 05 Dec 2017 11:40:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.146.69 with HTTP; Tue, 5 Dec 2017 11:40:42 -0800 (PST)
Received: by 10.28.146.69 with HTTP; Tue, 5 Dec 2017 11:40:42 -0800 (PST)
In-Reply-To: <AE14915B-37DF-4D94-A0B1-E32A26903807@sprovoost.nl>
References: <AE14915B-37DF-4D94-A0B1-E32A26903807@sprovoost.nl>
From: CryptAxe <cryptaxe@gmail.com>
Date: Tue, 5 Dec 2017 11:40:42 -0800
Message-ID: <CAF5CFkhwj5BHPndasvX5zYzmVwOF09XxzZo8hQO_f_1L3Vc+cg@mail.gmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1b4f1eadbf43055f9d02d9"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Tue, 05 Dec 2017 20:05:14 +0000
Cc: Matt Corallo <matt@chaincode.com>
Subject: Re: [bitcoin-dev] BIP-21 amendment proposal: -no125
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 05 Dec 2017 19:40:45 -0000

--94eb2c1b4f1eadbf43055f9d02d9
Content-Type: text/plain; charset="UTF-8"

Perhaps instead of a flag that can be used to disable a specific operation,
there should be a "-ignoredflags=x,y,z" section of the URI that can be used
to ignore whatever BIP this might also be useful for in the future?

On Dec 5, 2017 11:34 AM, "Sjors Provoost via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125
> [0]. It allows wallets to recommend lower fees, because if a transaction
> gets stuck due to underestimation, the fee can easily be bumped.
>
> Bitcoin Core has had support for RBF for a while, and as of v0.15.0
> recommends lower fees [1] when the user chooses to use RBF.
>
> I recently submitted a pull request that would turn on RBF by default,
> which triggered some discussion [2]. To ease the transition for merchants
> who are reluctant to see their customers use RBF, Matt Corallo suggested
> that wallets honor a no125=1 flag.
>
> So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=20.
> 3&no125=1
>
> When this flag is set, wallets should not use RBF, regardless of their
> default, unless the user explicitly overrides the merchant's preference.
>
> Afaik adding this flag won't break existing BIP-21 support. It doesn't use
> the req- prefix, because it's optional. I'm also not aware of any ad hoc
> standards that use no125 in BIP-21-ish URIs.
>
> - Sjors
>
> P.S. I'd similarly suggest adding a bech32 param, but that's for another
> discussion
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
> [1] https://bitcoincore.org/en/2017/09/01/release-0.15.0/#
> better-fee-estimates
> [2] https://github.com/bitcoin/bitcoin/pull/11605
> [3] https://github.com/bitcoin/bitcoin/issues/11828
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c1b4f1eadbf43055f9d02d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><span style=3D"font-family:sans-serif">Perhaps instead of=
 a flag that can be used to disable a specific operation, there should be a=
 &quot;-ignoredflags=3Dx,y,z&quot; section of the URI that can be used to i=
gnore whatever BIP this might also be useful for in the future?=C2=A0</span=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Dec 5, =
2017 11:34 AM, &quot;Sjors Provoost via bitcoin-dev&quot; &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125 [=
0]. It allows wallets to recommend lower fees, because if a transaction get=
s stuck due to underestimation, the fee can easily be bumped.<br>
<br>
Bitcoin Core has had support for RBF for a while, and as of v0.15.0 recomme=
nds lower fees [1] when the user chooses to use RBF.<br>
<br>
I recently submitted a pull request that would turn on RBF by default, whic=
h triggered some discussion [2]. To ease the transition for merchants who a=
re reluctant to see their customers use RBF, Matt Corallo suggested that wa=
llets honor a no125=3D1 flag.<br>
<br>
So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=3D20.<wbr>3=
&amp;no125=3D1<br>
<br>
When this flag is set, wallets should not use RBF, regardless of their defa=
ult, unless the user explicitly overrides the merchant&#39;s preference.<br=
>
<br>
Afaik adding this flag won&#39;t break existing BIP-21 support. It doesn&#3=
9;t use the req- prefix, because it&#39;s optional. I&#39;m also not aware =
of any ad hoc standards that use no125 in BIP-21-ish URIs.<br>
<br>
- Sjors<br>
<br>
P.S. I&#39;d similarly suggest adding a bech32 param, but that&#39;s for an=
other discussion<br>
<br>
[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bi=
ps/blob/master/bip-0125.<wbr>mediawiki</a><br>
[1] <a href=3D"https://bitcoincore.org/en/2017/09/01/release-0.15.0/#better=
-fee-estimates" rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.or=
g/en/<wbr>2017/09/01/release-0.15.0/#<wbr>better-fee-estimates</a><br>
[2] <a href=3D"https://github.com/bitcoin/bitcoin/pull/11605" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/11605<=
/a><br>
[3] <a href=3D"https://github.com/bitcoin/bitcoin/issues/11828" rel=3D"nore=
ferrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bitcoin/issues/11=
828</a><br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--94eb2c1b4f1eadbf43055f9d02d9--