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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
|
Return-Path: <srintuar@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 49CB69EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Oct 2018 00:29:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7AF5C701
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Oct 2018 00:29:55 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id l14-v6so20930323edq.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Oct 2018 17:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=1W5gZTlIPKI8lMAAWRHTXHtqpDbXJlerHHFFzpI5CWQ=;
b=tBlBkMWzhXOH1bFrUqBoi5EqDOms4M7q1B9H6Uv0n/xliyOSyTVHhirPtdS41PjMBA
zuhNqDIiAc41TCWhnf9WWB+G8Qj42FUQkSoy+vE3hI3DpL21unExnL2AXqgQgWUCAv8W
k7QIEw1R2SdLqYSTdwNlbXzjjIOxNzKhE9Dz3yg/2aTBgRPLkmGlmK/+8K8HL+mVzKwU
HaVvt5EyayDrsLVn5hibP3jNyS9ZaGJ3L1aDd7c9Hxs+p9Ds7VmX+vl0qPiAs5Id6d15
o6TW7+zDNMc+WZZjdHZyzT5aIWplfRjBpLkPSbAuWOeYTgWQJ1UIpWoRxyPTLkufoRHF
6eOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=1W5gZTlIPKI8lMAAWRHTXHtqpDbXJlerHHFFzpI5CWQ=;
b=tsXJPk+NM5+6ZxlGPMCXdZy1JfbH+tu7TMbfgs+DaUMT1fpc0oxfgX0uA5iBoIlopg
+BScPji0SiI6J+S7TNlJ0+90W3O4kDZFxd4YlxA8t2H5s2vL8+dlk6veM5qyhRfG/hIc
s4ibENMvcaotzsrP3sEFn96tkB0F6Ki98PNxXQRVZ2u1K/rImBGwxiweVv6kLtoEOZAd
S4hgDZ7MQq0QFl/IfnkVEYl6vGoIi98PKp4vfal7h2kWUD7iIRMudAzOeZkT2gstakGF
QTeirfXVy7swWgIiELTP59DWB2ysUW/Jf+IW+E1LgYpj+sOiUJl0YTqZuIWjDXdfNNGF
BCQQ==
X-Gm-Message-State: ABuFfogXkM4rRlQ+ewHb2MmfXn4SvV8eWWxxAYlJoPnhdQ9ObRTqQwVR
L8fLx1THM66t3qaKtaVHJr8A/lwdft5BfFCvVtjriVjU
X-Google-Smtp-Source: ACcGV62LflvBwPZA1KONvAa68c9kcCPhakvGNH8KsuVROHqe21epQQv2fMZBN8pmTVmMN2KevkY5flNPOh2WTy8h69w=
X-Received: by 2002:a50:9043:: with SMTP id
z3-v6mr4625863edz.216.1539908993980;
Thu, 18 Oct 2018 17:29:53 -0700 (PDT)
MIME-Version: 1.0
From: Srintuar <srintuar@gmail.com>
Date: Thu, 18 Oct 2018 20:29:42 -0400
Message-ID: <CACUQsLKPk6n6DrXiuoLAKbYAEXrYZeJTs+1F8M6u5v0ReqQAeA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000929cf605788a0083"
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: Fri, 19 Oct 2018 04:30:24 +0000
Subject: [bitcoin-dev] Reformatted BIP proposal for address backward
compatibility
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: Fri, 19 Oct 2018 00:29:56 -0000
--000000000000929cf605788a0083
Content-Type: text/plain; charset="UTF-8"
I have included the comma delimited list in the proposal this time.
It occurs to me that it is simpler to just include the desired destination
script, so I included that as well as an alternative.
Perhaps that should be included as an option in the spec, at the risk of
additional complexity. Alternatively, it could replace the entire
proposal....
---------------------------------------------------
A simple BIP writeup for a backward compatible URI scheme to help with
segwit adoption by online stores and metchants.
====
This BIP is a modification of an earlier [[bip-0021.mediawiki|BIP 0021]] by
Nils Schneider and Matt Corallo
==Abstract==
This BIP proposes a URI scheme which allows for backward compatibility with
native segwit (bech32) wallets and legacy wallets (base58)
==Motivation==
The purpose of this URI scheme is to enable all users to easily make
payments from any wallet, without allowing backward compatibility to be a
barrier to segwit adoption. This BIP allows a merchant to preferentially
receive payments to a bech32 address, while gracefully allowing older
clients to make base58 encoded payments.
A comma separated, ordered list of preferred addresses is supplied as
alternatives to the address field from BIP21. The list is ordered from most
preferred to least, with the BIP21 address implicitly last. Senders should
send to the first address which they know how to send to.
==Specification==
=== Query Keys ===
*address: an ordered list bitcoin destination which is preferred over the
"address" of the url, in order from most preferred to less, with the url
address value as least preferred
=== ABNF Grammar ===
bitcoinaddress = base58 / bech32 / <future address format>
bitcoinaddresslist = bitcoinaddress [ "," bitcoinaddresslist ]
== Appendix ==
=== Simpler syntax ===
<nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>][?address=<bitcoinaddresslist>]</nowiki>
=== Examples ===
Just the address:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
QR size: ~370 bytes
The address and other fields:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy&amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz
QR size: ~470 bytes
Multiple addresses:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1qq82ajthl5mlm50h6x70esvxs7atp3vfnjwp8z5kjdepsjqqw3zcs9u4nnp,bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
QR size: ~540 bytes
== Reference Implementations ==
=== Bitcoin clients ===
* none yet
== Alternative Proposal ==
Just include the desired script itself, encoded as hex:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?script=0014a70aa2014fbc2151e0a5da78a8dead358d3af384
=== Pros ===
* Infinite forward compatibility with any future script design
* Raw hex encoded scripts are short, and thus would make easy to scan images
* no need for list processing, or multiple alternatives
=== Cons ==
* address encoding features including checksum and network identification
would be absent
* errors in script formation not detectable by the sender; risk of funds
loss if the script is spendable but incorrect
* all error detection depends on the QR code or other transmission medium
* A separate top level uri scheme, such as bitcoinscript:<hex> might be
more appropriate, but would cost backwards compatibility
--000000000000929cf605788a0083
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>I have included the c=
omma delimited list in the proposal this time. <br></div><div></div><div>It=
occurs to me that it is simpler to just include the desired destination sc=
ript, so I included that as well as an alternative.</div><div><br></div><di=
v>Perhaps that should be included as an option in the spec, at the risk of =
additional complexity. Alternatively, it could replace the entire proposal.=
...<br></div><div><br></div><div><br></div><div><br></div><div><br></div><d=
iv>---------------------------------------------------</div><div><br></div>=
<div>A simple BIP writeup for a backward compatible URI scheme to help with=
segwit adoption by online stores and metchants.<br></div><div><br></div><d=
iv><br>=3D=3D=3D=3D<br><br><br>This BIP is a modification of an earlier [[b=
ip-0021.mediawiki|BIP 0021]] by Nils Schneider and Matt Corallo<br><br>=3D=
=3DAbstract=3D=3D<br>This BIP proposes a URI scheme which allows for backwa=
rd compatibility with native segwit (bech32) wallets and legacy wallets (ba=
se58)<br><br>=3D=3DMotivation=3D=3D<br>The purpose of this URI scheme is to=
enable all users to easily make payments from any wallet, without allowing=
backward compatibility to be a barrier to segwit adoption. This BIP allows=
a merchant to preferentially receive payments to a bech32 address, while g=
racefully allowing older clients to make base58 encoded payments.<br><br>A =
comma separated, ordered list of preferred addresses is supplied as alterna=
tives to the address field from BIP21. The list is ordered from most prefer=
red to least, with the BIP21 address implicitly last. Senders should send t=
o the first address which they know how to send to.<br><br>=3D=3DSpecificat=
ion=3D=3D<br><br>=3D=3D=3D Query Keys =3D=3D=3D<br><br>*address: an ordered=
list bitcoin destination which is preferred over the "address" o=
f the url, in order from most preferred to less, with the url address value=
as least preferred<br><br>=3D=3D=3D ABNF Grammar =3D=3D=3D<br><br>=C2=A0=
=C2=A0=C2=A0 bitcoinaddress =3D base58 / bech32 / <future address format=
><br>=C2=A0=C2=A0=C2=A0 bitcoinaddresslist =3D bitcoinaddress [ ",&=
quot; bitcoinaddresslist ]<br><br>=3D=3D Appendix =3D=3D<br><br>=3D=3D=3D S=
impler syntax =3D=3D=3D<br><br>=C2=A0<nowiki>bitcoin:<address>[=
?amount=3D<amount>][?label=3D<label>][?message=3D<message>=
;][?address=3D<bitcoinaddresslist>]</nowiki><br><br>=3D=3D=3D E=
xamples =3D=3D=3D<br><br>Just the address:<br>=C2=A0bitcoin:3BnsWZiTdYVrqiP=
h2RP3q9Y3ZqvhbCN2it?address=3Dbc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy<br=
>=C2=A0QR size: ~370 bytes <br><br>The address and other fields:<br>=C2=A0b=
itcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=3Dbc1q5u92yq20hss4rc99mfu23h=
4dxkxn4uuyqd5dzy&amount=3D50&label=3DLuke-Jr&message=3DDonation=
%20for%20project%20xyz<br>=C2=A0QR size: ~470 bytes<br><br><br>Multiple add=
resses:<br>=C2=A0bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=3Dbc1qq=
82ajthl5mlm50h6x70esvxs7atp3vfnjwp8z5kjdepsjqqw3zcs9u4nnp,bc1q5u92yq20hss4r=
c99mfu23h4dxkxn4uuyqd5dzy <br>=C2=A0QR size: ~540 bytes<br><br><br>=3D=3D R=
eference Implementations =3D=3D<br><br>=3D=3D=3D Bitcoin clients =3D=3D=3D<=
br><br>* none yet<br><br>=3D=3D Alternative Proposal =3D=3D<br><br>Just inc=
lude the desired script itself, encoded as hex:<br><br>=C2=A0bitcoin:3BnsWZ=
iTdYVrqiPh2RP3q9Y3ZqvhbCN2it?script=3D0014a70aa2014fbc2151e0a5da78a8dead358=
d3af384<br><br>=3D=3D=3D Pros =3D=3D=3D<br><br>* Infinite forward compatibi=
lity with any future script design<br>* Raw hex encoded scripts are short, =
and thus would make easy to scan images<br>* no need for list processing, o=
r multiple alternatives<br><br>=3D=3D=3D Cons =3D=3D<br><br>* address encod=
ing features including checksum and network identification would be absent<=
br>* errors in script formation not detectable by the sender; risk of funds=
loss if the script is spendable but incorrect<br>* all error detection dep=
ends on the QR code or other transmission medium<br>* A separate top level =
uri scheme, such as bitcoinscript:<hex> might be more appropriate, bu=
t would cost backwards compatibility<br><br><br><br><br><br><br><br></div><=
/div></div>
--000000000000929cf605788a0083--
|
