Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-21 📝 Original message:On Tue, Jun 21, 2016 at ...
📅 Original date posted:2016-06-21
📝 Original message:On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/3d77b01a/attachment.html>;
📝 Original message:On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/3d77b01a/attachment.html>;