📅 Original date posted:2014-01-29
📝 Original message:> But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector...
If the only concern is to make scan-to-pay work without reliance on
SSL's PKI, it might be better to specify the payment protocol url
*and* the public key used for signing right in the qr code. The wallet
connects to the url, fetches the payment request (maybe over a secure
connection, maybe not, doesn't matter), and verifies the signature
matches the public key from the qr code.
Downsides compared to embedding the entire request:
Payee needs to host/serve requests somewhere online. This introduces
reliability and DoS concerns.
Payer needs an internet connection to fetch the request.
Advantages:
Serve variable payment requests from the same qr code (improving
recipient privacy).
Still no hard dependency on CAs. Even if both CA and DNS are
compromised by an attacker, the worst they can do is Denial of
Service.
Optionally use CAs so that the wallet can attach an identity to who
you're paying by QR code. This partly addresses the problem of the
waiter overwriting the QR code. A non-PKI transaction would simply
show "Unknown recipient".
Much smaller QR code (only overhead is the key parameter, and you
could use a boolean param + the "address as public key" hack Mike
mentionned, for only 4 characters of overhead).
No need for a backward-incompatible bitcoin: scheme
On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
>> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
>> <andreas at schildbach.de> wrote:
>>
>> > SCAN TO PAY
>> > For scan-to-pay, the current landscape looks different. I assume at
>> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> > into a QR-code. Nevertheless, I tried to encode a payment request into
>> > the bitcoin URL. I used my existing work on encoding transactions into
>> > QR-codes. Steps to encode:
>>
>> Really interesting work. When using scan-to-pay, after the payer scans the
>> QR code with the protobuf PaymentRequest (not a URL to download the
>> PaymentRequest) are they using their own connectivity to submit the
>> Payment response?
>>
>> If we assume connectivity on the phone, might as well just get a URL from
>> the QR code and re-use existing infrastructure for serving that?
>
> My first thought was likewise. In the case where the phone needs
> Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
>
> I'm assuming that every client will have to support this is any case,
> since it's effectively mandated by the BIP, so why add another mode of
> operation?
>
> However, PaymentRequest-over-QR-code does seem to me to have one
> rather attractive advantage: the authentication model is orders of
> magnitude simpler and more intuitive for a face-to-face transaction
> than anything else. You're saying "pay the coins to that thing over
> there displaying that QR code". Which, most of the time, is exactly
> what you want.
>
> In the web case, it's fine to ignore the case where the URL domain has
> been subverted (and an cert obtained by the attacker) because in that
> case you've lost before you even get to payments (MitM attacker shows
> you a modified web page with different payment details). But the
> face-to-face case isn't intrinsically dependent on SSL security, and
> it's nice not to introduce that attack vector...
>
> roy
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Christophe Biocca [ARCHIVE] /
npub1mt…9g5zm
2023-06-07 15:12:43
in reply to nevent1q…lzde
Author Public Key
npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmPublished at
2023-06-07 15:12:43Event JSON
{
"id": "779155fc44f22aab410284216b00789af0bd528c69bce489087f0422d655a567",
"pubkey": "dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d",
"created_at": 1686150763,
"kind": 1,
"tags": [
[
"e",
"e58bd7fc71e0b34db5ffe731162734e74d81715bfe40046de10c0268ccbf9fd4",
"",
"root"
],
[
"e",
"b58d677f93480890512f3eafca1356a070d58bf2cc14a348c06b1f833851b7f8",
"",
"reply"
],
[
"p",
"58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950"
]
],
"content": "📅 Original date posted:2014-01-29\n📝 Original message:\u003e But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector...\n\nIf the only concern is to make scan-to-pay work without reliance on\nSSL's PKI, it might be better to specify the payment protocol url\n*and* the public key used for signing right in the qr code. The wallet\nconnects to the url, fetches the payment request (maybe over a secure\nconnection, maybe not, doesn't matter), and verifies the signature\nmatches the public key from the qr code.\n\nDownsides compared to embedding the entire request:\nPayee needs to host/serve requests somewhere online. This introduces\nreliability and DoS concerns.\nPayer needs an internet connection to fetch the request.\n\nAdvantages:\nServe variable payment requests from the same qr code (improving\nrecipient privacy).\nStill no hard dependency on CAs. Even if both CA and DNS are\ncompromised by an attacker, the worst they can do is Denial of\nService.\nOptionally use CAs so that the wallet can attach an identity to who\nyou're paying by QR code. This partly addresses the problem of the\nwaiter overwriting the QR code. A non-PKI transaction would simply\nshow \"Unknown recipient\".\nMuch smaller QR code (only overhead is the key parameter, and you\ncould use a boolean param + the \"address as public key\" hack Mike\nmentionned, for only 4 characters of overhead).\nNo need for a backward-incompatible bitcoin: scheme\n\nOn Mon, Jan 27, 2014 at 3:34 PM, Roy Badami \u003croy at gnomon.org.uk\u003e wrote:\n\u003e On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:\n\u003e\u003e On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach\n\u003e\u003e \u003candreas at schildbach.de\u003e wrote:\n\u003e\u003e\n\u003e\u003e \u003e SCAN TO PAY\n\u003e\u003e \u003e For scan-to-pay, the current landscape looks different. I assume at\n\u003e\u003e \u003e least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded\n\u003e\u003e \u003e into a QR-code. Nevertheless, I tried to encode a payment request into\n\u003e\u003e \u003e the bitcoin URL. I used my existing work on encoding transactions into\n\u003e\u003e \u003e QR-codes. Steps to encode:\n\u003e\u003e\n\u003e\u003e Really interesting work. When using scan-to-pay, after the payer scans the\n\u003e\u003e QR code with the protobuf PaymentRequest (not a URL to download the\n\u003e\u003e PaymentRequest) are they using their own connectivity to submit the\n\u003e\u003e Payment response?\n\u003e\u003e\n\u003e\u003e If we assume connectivity on the phone, might as well just get a URL from\n\u003e\u003e the QR code and re-use existing infrastructure for serving that?\n\u003e\n\u003e My first thought was likewise. In the case where the phone needs\n\u003e Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?\n\u003e\n\u003e I'm assuming that every client will have to support this is any case,\n\u003e since it's effectively mandated by the BIP, so why add another mode of\n\u003e operation?\n\u003e\n\u003e However, PaymentRequest-over-QR-code does seem to me to have one\n\u003e rather attractive advantage: the authentication model is orders of\n\u003e magnitude simpler and more intuitive for a face-to-face transaction\n\u003e than anything else. You're saying \"pay the coins to that thing over\n\u003e there displaying that QR code\". Which, most of the time, is exactly\n\u003e what you want.\n\u003e\n\u003e In the web case, it's fine to ignore the case where the URL domain has\n\u003e been subverted (and an cert obtained by the attacker) because in that\n\u003e case you've lost before you even get to payments (MitM attacker shows\n\u003e you a modified web page with different payment details). But the\n\u003e face-to-face case isn't intrinsically dependent on SSL security, and\n\u003e it's nice not to introduce that attack vector...\n\u003e\n\u003e roy\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e CenturyLink Cloud: The Leader in Enterprise Cloud Services.\n\u003e Learn Why More Businesses Are Choosing CenturyLink Cloud For\n\u003e Critical Workloads, Development Environments \u0026 Everything In Between.\n\u003e Get a Quote or Start a Free Trial Today.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=119420431\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",
"sig": "35b881dc9309db95d8a698579a9fbeba1a64ae3e7a3bdfa731f2c0535a11331cccf93e6d5dbd3893097ff002ea8446e17a3c6e625e51a2c15dcd2f9b574fc71e"
}