MIME-Version: 1.0
Sender: earonesty@gmail.com
In-Reply-To: <nkb27k$5bi$1@ger.gmane.org>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<nkb27k$5bi$1@ger.gmane.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 21 Jun 2016 13:09:41 -0400
Message-ID: <CAJowKgKA4UphM7O7i53WtLGV7_b-ve+o=nuWv6K7nw6LOcQFkQ@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c08bc360d13aa0535cce385
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Precedence: list

--94eb2c08bc360d13aa0535cce385
Content-Type: text/plain; charset=UTF-8

On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having coded both, I can say Protobuf is not more
> difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
> based on Protobuf, but that's another story.)
>

I like protobuf, personally, for C++ stuff.  I just imagined it would be
harder on mobile, or in some languages, to implement.   I'll focus on the
scheduling issue.  Really, that's the only thing I want hashed out.


>
> Yes, all extensions to BIP70 should go into new BIPs. Note the plural
> here: if you have orthogonal ideas I strongly suggest one BIP per idea
> so they can be discussed and implemented (or rejected) separately.
>
>
I think the intervals should *not* be flexible, even at the protocol level,
to prevent attacks designed to confuse users  - plus for shorter intervals,
you need payment channels anyway.  Also, I think the spec should be rigid
with respect to response times, retry periods, etc.... to encourage
consistency among wallet vendors.   Not sure how anyone else feels about
that.  I suspect the netki guys should have opinions, since they are
working on similar UI-stuff.

Should UI standards go somewhere else - not in a BIP?  I do think there
need to be UI standards.  Something with RFC-style should/must/will/wont
language, like "Wallet software *must* show unconfirmed transactions as
distinct from confirmed", and "Wallet software *should *show some visual
indication of other levels of confirmation" ....  stuff like that.

--94eb2c08bc360d13aa0535cce385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bi=
tcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Protobuf vs. JSON was a de=
liberate decision. Afaik Protobuf was chosen<br>
because of its strong types, less vulnerability to malleability and very<br=
>
good platform support. Having coded both, I can say Protobuf is not more<br=
>
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be<br=
>
based on Protobuf, but that&#39;s another story.)<br></blockquote><div><br>=
<div>I like protobuf, personally, for C++ stuff.=C2=A0 I just imagined it=
=20
would be harder on mobile, or in some languages, to implement.=C2=A0=C2=A0 =
I&#39;ll=20
focus on the scheduling issue.=C2=A0 Really, that&#39;s the only thing I wa=
nt=20
hashed out.=C2=A0=C2=A0 <br></div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
<br>
Yes, all extensions to BIP70 should go into new BIPs. Note the plural<br>
here: if you have orthogonal ideas I strongly suggest one BIP per idea<br>
so they can be discussed and implemented (or rejected) separately.<br>
<span class=3D""><br></span></blockquote><div><br>I think the intervals sho=
uld *not* be
 flexible, even at the protocol level, to prevent attacks designed to=20
confuse users=C2=A0 - plus for shorter intervals, you need payment channels=
=20
anyway.=C2=A0 Also, I think the spec should be rigid with respect to respon=
se
 times, retry periods, etc.... to encourage consistency among wallet=20
vendors.=C2=A0=C2=A0 Not sure how anyone else feels about that.=C2=A0 I sus=
pect the netki guys should have opinions, since they are working on similar=
 UI-stuff.<br><br>Should UI standards go somewhere else - not in a BIP?=C2=
=A0 I do=20
think there need to be UI standards.=C2=A0 Something with RFC-style=20
should/must/will/wont language, like &quot;Wallet software <i>must</i> show=
 unconfirmed transactions as distinct from confirmed&quot;, and &quot;Walle=
t software <i>should </i>show some visual indication of other levels of con=
firmation&quot; ....=C2=A0 stuff like that.=C2=A0 <br></div></div><br></div=
></div>

--94eb2c08bc360d13aa0535cce385--