📅 Original date posted:2014-06-30
📝 Original message:It took some time but we have finally implemented bluetooth integration
offered by Andreas in our bitcoin payment terminals.
However it's not ideal at the moment. Basically the main problem is that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if client wallet supports BIP70 but doesn't not
support fetching over bluetooth or bluetooth connection fails for any
reason.
There is a way to define alternative URIs inside payment request itself,
but that doesn't really work as client first needs to get payment request
message itself somehow and this is exactly the problem.
As far as I see there is three ways to solve that:
1. add new URI parameter for bluetooth address
(e.g. r=http://<web_address>&rbt=bt:<BT_MAC_addres>;).
2. allow multiple "r" parameters
(e.g. r=http://<web_address>&r=bt:<BT_MAC_addres>;).
3. allow "r" to be an array
(e.g. r%5B0%5D=http://<web_address>&r%5B1%5D=bt:<BT_MAC_addres>;).
Option #1 isn't great at all, as it solves existing problem, but not
provides any way to solve same problem appearing again for another possible
protocol.
Options #2 & #3 may be working and seem to be nearly equal, and both are
not great in the way that URI parser behavior in these cases is not clearly
defined. I've checked through relevant RFCs and found nothing specific
about this. According to my limited web experience the array scheme is
working better than multiple repeating parameters.
So I'm looking for some advice on which route of three proposed may be
better here, or if there are any other ways I'm missing.
2014-03-27 13:31 GMT+00:00 vv01f <vv01f at riseup.net>:
> Companies can have a Cert with their name via CAcert. It requires some
> work though to get assured as an organisation.
> Did you already think about what CA is to be trusted or do users need to
> do that. The least good decision in my POV would be to accept OS/browser
> built in CAs only.
>
> Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike at plan99.net>:
>
> But these cases are the norm, rather than the exception.
>>
>
> Well, you're lucky, you live in Berlin. Most of the payments I make with
> Bitcoin are online, to websites. So this will differ between people.
>
> I wonder how critical it is. Let's say you are paying for a meal. In your
> head the place you're at is just "the little Indian restaurant on the
> corner". In the companies register and therefore certificate it's something
> like "Singh Food GmbH". That's probably good enough to prevent shenanigans.
> Even if there's a virus on your phone, it can't really replace the cert
> with a random stolen one, otherwise your meal could show up like "IronCore
> Steel Inc" or something that's obviously bogus. It'd have to be an
> incredibly smart virus that knew how to substitute one name for a different
> one, from a large library of stolen identities, such that the swap seemed
> plausible. That sounds very hard, certainly too hard to bother with for
> stealing restaurant fees.
>
> And if a waiter at the restaurant is corrupt and they replace the cert
> with one that's for their own 1-man business "BP-Gupta" or something, OK,
> you might pay the wrong person by mistake. But eventually the corrupt
> waiter will be discovered and then someone will have proof of what they
> did. It's FAR more likely they'd just strip the signature entirely and try
> to convince you the restaurant doesn't use BIP70 at all.
>
> Still, if we want to fix this, one approach I was thinking about is to
> have a super-cheesy CA just for us that issues certs with addresses in
> them, for any name you ask for. That is, if you say you want a cert for
> "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a
> postcard to that address with a code to check ownership of the address, or
> it checks ownership of the place on Google Maps (which does the same
> postcard trick but for free!).
>
> That doesn't work for vending machines, but perhaps we just don't care
> about those. If a MITM steals your lunch money, boo hoo.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140630/c57b4bfb/attachment.html>;
Alex Kotenko [ARCHIVE] /
npub14j…h00t4
2023-06-07 15:23:23
in reply to nevent1q…5gna
Author Public Key
npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4Published at
2023-06-07 15:23:23Event JSON
{
"id": "696d935982f3c7c15f139c963728b6be55bed359afad137e74956b5d50e888f3",
"pubkey": "ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec",
"created_at": 1686151403,
"kind": 1,
"tags": [
[
"e",
"fa2b9cfa01c5894ed47509cea067c42947036d2aca239ff7a4b1473ba0342b81",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-06-30\n📝 Original message:It took some time but we have finally implemented bluetooth integration\noffered by Andreas in our bitcoin payment terminals.\n\nHowever it's not ideal at the moment. Basically the main problem is that\nin the BIP72 there is no way to provide a fallback alternative URI for\npayment request fetch if client wallet supports BIP70 but doesn't not\nsupport fetching over bluetooth or bluetooth connection fails for any\nreason.\nThere is a way to define alternative URIs inside payment request itself,\nbut that doesn't really work as client first needs to get payment request\nmessage itself somehow and this is exactly the problem.\n\nAs far as I see there is three ways to solve that:\n1. add new URI parameter for bluetooth address\n (e.g. r=http://\u003cweb_address\u003e\u0026rbt=bt:\u003cBT_MAC_addres\u003e).\n2. allow multiple \"r\" parameters\n (e.g. r=http://\u003cweb_address\u003e\u0026r=bt:\u003cBT_MAC_addres\u003e).\n3. allow \"r\" to be an array\n (e.g. r%5B0%5D=http://\u003cweb_address\u003e\u0026r%5B1%5D=bt:\u003cBT_MAC_addres\u003e).\n\nOption #1 isn't great at all, as it solves existing problem, but not\nprovides any way to solve same problem appearing again for another possible\nprotocol.\n\nOptions #2 \u0026 #3 may be working and seem to be nearly equal, and both are\nnot great in the way that URI parser behavior in these cases is not clearly\ndefined. I've checked through relevant RFCs and found nothing specific\nabout this. According to my limited web experience the array scheme is\nworking better than multiple repeating parameters.\n\nSo I'm looking for some advice on which route of three proposed may be\nbetter here, or if there are any other ways I'm missing.\n\n\n2014-03-27 13:31 GMT+00:00 vv01f \u003cvv01f at riseup.net\u003e:\n\n\u003e Companies can have a Cert with their name via CAcert. It requires some\n\u003e work though to get assured as an organisation.\n\u003e Did you already think about what CA is to be trusted or do users need to\n\u003e do that. The least good decision in my POV would be to accept OS/browser\n\u003e built in CAs only.\n\u003e\n\u003e Am 27.03.2014 um 11:08 schrieb Mike Hearn \u003cmike at plan99.net\u003e:\n\u003e\n\u003e But these cases are the norm, rather than the exception.\n\u003e\u003e\n\u003e\n\u003e Well, you're lucky, you live in Berlin. Most of the payments I make with\n\u003e Bitcoin are online, to websites. So this will differ between people.\n\u003e\n\u003e I wonder how critical it is. Let's say you are paying for a meal. In your\n\u003e head the place you're at is just \"the little Indian restaurant on the\n\u003e corner\". In the companies register and therefore certificate it's something\n\u003e like \"Singh Food GmbH\". That's probably good enough to prevent shenanigans.\n\u003e Even if there's a virus on your phone, it can't really replace the cert\n\u003e with a random stolen one, otherwise your meal could show up like \"IronCore\n\u003e Steel Inc\" or something that's obviously bogus. It'd have to be an\n\u003e incredibly smart virus that knew how to substitute one name for a different\n\u003e one, from a large library of stolen identities, such that the swap seemed\n\u003e plausible. That sounds very hard, certainly too hard to bother with for\n\u003e stealing restaurant fees.\n\u003e\n\u003e And if a waiter at the restaurant is corrupt and they replace the cert\n\u003e with one that's for their own 1-man business \"BP-Gupta\" or something, OK,\n\u003e you might pay the wrong person by mistake. But eventually the corrupt\n\u003e waiter will be discovered and then someone will have proof of what they\n\u003e did. It's FAR more likely they'd just strip the signature entirely and try\n\u003e to convince you the restaurant doesn't use BIP70 at all.\n\u003e\n\u003e Still, if we want to fix this, one approach I was thinking about is to\n\u003e have a super-cheesy CA just for us that issues certs with addresses in\n\u003e them, for any name you ask for. That is, if you say you want a cert for\n\u003e \"Shamrock Irish Pub, Wollishofen, Zurich, CH\" then it either sends a\n\u003e postcard to that address with a code to check ownership of the address, or\n\u003e it checks ownership of the place on Google Maps (which does the same\n\u003e postcard trick but for free!).\n\u003e\n\u003e That doesn't work for vending machines, but perhaps we just don't care\n\u003e about those. If a MITM steals your lunch money, boo hoo.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\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\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140630/c57b4bfb/attachment.html\u003e",
"sig": "0cb353d671275303ebf02279d87f1f97fe96cc9710d980da43aaaf06817d760b02f35661e5f4d796b43c7866ddc02557ddaded75861d799667477e3a96ab7c28"
}