📅 Original date posted:2014-03-08
📝 Original message:On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote:
> Not sure if you've seen it, but here is how we do NFC right now
> http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
Very interesting, thanks for sharing! Are the two devices on the same
wifi network in the demo? In my experience transaction propagation
through the Bitcoin network takes a couple of seconds longer on average,
so I'm surprised it's that fast here.
You probably share this view, but I just wanted to repeat, that from my
experiments, I think that sending the transaction only over the Bitcoin
network should be a rarely-used fallback. It usually takes a little
longer than you would like for a POS solution and every so often you
don't get the transaction at all until the next block. And then what do
you do? Maybe you would need to ask the customer to pay again, to get
things done now, and put the previous transaction in some kind of refund
mode, where - when you finally get it - you send it back somewhere. But
it's really a problematic corner case - but yet it will happen
occasionally with network-only propagation.
In the context of this discussion, I would also like to share a video of
a prototype system:
https://www.youtube.com/watch?v=mguRpvf3aMc
Here shown is the (currently no longer working) Bridgewalker client, but
it is also fully compatible with Andreas' wallet. The client picks up
the payment details via NFC (as a Bitcoin URI - could and should be
updated to use payment protocol) and transmits a copy of the transaction
via Bluetooth (using the simple convention first implemented by
Andreas). One optimization I did in the Bridgewalker client is, that it
already opens the Bluetooth connection when presenting the user with the
confirmation dialog. This results in a little additional speed-up, as
the connection is already "warmed up", when the user confirms. All code
of this prototype is open source, as is the Bridgewalker client.
>From my testing, I can say that NFC for getting the payment details +
Bluetooth for transmitting the transaction back works well. I'm a bit
skeptical about using NFC also for the back-channel, but maybe for cases
where there is no additional user confirmation it could work.
One problem with Bluetooth I see is, that it seems to be mostly turned
off by users and many seem to perceive it as "insecure", to have it
active, as a result of earlier Bluetooth hacks. So I'm not sure if that
will turn out to be a problem for usability when rolled-out in practice.
Jan Vornberger [ARCHIVE] /
npub147…tnsv4
2023-06-07 15:14:55
in reply to nevent1q…rju8
Author Public Key
npub147edljttlezv8m5dugzg4ka8cg3073j3t2hq4h8ncxaz9sm5swuq4tnsv4Published at
2023-06-07 15:14:55Event JSON
{
"id": "b8a4f7b088ca282d6d965e3f600a56e7e72dc6a757d1b6b86efb2fbd4353b92a",
"pubkey": "afb2dfc96bfe44c3ee8de2048adba7c222ff46515aae0adcf3c1ba22c37483b8",
"created_at": 1686150895,
"kind": 1,
"tags": [
[
"e",
"a596a87c6af457be0f805b03270c063d690d47775921aaf8262e434ce379245e",
"",
"root"
],
[
"e",
"eb86bdffb44bcc3b9fa645843caa58b3cc02ce4cdc0cc041674af8d950ab013c",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-03-08\n📝 Original message:On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote:\n\u003e Not sure if you've seen it, but here is how we do NFC right now\n\u003e http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.\n\nVery interesting, thanks for sharing! Are the two devices on the same\nwifi network in the demo? In my experience transaction propagation\nthrough the Bitcoin network takes a couple of seconds longer on average,\nso I'm surprised it's that fast here.\n\nYou probably share this view, but I just wanted to repeat, that from my\nexperiments, I think that sending the transaction only over the Bitcoin\nnetwork should be a rarely-used fallback. It usually takes a little\nlonger than you would like for a POS solution and every so often you\ndon't get the transaction at all until the next block. And then what do\nyou do? Maybe you would need to ask the customer to pay again, to get\nthings done now, and put the previous transaction in some kind of refund\nmode, where - when you finally get it - you send it back somewhere. But\nit's really a problematic corner case - but yet it will happen\noccasionally with network-only propagation.\n\nIn the context of this discussion, I would also like to share a video of\na prototype system:\n\n https://www.youtube.com/watch?v=mguRpvf3aMc\n\nHere shown is the (currently no longer working) Bridgewalker client, but\nit is also fully compatible with Andreas' wallet. The client picks up\nthe payment details via NFC (as a Bitcoin URI - could and should be\nupdated to use payment protocol) and transmits a copy of the transaction\nvia Bluetooth (using the simple convention first implemented by\nAndreas). One optimization I did in the Bridgewalker client is, that it\nalready opens the Bluetooth connection when presenting the user with the\nconfirmation dialog. This results in a little additional speed-up, as\nthe connection is already \"warmed up\", when the user confirms. All code\nof this prototype is open source, as is the Bridgewalker client.\n\n\u003eFrom my testing, I can say that NFC for getting the payment details +\nBluetooth for transmitting the transaction back works well. I'm a bit\nskeptical about using NFC also for the back-channel, but maybe for cases\nwhere there is no additional user confirmation it could work.\n\nOne problem with Bluetooth I see is, that it seems to be mostly turned\noff by users and many seem to perceive it as \"insecure\", to have it\nactive, as a result of earlier Bluetooth hacks. So I'm not sure if that\nwill turn out to be a problem for usability when rolled-out in practice.",
"sig": "dcd164b894a02ad216de471724200802165f9f6364c4a7440fc25ba1261e5d71441f54eef55f8ee6a230d2f0bbe85b761e1d7adf366c4531aad0272f9092077f"
}