Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]