š
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>;
Erik Aronesty [ARCHIVE] /
npub1y2ā¦5taj0
2023-06-07 17:51:17
in reply to nevent1qā¦vzjz
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:51:17Event JSON
{
"id": "6538f0c662c72bc4b82743ad6ce937e34951e15d655973b8431e01f9253a8b2f",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686160277,
"kind": 1,
"tags": [
[
"e",
"a5039b46ff53fe0ad45fb1e565b7c7f05169b35d2126c2ee18198a6f3405f573",
"",
"root"
],
[
"e",
"d90c512d92cf91639f8683a6104597e13c98fbc42e5db3a990f81bdb88b59c9e",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "š
Original date posted:2016-06-21\nš Original message:On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen\n\u003e because of its strong types, less vulnerability to malleability and very\n\u003e good platform support. Having coded both, I can say Protobuf is not more\n\u003e difficult than JSON. (Actually the entire Bitcoin P2P protocol should be\n\u003e based on Protobuf, but that's another story.)\n\u003e\n\nI like protobuf, personally, for C++ stuff. I just imagined it would be\nharder on mobile, or in some languages, to implement. I'll focus on the\nscheduling issue. Really, that's the only thing I want hashed out.\n\n\n\u003e\n\u003e Yes, all extensions to BIP70 should go into new BIPs. Note the plural\n\u003e here: if you have orthogonal ideas I strongly suggest one BIP per idea\n\u003e so they can be discussed and implemented (or rejected) separately.\n\u003e\n\u003e\nI think the intervals should *not* be flexible, even at the protocol level,\nto prevent attacks designed to confuse users - plus for shorter intervals,\nyou need payment channels anyway. Also, I think the spec should be rigid\nwith respect to response times, retry periods, etc.... to encourage\nconsistency among wallet vendors. Not sure how anyone else feels about\nthat. I suspect the netki guys should have opinions, since they are\nworking on similar UI-stuff.\n\nShould UI standards go somewhere else - not in a BIP? I do think there\nneed to be UI standards. Something with RFC-style should/must/will/wont\nlanguage, like \"Wallet software *must* show unconfirmed transactions as\ndistinct from confirmed\", and \"Wallet software *should *show some visual\nindication of other levels of confirmation\" .... stuff like that.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/3d77b01a/attachment.html\u003e",
"sig": "f872cb11eb6ba3c02d39b8ae3e962a99ac4360c699d4b7509f8b01944d3e14d3c160cca29ed8d0c714568baf7fe79e19733977e3396b8987b0974e0d5cd40426"
}