📅 Original date posted:2014-09-12
📝 Original message:Putting aside the question of necessity for a moment, a more efficient
approach to this would be;
1. Add another marker param like &s to the end of the URL
2. Add another field to PaymentRequest that contains an ECC signature
calculated using the public key that hashes to the address in the URI
3. Upgraded wallets look for the additional param and if it's there,
expect to find the PaymentDetails signed with the address key. PKI signing
of course is still useful to provide an actual identity for receipts,
display on hardware wallets, dispute mediation etc.
This adds only a few characters to a normal backwards-compatible QR code,
and is not hard to implement.
On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike at plan99.net> wrote:
> That way we leave up to implementers to experiment with different
>> lengths and figure out what the optimum is
>
>
> Ah, that's a good suggestion if we do go this way.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140912/7122a333/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:25:42
in reply to nevent1q…8a8t
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:25:42Event JSON
{
"id": "033a3cb851b85a3687dec1262cb156d429841007ec3b2999356abfae2ac3c53c",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151542,
"kind": 1,
"tags": [
[
"e",
"5045235f447739204820462b94c541446b82ef26097d3889eeeed0767ae1d197",
"",
"root"
],
[
"e",
"1a480a70872464064a48dfcb7f756366c94b83b09bb5cad280ab949a8f53fe22",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 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",
"sig": "5964b98036a2016a4d920a66179257ad92593a028ccfdc91545b8ac58ffaff3b6c81f9ecfa4f72c757348556064e1af2c987dfbeb8e7f8bdde29ff14a14948a6"
}