š
Original date posted:2014-01-27
š Original message:On Jan 27, 2014, at 9:39 AM, Andreas Schildbach <andreas at schildbach.de> wrote:
> On 01/27/2014 06:11 PM, Jeremy Spilman 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?
>>
>> How about putting a Bluetooth address in the payment_url inside the
>> PaymentDetails message for the smartphone to send back the Payment
>> response and get PaymentAck?
>
> That's exactly what I have prototyped. I am putting a Bluetooth MAC
> address into the payment_url. Have a look at the TAP TO PAY paragraph
> for details, its mostly the same mechanism.
>
Same mechanism for both, of course. Sorry, that was obvious. :)
Jeremy Spilman [ARCHIVE] /
npub10eā¦jc727
2023-06-07 15:12:42
in reply to nevent1qā¦5yrx
Author Public Key
npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727Published at
2023-06-07 15:12:42Event JSON
{
"id": "6b71e4b93c2a00086f605caf95cf9d7721e179bd0bc3a56cfa9055421fa967ec",
"pubkey": "7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3",
"created_at": 1686150762,
"kind": 1,
"tags": [
[
"e",
"e58bd7fc71e0b34db5ffe731162734e74d81715bfe40046de10c0268ccbf9fd4",
"",
"root"
],
[
"e",
"f510b8f89c19e54bf297ea24a53f97c3b2d1a917f7f5afd4c4517c33f53d1a4c",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "š
Original date posted:2014-01-27\nš Original message:On Jan 27, 2014, at 9:39 AM, Andreas Schildbach \u003candreas at schildbach.de\u003e wrote:\n\n\u003e On 01/27/2014 06:11 PM, Jeremy Spilman wrote:\n\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 How about putting a Bluetooth address in the payment_url inside the\n\u003e\u003e PaymentDetails message for the smartphone to send back the Payment\n\u003e\u003e response and get PaymentAck?\n\u003e \n\u003e That's exactly what I have prototyped. I am putting a Bluetooth MAC\n\u003e address into the payment_url. Have a look at the TAP TO PAY paragraph\n\u003e for details, its mostly the same mechanism.\n\u003e \n\nSame mechanism for both, of course. Sorry, that was obvious. :)",
"sig": "3d00add1f8a7466655a0fac6919bdb349876490c0485584ef4e8ae6d4976d5a3bea5a903831c70651168413a2d8d7f579a0f57c8b9554740f953d5c757821d92"
}