📅 Original date posted:2014-01-27
📝 Original message: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
Roy Badami [ARCHIVE] /
npub1tr…0f95j
2023-06-07 15:12:43
in reply to nevent1q…2622
Author Public Key
npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95jPublished at
2023-06-07 15:12:43Event JSON
{
"id": "b58d677f93480890512f3eafca1356a070d58bf2cc14a348c06b1f833851b7f8",
"pubkey": "58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950",
"created_at": 1686150763,
"kind": 1,
"tags": [
[
"e",
"e58bd7fc71e0b34db5ffe731162734e74d81715bfe40046de10c0268ccbf9fd4",
"",
"root"
],
[
"e",
"6b71e4b93c2a00086f605caf95cf9d7721e179bd0bc3a56cfa9055421fa967ec",
"",
"reply"
],
[
"p",
"7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3"
]
],
"content": "📅 Original date posted:2014-01-27\n📝 Original message:On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:\n\u003e On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach \n\u003e \u003candreas at schildbach.de\u003e wrote:\n\u003e \n\u003e \u003e SCAN TO PAY\n\u003e \u003e For scan-to-pay, the current landscape looks different. I assume at\n\u003e \u003e least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded\n\u003e \u003e into a QR-code. Nevertheless, I tried to encode a payment request into\n\u003e \u003e the bitcoin URL. I used my existing work on encoding transactions into\n\u003e \u003e QR-codes. Steps to encode:\n\u003e \n\u003e Really interesting work. When using scan-to-pay, after the payer scans the \n\u003e QR code with the protobuf PaymentRequest (not a URL to download the \n\u003e PaymentRequest) are they using their own connectivity to submit the \n\u003e Payment response?\n\u003e \n\u003e If we assume connectivity on the phone, might as well just get a URL from \n\u003e the QR code and re-use existing infrastructure for serving that?\n\nMy first thought was likewise. In the case where the phone needs\nInternet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?\n\nI'm assuming that every client will have to support this is any case,\nsince it's effectively mandated by the BIP, so why add another mode of\noperation?\n\nHowever, PaymentRequest-over-QR-code does seem to me to have one\nrather attractive advantage: the authentication model is orders of\nmagnitude simpler and more intuitive for a face-to-face transaction\nthan anything else. You're saying \"pay the coins to that thing over\nthere displaying that QR code\". Which, most of the time, is exactly\nwhat you want.\n\nIn the web case, it's fine to ignore the case where the URL domain has\nbeen subverted (and an cert obtained by the attacker) because in that\ncase you've lost before you even get to payments (MitM attacker shows\nyou a modified web page with different payment details). But the\nface-to-face case isn't intrinsically dependent on SSL security, and\nit's nice not to introduce that attack vector...\n\nroy",
"sig": "deabaf63e7ee0c9747e500da04559fc8aaecdb19e1342b6743a8ba95369b86898648099b60205ab5535650e7766b7b42366008e2683b0b81bebdf078724fc0b2"
}