📅 Original date posted:2015-03-13
📝 Original message:Hi
No I don't agree with the analysis.
Yes, the PaymentRequest can be stored with the same security as the private
keys are stored. The big difference is that the keys never leave the
wallet. As soon as that PaymentRequest leaves the wallet on its way to the
hotel server, it is up for grabs which makes it inappropriate for use as a
proof of payment other than for resolving disputes and other one-time stuff.
/Kalle
2015-03-13 22:31 GMT+01:00 Mike Hearn <mike at plan99.net>:
> Hi Kalle,
>
> I think you're thinking along the right lines, but I am skeptical that
> this protocol adds much. A saved payment request is meant to be unique per
> transaction e.g. because the destination address is unique for that payment
> (for privacy reasons). Where would you store the signed payment request?
> Probably in the wallet. You could just extract the metadata that's useful
> for UI rendering into a separate structure and then encrypt the original
> full payment request under the wallet key. At least this is how I imagine
> it would work.
>
> So then, if someone can steal a payment request they can probably steal
> the wallet signing keys too, and thus signing a challenge with the wallet
> keys doesn't add much. It means the wallet doesn't have to store the
> PaymentRequest encrypted. But AFAICT that's about all it does.
>
> Do you agree with this analysis?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/fe954efb/attachment.html>;
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 15:31:52
in reply to nevent1q…5xhg
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 15:31:52Event JSON
{
"id": "9abde4801a8cd7cd1f74295fdb4726fa8b2ef58751c45421988a53ff4d2ab933",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686151912,
"kind": 1,
"tags": [
[
"e",
"bbd5f70505a5f5f17c6426f221fc86b1eb39c7e5d6e2ce7a472cfbb7c616ea1f",
"",
"root"
],
[
"e",
"ea9bd8e60aca4ac5d05fd382039819c680a472aca5eda69d04663407a3b91e88",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-03-13\n📝 Original message:Hi\n\nNo I don't agree with the analysis.\n\nYes, the PaymentRequest can be stored with the same security as the private\nkeys are stored. The big difference is that the keys never leave the\nwallet. As soon as that PaymentRequest leaves the wallet on its way to the\nhotel server, it is up for grabs which makes it inappropriate for use as a\nproof of payment other than for resolving disputes and other one-time stuff.\n\n/Kalle\n\n\n2015-03-13 22:31 GMT+01:00 Mike Hearn \u003cmike at plan99.net\u003e:\n\n\u003e Hi Kalle,\n\u003e\n\u003e I think you're thinking along the right lines, but I am skeptical that\n\u003e this protocol adds much. A saved payment request is meant to be unique per\n\u003e transaction e.g. because the destination address is unique for that payment\n\u003e (for privacy reasons). Where would you store the signed payment request?\n\u003e Probably in the wallet. You could just extract the metadata that's useful\n\u003e for UI rendering into a separate structure and then encrypt the original\n\u003e full payment request under the wallet key. At least this is how I imagine\n\u003e it would work.\n\u003e\n\u003e So then, if someone can steal a payment request they can probably steal\n\u003e the wallet signing keys too, and thus signing a challenge with the wallet\n\u003e keys doesn't add much. It means the wallet doesn't have to store the\n\u003e PaymentRequest encrypted. But AFAICT that's about all it does.\n\u003e\n\u003e Do you agree with this analysis?\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/fe954efb/attachment.html\u003e",
"sig": "915db6943f06b8d6f4fc2d78209cf48fddb8618e2c82a072afa45fd7c41439c2af36eea3fd250462408c3d123f52369517ce584ecb977f97a33cb28ba4cf9ff7"
}