Re: [Bitcoin-development] Instant / contactless payments
2014-03-08 8:52 GMT+00:00 Jan Vornberger j...@uos.de: On Thu, Mar 06, 2014 at 02:39:52PM +, 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. No, devices on this video are not on the same network, and even if they would - I cannot control what remote hosts my phone would connect to, so transaction may anyway travel around the globe before coming to the POS even if they would be on one LAN. As for transaction times - I'd say it varies. From my extensive testing most of transactions usually come through within 2-5 seconds, but roughly one in ten transactions may take more time, sometimes much more time. 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. Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. 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. Yes, I've seen this demonstration, I think it was on reddit about two month ago. Looks interesting, but by that time most of my client software was already done, so I couldn't really use this. 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. NFC as back channel definitely will not work . Mike proposed something like a threshold to define minimal amount available for spending without confirmation, but I don't see this thing becoming widely used any time soon, and before that we will need to have confirm button tap. 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. Yes, this is a problem, I think bluetooth is offline on many devices, and keeping it on all the time will harm security (if not real security, then at least perceived by users) and also harm battery life, which will be seen as huge problem by the users. Would be great to be able to control BT state automatically from within the wallet app with user permission given once on installation time, but not sure if it's possible in Android. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less. I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved. jp On Mar 10, 2014, at 9:04 AM, Mike Hearn m...@plan99.net 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. A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage. By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they: a) Reject cards entirely because the payment is too small b) Don't have the right hardware, or the hardware just mysteriously fails to work. c) Require a PIN because the payment is too large I'm sure Bitcoin can do better than this. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
It heavily depends on where you use it. Here in UK any card payments are often limited to minimum of £5 in small shops that have heavy transaction fees burden and low margins. Big networks with more resources often let you pay as little as you want by card, and they more often have NFC enabled POS devices. So it's not an NFC or POS limit, but a business decision for these small merchants. Bitcoin can address this issue for sure, but this doesn't concern NFC. 2014-03-10 16:14 GMT+00:00 Jean-Paul Kogelman jeanpaulkogel...@me.com: Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less. I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved. jp On Mar 10, 2014, at 9:04 AM, Mike Hearn m...@plan99.net 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. A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage. By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they: a) Reject cards entirely because the payment is too small b) Don't have the right hardware, or the hardware just mysteriously fails to work. c) Require a PIN because the payment is too large I'm sure Bitcoin can do better than this. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Ah, I see, so it's only payee who has to enable it, payer side is on by default. Then fine, situation is better than I thought. We'll look at implementing BIP70 asap. Best regards, Alex Kotenko 2014-03-10 19:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On Thu, Mar 06, 2014 at 02:39:52PM +, 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. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/06/2014 07:03 PM, Alex Kotenko wrote: Supporting Bluetooth is optional in the sense that if a wallet should not support it, you will still receive the transaction via the P2P network. So I'd say definately go for Bluetooth. Yes, it's part of the plan. Just again - I need to make sure we support all major wallets. And no other wallets actually support NFC by now, not talking about bluetooth. So I imagine we will decide and implement together some solution here, both on the wallet and POS sides, but I will have to keep URI method and even QR codes for backwards compatibility, and wait for other main wallets to accept innovations before we will be able to completely switch to it. As I said earlier - bluetooth support for my POS is not a problem, we can plug it in easily and make it work. Support among all hardware/software and polished user experience - this is a main thing here really. Sure, take all the time you need. All I wanted to say is you don't need to break Bitcoin URI compatibility in order to support direct payments via Bluetooth. It's simply an add-on, both in the BIP21 and the BIP70 cases. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
2014-03-06 12:26 GMT+01:00 Andreas Schildbach andr...@schildbach.de: In current phone implementations, the screen must be on already for NFC to be active. Also it must be unlocked, although I certainly hope future OSes will allow payment apps on the lock screen, just like they allow music players. Just a small input to this point: On Android 4.4 the new host card emulation (HCE) feature (aka: the phone emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like a Smartcard would do) only works when the display is on, but even when the screen is locked (can be changed with android:requireDeviceUnlock in Manifest). See here for detailled specification: http://developer.android.com/guide/topics/connectivity/nfc/hce.html Using the HCE API on Android 4.4 also has the beauty that any app that registers itself for HCE and sets its category to CATEGORY_PAYMENT in the Manifest automatically shows up in Adroid's system settings under Tap Pay (where a user would expect payment applications). -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. It's ok if some people decide to let the app do risk analysis, but you cannot force it onto users by picking a protocol that cannot deal with manual verification. Users should always have the choice to verify their payment without time pressure and by holding the device of their choice at their individual viewing distance. Besides, how do you plan to risk-analyse the memo field? In current phone implementations, the screen must be on already for NFC to be active. Also it must be unlocked, although I certainly hope future OSes will allow payment apps on the lock screen, just like they allow music players. To get the very fast light feel the actual contact period has to be quite short, so I bet we'd need to optimise the bootup process of the Android wallet app. It's already very short if you can do without Android Beam, e.g. on Android 2.3. I'd say 200 ms for an BIP21 payment request. Bootup of the app and everything else happens after -- no need to continue contact. Indeed most of the bootup time goes into loading complex wallets. Our long standing plans to clean up the wallet and archieve transactions should help. Also, if Bitcoin catches on the app will just stay in memory. The most obvious optimization to speed up signature checking is to make it lazy. The user can already inspect the payment while signatures are being checked. Even transaction signing could already happen in advance, if it can be made sure that no signed transaction escapes the dialog without the users consent. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)! -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach andr...@schildbach.dewrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Besides, how do you plan to risk-analyse the memo field? I guess only the amount and destination are relevant for risk analysis. It's already very short if you can do without Android Beam, e.g. on Android 2.3. I think IsoDep based protocols must bypass Beam - when I scan my e-passport there's no beam animation. The most obvious optimization to speed up signature checking is to make it lazy. The user can already inspect the payment while signatures are being checked. Well, for 400msec there can't be any user interaction. But checking signatures on the payment request and constructing and signing the inputs can all be done in parallel - you should be able to max out every core, at least for a brief moment. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)! Then that subway kind of sucks ;) Have you been to London and used Oyster? I think the capital wouldn't work at all without the low latency Oyster cards. The tube would have stopped scaling some time ago. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On Mar 6, 2014 3:47 AM, Mike Hearn m...@plan99.net 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. 3) Have some kind of decentralised reputation network. I spent some time thinking about this, but it rapidly became very complicated and feels like an entirely separate project that should stand alone from Bitcoin itself. Perhaps rather than try to make a global system, social data could be exchanged (using some fancy privacy preserving protocols?) so if your friends have decided to trust seller X, your phone automatically trusts them too. A reputation network might be an interesting idea, or several different networks with different curators (to prevent complete centralization), like how the US credit score system has three main companies who track your score. Something like a GPG ring of trust, with addresses signing other addresses would work well, if some sort of Stealth address or HD wallet root was the identity gaining the reputation, then address re-use wouldn't have to be mandatory. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Hi Mike 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. For now this is just an NDEF URI message with Bitcoin URI inside, and then transaction itself propagated to the network by the phone using it's own Internet connection. Far not ideal, but even this is supported only by Andreas' Wallet, so we cannot move ahead alot really until other wallets will have some support in this area. As you see - it's taking just few seconds, most of which is manual payment confirmation. Btw, ignore my first screen tap, where I'm selecting wallets - it's an unlikely thing to happen IRL to have several wallets installed at the same time. Also, I think many people may not know about Oyster cards, so this might need little bit of explanation. And btw, have you been to London lately? Oyster readers now accept contactless cards directly along with Oyster cards itself. I wonder if eventually in future we could add bitcoin support into that system directly, without hardware replacements. I cannot put much into the actual protocol discussion, but I'm happy to provide feedback on the side of actual POS implementation needed and testbase if required. Have an idea - it's a good thing to cap confirmationless payments, but the actual cap value definition can be tricky considering Bitcoin volatility. Inless you want to tie it to some external price definition thirdparty service it could be tied to transaction fees. I mean - if with Bitcoin v0.9 transaction fees will become really floating, and it should eventually reach equilibrium that will reflect some real world value. Probably a tiny value, but probably also rather stable value. So confirmationless payment cap may be defined as current_average_transaction_feex1. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/06/2014 02:44 PM, Mike Hearn wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be an option. Besides, how do you plan to risk-analyse the memo field? I guess only the amount and destination are relevant for risk analysis. The memo field (and its logical evolution, an invoice) also needs to be verified, since its part of the contract. Imagine sitting in a restaurant and you're being presented the bill, most people will do a quick scan of the meals and drinks consumed (and non-malignant errors are frequent in that business). It's already very short if you can do without Android Beam, e.g. on Android 2.3. I think IsoDep based protocols must bypass Beam - when I scan my e-passport there's no beam animation. Everything except Beam bypasses Beam (-: Beam is an Android-specific protocol. I assume it would also be possible to write an own NDEF implementation on top of the low level NFC APIs. I want to try as soon as I have a second NFC-capable phone, preferably Android 4.4. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)! Then that subway kind of sucks ;) You can't really blame the subway for a broken payment process. Have you been to London and used Oyster? Yes, it was a complete disaster. Obtaining a ticket took even longer -- ca. 45 minutes. Boarding the train took some additional seconds, compared to no overhead in Germany where we simply don't have any gates. On top of that, you walk more (in tunnels) than you get driven around, get tracked on each movement and if you want to get your (monetary) change, you need to wait for another 45 minutes. The upside is, when going by public transport in England I always feel like Mr. Freeman in City 17 (-: -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
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. Thanks for the video! It's always good to see these things in action so you can start believing in it. For now this is just an NDEF URI message with Bitcoin URI inside, and then transaction itself propagated to the network by the phone using it's own Internet connection. Far not ideal, but even this is supported only by Andreas' Wallet, so we cannot move ahead alot really until other wallets will have some support in this area. Supporting Bluetooth is optional in the sense that if a wallet should not support it, you will still receive the transaction via the P2P network. So I'd say definately go for Bluetooth. As you see - it's taking just few seconds, most of which is manual payment confirmation. I wonder about the receipt step -- are you generating a PDF on device and sending it via NFC? This is something that could be supported by the BIP70 payment protocol. We should try to avoid the second tap, its not intuitive. And btw, have you been to London lately? Oyster readers now accept contactless cards directly along with Oyster cards itself. Contactless cards? Last I was to London, the Oyster card was already contactless. Have there ever been magnet-strip-based Oyster cards? I wonder if eventually in future we could add bitcoin support into that system directly, without hardware replacements. Neat thought (-: -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
I wonder about the receipt step -- are you generating a PDF on device and sending it via NFC? This is something that could be supported by the BIP70 payment protocol. We should try to avoid the second tap, its not intuitive. Together, the signed PaymentRequest and the transactions in the block chain should act like a receipt: it's proof you requested payment in a certain way, and I satisfied that payment. So it's proof of payment and the memo field can describe what I bought. Contactless cards? Last I was to London, the Oyster card was already contactless. Have there ever been magnet-strip-based Oyster cards? He means, contactless credit cards can be used too. No need to enroll for Oyster specifically. I guess in the long run Oyster and its equivalents in other cities (octopus etc) will be phased out. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments, IsoDep
On 03/06/2014 03:51 PM, Andreas Schildbach wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be an option. One of the first things to explore is if its possible to dispatch different isodep applications to different apps. I know you can add an intent filter matching action=android.nfc.action.TECH_DISCOVERED and a custom tech filter android.nfc.tech.IsoDep. However, as long as there is no mime type or similar concept, apps will always fight for access to IsoDep endpoints. We will want to avoid that situation. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments, IsoDep
I think maybe the way you do it is to have a NDEF tag that triggers the app, and then that starts an IsoDep protocol once opened. I *think*. On Thu, Mar 6, 2014 at 5:55 PM, Andreas Schildbach andr...@schildbach.dewrote: On 03/06/2014 03:51 PM, Andreas Schildbach wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be an option. One of the first things to explore is if its possible to dispatch different isodep applications to different apps. I know you can add an intent filter matching action=android.nfc.action.TECH_DISCOVERED and a custom tech filter android.nfc.tech.IsoDep. However, as long as there is no mime type or similar concept, apps will always fight for access to IsoDep endpoints. We will want to avoid that situation. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Thanks Alex! About the video - I'm curious how your device is better than just a regular tablet. Could you give us the elevator pitch? :) On Thu, Mar 6, 2014 at 3:39 PM, Alex Kotenko alexy...@gmail.com wrote: I mean - if with Bitcoin v0.9 transaction fees will become really floating, and it should eventually reach equilibrium that will reflect some real world value. Probably a tiny value, but probably also rather stable value. So confirmationless payment cap may be defined as current_average_transaction_feex1. I guess fees will wander up and down depending on system load rather than real world value - but maybe you're right. That said, all wallets sync exchange rates automatically already. In some Star Trek future, perhaps we would want Bitcoin to be independent of other value units. But I'm not convinced such a world will ever exist. Arguably, a stable currency would slowly become worth more over time in line with economic growth. But then for stable prices you would need something like a fake currency that was backed by (really: represented by) a basket of goods. Otherwise over time your rent would go up in real terms, for good real reason. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
if some sort of Stealth address or HD wallet root was the identity gaining the reputation, then address re-use wouldn't have to be mandatory. The identity would be the X.520 name in the signing cert that signed the payment request. It doesn't have to be a difficult to obtain cert. It could even be self signed for this use case, but then you lose the security benefits and a key rotation would delete your reputation, so in practice I think most people would want the reputation to accrue to the name itself. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
If there was a way for a Bitcoin user to provide feedback on a payment (ECDSA signature from one of the addresses involved in the payment, signing an identifier of the payment and a feedback score) Well now you're getting into the area that I said rapidly got very complicated. Define bitcoin user? What stops me paying myself to accrue positive reputation? Etc. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
it's the responsibility of the individual members to maintain their own good/bad user lists. Would you think that's a good thing or a bad thing to give the individual players that level of control/responsibility? If it's explicit, I think it's a non starter and nobody will bother with it, especially not just for instant payments. If it's just a case of link your wallet with your Facebook account and requires no more effort than that, some people might, but of course the user experience would be rather random. Hey why did that guy in front of me get instant payments and I had to confirm even though we bought the same things? I'm not a big fan of UX's that appear totally random to the user. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
