rich1.0npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://nostr.ae📅 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>