Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder <info@AndySchroder.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5847 bytes --]

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 
although protocol buffers have good platform support, I don't know that 
the documentation for each platform is very good. This is the main 
drawback I see with them. One additional advantage of protocol buffers 
is that the .proto file is a specification, whereas with JSON, you'd 
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 
manual verification (in my mind, the highest quality) of key 
authenticity (or, with PGP you also have the option to opt into some 
centralized service for key verification). This can be useful when 
dealing with semi-manually issued invoices for goods and services. The 
local bitcoin wallet could just interact with the local PGP keyring. 
Although, one can already just send the payment request in a PGP signed 
e-mail, so I'm not sure if PGP signing is really needed if you're using 
PGP email. The main benefit may just be consolidating/itemizing into 
your bitcoin wallet's transaction history whether the payment 
destination/request was securely received or not. It may also be useful 
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 
you don't want your accounting person to need your entire e-mail 
correspondence with a supplier to be able to just verify the payment 
request and make a payment for your company).

I'm concerned about extending the URI scheme too much. Isn't this going 
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 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.)
>
> 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 extensibility
>> is desired over the minor gains of efficiency in this protocol.  Not too
>> 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), pgp
>> and possibly keybase seem like good ideas.   personally, i like keybase,
>> 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 when
>> establishing subscriptions.  Or, merchants can specify replacement
>> addresses in ACK/NACK responses.   UI confirms are /required /when there
>> are no replacement addresses or payment codes used.
>>
>> - Wallets must confirm and store subscriptions, and are responsible for
>> 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 notified
>> and confirm every interval - or not.   Wallets that do not ask /must
>> /notify before initiating each payment.   Interval confirmations should
>> begin at /least /1 day in advance of the next payment.
>>
>> /Proposed in general:
>> /
>> - JSON should be used instead of protocol buffers going forward.  Easier
>> to use, explain extend.
>>
>> - "Extendible" URI-like scheme to support multi-mode identity mechanisms
>> 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 anyone
>> 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
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]