{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-11-27\n📝 Original message:RE: SignedReceipt:  I agree it is superfluous.  I'll remove it from the spec.\n\nRE: \"it is controversial use of the host key to use it for digital\nsigning of documents\"  :  The idea of embedding a x509 certificate\nchain comes from the IETF's JSON Object Signing and Encryption working\ngroup \"JWS\" specification, so I can't be TOO controversial.\n\nRE: the ifex-project and other electronic invoicing standards:  Thanks\nfor the pointers, Walter! I'm all for adopting the best ideas that\nhave come before, as long as we end up with something useful and small\nenough to convince ourselves it is as secure as we can make it. I\nlooked at the ifex spec, and quickly got lost. It would help me if you\ncould write up what our motivating use cases would look like if\nimplemented on top of ifex.\n\nRE: jgarzik's suggestion to allow txids in the Payment: that worries\nme, because it is trivial to create several different variations of\nthe same transaction (same inputs to same outputs) with different\ntxids (re-signing inputs uses a different signature nonce, which\nchanges the signature/txid, for example).\n\nRE: using self-signed certificates:  as Mike said, I assume Bitcoin\nclients will have some way of managing root certificates, so experts\ncould add trusted self-signed certs.\n\n-- \n--\nGavin Andresen"}