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
|
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 <g.rowe.froot@gmail.com>) id 1Rrwfv-0006Se-4W
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 19:13:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.175 as permitted sender)
client-ip=209.85.160.175; envelope-from=g.rowe.froot@gmail.com;
helo=mail-gy0-f175.google.com;
Received: from mail-gy0-f175.google.com ([209.85.160.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rrwfu-0003zf-An
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 19:13:59 +0000
Received: by ghrr13 with SMTP id r13so412594ghr.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 11:13:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.115.231 with SMTP id e67mr28056576yhh.16.1327950832957;
Mon, 30 Jan 2012 11:13:52 -0800 (PST)
Sender: g.rowe.froot@gmail.com
Received: by 10.236.195.99 with HTTP; Mon, 30 Jan 2012 11:13:52 -0800 (PST)
In-Reply-To: <201201301356.16032.luke@dashjr.org>
References: <CAKm8k+1VFYSt7115KKGy5C7orFoU-N=8vfkQ_sc8onfQq96_Ww@mail.gmail.com>
<201201301356.16032.luke@dashjr.org>
Date: Mon, 30 Jan 2012 19:13:52 +0000
X-Google-Sender-Auth: E9g0zToAT9GutgOs6xwdYUzo5Kg
Message-ID: <CAKm8k+2JcZ++N76HOd+Obr1DR3gG9e+U-gVCHYyN_Eo-4+ciZw@mail.gmail.com>
From: Gary Rowe <g.rowe@froot.co.uk>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=20cf303b434fad797204b7c3a57d
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
(g.rowe.froot[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: 1Rrwfu-0003zf-An
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
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: Mon, 30 Jan 2012 19:13:59 -0000
--20cf303b434fad797204b7c3a57d
Content-Type: text/plain; charset=UTF-8
Having closely read the BIP20 proposal, I can see your point. As I see it,
BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
field. BIP 20 proposes that "amount" can contain alternative
representations, clearly defined, whereas BIP 21 requires the use of a
single representation in decimal notation.
In my view, BIP 21 still wins since it reduces complexity for the end
client both at the human and machine level.
On 30 January 2012 18:56, Luke-Jr <luke@dashjr.org> wrote:
> On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> > Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> > will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> > BIP 21 proposal.
>
> It is not correct to imply that BIP 20 requires Tonal Bitcoin support.
> In fact, the exact opposite is true; it states that even if one unit (eg,
> TBC)
> would be a more rational way to display a specified amount, clients should
> still interpret it in the way that is deemed to be most intuitive to the
> user
> (eg, BTC).
>
--20cf303b434fad797204b7c3a57d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Having closely read the BIP20 proposal, I can see your point. As I see it, =
BIP 20 vs BIP 21 is about standardising on a representation of the "am=
ount" field. BIP 20 proposes that "amount" can contain alter=
native representations, clearly defined, whereas BIP 21 requires the use of=
a single representation in decimal notation. <br>
<br>In my view, BIP 21 still wins since it reduces complexity for the end c=
lient both at the human and machine level. <br><br><div class=3D"gmail_quot=
e">On 30 January 2012 18:56, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailt=
o:luke@dashjr.org">luke@dashjr.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Mond=
ay, January 30, 2012 1:50:03 PM Gary Rowe wrote:<br>
> Speaking on behalf of the MultiBit team (Jim's currently on holida=
y), we<br>
> will not be supporting Tonal Bitcoins anytime soon. Therefore we back =
the<br>
> BIP 21 proposal.<br>
<br>
</div>It is not correct to imply that BIP 20 requires Tonal Bitcoin support=
.<br>
In fact, the exact opposite is true; it states that even if one unit (eg, T=
BC)<br>
would be a more rational way to display a specified amount, clients should<=
br>
still interpret it in the way that is deemed to be most intuitive to the us=
er<br>
(eg, BTC).<br>
</blockquote></div><br>
--20cf303b434fad797204b7c3a57d--
|
