{"type":"rich","version":"1.0","author_name":"npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","author_url":"https://nostr.ae/npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-22\n📝 Original message:IMO the moderate success of BIP70 is caused by its complexity. Since the\namount of data in a BIP70 payment request does not fit in a bitcoin:\nURI, an https server is required to serve the requests.\n\nOnly large merchants are able to maintain such an infrastructure; (even\nCoinbase recently failed at it, they forgot to update their\ncertificate). For end users that is completely unpractical.\n\nThe main benefit of BIP70 is that the payment request is signed by the\nrequestor; this gives the sender a proof that they are sending to the\nright person, and that the person actually requested the payment.\n\nThe same benefit can be achieved without the complexity of BIP70, by\nextending the Bitcoin URI scheme. The requestor is authenticated using\nDNSSEC, and the payment request is signed using an EC private key. A\ndomain name and an EC signature are short enough to fit in a Bitcoin URI\nand to be shared by QR code or SMS text.\n\n bitcoin:address?amount=xx\u0026message=yyy\u0026name=john.example.com\u0026sig=zzz\n\nThe URI scheme is extended with two fields:\n name: DNS name containing a public key or bitcoin address\n sig: signature\n\nThat extension is sufficient to provide authenticated requests, without\nrequiring a https server. The signed data can be serialized from the\nURI, and DNSSEC verification succeeds without requesting extra data from\nthe requestor. The only assumption is that the verifier is able to make\nDNS requests.\n\nI am willing to write a BIP if other wallet developers are interested.\n\n\n\n\nLe 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :\n\u003e BIP 0070 has been a a moderate success, however, IMO:\n\u003e \n\u003e - protocol buffers are inappropriate since ease of use and extensibility is\n\u003e desired over the minor gains of efficiency in this protocol.  Not too late\n\u003e to support JSON messages as the standard going forward\n\u003e \n\u003e - problematic reliance on merchant-supplied https (X509) as the sole form\n\u003e of mechant identification.   alternate schemes (dnssec/netki), pgp and\n\u003e possibly keybase seem like good ideas.   personally, i like keybase, since\n\u003e there is no reliance on the existing domain-name system (you can sell with\n\u003e a github id, for example)\n\u003e \n\u003e - missing an optional client supplied identification\n\u003e \n\u003e - lack of basic subscription support\n\u003e \n\u003e *Proposed for subscriptions:*\n\u003e \n\u003e - BIP0047 payment codes are recommended instead of wallet addresses when\n\u003e establishing subscriptions.  Or, merchants can specify replacement\n\u003e addresses in ACK/NACK responses.   UI confirms are *required *when there\n\u003e are no replacement addresses or payment codes used.\n\u003e \n\u003e - Wallets must confirm and store subscriptions, and are responsible for\n\u003e initiating them at the specified interval.\n\u003e \n\u003e - Intervals can *only *be from a preset list: weekly, biweekly, or 1,\n\u003e 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause\n\u003e suspension until the user re-verifies.\n\u003e \n\u003e - Wallets *may *optionally ask the user whether they want to be notified\n\u003e and confirm every interval - or not.   Wallets that do not ask *must *notify\n\u003e before initiating each payment.   Interval confirmations should begin at *least\n\u003e *1 day in advance of the next payment.\n\u003e \n\u003e \n\u003e *Proposed in general:*\n\u003e - JSON should be used instead of protocol buffers going forward.  Easier to\n\u003e use, explain extend.\n\u003e \n\u003e - \"Extendible\" URI-like scheme to support multi-mode identity mechanisms on\n\u003e both payment and subscription requests.   Support for keybase://, netki://\n\u003e and others as alternates to https://.\n\u003e \n\u003e - Support for client as well as merchant multi-mode verification\n\u003e \n\u003e - Ideally, the identity verification URI scheme is somewhat\n\u003e orthogonal/independent of the payment request itself\n\u003e \n\u003e Question:\n\u003e \n\u003e Should this be a new BIP?  I know netki's BIP75 is out there - but I think\n\u003e it's too specific and too reliant on the domain name system.\n\u003e \n\u003e Maybe an identity-protocol-agnostic BIP + solid implementation of a couple\n\u003e major protocols without any mention of payment URI's ... just a way of\n\u003e sending and receiving identity verified messages in general?\n\u003e \n\u003e I would be happy to implement plugins for identity protocols, if anyone\n\u003e thinks this is a good idea.\n\u003e \n\u003e Does anyone think https:// or keybase, or PGP or netki all by themselves,\n\u003e is enough - or is it always better to have an extensible protocol?\n\u003e \n\u003e - Erik Aronesty\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}