public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32•com>
To: Andreas Schildbach <andreas@schildbach•de>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Tue, 21 Jun 2016 13:09:41 -0400	[thread overview]
Message-ID: <CAJowKgKA4UphM7O7i53WtLGV7_b-ve+o=nuWv6K7nw6LOcQFkQ@mail.gmail.com> (raw)
In-Reply-To: <nkb27k$5bi$1@ger.gmane.org>

[-- 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 --]

  reply	other threads:[~2016-06-21 17:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 17:33 Erik Aronesty
2016-06-21  9:43 ` Andreas Schildbach
2016-06-21 17:09   ` Erik Aronesty [this message]
2016-06-21 19:50   ` Andy Schroder
2016-06-21 20:44 ` Luke Dashjr
2016-06-21 21:42   ` Erik Aronesty
2016-06-22  0:36     ` Luke Dashjr
2016-06-21 22:10   ` Peter Todd
2016-06-21 22:19   ` Peter Todd
2016-06-21 20:56 ` James MacWhyte
2016-06-21 21:17   ` Matt David
2016-06-21 22:13 ` Peter Todd
2016-06-21 22:50   ` James MacWhyte
2016-06-21 23:02     ` Peter Todd
2016-06-22  0:14   ` Justin Newton
2016-06-23 10:56     ` Peter Todd
2016-06-23 11:30       ` Pieter Wuille
2016-06-23 11:39         ` Peter Todd
2016-06-23 12:01           ` Pieter Wuille
2016-06-23 12:10             ` Peter Todd
2016-06-23 12:16               ` Pieter Wuille
2016-06-23 12:43                 ` Peter Todd
2016-06-23 13:03       ` Erik Aronesty
2016-06-23 16:58       ` Aaron Voisine
2016-06-23 20:46       ` s7r
2016-06-23 21:07         ` Justin Newton
2016-06-23 21:31           ` Police Terror
2016-06-23 22:44             ` Justin Newton
2016-06-24  2:26               ` Erik Aronesty
2016-06-24  5:27                 ` James MacWhyte
2016-06-22  7:57 ` Thomas Voegtlin
2016-06-22 14:25   ` Erik Aronesty
2016-06-22 15:12     ` Andy Schroder
2016-06-22 15:30       ` Erik Aronesty
2016-06-22 16:20         ` Andy Schroder
2016-06-22 17:07           ` Erik Aronesty
2016-06-22 20:11             ` James MacWhyte
2016-06-22 20:37               ` Erik Aronesty
2016-06-23 11:50     ` Andreas Schildbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJowKgKA4UphM7O7i53WtLGV7_b-ve+o=nuWv6K7nw6LOcQFkQ@mail.gmail.com' \
    --to=erik@q32$(echo .)com \
    --cc=andreas@schildbach$(echo .)de \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox