{"type":"rich","version":"1.0","author_name":"npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","author_url":"https://nostr.ae/npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-09-12\n📝 Original message:Are there any circumstances where the payment request object might be\nserved over a different domain than the CNAME of the object's signer?\n\nBIP72 states \"Bitcoin wallets must support fetching PaymentRequests\nvia http and https protocols;\". If the request object is signed by the\nowner of the domain, then the worst an attacker who doesn't have the\nsigning key can do is replace the request with another validly signed\nrequest intended for someone else, but that could be the attacker's\nown product order, tricking someone else into paying for it.\n\nShould BIP72 require that signed payment requests be from the same\ndomain, and also require https?\n\nAaron\n\nAaron Voisine\nbreadwallet.com\n\n\nOn Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Putting aside the question of necessity for a moment, a more efficient\n\u003e approach to this would be;\n\u003e\n\u003e Add another marker param like \u0026s to the end of the URL\n\u003e Add another field to PaymentRequest that contains an ECC signature\n\u003e calculated using the public key that hashes to the address in the URI\n\u003e Upgraded wallets look for the additional param and if it's there, expect to\n\u003e find the PaymentDetails signed with the address key. PKI signing of course\n\u003e is still useful to provide an actual identity for receipts, display on\n\u003e hardware wallets, dispute mediation etc.\n\u003e\n\u003e This adds only a few characters to a normal backwards-compatible QR code,\n\u003e and is not hard to implement.\n\u003e\n\u003e\n\u003e On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e That way we leave up to implementers to experiment with different\n\u003e\u003e\u003e lengths and figure out what the optimum is\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Ah, that's a good suggestion if we do go this way.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Want excitement?\n\u003e Manually upgrade your production database.\n\u003e When you want reliability, choose Perforce\n\u003e Perforce version control. Predictably reliable.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=157508191\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}