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
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <info@AndySchroder.com>) id 1YJWGv-0002qt-Na
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:55:45 +0000
X-ACL-Warn:
Received: from uschroder.com ([74.142.93.202])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YJWGt-0002uQ-3h for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:55:45 +0000
Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com
[74.137.24.201])
by uschroder.com (Postfix) with ESMTPSA id 34F1922B83D96;
Thu, 5 Feb 2015 18:38:19 -0500 (EST)
Message-ID: <54D3FEE9.70502@AndySchroder.com>
Date: Thu, 05 Feb 2015 18:38:17 -0500
From: Andy Schroder <info@AndySchroder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <544174F8.1050208@AndySchroder.com>
In-Reply-To: <544174F8.1050208@AndySchroder.com>
X-Enigmail-Version: 1.6
OpenPGP: id=2D44186B;
url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="K8Wo9PsI2omGvHPArXUuj9BU2efV1ns9n"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YJWGt-0002uQ-3h
Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth
Communication and bitcoin: URI Scheme Improvements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2015 23:55:45 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--K8Wo9PsI2omGvHPArXUuj9BU2efV1ns9n
Content-Type: multipart/alternative;
boundary="------------090301090306050507010303"
This is a multi-part message in MIME format.
--------------090301090306050507010303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Hello,
With the recent discussion started today regarding another bluetooth=20
communication proposal created by Airbitz, I'd like to bring people's=20
attention back to this proposal that saw little discussion last fall. I=20
guess I'm not sure why two proposals are being created. Is their some=20
advantage of using bluetooth low energy over standard bluetooth (I'm not =
well versed in bluetooth low energy)? This NFC coupled approach seems to =
avoid a lot of issues with identifying the correct payee. You can see=20
this proposed scheme demonstrated in action in a POS application in the=20
video link below which demonstrates it with my fuel pump and Andreas=20
Schildbach's wallet.
There was a small discussion that occurred after my original=20
announcement below. If you are new to this e-mail list, you can find an=20
archive of those few replies here:=20
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/=
msg06354.html
Since this original announcement, a few improvements have been made to=20
the proposal:
1. Improved documentation and explanation of the use cases in
Schildbach's wallet's wiki
1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Request=
s
2. Issue with the payment_url field has resolved by changing to a
repeated field and requiring the wallet to search for the protocol
they want to use, rather than expecting it to be a certain element
number in the list.
1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediaw=
iki
Although there are some interesting use cases of Airbitz's proposal's=20
work flow, tapping an NFC radio with a 5 mm range requires much less=20
brain power and time than picking the correct name on the app's screen.=20
The manual name picking is going to be especially crazy in a very=20
congested location. The payer isn't ever going to want to have to try=20
and figure out what register or payment terminal they are at for most=20
applications I would ever use.
I'd like to see something happen with this technology. I've also noticed =
that micropayment channels have little formality to being established=20
practically and it would be awesome if they could be managed over=20
bluetooth as well. Maybe more improvements to the payment protocol can=20
simultaneously result (and also extended to bluetooth) that embrace the=20
establishment of micropayment channels.
Andy Schroder
On 10/17/2014 03:58 PM, Andy Schroder wrote:
> Hello,
>
> I'd like to introduce two proposed BIPs. They are primarily focused on =
> implementing the payment protocol using bluetooth connections. I've=20
> been working on automated point of sale devices and bluetooth=20
> communication is critical in my mind due to the potential lack of=20
> internet access at many points of sale, either due to lack of cellular =
> internet coverage, lack of payee providing wireless internet, and/or=20
> due to financial constraints of the payer prohibiting them from=20
> maintaining a cellular internet service plan. These BIPs are largely=20
> modeled after the current functionality of Andreas Schildbach's=20
> android Bitcoin Wallet's bluetooth capability. I've discussed the=20
> communication scheme with him in depth and believe these proposals to=20
> clearly and accurately represent the communication scheme.
>
> There is also an additional &h=3D parameter added to the bitcoin: URI=20
> scheme which applies to both bluetooth and http payment protocol=20
> requests which allows for a hash of the payment request to be=20
> included. This hash was proposed by Andreas as an amendment to BIP72,=20
> but others preferred not to amend BIP72 since it has already been put=20
> into place. The current version of Schildbach's bitcoin wallet already =
> supports the "h parameter".
>
> I'd appreciate feedback from everyone, particularly wallet developers=20
> as widespread bluetooth support among wallets is very important to me. =
> I'm also very new to this mailing list as well as the BIP writing=20
> process, so I'd appreciate your understanding if my conventions are=20
> not standard. I am currently using the naming conventions "TBIP", so=20
> that I can propose /temporary/ BIP numbers, and cross reference=20
> between the two. Obviously these will change if the BIPs are formally=20
> adopted. You can find a copy of these proposed BIPs at the following=20
> links:
>
> * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawik=
i
> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawik=
i
>
>
> If you are interested, you can see a demonstration of many of the=20
> proposed features using Schildbach's wallet and my fuel pump in a=20
> video I recently created: https://youtu.be/kkVAhA75k1Y . The main=20
> thing not implemented is multiple URLs for the payment protocol, so,=20
> as a hack, I'm just presenting https vi QR code and bluetooth via NFC=20
> on my fuel pump for now.
>
>
>
> There are a few known issues that could be improved to this bluetooth=20
> communication scheme as well as the general payment protocol and=20
> myself and Andreas would like to receive feedback regarding concerns=20
> and potential solutions. Some of the known issues are:
>
> * There may seem to be some inconsistency in the connection header
> messages between the payment request connection and the payment
> connection. This is largely because it is how Andreas originally
> implemented the communication and is hesitant to change it since
> there are many instances of is software already deployed that
> implement this scheme.
> * The current method uses an unauthenticated bluetooth connection
> for bluetooth 2.1 and newer devices (subject to man in the middle
> attacks, but not passive eavesdroppers), and an unsecure and
> unauthenticated connection for older devices. The known concerns
> here are that someone within 100 meters of the payer could track
> the bitcoin addresses used for the transaction and could possibly
> replace the refund address by submitting a forged payment message
> to the payee. Requiring bluetooth 2.1 and authenticating the
> connection out of band unfortunately don't seem to be as
> straightforward/simple of a task with most bluetooth libraries
> (although I'd love for someone to prove me wrong). It's possible
> this communication scheme could be extended to use an https "like"
> protocol that would not care if the underlying bluetooth
> connection is authenticated or encrypted. It's actually possible
> that http over a bluetooth socket (instead of tcp socket) could be
> implemented, however it is presently uncertain whether this would
> be too slow, too much overhead (both on the devices software and
> communication), or if http could easily be run over bluetooth
> sockets on all platforms.
> * There is no acknowledgement failure message possible in the
> payment protocol, only an acknowledgement message or lack of
> acknowledgement message. This issue seems to be a concern and as a
> result, the memo field is used to send an "ack" or "nack" in
> Schildbach's wallet. Can we add a boolean status field to the
> payment acknowledgement message?
> * I'd personally like a new optional boolean field added to the
> "PaymentDetails" portion of the "PaymentRequest" to allow for the
> payer's wallet to match the "Output" optional "amount" fields as a
> total amount of all Outputs, rather than requiring the amount for
> each output to be matched exactly. As it currently is, the payee
> can specify multiple receiving addresses in order to require a
> payer split up the payments so that when the payee then goes to
> spend the funds later, they don't necessarily have to give their
> payees as much knowledge of their balances and spending and
> receiving habits and sources. As the payment protocol currently is
> requiring all output amounts to be matched exactly for each
> output, there is no flexibility given to the payer in order to
> reduce a merging or unnecessary diverging of account funds, which
> can reduce the privacy of both the payer and the payee. If the
> payee were given the option to allow the payer the option to
> divide the amounts amount the outputs intelligently, there can be
> some privacy gained.
> * Amount of data stored in QR codes may be getting large when a
> backwards compatible URL is used (for wallets that don't support
> the payment protocol) and can be difficult to scan with outdoor
> screens that have an extra weather resistant pane when in direct
> sunlight.
> * The number of offline transactions of a wallet is limited to the
> known unspent outputs when they go offline. Long term, I'd like to
> see wallet devices that can use systems such as Kryptoradio's
> DVB-T based broadcast (but this will need yet another radio!).
> Another project may be to develop a blockchain query protocol of
> some kind where retailers can provide access to blockchain data so
> that customer's wallets can update their known unspent outputs via
> bluetooth. It's possible such a bluetooth system could be used in
> combination of "Kryptoradio" like broadcasts to provide multiple
> blockchain references.
> * The additional payment_url approach is a bit sloppy of a solution
> in the PaymentDetails portion of the PaymentRequest. It would have
> been ideal to just change this from an optional field to a
> repeated field, however, the backwards compatibility in the
> protocol buffer format will provide the last item in the array for
> a repeated field (to a code that expects it to be an optional
> field), rather than the first. Because of this, backwards
> compatibility with https payment requests wouldn't work if the
> payment_url field is just changed to a repeated field.
> o Possible alternatives to what is described in the proposed BIP
> + Change payment_url to a repeated field and then reverse
> the order of the parameter numbers in the payment_url,
> compared to the bitcoin URL "r parameter".
> + Create an additional, new payment_url_multi repeated field
> (or some better name), and then leave the original
> payment_url field in there for backwards compatibility
> (and then maybe phase it out in the future).
> o Reference
> + https://developers.google.com/protocol-buffers/docs/proto#u=
pdating
> # "|optional| is compatible with |repeated|. Given
> serialized data of a repeated field as input, clients
> that expect this field to be |optional| will take the
> last input value if it's a primitive type field or
> merge all input elements if it's a message type field."=
>
>
>
> Your comments and suggestions would be greatly appreciated.
>
> --=20
> Andy Schroder
>
--------------090301090306050507010303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Hello,<br>
<br>
With the recent discussion started today regarding another
bluetooth communication proposal created by Airbitz, I'd like to
bring people's attention back to this proposal that saw little
discussion last fall. I guess I'm not sure why two proposals are
being created. Is their some advantage of using bluetooth low
energy over standard bluetooth (I'm not well versed in bluetooth
low energy)? This NFC coupled approach seems to avoid a lot of
issues with identifying the correct payee. You can see this
proposed scheme demonstrated in action in a POS application in the
video link below which demonstrates it with my fuel pump and
Andreas Schildbach's wallet.<br>
<br>
There was a small discussion that occurred after my original
announcement below. If you are new to this e-mail list, you can
find an archive of those few replies here:
<a class=3D"moz-txt-link-freetext" href=3D"https://www.mail-archive.com/b=
itcoin-development%40lists.sourceforge.net/msg06354.html">https://www.mai=
l-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html</=
a><br>
<br>
Since this original announcement, a few improvements have been
made to the proposal:<br>
<ol>
<li>Improved documentation and explanation of the use cases in
Schildbach's wallet's wiki</li>
<ol>
<li><a class=3D"moz-txt-link-freetext" href=3D"https://github.c=
om/schildbach/bitcoin-wallet/wiki/Payment-Requests">https://github.com/sc=
hildbach/bitcoin-wallet/wiki/Payment-Requests</a></li>
</ol>
<li>Issue with the payment_url field has resolved by changing to
a repeated field and requiring the wallet to search for the
protocol they want to use, rather than expecting it to be a
certain element number in the list.</li>
<ol>
<li><a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"=
href=3D"https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediaw=
iki">https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki=
</a></li>
</ol>
</ol>
<br>
Although there are some interesting use cases of Airbitz's
proposal's work flow, tapping an NFC radio with a 5 mm range
requires much less brain power and time than picking the correct
name on the app's screen. The manual name picking is going to be
especially crazy in a very congested location. The payer isn't
ever going to want to have to try and figure out what register or
payment terminal they are at for most applications I would ever
use.<br>
<br>
I'd like to see something happen with this technology. I've also
noticed that micropayment channels have little formality to being
established practically and it would be awesome if they could be
managed over bluetooth as well. Maybe more improvements to the
payment protocol can simultaneously result (and also extended to
bluetooth) that embrace the establishment of micropayment
channels.<br>
<br>
<br>
<br>
<pre class=3D"moz-signature" cols=3D"72">Andy Schroder</pre>
On 10/17/2014 03:58 PM, Andy Schroder wrote:<br>
</div>
<blockquote cite=3D"mid:544174F8.1050208@AndySchroder.com" type=3D"ci=
te">
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
Hello,<br>
<br>
I'd like to introduce two proposed BIPs. They are primarily
focused on implementing the payment protocol using bluetooth
connections. I've been working on automated point of sale devices
and bluetooth communication is critical in my mind due to the
potential lack of internet access at many points of sale, either
due to lack of cellular internet coverage, lack of payee providing
wireless internet, and/or due to financial constraints of the
payer prohibiting them from maintaining a cellular internet
service plan. These BIPs are largely modeled after the current
functionality of Andreas Schildbach's android Bitcoin Wallet's
bluetooth capability. I've discussed the communication scheme with
him in depth and believe these proposals to clearly and accurately
represent the communication scheme.<br>
<br>
There is also an additional &h=3D parameter added to the
bitcoin: URI scheme which applies to both bluetooth and http
payment protocol requests which allows for a hash of the payment
request to be included. This hash was proposed by Andreas as an
amendment to BIP72, but others preferred not to amend BIP72 since
it has already been put into place. The current version of
Schildbach's bitcoin wallet already supports the "h parameter".<br>=
<br>
I'd appreciate feedback from everyone, particularly wallet
developers as widespread bluetooth support among wallets is very
important to me. I'm also very new to this mailing list as well as
the BIP writing process, so I'd appreciate your understanding if
my conventions are not standard. I am currently using the naming
conventions "TBIP", so that I can propose <i>temporary</i> BIP
numbers, and cross reference between the two. Obviously these will
change if the BIPs are formally adopted. You can find a copy of
these proposed BIPs at the following links:<br>
<ul>
<li><a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediaw=
iki">https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki=
</a></li>
<li><a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
href=3D"https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediaw=
iki">https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki=
</a><br>
</li>
</ul>
<br>
If you are interested, you can see a demonstration of many of the
proposed features using Schildbach's wallet and my fuel pump in a
video I recently created: <a moz-do-not-send=3D"true"
class=3D"moz-txt-link-freetext"
href=3D"https://youtu.be/kkVAhA75k1Y">https://youtu.be/kkVAhA75k1=
Y</a>
. The main thing not implemented is multiple URLs for the payment
protocol, so, as a hack, I'm just presenting https vi QR code and
bluetooth via NFC on my fuel pump for now.<br>
<br>
<br>
<br>
There are a few known issues that could be improved to this
bluetooth communication scheme as well as the general payment
protocol and myself and Andreas would like to receive feedback
regarding concerns and potential solutions. Some of the known
issues are:<br>
<br>
<ul>
<li>There may seem to be some inconsistency in the connection
header messages between the payment request connection and the
payment connection. This is largely because it is how Andreas
originally implemented the communication and is hesitant to
change it since there are many instances of is software
already deployed that implement this scheme.</li>
<li>The current method uses an unauthenticated bluetooth
connection for bluetooth 2.1 and newer devices (subject to man
in the middle attacks, but not passive eavesdroppers), and an
unsecure and unauthenticated connection for older devices. The
known concerns here are that someone within 100 meters of the
payer could track the bitcoin addresses used for the
transaction and could possibly replace the refund address by
submitting a forged payment message to the payee. Requiring
bluetooth 2.1 and authenticating the connection out of band
unfortunately don't seem to be as straightforward/simple of a
task with most bluetooth libraries (although I'd love for
someone to prove me wrong). It's possible this communication
scheme could be extended to use an https "like" protocol that
would not care if the underlying bluetooth connection is
authenticated or encrypted. It's actually possible that http
over a bluetooth socket (instead of tcp socket) could be
implemented, however it is presently uncertain whether this
would be too slow, too much overhead (both on the devices
software and communication), or if http could easily be run
over bluetooth sockets on all platforms.</li>
<li>There is no acknowledgement failure message possible in the
payment protocol, only an acknowledgement message or lack of
acknowledgement message. This issue seems to be a concern and
as a result, the memo field is used to send an "ack" or "nack"
in Schildbach's wallet. Can we add a boolean status field to
the payment acknowledgement message?<br>
</li>
<li>I'd personally like a new optional boolean field added to
the "PaymentDetails" portion of the <span class=3D"nc">"Payment=
Request"
to allow for the payer's wallet to match the "Output"
optional "amount" fields as a total amount of all Outputs,
rather than requiring the amount for each output to be
matched exactly. As it currently is, the payee can specify
multiple receiving addresses in order to require a payer
split up the payments so that when the payee then goes to
spend the funds later, they don't necessarily have to give
their payees as much knowledge of their balances and
spending and receiving habits and sources. As the payment
protocol currently is requiring all output amounts to be
matched exactly for each output, there is no flexibility
given to the payer in order to reduce a merging or
unnecessary diverging of account funds, which can reduce the
privacy of both the payer and the payee. If the payee were
given the option to allow the payer the option to divide the
amounts amount the outputs intelligently, there can be some
privacy gained.</span></li>
<li><span class=3D"nc">Amount of data stored in QR codes may be
getting large when a backwards compatible URL is used (for
wallets that don't support the payment protocol) and can be
difficult to scan with outdoor screens that have an extra
weather resistant pane when in direct sunlight.</span></li>
<li><span class=3D"nc">The number of offline transactions of a
wallet is limited to the known unspent outputs when they go
offline. </span>Long term, I'd like to see wallet devices
that can use systems such as Kryptoradio's DVB-T based
broadcast (but this will need yet another radio!). Another
project may be to develop a blockchain query protocol of some
kind where retailers can provide access to blockchain data so
that customer's wallets can update their known unspent outputs
via bluetooth. It's possible such a bluetooth system could be
used in combination of "Kryptoradio" like broadcasts to
provide multiple blockchain references.</li>
<li>The additional payment_url approach is a bit sloppy of a
solution in the PaymentDetails portion of the PaymentRequest.
It would have been ideal to just change this from an optional
field to a repeated field, however, the backwards
compatibility in the protocol buffer format will provide the
last item in the array for a repeated field (to a code that
expects it to be an optional field), rather than the first.
Because of this, backwards compatibility with https payment
requests wouldn't work if the payment_url field is just
changed to a repeated field.</li>
<ul>
<li>Possible alternatives to what is described in the proposed
BIP</li>
<ul>
<li>Change payment_url to a repeated field and then reverse
the order of the parameter numbers in the payment_url,
compared to the bitcoin URL "r parameter".</li>
<li>Create an additional, new payment_url_multi repeated
field (or some better name), and then leave the original
payment_url field in there for backwards compatibility
(and then maybe phase it out in the future).<br>
</li>
</ul>
<li>Reference<br>
</li>
<ul>
<li><a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetex=
t"
href=3D"https://developers.google.com/protocol-buffers/docs/proto#updatin=
g">https://developers.google.com/protocol-buffers/docs/proto#updating</a>=
</li>
<ul>
<li>"<code>optional</code> is compatible with <code>repeate=
d</code>.
Given serialized data of a repeated field as input,
clients that expect this field to be <code>optional</code=
>
will take the last input value if it's a primitive type
field or merge all input elements if it's a message type
field."</li>
</ul>
</ul>
</ul>
</ul>
<br>
<br>
Your comments and suggestions would be greatly appreciated.<br>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
Andy Schroder</pre>
<br>
</blockquote>
<br>
</body>
</html>
--------------090301090306050507010303--
--K8Wo9PsI2omGvHPArXUuj9BU2efV1ns9n
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJU0/7pAAoJEDT679stRBhrURMIAIOD1h+1m2CelyBbwObbX1M6
5GjWVY7ehC9Vu6JmJYO41ZbctY/qgaRrKWsDOxChLjB2K9xdOpVa6MWyvhgAIayj
jkvGm9tj2qPoOHsDX9NZ2c7oy3jPkBmbW45UoslhU5vzVTt6ddaqJFrUmQVdCjC/
E+2awd8RaxSq67pNipoGj6hLVO9JBwLNBrI4t7dxrzIKAG8pDRicNQSMEZigokxj
JBZ0yEBTW1VDSw7tKFTHcdmj2b4azJ641Fvi/Hf7zPNxtehPnr32QGPlIbLgi+fE
6V5wHhZscJJUVg+9TDzb01zpOTenOoJMpUZneuKXCmrrYrN41OM4QkdYKCy3+yw=
=kD8R
-----END PGP SIGNATURE-----
--K8Wo9PsI2omGvHPArXUuj9BU2efV1ns9n--
|