Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
I'm wondering about whether (don't laugh) moving signing into the kernel and then using the MTRRs to disable caching entirely for a small scratch region of memory would also work. You could then disable pre-emption and prevent anything on the same core from interrupting or timing the signing operation. However I suspect just making a hardened secp256k1 signer implementation in userspace would be of similar difficulty, in which case it would naturally be preferable. On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com wrote: Everything you say is true. However, branchless does reduce the attack surface considerably - if nothing else, it significantly ups the difficulty of an attack for a relatively low cost in program complexity, and that might still make it worth doing. Absolutely. I believe these things are worth doing. My comment on it being insufficient was only that my signer is branchless doesn't make other defense measures (avoiding reuse, multsig with multiple devices, not sharing hardware, etc.) unimportant. As for uniform memory access, if we avoided any kind of heap allocation, wouldn't we avoid such issues? No. At a minimum to hide a memory timing side-channel you must perform no data dependent loads (e.g. no operation where an offset into memory is calculated). A strategy for this is to always load the same values, but then mask out the ones you didn't intend to read... even that I'd worry about on sufficiently advanced hardware, since I would very much not be surprised if the processor was able to determine that the load had no effect and eliminate it! :) ) Maybe in practice if your data dependencies end up only picking around in the same cache-line it doesn't actually matter... but it's hard to be sure, and unclear when a future optimization in the rest of the system might leave it exposed again. (In particular, you can't generally write timing sign-channel immune code in C (or other high level language) because the compiler is freely permitted to optimize things in a way that break the property. ... It may be _unlikely_ for it to do this, but its permitted— and will actually do so in some cases—, so you cannot be completely sure unless you check and freeze the toolchain) Anyhow, without having gone into the full details of this particular attack, it seems the main attack point is differences in how squaring and multiplication (in the case of field exponentiation) or doubling and point addition (in the case of ECDSA) are performed. I believe using a branchless implementation where each phase of the operation executes the exact same code and accesses the exact same stack frames would not be vulnerable to FLUSH+RELOAD. I wouldn't be surprised. -- 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
[Bitcoin-development] Instant / contactless payments
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. The other is that obviously the payment device has to decide to sign the transaction without any user interaction, i.e. the payment is at low risk of being unintentional. If you nail this it can be used for one-click web payments too. Andreas already did some work on embedding full blown payment requests into an NFC tag, but I think we need to switch this to being a packet based protocol (via ISO-DEP), otherwise you can't submit the Payment/tx messages back via NFC as well. This isn't a very complicated task and would make a fun project for a newbie who has Android and knows some Java. The resulting ISO-DEP protocol can be turned into a BIP without too much trouble. The risk analysis is the more complicated part. The real value Visa/MasterCard provide with NFC payments is not so much the tech (the clever part is the batteryless nature of the cards rather than the crypto/comms), but the fact that merchants are all verified and can be fined or evicted if they abuse the system and try to steal money. Bitcoin doesn't have anything like that. I think we have a few options to make it safe: 1) Require some very lightweight user confirmation, like pressing the power button to reach the lock screen and only allowing small payments. The combination of physical proximity and pressing the power button is probably good enough for now to avoid problems. Someone should try it out and see how it feels. 2) Have some kind of semi-centralised merchant verification/approval programs, like what the card networks do. The easiest way to start would be to piggyback on the work BitPay/Coinbase do and just auto-sign if payment amount is X mBTC and the payment is via one of these processors. But this is hardly in the spirit of Bitcoin and is generally unsatisfying. 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. 4) Have the touch trigger a delayed payment and the phone tries to attract attention to itself so the user can cancel. This way if someone tries to swipe money out of your pocket by getting up close on a subway or something, you have a chance to cancel. But it's quite hard for a small device to reliably attract attention quickly and it opens up the merchant to fraud where the user pays, leaves and then cancels the payment. Especially it'd be useless for things like mass transit. So I think such a system would have to be opt-in by the seller. 5) A combination of all the above. 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. 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. -- 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] New side channel attack that can recover Bitcoin keys
You've heard of TRESOR? No, not Trezor. https://en.wikipedia.org/wiki/TRESOR Signing on the CPU, without touching RAM. - Sent from my phone Den 6 mar 2014 09:41 skrev Mike Hearn m...@plan99.net: I'm wondering about whether (don't laugh) moving signing into the kernel and then using the MTRRs to disable caching entirely for a small scratch region of memory would also work. You could then disable pre-emption and prevent anything on the same core from interrupting or timing the signing operation. However I suspect just making a hardened secp256k1 signer implementation in userspace would be of similar difficulty, in which case it would naturally be preferable. On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell gmaxw...@gmail.comwrote: On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com wrote: Everything you say is true. However, branchless does reduce the attack surface considerably - if nothing else, it significantly ups the difficulty of an attack for a relatively low cost in program complexity, and that might still make it worth doing. Absolutely. I believe these things are worth doing. My comment on it being insufficient was only that my signer is branchless doesn't make other defense measures (avoiding reuse, multsig with multiple devices, not sharing hardware, etc.) unimportant. As for uniform memory access, if we avoided any kind of heap allocation, wouldn't we avoid such issues? No. At a minimum to hide a memory timing side-channel you must perform no data dependent loads (e.g. no operation where an offset into memory is calculated). A strategy for this is to always load the same values, but then mask out the ones you didn't intend to read... even that I'd worry about on sufficiently advanced hardware, since I would very much not be surprised if the processor was able to determine that the load had no effect and eliminate it! :) ) Maybe in practice if your data dependencies end up only picking around in the same cache-line it doesn't actually matter... but it's hard to be sure, and unclear when a future optimization in the rest of the system might leave it exposed again. (In particular, you can't generally write timing sign-channel immune code in C (or other high level language) because the compiler is freely permitted to optimize things in a way that break the property. ... It may be _unlikely_ for it to do this, but its permitted— and will actually do so in some cases—, so you cannot be completely sure unless you check and freeze the toolchain) Anyhow, without having gone into the full details of this particular attack, it seems the main attack point is differences in how squaring and multiplication (in the case of field exponentiation) or doubling and point addition (in the case of ECDSA) are performed. I believe using a branchless implementation where each phase of the operation executes the exact same code and accesses the exact same stack frames would not be vulnerable to FLUSH+RELOAD. I wouldn't be surprised. -- 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 -- 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
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] Stealth Addresses
I think stealth addresses combined with zk-snarks would obviate the need for CoinJoin. zk-snarks could be used to hide the coin's value and stealth addresses could be used to hide the recipient for payments and even mined coins. More info on zero-knowledge snarks: http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf Start with a mined coin: generate a coin secret, create a coinbase transaction with an output to your stealth address and send hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value) where only the recipient (you) can decrypt. (The reward value is known publicly but just assume it isn't here for generality). You also embed the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in fact SHA256(coin-secret + reward-value), where your private witnesses are (coin-secret, reward-value). Now you could split a coin into as many pieces as you want in a single transaction and send to multiple recipients, some pieces go to yourself (change) and others to the payee, every piece would have a different recipient address thanks to stealth addresses, and all values hidden thanks to zk-snarks. So lets say you want to split the mined coin into two new ones. You create a transaction where the input redeems the mined coin using mined tx out + your stealth address, and there are two new coins as outputs to your own stealth address each having: hash(new-coin-secret + new-hidden-value) + encrypt(new-coin-secret + new-hidden-value). You also embed the zk-snark proof that the two new hidden values add up to the original hidden value, and that the two new hash results are in fact SHA256(new-coin-secret + new-hidden-value), where your private witnesses are (original-coin-secret, original-hidden-value, new-coin-secrets, new-hidden-values). If you want to merge two coins into one it's just a split backwards, two inputs one output, zk-snark proof that two original hidden values add up to the new hidden value and that the new hash result is SHA256(new-coin-secret + new-hidden-value). If you want to transfer ownership of a coin then just redeem at input, and output same as mined coin except using recipient stealth address (which is a public key) to encrypt(coin-secret + hidden-value). - Dan On 2014-01-06 4:03 AM, Peter Todd wrote: * Abstract A Stealth Address is a new type of Bitcoin address and related scriptPubKey/transaction generation scheme that allowers payees to publish a single, fixed, address that payors can send funds efficiently, privately, reliably and non-interactively. Payors do not learn what other payments have been made to the stealth address, and third-parties learn nothing at all. (both subject to an adjustable anonymity set) -- 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
Re: [Bitcoin-development] bip-0021 and bip-0072 ambiguities mistakes
Yes please, pull req would be great! I also noticed that escaping doesn't seem to be necessary, and the resultant de-escaped QRcodes are certainly much nicer! Thanks! -- 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
[Bitcoin-development] bip-0021 and bip-0072 ambiguities mistakes
Hello, I am attempting to write a parser for bip-0021 URI's, including support for the new bip-0072 payment parameters. My goal is absolute correctness. Unfortunately, these BIP's have a few ambiguities and mistakes which ought to be corrected. First, I would like to point out that internet RFC 3986 governs the general syntax for URI's. It obsoletes RFC 1738 and various other early RFC's. Since RFC 3986 came out in 2005, I think we can agree that any bitcoin URI scheme should use this and not the earlier ones. Unfortunately, bip-0021 never actually mentions RFC 3986, which is a big omission. Even worse, bip-0072 explicitly refers to RFC 1738, which is obsolete. This is a problem, since the old, obsolete standard requires more escapes than are actually necessary. Updating bip-0072 to refer to RFC 3986 instead would allow shorter, more readable bitcoin URI's (things like slashes in payment addresses wouldn't need to be escaped). Secondly, neither of the bip's describe what to do with international characters. I doubt anybody wants to limit the label and message parameters to 7-bit ASCII, so a character encoding needs to be defined. RFC reccomends that all new URI schemes use UTF-8 as their encoding, which is perfectly reasonable. The bip-0021 standard just needs to actually say so. Finally, there is an error in the bip-0021 BNF grammar, which never mentions the '' separator between query elements. What is the procedure for getting these BIP's corrected? Submit a pull request with the changes? Hopefully we can all agree that these fixes are useful and necessary. -William P.S. The bitcoin-qt client uses QUrl to parse bitcoin uri's, and that is based on RFC 3986. Thus, the bitcoin-qt client is probably already implementing these suggestions. -- 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] bip-0021 and bip-0072 ambiguities mistakes
On Thu, Mar 6, 2014 at 2:59 PM, Mike Hearn m...@plan99.net wrote: Yes please, pull req would be great! I also noticed that escaping doesn't seem to be necessary, and the resultant de-escaped QRcodes are certainly much nicer! Thanks! All right, I have submitted the pull request. Hopefully, the specified behavior now corresponds more closely to what the bitcoin-qt client is actually doing, and to what the RFC recommends. -William -- 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
