{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-22\n📝 Original message:\u003e Only large merchants are able to maintain such an infrastructure; (even\n\u003e Coinbase recently failed at it, they forgot to update their\n\u003e certificate). For end users that is completely unpractical.\n\u003e\n\nPayment protocol is for when you buy stuff from purse.io, not really needed\nfor face-to face transfers, end users, IMO.\n\n\n\u003e The same benefit can be achieved without the complexity of BIP70, by\n\u003e extending the Bitcoin URI scheme. The requestor is authenticated using\n\u003e DNSSEC, and the payment request is signed using an EC private key. A\n\u003e domain name and an EC signature are short enough to fit in a Bitcoin URI\n\u003e and to be shared by QR code or SMS text.\n\u003e\n\u003e  bitcoin:address?amount=xx\u0026message=yyy\u0026name=john.example.com\u0026sig=zzz\n\u003e\n\nI agree.  A TXT record at that name could contain the pubkey.\n\n\n\u003e That extension is sufficient to provide authenticated requests, without\n\u003e requiring a https server. The signed data can be serialized from the\n\u003e URI, and DNSSEC verification succeeds without requesting extra data from\n\u003e the requestor. The only assumption is that the verifier is able to make\n\u003e DNS requests.\n\u003e\n\nThe problem is that there's no way for a merchant to *refuse *a payment\nwithout a direct communication with the merchant's server.    Verify first\n/ clear later is the rule.   Check stock, ensure you can deliver, and clear\nthe payment on the way out the door.\n\nAlso, as a merchant processing monthly subscriptions, you don't want the\nfirst time you hear about a user's payment to be *after *it hits the\nblockchain.  You could add a refund address to deal with it after the\nfact... stuff a refund address int OP_RETURN somehow?\n\nbitcoin:address?amount=xx\u0026currency=ccc\u0026message=yyy\u0026name=john.example.com\n\u0026offset=3d\u0026interval=1m\u0026sig=zzz\n\n... But what if the merchant simply goes out of business.  No OP_RETURN\nwill help you here.   You'll be posting transactions into a dead wallet.\nYou could have some way of posting a \"ping\" transaction, and then\nmonitoring for a valid response.   But this is \"spamming the blockchain for\ncommunications\".\n\nNo, I think BIP075 is fine.   You just need to extend the *PaymentAck *with\na single field, instead of just having a memo.\n\nnext_payment_days : integer\n\nThe wallet, when it sees this field, re-initiates an invoice request after\nthe selected number of days, after presenting the user with the content of\nthe memo field which will presumably explain the subscription.   Wallet\nvendors can let users \"auto approve\" vendors as needed.\n\nThis is, I think, the absolute minimum needed to update BIP0070/0075 for\nsubscriptions.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160622/69c8ccf9/attachment.html\u003e"}