Re: [Bitcoin-development] bip-0021 and bip-0072 ambiguities & mistakes
On Thu, Mar 6, 2014 at 2:59 PM, Mike Hearn 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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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 17:03 GMT+00:00 Mike Hearn : > About the video - I'm curious how your device is better than just a > regular tablet. Could you give us the elevator pitch? :) sure, here: - tougher than phone/tablet. Phone dropped on the tiled floor is likely to die instantly. Our device is designed to survive everyday intense use and drops on the floor also. - cheaper than phone/tablet. Usual phone/tablet costs few hundred bucks, our device on mass scale will be definitely cheaper than that. Maybe a noname chinese tablet will match on price, but then again what about reliability? - simpler than phone/tablet. Phone app needs some basic understanding to operate. Cheap cashier employees hired by small corner shops might find this a challenge. - safer than phone/tablet. No option to install random apps on it. And no temptation to steal it from the counter. -- 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=122218951&iu=/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=122218951&iu=/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:12 PM, Mike Hearn wrote: > 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. > Yes, I could see how that could get hairy; it would also need some ability to rate those giving the feedback, such that if you generate a whole bunch of payments to yourself, those payees don't have reputation on their own, so their review of you as a payer isn't weighted that highly. Then you have that ring-of-trust possibility where Alice thinks Eve is bad, so the fact that Eve thinks Bob is good doesn't impact Alice. But if Carol thinks Eve is good, Carol thinks Bob is good too, so Bob's reputation is different based on who's asking, and 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? -- 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=122218951&iu=/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=122218951&iu=/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 11:07 AM, Mike Hearn wrote: > 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. > That makes sense, to have self-signed certificates as a basic start, but then is it possible to have a Bitcoin user (address) add reputation/sign such a certificate, rather than having a central signing authority? 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) such that any user can add to the reputation with just the Bitcoin infrastructure, without having to learn X.500 certificate signing on top of EC signatures? If there was a standard structure for a message to be EC-signed with your Bitcoin client, and then a distributed store of those signed messages, could that form a reputation score? -- 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=122218951&iu=/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 16:46 GMT+00:00 Andreas Schildbach : > 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. 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. > No, I'm generating it on server and sending only URL via NFC. I think this area will change before we launch in production. Ideally I want the device to be completely autonomous, controlled on site by the merchant, probably with an app on his phone. But right now we have a backend server that gives merchant a dashboard with device configuration control, transactions history, daily reconciliation data and copies of receipts. So the PDF is sent from that server. We should avoid second tap ideally, but we need to make sure receipts and payment proofs are usable and understandable for both payers and payees. Right now a paperless PDF-only process is already a huge leap ahead comparing to numerous paper receipts printed for each transaction by existing POS systems. Implementing proof of payment based on BIP70 payment request+transaction in the blockchain+memo will require even bigger shift in the merchant's view on how business runs. Also it will need additional software on his side to actually be able to view and confirm these proofs of payment. In theory - yes, BIP70 will create a way to implement proof of payment. In practice in real life right now I don't see it viable, it will take time to adopt and few intermediary steps like PDF based paperless process I've implemented. -- 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=122218951&iu=/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=122218951&iu=/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 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 > x1. > 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=122218951&iu=/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 wrote: > 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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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 x1. -- 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=122218951&iu=/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" 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=122218951&iu=/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 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. > 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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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" : > 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 wrote: > >> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo >> 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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/4140/ostg.clktrk___ Bitcoin-develo
[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 -- 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=122218951&iu=/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
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 wrote: > On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo 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=122218951&iu=/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=122218951&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
