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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WGs7a-0002Ds-62
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Feb 2014 15:34:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.181 as permitted sender)
client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f181.google.com;
Received: from mail-ob0-f181.google.com ([209.85.214.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGs7Z-0002e3-BF
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Feb 2014 15:34:38 +0000
Received: by mail-ob0-f181.google.com with SMTP id wp4so2286150obc.12
for <bitcoin-development@lists.sourceforge.net>;
Fri, 21 Feb 2014 07:34:31 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.213.166 with SMTP id nt6mr5809206obc.53.1392996871687;
Fri, 21 Feb 2014 07:34:31 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 21 Feb 2014 07:34:31 -0800 (PST)
In-Reply-To: <5303B110.70603@bitpay.com>
References: <le05ca$qn5$1@ger.gmane.org>
<5303B110.70603@bitpay.com>
Date: Fri, 21 Feb 2014 21:04:31 +0530
X-Google-Sender-Auth: qY8gVlKs3pyQugVQyHrE6K--On4
Message-ID: <CANEZrP25u1V2rv_XM1pKzxm4YvUec89Vf1OmVujJLFBzEmmbXA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Ryan X. Charles" <ryan@bitpay.com>
Content-Type: multipart/alternative; boundary=001a11c2e60ab5fa9604f2ec5bdf
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WGs7Z-0002e3-BF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 proposed changes
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: Fri, 21 Feb 2014 15:34:38 -0000
--001a11c2e60ab5fa9604f2ec5bdf
Content-Type: text/plain; charset=UTF-8
>
> One more thing. The new bitcoin URI in BIP 72 is extremely long and
> makes for very dense QR codes.
BIP 73 seems OK except that existing wallets that can scan QR codes will
choke. One reason the new URIs are long is for backwards compatibility.
One thing that makes the URI smaller is not escaping the payment URL -
bitcoinj/Bitcoin Wallet at least does not require it, and it reduces the
size of the QR code by a non-trivial amount.
Removing the https:// and just defaulting to it also saves some bytes.
Finally, BitPay is using rather long invoice IDs. Do you really need an ID
like JkLdFhQVFqmUurXpPXZcRp? That's a really huge ID space and the invoices
expire fast. So you could potentially implement a short mapping on the
server side and make much smaller IDs that way.
--001a11c2e60ab5fa9604f2ec5bdf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
One more thing. The new bitcoin URI in BIP 72 is extremely long and<br>
makes for very dense QR codes.</blockquote><div><br></div><div>BIP 73 seems=
OK except that existing wallets that can scan QR codes will choke. One rea=
son the new URIs are long is for backwards compatibility.</div><div><br>
</div><div>One thing that makes the URI smaller is not escaping the payment=
URL - bitcoinj/Bitcoin Wallet at least does not require it, and it reduces=
the size of the QR code by a non-trivial amount.</div><div><br></div><div>
Removing the https:// and just defaulting to it also saves some bytes.</div=
><div><br></div><div>Finally, BitPay is using rather long invoice IDs. Do y=
ou really need an ID like=C2=A0JkLdFhQVFqmUurXpPXZcRp? That's a really =
huge ID space and the invoices expire fast. So you could potentially implem=
ent a short mapping on the server side and make much smaller IDs that way.<=
/div>
</div></div></div>
--001a11c2e60ab5fa9604f2ec5bdf--
|
