{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-21\n📝 Original message:Bluetooth exchange of payment requests already has a noticeable lag with \nprotocol buffers, so that would be another reason to argue against JSON, \nbecause JSON is less efficient size wise, correct? I will say that \nalthough protocol buffers have good platform support, I don't know that \nthe documentation for each platform is very good. This is the main \ndrawback I see with them. One additional advantage of protocol buffers \nis that the .proto file is a specification, whereas with JSON, you'd \njust have an example file, right?\n\nIsn't keybase a centralized infrastructure? Are you against a blockchain \nbased identification? There are a few out there. There is some confusion \nbecause onename's efforts are breaking away from namecoin though.\n\nI like the idea of PGP signatures of payment requests. This allows for \nmanual verification (in my mind, the highest quality) of key \nauthenticity (or, with PGP you also have the option to opt into some \ncentralized service for key verification). This can be useful when \ndealing with semi-manually issued invoices for goods and services. The \nlocal bitcoin wallet could just interact with the local PGP keyring. \nAlthough, one can already just send the payment request in a PGP signed \ne-mail, so I'm not sure if PGP signing is really needed if you're using \nPGP email. The main benefit may just be consolidating/itemizing into \nyour bitcoin wallet's transaction history whether the payment \ndestination/request was securely received or not. It may also be useful \nfor someone to be able to extract a signed payment request from a signed \nPGP e-mail and send it to someone else to make a payment for you (maybe \nyou don't want your accounting person to need your entire e-mail \ncorrespondence with a supplier to be able to just verify the payment \nrequest and make a payment for your company).\n\nI'm concerned about extending the URI scheme too much. Isn't this going \nto reach the practical size limit of NFC and QR codes pretty quickly?\n\n\n\n\nAndy Schroder\n\nOn 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote:\n\u003e Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen\n\u003e because of its strong types, less vulnerability to malleability and very\n\u003e good platform support. Having coded both, I can say Protobuf is not more\n\u003e difficult than JSON. (Actually the entire Bitcoin P2P protocol should be\n\u003e based on Protobuf, but that's another story.)\n\u003e\n\u003e Yes, all extensions to BIP70 should go into new BIPs. Note the plural\n\u003e here: if you have orthogonal ideas I strongly suggest one BIP per idea\n\u003e so they can be discussed and implemented (or rejected) separately.\n\u003e\n\u003e\n\u003e On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:\n\u003e\u003e BIP 0070 has been a a moderate success, however, IMO:\n\u003e\u003e\n\u003e\u003e - protocol buffers are inappropriate since ease of use and extensibility\n\u003e\u003e is desired over the minor gains of efficiency in this protocol.  Not too\n\u003e\u003e late to support JSON messages as the standard going forward\n\u003e\u003e\n\u003e\u003e - problematic reliance on merchant-supplied https (X509) as the sole\n\u003e\u003e form of mechant identification.   alternate schemes (dnssec/netki), pgp\n\u003e\u003e and possibly keybase seem like good ideas.   personally, i like keybase,\n\u003e\u003e since there is no reliance on the existing domain-name system (you can\n\u003e\u003e sell with a github id, for example)\n\u003e\u003e\n\u003e\u003e - missing an optional client supplied identification\n\u003e\u003e\n\u003e\u003e - lack of basic subscription support\n\u003e\u003e\n\u003e\u003e /Proposed for subscriptions:/\n\u003e\u003e\n\u003e\u003e - BIP0047 payment codes are recommended instead of wallet addresses when\n\u003e\u003e establishing subscriptions.  Or, merchants can specify replacement\n\u003e\u003e addresses in ACK/NACK responses.   UI confirms are /required /when there\n\u003e\u003e are no replacement addresses or payment codes used.\n\u003e\u003e\n\u003e\u003e - Wallets must confirm and store subscriptions, and are responsible for\n\u003e\u003e initiating them at the specified interval.\n\u003e\u003e\n\u003e\u003e - Intervals can /only /be from a preset list: weekly, biweekly, or 1,\n\u003e\u003e 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause\n\u003e\u003e suspension until the user re-verifies.\n\u003e\u003e\n\u003e\u003e - Wallets /may /optionally ask the user whether they want to be notified\n\u003e\u003e and confirm every interval - or not.   Wallets that do not ask /must\n\u003e\u003e /notify before initiating each payment.   Interval confirmations should\n\u003e\u003e begin at /least /1 day in advance of the next payment.\n\u003e\u003e\n\u003e\u003e /Proposed in general:\n\u003e\u003e /\n\u003e\u003e - JSON should be used instead of protocol buffers going forward.  Easier\n\u003e\u003e to use, explain extend.\n\u003e\u003e\n\u003e\u003e - \"Extendible\" URI-like scheme to support multi-mode identity mechanisms\n\u003e\u003e on both payment and subscription requests.   Support for keybase://,\n\u003e\u003e netki:// and others as alternates to https://.\n\u003e\u003e\n\u003e\u003e - Support for client as well as merchant multi-mode verification\n\u003e\u003e\n\u003e\u003e - Ideally, the identity verification URI scheme is somewhat\n\u003e\u003e orthogonal/independent of the payment request itself\n\u003e\u003e\n\u003e\u003e Question:\n\u003e\u003e\n\u003e\u003e Should this be a new BIP?  I know netki's BIP75 is out there - but I\n\u003e\u003e think it's too specific and too reliant on the domain name system.\n\u003e\u003e\n\u003e\u003e Maybe an identity-protocol-agnostic BIP + solid implementation of a\n\u003e\u003e couple major protocols without any mention of payment URI's ... just a\n\u003e\u003e way of sending and receiving identity verified messages in general?\n\u003e\u003e\n\u003e\u003e I would be happy to implement plugins for identity protocols, if anyone\n\u003e\u003e thinks this is a good idea.\n\u003e\u003e\n\u003e\u003e Does anyone think https:// or keybase, or PGP or netki all by\n\u003e\u003e themselves, is enough - or is it always better to have an extensible\n\u003e\u003e protocol?\n\u003e\u003e\n\u003e\u003e - Erik Aronesty\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/6970aa58/attachment.sig\u003e"}