path: root/24/b75c2bab691ee91b7aab67e6a3a4cb111b4f3e

Return-Path: <info@AndySchroder.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F23725A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jun 2016 15:51:00 -0400 (EDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<nkb27k$5bi$1@ger.gmane.org>
From: Andy Schroder <info@AndySchroder.com>
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: <nkb27k$5bi$1@ger.gmane.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <info@AndySchroder.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <57699AA3.2010601@AndySchroder.com>
Subject: Re: Even more proposed BIP extensions to BIP 0070
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
 <nkb27k$5bi$1@ger.gmane.org>
In-Reply-To: <nkb27k$5bi$1@ger.gmane.org>

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