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; 
MIME-Version: 1.0
Sender: g.rowe.froot@gmail.com
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
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
Precedence: list

--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 &quot;am=
ount&quot; field. BIP 20 proposes that &quot;amount&quot; 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">&lt;<a href=3D"mailt=
o:luke@dashjr.org">luke@dashjr.org</a>&gt;</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>
&gt; Speaking on behalf of the MultiBit team (Jim&#39;s currently on holida=
y), we<br>
&gt; will not be supporting Tonal Bitcoins anytime soon. Therefore we back =
the<br>
&gt; 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--