📅 Original date posted:2015-03-14
📝 Original message:>
> Actually, the security of the PaymetRequest is pretty much out of your
>> control as soon as the PaymentRequest is created on the server. You have no
>> idea what the hotel does with it. Also if it's stored in the hotel server I
>> have to trust the hotel to keep it safe for me.
>>
>
> Well, yes. But if the hotel itself is hacked then the whole process is
> meaningless, no? The hacker could just make the hotel think the proof of
> payment is correct even though it was never made at all, for instance.
>
Maybe the hotel example is not perfect for this discussion. Let's instead
assume that the server holds yearly subscriptions to some expensive video
service. If that service stores PaymentRequests for all their subscribers,
and accept them as proof of payment, that would be similar to storing
username and (possibly hashed) passwords for all subscribers. If all the
PaymentRequests for all users are stolen, then they have to shut down all
accounts if they discover the theft. If they don't discover the theft the
"accounts" are out in the wild, for sale, for blackmail, etc.
Wouldn't it be better if the service don't accept the reusable
PaymentRequests as proof, and instead accept a proof generated on demand,
at the very moment it is needed, and that it is only usable once? From a
usability perspective there is no difference; The users simply need access
the service and authorize the proof being sent to the server.
>
>
>> Another thing is that you assume BIP0070 is used for payments, which
>> isn't necessarily is the case.
>>
>
> It's just a convenient place to put things. There are lots of useful
> features that need BIP 70. I hope eventually all wallets will support it.
>
I also hope BIP0070 will take off. It would greatly improve the user
experience. But even then, all payments are not BIP0070. BIP0070 is
primarily for merchants who have the skills, time and money to use
certificates. I don't think a lottery at the local church would want to set
up a secure BIP0070 server, but they still might want to use bitcoin for
their lottery.
Regards,
Kalle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150314/c5d37d17/attachment.html>;
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 15:31:53
in reply to nevent1q…2hhn
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 15:31:53Event JSON
{
"id": "5a7e9d4d6feb90663a10965a19e1ed7a084570010e461eaccf2504cb8f7be62e",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686151913,
"kind": 1,
"tags": [
[
"e",
"bbd5f70505a5f5f17c6426f221fc86b1eb39c7e5d6e2ce7a472cfbb7c616ea1f",
"",
"root"
],
[
"e",
"02a8a66707ce5eed4abd3cc20a554ebebfe1db368ad8456f6ff5b97c117cf063",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-03-14\n📝 Original message:\u003e\n\u003e Actually, the security of the PaymetRequest is pretty much out of your\n\u003e\u003e control as soon as the PaymentRequest is created on the server. You have no\n\u003e\u003e idea what the hotel does with it. Also if it's stored in the hotel server I\n\u003e\u003e have to trust the hotel to keep it safe for me.\n\u003e\u003e\n\u003e\n\u003e Well, yes. But if the hotel itself is hacked then the whole process is\n\u003e meaningless, no? The hacker could just make the hotel think the proof of\n\u003e payment is correct even though it was never made at all, for instance.\n\u003e\n\nMaybe the hotel example is not perfect for this discussion. Let's instead\nassume that the server holds yearly subscriptions to some expensive video\nservice. If that service stores PaymentRequests for all their subscribers,\nand accept them as proof of payment, that would be similar to storing\nusername and (possibly hashed) passwords for all subscribers. If all the\nPaymentRequests for all users are stolen, then they have to shut down all\naccounts if they discover the theft. If they don't discover the theft the\n\"accounts\" are out in the wild, for sale, for blackmail, etc.\n\nWouldn't it be better if the service don't accept the reusable\nPaymentRequests as proof, and instead accept a proof generated on demand,\nat the very moment it is needed, and that it is only usable once? From a\nusability perspective there is no difference; The users simply need access\nthe service and authorize the proof being sent to the server.\n\n\n\u003e\n\u003e\n\u003e\u003e Another thing is that you assume BIP0070 is used for payments, which\n\u003e\u003e isn't necessarily is the case.\n\u003e\u003e\n\u003e\n\u003e It's just a convenient place to put things. There are lots of useful\n\u003e features that need BIP 70. I hope eventually all wallets will support it.\n\u003e\n\nI also hope BIP0070 will take off. It would greatly improve the user\nexperience. But even then, all payments are not BIP0070. BIP0070 is\nprimarily for merchants who have the skills, time and money to use\ncertificates. I don't think a lottery at the local church would want to set\nup a secure BIP0070 server, but they still might want to use bitcoin for\ntheir lottery.\n\nRegards,\nKalle\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150314/c5d37d17/attachment.html\u003e",
"sig": "ad34a9c256e0b536bfeef6da17753cfe9a09d77a76e5c67d0ca75079b11728c26fa8d6981361956188742325c00692fa93cad73c1acc06aa268ae99d1050afd5"
}