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 2F23725A for ; Tue, 21 Jun 2016 19:58:16 +0000 (UTC) X-Greylist: delayed 00:07:13 by SQLgrey-1.7.6 Received: from uschroder.com (uschroder.com [74.142.93.202]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 41BE8162 for ; Tue, 21 Jun 2016 19:58:15 +0000 (UTC) Received: from [192.168.253.4] (cpe-96-28-21-149.kya.res.rr.com [96.28.21.149]) by uschroder.com (Postfix) with ESMTPSA id 37A56233AF3A0 for ; Tue, 21 Jun 2016 15:51:00 -0400 (EDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Andy Schroder Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Message-ID: <57699AA3.2010601@AndySchroder.com> Date: Tue, 21 Jun 2016 15:50:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rmALiIJEvrw17pApNTJvXtwjWV9gjIQDu" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 20:25:55 +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 19:58:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rmALiIJEvrw17pApNTJvXtwjWV9gjIQDu Content-Type: multipart/mixed; boundary="Aka4RehA38qadrN3fnuA0OeH8q39s46U8" From: Andy Schroder To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <57699AA3.2010601@AndySchroder.com> Subject: Re: Even more proposed BIP extensions to BIP 0070 References: In-Reply-To: --Aka4RehA38qadrN3fnuA0OeH8q39s46U8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Bluetooth exchange of payment requests already has a noticeable lag with = protocol buffers, so that would be another reason to argue against JSON, = because JSON is less efficient size wise, correct? I will say that=20 although protocol buffers have good platform support, I don't know that=20 the documentation for each platform is very good. This is the main=20 drawback I see with them. One additional advantage of protocol buffers=20 is that the .proto file is a specification, whereas with JSON, you'd=20 just have an example file, right? Isn't keybase a centralized infrastructure? Are you against a blockchain = based identification? There are a few out there. There is some confusion = because onename's efforts are breaking away from namecoin though. I like the idea of PGP signatures of payment requests. This allows for=20 manual verification (in my mind, the highest quality) of key=20 authenticity (or, with PGP you also have the option to opt into some=20 centralized service for key verification). This can be useful when=20 dealing with semi-manually issued invoices for goods and services. The=20 local bitcoin wallet could just interact with the local PGP keyring.=20 Although, one can already just send the payment request in a PGP signed=20 e-mail, so I'm not sure if PGP signing is really needed if you're using=20 PGP email. The main benefit may just be consolidating/itemizing into=20 your bitcoin wallet's transaction history whether the payment=20 destination/request was securely received or not. It may also be useful=20 for someone to be able to extract a signed payment request from a signed = PGP e-mail and send it to someone else to make a payment for you (maybe=20 you don't want your accounting person to need your entire e-mail=20 correspondence with a supplier to be able to just verify the payment=20 request and make a payment for your company). I'm concerned about extending the URI scheme too much. Isn't this going=20 to reach the practical size limit of NFC and QR codes pretty quickly? Andy Schroder On 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote: > Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen > because of its strong types, less vulnerability to malleability and ver= y > good platform support. Having coded both, I can say Protobuf is not mor= e > difficult than JSON. (Actually the entire Bitcoin P2P protocol should b= e > based on Protobuf, but that's another story.) > > 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. > > > On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote: >> BIP 0070 has been a a moderate success, however, IMO: >> >> - protocol buffers are inappropriate since ease of use and extensibili= ty >> is desired over the minor gains of efficiency in this protocol. Not t= oo >> late to support JSON messages as the standard going forward >> >> - problematic reliance on merchant-supplied https (X509) as the sole >> form of mechant identification. alternate schemes (dnssec/netki), pg= p >> and possibly keybase seem like good ideas. personally, i like keybas= e, >> since there is no reliance on the existing domain-name system (you can= >> sell with a github id, for example) >> >> - missing an optional client supplied identification >> >> - lack of basic subscription support >> >> /Proposed for subscriptions:/ >> >> - BIP0047 payment codes are recommended instead of wallet addresses wh= en >> establishing subscriptions. Or, merchants can specify replacement >> addresses in ACK/NACK responses. UI confirms are /required /when the= re >> are no replacement addresses or payment codes used. >> >> - Wallets must confirm and store subscriptions, and are responsible fo= r >> initiating them at the specified interval. >> >> - Intervals can /only /be from a preset list: weekly, biweekly, or 1, >> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause >> suspension until the user re-verifies. >> >> - Wallets /may /optionally ask the user whether they want to be notifi= ed >> and confirm every interval - or not. Wallets that do not ask /must >> /notify before initiating each payment. Interval confirmations shoul= d >> begin at /least /1 day in advance of the next payment. >> >> /Proposed in general: >> / >> - JSON should be used instead of protocol buffers going forward. Easi= er >> to use, explain extend. >> >> - "Extendible" URI-like scheme to support multi-mode identity mechanis= ms >> on both payment and subscription requests. Support for keybase://, >> netki:// and others as alternates to https://. >> >> - Support for client as well as merchant multi-mode verification >> >> - Ideally, the identity verification URI scheme is somewhat >> orthogonal/independent of the payment request itself >> >> Question: >> >> Should this be a new BIP? I know netki's BIP75 is out there - but I >> think it's too specific and too reliant on the domain name system. >> >> Maybe an identity-protocol-agnostic BIP + solid implementation of a >> couple major protocols without any mention of payment URI's ... just a= >> way of sending and receiving identity verified messages in general? >> >> I would be happy to implement plugins for identity protocols, if anyon= e >> thinks this is a good idea. >> >> Does anyone think https:// or keybase, or PGP or netki all by >> themselves, is enough - or is it always better to have an extensible >> protocol? >> >> - Erik Aronesty >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> --Aka4RehA38qadrN3fnuA0OeH8q39s46U8-- --rmALiIJEvrw17pApNTJvXtwjWV9gjIQDu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXaZqjAAoJEDT679stRBhrGzQH/2ewQYaqvpQ8E3gGJmfF52mh 31hYcs4kVOjfbMxMYCzvnCs60lb/sYY870H25yX9wnnJdKwgpFlPJ0Y4dWbrKdfZ jOFecQaH5lFpLWWDEgj3YYKrupRgF0wtZ71rpLHJQF3psH2aBKIk6RRGoj/8T+yz dIrY17C7k0HVTpsDb1/oSbT2UU8k3U5obUV2ZRqURWPZquQ1eiLhf33NPppL7DfH 7xTYNyXpCO0btOvmapY/bWemNTFlk1glaVr/7nXFspojdMyQDRbU0Yfdr1lQYTd3 9xmN/s/OESMzYKMan1BEX3us8JliHorByQezuI8PYAkeu5NXgO+IbTmXhWfbJQw= =zQ2j -----END PGP SIGNATURE----- --rmALiIJEvrw17pApNTJvXtwjWV9gjIQDu--