Troy Benjegerdes [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-07 📝 Original message:On Thu, Mar 06, 2014 at ...
📅 Original date posted:2014-03-07
📝 Original message:On Thu, Mar 06, 2014 at 10:45:31AM +0100, Mike Hearn wrote:
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future. I think people will come to expect this kind of
> no-friction payment experience and Bitcoin will need to match it, so here
> are some notes on what's involved.
>
> There are two aspects that can be implemented independently of each other:
>
> 1) The physical/NFC layer.
> 2) The risk analysis layer.
>
> A contactless payment needs two things to work: one is a VERY fast, low
> latency communication between payment device (phone in our case) and
> terminal. I couldn't find actual latency specs yet but it felt like using
> an Oyster card, which aims for <400msec.
What matters more than the latency is the *variability*. I would spec this
system for no less than 200ms, and no more than 250ms to be 'standard'.
> ..... so I bet we'd need to optimise the bootup process of the Android
> wallet app. Right now it does slow things like deserialising giant protocol
> buffers and is just generally not optimised for startup time. Loading the
> wallet, reading the payment request over NFC, checking the cert signatures,
> making the trust decision, calculating a transaction, signing it, sending
> it back to the recipient all in under 400 msec would be a tough (but fun)
> programming challenge. Some of the steps can be parallelised and modern
> phones are mostly multicore.
If you have to invoke a java/ios/etc app you are never going to be consistent,
however if you have a GPL linux kernel module (like I proposed for my still
hypothetical 7coin), you should have no trouble meeting those specs.
I'd like to be able to load my java app, tell it to put $50 on my 'instant'/nfc
wallet, and then let the kernel module spend out the $50 whenever the phone
gets swiped by somehting.
If you do this right, every device has a well-known payment address for it's
'instant' wallet, and it should be trivial for merchants to just look at the
blockchain and confirm the instant wallet has a sufficient balance to cover
the transaction.
One more comment... having a bitcoin payment application 'check certs' seems
like a great way to ensure that Visa maintains their market share.
If it's my phone, and I press the hardware payment button, and I only put
$50 on it, I frankly don't care if there's a cert or not. The last thing I
want is a 'certificate validation error' when I'm trying to buy a soda.
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
📝 Original message:On Thu, Mar 06, 2014 at 10:45:31AM +0100, Mike Hearn wrote:
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future. I think people will come to expect this kind of
> no-friction payment experience and Bitcoin will need to match it, so here
> are some notes on what's involved.
>
> There are two aspects that can be implemented independently of each other:
>
> 1) The physical/NFC layer.
> 2) The risk analysis layer.
>
> A contactless payment needs two things to work: one is a VERY fast, low
> latency communication between payment device (phone in our case) and
> terminal. I couldn't find actual latency specs yet but it felt like using
> an Oyster card, which aims for <400msec.
What matters more than the latency is the *variability*. I would spec this
system for no less than 200ms, and no more than 250ms to be 'standard'.
> ..... so I bet we'd need to optimise the bootup process of the Android
> wallet app. Right now it does slow things like deserialising giant protocol
> buffers and is just generally not optimised for startup time. Loading the
> wallet, reading the payment request over NFC, checking the cert signatures,
> making the trust decision, calculating a transaction, signing it, sending
> it back to the recipient all in under 400 msec would be a tough (but fun)
> programming challenge. Some of the steps can be parallelised and modern
> phones are mostly multicore.
If you have to invoke a java/ios/etc app you are never going to be consistent,
however if you have a GPL linux kernel module (like I proposed for my still
hypothetical 7coin), you should have no trouble meeting those specs.
I'd like to be able to load my java app, tell it to put $50 on my 'instant'/nfc
wallet, and then let the kernel module spend out the $50 whenever the phone
gets swiped by somehting.
If you do this right, every device has a well-known payment address for it's
'instant' wallet, and it should be trivial for merchants to just look at the
blockchain and confirm the instant wallet has a sufficient balance to cover
the transaction.
One more comment... having a bitcoin payment application 'check certs' seems
like a great way to ensure that Visa maintains their market share.
If it's my phone, and I press the hardware payment button, and I only put
$50 on it, I frankly don't care if there's a cert or not. The last thing I
want is a 'certificate validation error' when I'm trying to buy a soda.
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash