📅 Original date posted:2014-01-27 📝 Original message:On Jan 27, 2014, at 9:39 ...

Jeremy Spilman [ARCHIVE] /

npub10et…c727

2023-06-07 15:12:42

in reply to nevent1q…5yrx

📅 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. :)

Author Public Key

npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727

Show more details

Published at

2023-06-07 15:12:42

Kind type

1 Short Text Note

Event 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" }