{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-09-12\n📝 Original message:Putting aside the question of necessity for a moment, a more efficient\napproach to this would be;\n\n   1. Add another marker param like \u0026s to the end of the URL\n   2. Add another field to PaymentRequest that contains an ECC signature\n   calculated using the public key that hashes to the address in the URI\n   3. Upgraded wallets look for the additional param and if it's there,\n   expect to find the PaymentDetails signed with the address key. PKI signing\n   of course is still useful to provide an actual identity for receipts,\n   display on hardware wallets, dispute mediation etc.\n\nThis adds only a few characters to a normal backwards-compatible QR code,\nand is not hard to implement.\n\n\nOn Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e That way we leave up to implementers to experiment with different\n\u003e\u003e lengths and figure out what the optimum is\n\u003e\n\u003e\n\u003e Ah, that's a good suggestion if we do go this way.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140912/7122a333/attachment.html\u003e"}