From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 618D692 for ; Tue, 21 Jun 2016 17:09:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7826921B for ; Tue, 21 Jun 2016 17:09:43 +0000 (UTC) Received: by mail-yw0-f180.google.com with SMTP id v77so19818945ywg.0 for ; Tue, 21 Jun 2016 10:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=G+uBrEnCfjS/dzjVlhL9/xQ/chTTc60+sz2tIPC4aoM=; b=g+abeNx52co21ZAMheVWxh468X2Tqa5zvtVtUMSwfqrvyAOPtL4bzy7jxCa7vIbEqV GegTv4ch51hciQoMq0+SsKru6ZCxVR+jzx12OhwOYFV0NzBRlk0j1g8jR2DbXeJ9IN13 B+BO5JV5+FZ4DD769kELCIrNaT5he8pZjK6kO2o7QCDo0/P4mt3RlyHeFf/HffTZ6s3A uA7oDfMrMVRD+dpUWz4r40k7rxTtalZuswbXNGjkBny2JbNE2oCXbz2JZ73zFiQJdigb 0ukN6rT6jSvay5W1mwWTDE86QbWScW5tsq/ySajhjSOjy6J+92vCWqF+OxmzALcMbLju IC9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=G+uBrEnCfjS/dzjVlhL9/xQ/chTTc60+sz2tIPC4aoM=; b=m69IF+1NIrfTtm1+fcnuM8MA40/uN9jP5SPqBOoQ5uiE5tGsIwJLtAHzhj+bQORXDh Ag5kVEyazajehuZtu3BpUaFp2hB8VIHHQjQ1BN+ryXEKs/6yqrVGQGlhsNcW+fyoKMrH XDfzGOhpVe3miEUf50rXizu6uVjaT7oCJw0rIHmxkY8lmVuogVBYr6vLdbxcSPCUPzhX PfmmAkBmntRKGCD3pe/YqU3aHQJklVhFoiGb6tDB5DsGSt8GQMJ/xBGNUdHcDxMitKPC 4a7cSNdH5W6V0fXQmDTtovI1igKya7h51jvlED1RRcqaTqWCxHp1SxmXWJXM2JlpzepU uGnQ== X-Gm-Message-State: ALyK8tJQt7e7Bzwirwr1nAYBI207HYncVQBbhhddnChyb2GASqnfouGaFos6xgOVPtLakIVLx+3DqugRyxWRDA== X-Received: by 10.37.198.133 with SMTP id k127mr12398085ybf.53.1466528982436; Tue, 21 Jun 2016 10:09:42 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.72.68 with HTTP; Tue, 21 Jun 2016 10:09:41 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Tue, 21 Jun 2016 13:09:41 -0400 X-Google-Sender-Auth: 7yukxDmitipgMJ0kBINolHaw65A Message-ID: To: Andreas Schildbach , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c08bc360d13aa0535cce385 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 21 Jun 2016 17:18:33 +0000 Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 17:09:44 -0000 --94eb2c08bc360d13aa0535cce385 Content-Type: text/plain; charset=UTF-8 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. --94eb2c08bc360d13aa0535cce385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Protobuf vs. JSON was a de= liberate 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.=C2=A0 I just imagined it= =20 would be harder on mobile, or in some languages, to implement.=C2=A0=C2=A0 = I'll=20 focus on the scheduling issue.=C2=A0 Really, that's the only thing I wa= nt=20 hashed out.=C2=A0=C2=A0
=C2=A0

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 sho= uld *not* be flexible, even at the protocol level, to prevent attacks designed to=20 confuse users=C2=A0 - plus for shorter intervals, you need payment channels= =20 anyway.=C2=A0 Also, I think the spec should be rigid with respect to respon= se times, retry periods, etc.... to encourage consistency among wallet=20 vendors.=C2=A0=C2=A0 Not sure how anyone else feels about that.=C2=A0 I sus= pect the netki guys should have opinions, since they are working on similar= UI-stuff.

Should UI standards go somewhere else - not in a BIP?=C2= =A0 I do=20 think there need to be UI standards.=C2=A0 Something with RFC-style=20 should/must/will/wont language, like "Wallet software must show= unconfirmed transactions as distinct from confirmed", and "Walle= t software should show some visual indication of other levels of con= firmation" ....=C2=A0 stuff like that.=C2=A0

--94eb2c08bc360d13aa0535cce385--