Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 08:02:03AM +, Adam Back wrote: FWIW I've been advocating this kind of thing in various forms for literally years, including to hold fidelity bonded banks honest - what you now call 'federated sidechains' - and most recently Feb 12th on #bitcoin-dev: 19:56 petertodd leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees 19:57 petertodd leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend 19:58 leakypat Yeah, proof of double spend would ideally be done at the protocol level 19:59 petertodd leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas... Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Equally, that *is* what replace-by-fee scorched-earth does without the need for a soft-fork, minus the cryptographic proof and with a bit less flexibility. I agree with Mike Jeff. Blowing up 0-confirm transactions is vandalism. Is releasing a version of Bitcoin Core with different IsStandard() rules than the previous version vandalism? Is mining with a different policy than other people vandalism? Is mining at a pool that gets sybil attacked vandalism? Are my replace-by-fee tools an act of vandalism? Because every one of those things causes people to get double-spent in the real world, even losing tens of thousands of dollars until they get some sense and stop treating unconfirmed transactions as confirmed. Is it vandalism if you decide to host a wedding right next to a hairpin corner at a rally race and complain to me that mud is getting on the pretty white dresses? Is it vandalism if I tell that wedding party to fuck off before someone gets hurt? Is it vandalism if some racers take the mudguards off for a few laps to see if we can encourage them to leave before someone gets *actually* hurt? Or someone decides that the solution is to pave the track over and hold a bicycle race instead... -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org: Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another. So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new. Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block. Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created? Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves? In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote: In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. I keep telling people not to accept transactions with zero confirmations, but no one listens. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back a...@cypherspace.org wrote: away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. Scenario: Users are using some system in a way that the system was not intended to be used. Let me also further constrain the scenario and suggest that the function (pretend that means instantaneous confirmed transactions) that the user wants is impossible. So in this scenario, is it your job as some developer to change the system to do something it wasn't designed to do? I mean, you certainly weren't the one telling them they should accept zero confirmation transactions. Also, I make no claims as to whether this scenario maps accurately to the current topic. - Bryan http://heybryan.org/ 1 512 203 0507 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com wrote: In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to tell whether the motivation was fee replacement, output replacement, or both. My proposal is to always treat these instances as output replacement and punish the sender. The sender needs to make it unambiguously clear it's only a fee replacement by creating a new transaction that produces an output with the desired extra fee and then adding an input that spends it to the original transaction. That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed) Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= =1vbN -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote: My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. If I understand this is also your own motivation. Indeed, which is why I wrote some easy-to-use and highly effective tools to pull off double-spends and made sure to publicise them and their effectiveness widely. They've had their desired effect and very few people are relying on unconfirmed transactions anymore. As for the remaining, next week alone I'll be volunteering one or two hours of my consulting time to discuss solutions with a team doing person-to-person trading for instance. Like I've said repeatedly, the current weaker 0-conf transactions gets people new to Bitcoin - both individuals and companies - burnt over and over again because inevitably someone eventually gets motivated and breaks them, and suddenly they lose stacks of money. Keeping *that* kind of security around rather than depreciating it ASAP and being honest about what Bitcoin can do does no-one any good. Anyway, there is no one magic solution to this stuff - the best solutions vary greatly on the situation. -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 14:29 skrev Natanael natanae...@gmail.com: Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org: Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another. So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new. Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block. Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created? Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves? In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. Additional comments: If you punish the creation of UTXO_replacement, you will punish people who was lead to think zero-confirmation transactions were safe and thus that chains of zero-confirmation transactions also were safe. If you don't, but STILL accept chains of zero-confirmation transactions were not all of them are covered by fidelity bonds, then you failed to protect yourself against thieves who creates chains of unconfirmed transactions. Another question: if all transactions in the chain are covered by fidelity bonds for their own value, which one pays out to who? Does only the first one pay out, and only to the last party in the chain? Or to every subsequent party after him? In full or just a fraction? Why, why not? You might not know which of these serviced their customers in full without getting full value back in exchange due to the doublespend. What if the fidelity bond is too small, do you stop accepting it as a zero-confirmation transaction? Do you even accept chains of unconfirmed transactions at all? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock b...@mattwhitlock.name wrote: On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote: In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. Great example! Systems that appear more secure than they really are to uninformed users are dangerous. Same reason why brain wallets are such scary technology, and equally, why I like to give a few dollars away every so often to the guys brute forcing weak ones. I keep telling people not to accept transactions with zero confirmations, but no one listens. In my experience there's a pattern of accept unconfirmed; get burned badly/see someone else get burned; stop relying on them Although of course, there's some bias in that people contact me asking what to do after they get burned. :) -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6eKG AAoJEMCF8hzn9LncGz0H/ivA9J4MqsVnkPm9JVAIXgZiT7rAVO0Rp1lO/8PGPS6K dXBFXESicszeBx5yeyQrLUFh58DVgp21sFHSMNTKmujDJJgxNf/ygffN9dTLriwt PJcDWvxPzqyLy2e/CloRonxwlO3+Umv1OiPs1yy7a7auDVAEm1xvh/pc3A48u1bO ++cyxZs8j5yv3Ms2n/FmGekhL9jZHJAgmiVnSks0cMqq9+cYipEjy+FEq3KFGlFI 4iZ58f57g6W7bVqM+9Z6dbLczWobnQ+nfo7lFZWgGdbhKf4Jv7tHOcfSw4nbmJz4 OgWmKtM724h7abOIrqJnTF0u10dmapVv+lRtjiGXo8c= =7W03 -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On 2015-02-22 14:33, Peter Todd wrote: On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote: My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. If I understand this is also your own motivation. Indeed, which is why I wrote some easy-to-use and highly effective tools to pull off double-spends and made sure to publicise them and their effectiveness widely. They've had their desired effect and very few people are relying on unconfirmed transactions anymore. You mean you wrote a bunch of FUD about zeroconf transactions while working for companies like Coinbase and GreenAddress that were trying to sell 100% centralized solutions? Lets just be clear on this. I and many other people tried your replace-by-fee tools and found out that they worked **maybe** 1-2% of the time. You claimed 95% success rates. As for the remaining, next week alone I'll be volunteering one or two hours of my consulting time to discuss solutions with a team doing person-to-person trading for instance. A team You mean a **Company**? We don't need yet another 100% centralized LocalBitcoins snooping on our transactions. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote: On 2/11/2015 10:47 PM, Peter Todd wrote: My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 This patch immediately simplifies successful double-spends of unconfirmed transactions. But the idea that it gives a path to making zeroconf transactions economically secure is quite dubious. * You don't provide sufficient means to detect and relay double-spends, which is necessary to trigger a scorched-earth reaction. Not all double-spends will conform to your replacement rules. No, OTOH if they don't then the situation is no difference from what we have now, and replace-by-fee does no harm. Meanwhile, relaying of bare double-spend signatures can be implemented in the future, as I suggested last year for your/Andresen's double-spend relaying patch. Did you notice the even more obvious way to defeat ANYONECANPAY scorched earth with that patch? * Maybe XT nodes would help to overcome this. But meanwhile, in the ANYONECANPAY design, Bob's replacement is a triple-spend. Even XT nodes won't relay it. So? RBF nodes will. * It's unclear when, if ever, any senders/receivers will actually try to use scorched-earth as a double-spend deterrent. I suspect many won't, because few people need to rely on unconfirmed transactions anyway. Also, this patch significantly weakens DoS protections: * It removes the early conflict check, making all conflict processing more expensive If you're going to consider replacement, conflict processing will definitely be more expensive. :) An actual DoS attacker would do their DoS attack in a way where conflict processing has nothing to do with it, so this change does no actual harm. * There is no attempt to protect against the same transaction being continually replaced with the fee bumped by a minimal amount. What exact git commit were you looking at? I did have an early one that did have a bug along those lines, now fixed. The current version ensures every replacement pays at least as much additional fees as would normally cost to broadcast that much data on the network, and additionally requires the fees/KB to always increase; under all circumstances it should be no more of a DoS threat than low-fee transactions are otherwise. I'd like to know if there is a flaw in that code however! -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 10:17 AM, Natanael wrote: The problem with this approach is that it is worthless as a predictor. We aren't dealing with traffic safety and road design - we are dealing with adaptive attackers and malicious miners and pools. Anything which does not invalidate blocks carrying doublespends WILL allow malicious miners and pools to conspire with thieves to steal money. The probability of being hit will then be (their proliferation in your business area) * (their fraction of the mining power). That might seem to give small numbers for most sets of reasonable assumptions. But the problem is that's only an average, and the people being hit might have small profit margins - one successful attack can place hundreds of merchants in red numbers and force them to shut down. You should never expose yourself to attacks which you can't defend against and which can be fatal. In particular not if there's nothing in the environment that is capable of limiting the size or numbers of any attacks. And there's no such thing today in Bitcoin. This is why I sketched out the multisignature notary approach, and why some decided to extend that approach with collateral (NoRiskWallet) to further reduce trust in the notary. This is the single most practical approach I know of today to achieve ACTUAL SECURITY for unconfirmed transactions. Don't like it? See if you can do better! Just don't rely on zero-confirmation transactions! You just disproved your own argument. It is possible to predict risk, and therefore to price the risk. You also noted that for some Bitcoin users, the price of that risk is too high for the types of transactions in which wish to engage. In what way does that translated into a universal requirement for everybody to use multisignature notaries? Surely the users who can afford the risk can use zero conf if they like, and those who can't can use multisig notaries? -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73 ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9 ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7 ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j 5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1 i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2 VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN RqUYrOBf/PaMneNxwJp+ =w36r -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 17:00 skrev Justus Ranvier justusranv...@riseup.net: On 02/22/2015 07:50 AM, Matt Whitlock wrote: This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. I keep telling people not to accept transactions with zero confirmations, but no one listens. A better solution is to track the failure rate of zero confirmation transactions, and adjust prices accordingly to cover the expected loss. This is what every merchant *already does* since no payment method has a 0% fraud rate. Even physical cash has a probability of being counterfeit, and the prices you pay for things at a convenience store already have that risk priced in. The idea that zero confirmation transactions require a 100% guarantee is a strawman, especially since there exists no number of confirmations the actually produce a 100% irreversibility guarantee. The problem with this approach is that it is worthless as a predictor. We aren't dealing with traffic safety and road design - we are dealing with adaptive attackers and malicious miners and pools. Anything which does not invalidate blocks carrying doublespends WILL allow malicious miners and pools to conspire with thieves to steal money. The probability of being hit will then be (their proliferation in your business area) * (their fraction of the mining power). That might seem to give small numbers for most sets of reasonable assumptions. But the problem is that's only an average, and the people being hit might have small profit margins - one successful attack can place hundreds of merchants in red numbers and force them to shut down. You should never expose yourself to attacks which you can't defend against and which can be fatal. In particular not if there's nothing in the environment that is capable of limiting the size or numbers of any attacks. And there's no such thing today in Bitcoin. This is why I sketched out the multisignature notary approach, and why some decided to extend that approach with collateral (NoRiskWallet) to further reduce trust in the notary. This is the single most practical approach I know of today to achieve ACTUAL SECURITY for unconfirmed transactions. Don't like it? See if you can do better! Just don't rely on zero-confirmation transactions! -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the transaction before you have seen the details. (I believe Google Wallet can also work this way.) 3. Tap the phone, then establish a Bluetooth connection which allows you to do all necessary communication even if the user takes the device back. I feel that option 3 is the nicest UX, so that is what I am focusing on right now, but there are pros and cons to all options. One disadvantage of option 3 in practice is, that many users - in my experience - have Bluetooth turned off, so it can result in additional UI dialogs popping up, asking the user to turn on Bluetooth. Regarding doing everything via Bluetooth or maybe BLE: I have been following the work that Airbitz has done around that, but personally I prefer the NFC interaction of I touch what I want to pay rather than a payment request comes to me through the air and I figure out whether it is meant for me/is legitimate. ## NFC data formats ## A bit of background for those who are not that familiar with NFC: Most Bitcoin wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I am aware (with CoinBlesk being an exception, which uses host-based card emulation, if I understand it correctly). NDEF defines a number of record types, among them 'URI' and 'Mime Type'. A common way of using NFC with Bitcoin is to create a URI record that contains a Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support the mime type record, which is then set to 'application/bitcoin-paymentrequest' and the rest of the NFC data is a complete BIP70 payment request. ## Implementation ## To structure the discussion a little bit, I have listed a number of scenarios to consider below. Not every possible combination is listed, but it should cover a bit of everything. Scenarios: 1) Scan QR code, transmit transaction via Bitcoin network Example QR code: bitcoin:1asdf...?amount=42 2) Touch NFC pad, transmit transaction via Bitcoin network Example NFC URI: bitcoin:1asdf...?amount=42 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP Example QR code: bitcoin:1asdf...?amount=42r=https://example.org/bip70paymentrequest 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP Example NFC URI: bitcoin:1asdf...?amount=42r=https://example.org/bip70paymentrequest 5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth Example QR code: bitcoin:1asdf...?amount=42bt=1234567890AB Payment request has 'payment_url' set to 'bt:1234567890AB' 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth Example NFC URI: bitcoin:1asdf...?amount=42bt=1234567890AB Payment request has 'payment_url' set to 'bt:1234567890AB' Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just listing them here for comparison.
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On 2/11/2015 10:47 PM, Peter Todd wrote: My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 This patch immediately simplifies successful double-spends of unconfirmed transactions. But the idea that it gives a path to making zeroconf transactions economically secure is quite dubious. * You don't provide sufficient means to detect and relay double-spends, which is necessary to trigger a scorched-earth reaction. Not all double-spends will conform to your replacement rules. * Maybe XT nodes would help to overcome this. But meanwhile, in the ANYONECANPAY design, Bob's replacement is a triple-spend. Even XT nodes won't relay it. * It's unclear when, if ever, any senders/receivers will actually try to use scorched-earth as a double-spend deterrent. Also, this patch significantly weakens DoS protections: * It removes the early conflict check, making all conflict processing more expensive * There is no attempt to protect against the same transaction being continually replaced with the fee bumped by a minimal amount. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
- Sent from my tablet Den 22 feb 2015 17:25 skrev Justus Ranvier justusranv...@riseup.net: You just disproved your own argument. It is possible to predict risk, and therefore to price the risk. Your fault is that you assume the predictions can be reliable and trustable. They can not be. The data you have available has none of the indicators you actually NEED to make predictions. You're making extrapolations from the past, not calculations based on recent trends and behavior globally. You also noted that for some Bitcoin users, the price of that risk is too high for the types of transactions in which wish to engage. In what way does that translated into a universal requirement for everybody to use multisignature notaries? It isn't universal. It is just the most practical solution if you need instant confirmation for high value transactions with customers you don't yet trust. Surely the users who can afford the risk can use zero conf if they like, and those who can't can use multisig notaries? Use whatever you want. I don't care. I will warn you about the risks and make suggestions, but I won't force you to do anything differently. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
I agree with Mike Jeff. Blowing up 0-confirm transactions is vandalism. bitcoin transactions are all probabilistic. there is a small chance 1-confirm transactions can be reversed, and a different but also usable chance that 0-confirm transactions can be reversed. I know 0-confirm is implemented in policy and not consensus, but it provides fast transactions and a lot of the current ecosystem is using it for low value transactions. why would anyone want to vandalise that. to echo Mike bitcoin itself kind of depends on some honest majority, we can otherwise get to situations soon enough where its more profitable to double-spend than mine honestly as subsidy drops and transaction values increase even without 0-confirm transactions. subsidy doesnt last forever (though it lasts a really long time) and even right now if you involve values that dwarf subsidy you could make a criminally rational behaviour that was more profitable. we even saw 0-confirm odds-attacks against satoshi dice clones. but if we assume the criminal rational model, its a is a race to the bottom logic, and bitcoin is already broken if we have someone who wants to go for it with high values. that'd be scorched earth also. (I read the rest of the arguments, i understood them, I disagree, no need to repeat in reply.) So how about instead, to be constructive, whether you agree with the anti-arson view or not, lets talk about solutions. Here's one idea: We introduce a new signature type that marks itself as can be spent by miners if a double-spend is seen (before 1-confirm.) We'd define a double-spend as a spend that excludes outputs to avoid affecting valid double-spend scenarios. And we add behaviour to relay those double-spends (at priority). We may even want the double-spend to be serialisation incomplete but verifiable to deter back-channel payments to pretend not to receive one, in collusion with the double-spending party. Now the risk to the sender is if they accidentally double-spend. How could they do that? By having a hardware or software crash where they sent a tx but crashed before writing a record of having sent it. The correct thing to do would be to transactionally write the transaction before sending it. Still you can get a fail if the hardware irrecoverably fails, and you have to resume from backup. Or if you run multiple non-synced wallets on the same coins. Typically if you recover from backup the 1-confirmation window will have passed so the risk is limited. The feature is opt-in so you dont have to put high value coins at risk of failure. (Its related to the idea of a one-use signature, where two signatures reveals a simultaneous equation that can recover the private key; except here the miner is allowed to take the coins without needing the private key). Its soft-forkable because its a new transaction type. ps I agree with Greg also that longer-term more scalable solutions are interesting, but I'd like to see the core network work as a stepping stone. As Justus observed: the scalable solutions so far have had non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain 0-confirm. Adam On 22 February 2015 at 04:06, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 02:37 PM, Andy Schroder wrote: I'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. Yes, this should be a prerequisite issue to all others. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There is no reason to add this significant complexity. The purpose of SSL/TLS is to establish privacy over a *public* channel. But to do so requires verification by the user of the merchant's public certificate. Once we rely on the channel being *private*, the entire SSL process is unnecessary. Presumably we would not want to require PKI for privacy, since that's a bit of a contradiction. But if one wants to do this NFC is not required, since the private session can be established over the public (Bluetooth) network. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015 02:08 PM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the transaction before you have seen the details. (I believe Google Wallet can also work this way.) 3. Tap the phone, then establish a Bluetooth connection which allows you to do all necessary communication even if the user takes the device back. I feel that option 3 is the nicest UX, so that is what I am focusing on right now, but there are pros and cons to all options. One disadvantage of option 3 in practice is, that many users - in my experience - have Bluetooth turned off, so it can result in additional UI dialogs popping up, asking the user to turn on Bluetooth. Regarding doing everything via Bluetooth or maybe BLE: I have been following the work that Airbitz has done around that, but personally I prefer the NFC interaction of I touch what I want to pay rather than a payment request comes to me through the air and I figure out whether it is meant for me/is legitimate. ## NFC data formats ## A bit of background for those who are not that familiar with NFC: Most Bitcoin wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I am aware (with CoinBlesk being an exception, which uses host-based card emulation, if I understand it correctly). NDEF defines a number of record types, among them 'URI' and 'Mime Type'. A common way of using NFC with Bitcoin is to create a URI record that contains a Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support the mime type record, which is then set to 'application/bitcoin-paymentrequest' and the rest of the NFC data is a complete BIP70 payment request. ## Implementation ## To structure the discussion a little bit, I
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hello Jan, Regarding a few of your questions: Andreas and I had a number of private discussions regarding the payment_url parameter. I had suggested a additional_payment_urls repeated parameter, but he didn't seem to like that idea and I personally am indifferent, so that is why we decided to just change payment_url to a repeated field. The spec is simpler without the additional_payment_urls, but the wallets have to be a little bit smarter finding the right url they want to use in the list. It's maybe not a bad idea for the wallet to try all payment_url mechanisms in parallel. Should we add this as a recommendation to wallets in TBIP75? I had heard from Andreas a few weeks ago that the multiple r parameters was not yet implemented. Maybe your interest can motivate him to do so! I actually also happen to be using nfcpy. I am having some reliability issues as well with it. What exactly are your problems? I have seen your video before. I guess I'm wondering how your prototype works with bitpay and bluetooth. Doesn't bitpay sign the payment request for you with an https based payment_url? If so, how do you add the bluetooth payment_url while keeping their signature valid? In your video it looks like the phone still has cellular and wifi reception (it is not offline). You mention workflow options 1,2,3. You forgot to mention that options 1,2 are not backwards compatible with older wallets. Regarding the NFC data formats. I would like to clarify that the wallets are having those events dispatched by the android OS. The URI and mime type events are sent to the application in the same way as from other sources such as a web browser, e-mail, stand alone QR code scanner app, etc.. So, I don't think the wallet actually knows it is receiving the event from NFC. That is one reason why so many existing wallets happen to support BIP21 payment request via NFC. Andreas can correct me if I am wrong on these statements. I'm a little weary sending the mime type based format over NFC because of backwards compatibility and because of the long certificate chain that needs to be transferred. You want that tap to be as robust and fast as possible. A bluetooth connection can have a retry without any user interaction. I don't really understand why Mike Hearn has the objections to the h parameter. It seems like you should already be ready to produce the BIP70 payment request at the time when the URI is generated. I'd also like to clarify that the h parameter is for more than just unsigned payment requests. You can have a signed payment request with the wrong signer. There is way to much brainpower required to verify that the signer is actually the merchant you are doing business with. Just think how many times you shop at a store that you don't even know the name of. Also, the store may contract their payment processing out to another party, or they may have multiple store names but use the same payment processing system for all their stores, and the parent company has a different name. It's good to have both the h parameter AND the signed payment request. I don't really like the Airbitz proposal. Figuring out if your selecting is the right one is a real nuisance. The idea is neat in a few applications, but I just don't think it is going to work for people as the most efficient and trouble free option day to day. I realize they are probably doing it to work with Apple's limited functionality phones (and BLE is a new buzz word). However, I don't think we should base bitcoin around what Apple wants us to do. They've already had their war on bitcoin. They are going to do whatever they can to protect their NFC based payment system. We need to make their platform the the less desirable one if they are going to play the game that way. If that means an Airbitz like proposal is implemented as a fallback, maybe that is fine and POS systems need to support both, but I just don't think we should limit what we can do because of Apple's products capabilities. There is also the ack memo that I mentioned in reference [2]. I think we can improve upon this really. Can we make a new status field or different bluetooth message header? I know Andreas didn't want to change it because that is how his app already works, but I don't think the way it is is ideal. I'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the r and payment_url parameters makes sense, with only the potential backward compat issue on payment_url. TBIP75 furthermore proposes to include an additional 'h' parameter which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed. This would have also been my suggestion, although I know that Mike Hearn has raised concerns about this approach. One being, that one needs to finalize the BIP70 payment request at the time the QR code and NFC URI is generated. ... 3) Are there other comments regarding 'h' parameter as per TBIP75? Yes, this design is problematic from a privacy standpoint. Anyone within the rather significant range of the Bluetooth terminal is able to capture payment requests and correlate them to people. In other words it can be used to automate tainting. The problem is easily resolved by recognizing that, in the envisioned face-to-face trade, proximity is the source of trust. Even in the above proposal the h parameter is trusted because it was obtained by proximity to the NFC terminal. The presumption is that this proximity produces a private channel. As such the tap should transfer a session key used for symmetric block cipher over the Bluetooth channel. This also resolves the issue of needing to formulate the payment request before the NFC. As an aside, in other scenarios, such as an automated dispenser, this presumption does not hold. The merchant is not present to guard against device tampering. Those scenarios can be secured using BIP70, but cannot guarantee privacy. The other differences I have with the proposal pertain to efficiency, not privacy or integrity of the transaction: The proposed resource name is redundant with any unique identifier for the session. For example, the h parameter is sufficient. But with the establishment of a session key both as I propose above, the parties can derive a sufficiently unique public resource name from a hash of the key. An additional advantage is that the resource name can be fixed-length, simplifying the encoding/decoding. The MAC address (and resource name) should be encoded using base58. This is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. There is no need for the establishment of two Bluetooth services. I would change the payment_url recommendation so that the list order represents a recommended ordering provided by the terminal for the wallet. I wrote up my thoughts on these considerations last year and recently revised it by adding a section at the end to incorporate the r and payment_url generalizations from Andreas and Andy. https://github.com/evoskuil/bips/tree/master/docs e On 02/22/2015 11:08 AM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
One correction inline below. e On 02/22/2015 02:39 PM, Eric Voskuil wrote: Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the r and payment_url parameters makes sense, with only the potential backward compat issue on payment_url. TBIP75 furthermore proposes to include an additional 'h' parameter which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed. This would have also been my suggestion, although I know that Mike Hearn has raised concerns about this approach. One being, that one needs to finalize the BIP70 payment request at the time the QR code and NFC URI is generated. ... 3) Are there other comments regarding 'h' parameter as per TBIP75? Yes, this design is problematic from a privacy standpoint. Anyone within the rather significant range of the Bluetooth terminal is able to capture payment requests and correlate them to people. In other words it can be used to automate tainting. The problem is easily resolved by recognizing that, in the envisioned face-to-face trade, proximity is the source of trust. Even in the above proposal the h parameter is trusted because it was obtained by proximity to the NFC terminal. The presumption is that this proximity produces a private channel. As such the tap should transfer a session key used for symmetric block cipher over the Bluetooth channel. This also resolves the issue of needing to formulate the payment request before the NFC. As an aside, in other scenarios, such as an automated dispenser, this presumption does not hold. The merchant is not present to guard against device tampering. Those scenarios can be secured using BIP70, but cannot guarantee privacy. The other differences I have with the proposal pertain to efficiency, not privacy or integrity of the transaction: The proposed resource name is redundant with any unique identifier for the session. For example, the h parameter is sufficient. But with the establishment of a session key both as I propose above, the parties can derive a sufficiently unique public resource name from a hash of the key. An additional advantage is that the resource name can be fixed-length, simplifying the encoding/decoding. The MAC address (and resource name) should be encoded using base58. This The MAC address (and session key) should be encoded using base58. This is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. There is no need for the establishment of two Bluetooth services. I would change the payment_url recommendation so that the list order represents a recommended ordering provided by the terminal for the wallet. I wrote up my thoughts on these considerations last year and recently revised it by adding a section at the end to incorporate the r and payment_url generalizations from Andreas and Andy. https://github.com/evoskuil/bips/tree/master/docs e On 02/22/2015 11:08 AM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sunday, February 22, 2015, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com javascript:; wrote: In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to tell whether the motivation was fee replacement, output replacement, or both. My proposal is to always treat these instances as output replacement and punish the sender. The sender needs to make it unambiguously clear it's only a fee replacement by creating a new transaction that produces an output with the desired extra fee and then adding an input that spends it to the original transaction. That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed) That won't work because in general it is impossible to know which transaction is the original. Did we add outputs to transaction A? Or remove outputs from transaction B? Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative. I think you're unnecessarily complicating use cases. As for 0-conf security, there are instances where 0-conf transactions make a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such services which could be immediately shut off upon detection of a double-spend. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= =1vbN -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Andy Schroder On 02/22/2015 06:06 PM, Eric Voskuil wrote: On 02/22/2015 02:37 PM, Andy Schroder wrote: I'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. Yes, this should be a prerequisite issue to all others. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There is no reason to add this significant complexity. The purpose of SSL/TLS is to establish privacy over a *public* channel. But to do so requires verification by the user of the merchant's public certificate. Once we rely on the channel being *private*, the entire SSL process is unnecessary. I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? Presumably we would not want to require PKI for privacy, since that's a bit of a contradiction. But if one wants to do this NFC is not required, since the private session can be established over the public (Bluetooth) network. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015 02:08 PM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the transaction before you have seen the details. (I believe Google Wallet can also work this way.) 3. Tap the phone, then establish a Bluetooth connection which allows you to do all necessary communication even if the user takes the device back. I feel that option 3 is the nicest UX, so that is what I am focusing on right now, but there are pros and cons to all options. One disadvantage of option 3 in practice is, that many users - in my experience - have Bluetooth turned off, so it can result in additional UI dialogs popping up, asking the user to turn on Bluetooth. Regarding doing everything via Bluetooth or maybe BLE: I have been following the work that Airbitz has done around that, but personally I prefer the NFC interaction of I touch what I want to pay rather than a payment request comes to me through the air and I figure out whether it is meant for me/is legitimate. ## NFC data formats ## A bit of background for those who are not that familiar with NFC: Most Bitcoin wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I am aware (with CoinBlesk being an exception, which uses host-based card emulation, if I understand it correctly). NDEF defines a number of record types, among them 'URI' and 'Mime
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Andy Schroder On 02/22/2015 05:48 PM, Eric Voskuil wrote: One correction inline below. e On 02/22/2015 02:39 PM, Eric Voskuil wrote: Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the r and payment_url parameters makes sense, with only the potential backward compat issue on payment_url. TBIP75 furthermore proposes to include an additional 'h' parameter which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed. This would have also been my suggestion, although I know that Mike Hearn has raised concerns about this approach. One being, that one needs to finalize the BIP70 payment request at the time the QR code and NFC URI is generated. ... 3) Are there other comments regarding 'h' parameter as per TBIP75? Yes, this design is problematic from a privacy standpoint. Anyone within the rather significant range of the Bluetooth terminal is able to capture payment requests and correlate them to people. In other words it can be used to automate tainting. The problem is easily resolved by recognizing that, in the envisioned face-to-face trade, proximity is the source of trust. Even in the above proposal the h parameter is trusted because it was obtained by proximity to the NFC terminal. The presumption is that this proximity produces a private channel. As such the tap should transfer a session key used for symmetric block cipher over the Bluetooth channel. This also resolves the issue of needing to formulate the payment request before the NFC. As an aside, in other scenarios, such as an automated dispenser, this presumption does not hold. The merchant is not present to guard against device tampering. Those scenarios can be secured using BIP70, but cannot guarantee privacy. The other differences I have with the proposal pertain to efficiency, not privacy or integrity of the transaction: The proposed resource name is redundant with any unique identifier for the session. For example, the h parameter is sufficient. But with the establishment of a session key both as I propose above, the parties can derive a sufficiently unique public resource name from a hash of the key. An additional advantage is that the resource name can be fixed-length, simplifying the encoding/decoding. The MAC address (and resource name) should be encoded using base58. This The MAC address (and session key) should be encoded using base58. This As I mentioned in my other e-mail, I don't know that we can consider this NFC a private channel, so I don't think a session key should be transmitted over it. is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. There is no need for the establishment of two Bluetooth services. I would change the payment_url recommendation so that the list order represents a recommended ordering provided by the terminal for the wallet. I wrote up my thoughts on these considerations last year and recently revised it by adding a section at the end to incorporate the r and payment_url generalizations from Andreas and Andy. The order is set so that it maintains backwards compatibility by providing the https request first. As mentioned in the proposal, the order of the r parameters has the recommended (but not required) priority. The wallet is encouraged to use the same protocol (but not required). https://github.com/evoskuil/bips/tree/master/docs e On 02/22/2015 11:08 AM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 11:37 PM, Andy Schroder wrote: Andreas and I had a number of private discussions regarding the payment_url parameter. I had suggested a additional_payment_urls repeated parameter, but he didn't seem to like that idea and I personally am indifferent, so that is why we decided to just change payment_url to a repeated field. The spec is simpler without the additional_payment_urls, but the wallets have to be a little bit smarter finding the right url they want to use in the list. It's maybe not a bad idea for the wallet to try all payment_url mechanisms in parallel. Should we add this as a recommendation to wallets in TBIP75? I think it will cause too much chaos. My recommendation for the payment_url field is prefer the same mechanism that was used for fetching the payment request. Only if the recommendation fails use the alternatives in order (or in reverse order, I'm not sure at the moment). Regarding the NFC data formats. I would like to clarify that the wallets are having those events dispatched by the android OS. The URI and mime type events are sent to the application in the same way as from other sources such as a web browser, e-mail, stand alone QR code scanner app, etc.. So, I don't think the wallet actually knows it is receiving the event from NFC. I think it can know. The method for catching these intents is very similar and you can reuse almost all code, but in fact you need to add an additional line to your AndroidManifest.xml. That is one reason why so many existing wallets happen to support BIP21 payment request via NFC. Many? Bitcoin Wallet and its forks were the only ones for about a year. Only recently Mycelium caught up and the others still do not care I guess. I'm a little weary sending the mime type based format over NFC because of backwards compatibility and because of the long certificate chain that needs to be transferred. You want that tap to be as robust and fast as possible. A bluetooth connection can have a retry without any user interaction. I agree whatever we do must be robust. However I see no reason why NFC can't be robust, see my previous post. I don't really like the Airbitz proposal. Figuring out if your selecting is the right one is a real nuisance. The idea is neat in a few applications, but I just don't think it is going to work for people as the most efficient and trouble free option day to day. I realize they are probably doing it to work with Apple's limited functionality phones (and BLE is a new buzz word). However, I don't think we should base bitcoin around what Apple wants us to do. They've already had their war on bitcoin. They are going to do whatever they can to protect their NFC based payment system. We need to make their platform the the less desirable one if they are going to play the game that way. If that means an Airbitz like proposal is implemented as a fallback, maybe that is fine and POS systems need to support both, but I just don't think we should limit what we can do because of Apple's products capabilities. Ack on Airbitz, and ack on our relationship to Apple (-: There is also the ack memo that I mentioned in reference [2]. I think we can improve upon this really. Can we make a new status field or different bluetooth message header? I know Andreas didn't want to change it because that is how his app already works, but I don't think the way it is is ideal. I'm not against improving this point, but I felt the BT enhancements and the r,r1,r2 proposals are already getting complex enough. I would like to simplify the proposal by moving unrelated things to somewhere else. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/23/2015 12:32 AM, Andy Schroder wrote: I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? I think the trust by proximity is the best we've got. If we don't trust the NFC link (or the QR code scan), what other options have we got? Speaking the session key by voice? Bad UX, and can be eavesdropped as well of course. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 03:32 PM, Andy Schroder wrote: On 02/22/2015 06:06 PM, Eric Voskuil wrote: On 02/22/2015 02:37 PM, Andy Schroder wrote: I'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. Yes, this should be a prerequisite issue to all others. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There is no reason to add this significant complexity. The purpose of SSL/TLS is to establish privacy over a *public* channel. But to do so requires verification by the user of the merchant's public certificate. Once we rely on the channel being *private*, the entire SSL process is unnecessary. I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. If the NFC communication is not private then there is no reason to use it. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. See my comments on an unmonitored terminal. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? My point is that you are not solving that problem by creating a more complex system. Either you establish trust via proximity or you don't. If you don't, it's a public network. If you do, then keep it simple. There's nothing holy about a session key in this scenario. It's not derived from long-lived keys and is itself used only once. There is nothing wrong with the URL carrying the secret. If you want to secure this channel without manual intervention, there is ultimately no other option. Presumably we would not want to require PKI for privacy, since that's a bit of a contradiction. But if one wants to do this NFC is not required, since the private session can be established over the public (Bluetooth) network. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015 02:08 PM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the transaction before you have seen the details. (I believe Google Wallet can also work this way.) 3. Tap the phone, then establish a Bluetooth connection which allows you to do all necessary communication even if the user takes the device back. I feel that option 3 is the nicest UX, so that is what I am focusing on right now, but there are pros and cons to all options. One disadvantage of option 3 in practice is, that many users - in my experience - have Bluetooth turned off, so it can result in additional UI dialogs
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Jan, this is great stuff! Thanks for sharing your experiences. I think the 4k payments requests issue must be solvable somehow. I had no trouble transmitting that amount via NFC, although yes a bit of delay was noticable. About payment_url: Protobuf allows changing optional to repeated and yes it's backwards compatible. Which is why I'm personally against parsing two fields rather than just one. 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet? No it isn't. It's implemented in bitcoinj though. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 11:39 PM, Eric Voskuil wrote: The MAC address (and resource name) should be encoded using base58. This is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. Of course this is just a minor detail, but Base64Url is well defined, almost always more efficient than Base58 and never less efficient, and implemented in way more libraries and OSes than Base58. Base58 was designed for copy-typing by humans. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/22/2015 03:35 PM, Andy Schroder wrote: On 02/22/2015 02:39 PM, Eric Voskuil wrote: Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the r and payment_url parameters makes sense, with only the potential backward compat issue on payment_url. TBIP75 furthermore proposes to include an additional 'h' parameter which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed. This would have also been my suggestion, although I know that Mike Hearn has raised concerns about this approach. One being, that one needs to finalize the BIP70 payment request at the time the QR code and NFC URI is generated. ... 3) Are there other comments regarding 'h' parameter as per TBIP75? Yes, this design is problematic from a privacy standpoint. Anyone within the rather significant range of the Bluetooth terminal is able to capture payment requests and correlate them to people. In other words it can be used to automate tainting. The problem is easily resolved by recognizing that, in the envisioned face-to-face trade, proximity is the source of trust. Even in the above proposal the h parameter is trusted because it was obtained by proximity to the NFC terminal. The presumption is that this proximity produces a private channel. As such the tap should transfer a session key used for symmetric block cipher over the Bluetooth channel. This also resolves the issue of needing to formulate the payment request before the NFC. As an aside, in other scenarios, such as an automated dispenser, this presumption does not hold. The merchant is not present to guard against device tampering. Those scenarios can be secured using BIP70, but cannot guarantee privacy. The other differences I have with the proposal pertain to efficiency, not privacy or integrity of the transaction: The proposed resource name is redundant with any unique identifier for the session. For example, the h parameter is sufficient. But with the establishment of a session key both as I propose above, the parties can derive a sufficiently unique public resource name from a hash of the key. An additional advantage is that the resource name can be fixed-length, simplifying the encoding/decoding. The MAC address (and resource name) should be encoded using base58. This The MAC address (and session key) should be encoded using base58. This As I mentioned in my other e-mail, I don't know that we can consider this NFC a private channel, so I don't think a session key should be transmitted over it. I don't think there is another option. The point of the NFC terminal is to establish trust based on proximity. I don't agree that it's insufficiently private. It's no less private than if the customer pulled out an R2-D2 interface arm and plugged into the merchant's terminal. The terminal connection can still be compromised. IOW the merchant trusts that the person who just tapped on the NFC terminal is the one who he/she is going to hand the product to, and both parties trust that because of this handshake, no non-proximate interlopers can monitor the content of the transaction. In the absence of BIP70 (quite real in some scenarios) the payer also relies on proximity to establish the identity of the receiver. Otherwise, without proximity establishment, an *independent* secure channel is required (see the Airbitz/RedPhone discussion). You end up with an infinite regression problem. RedPhone terminates this regression by relying on each party's ability to recognize the other's voice, and in the difficulty of spoofing a voice. PKI deals with it by trusting root CAs on presumed-trusted platforms (and a troublesome revocation process). WoT establishes this by unspecified means (e.g. Peter Todd has produced a nice video of him reading out his PGP key fingerprint). If interlopers are so close to the NFC terminal that they can join the session, they have effectively compromised an endpoint, so the privacy problem becomes moot. Both endpoints must secure their devices to achieve privacy in any design. is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. There is no need for the establishment of two Bluetooth services. I would change the payment_url recommendation so that the list order represents a recommended ordering provided by the terminal for the wallet. I wrote up my thoughts on these considerations last year and recently revised it by adding a section at the end to incorporate the r and payment_url generalizations from Andreas and Andy. The order is set so that it maintains backwards compatibility by providing the https request first. Understood, it just isn't entirely clear to me that the backward compat in this case doesn't depend on implementation choices of existing systems.
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
However, I don't think we should base bitcoin around what Apple wants us to do. They've already had their war on bitcoin. They are going to do whatever they can to protect their NFC based payment system. We need to make their platform the the less desirable one if they are going to play the game that way. If that means an Airbitz like proposal is implemented as a fallback, maybe that is fine and POS systems need to support both, but I just don't think we should limit what we can do because of Apple's products capabilities. Ack on Airbitz, and ack on our relationship to Apple (-: I also agree we shouldn't limit specs to Apple product capabilities. If history is any indication, NFC will be opened up to developers in iOS 9, just like touch id in was in iOS 8, and bluetooth LE in iOS 5, one major OS revision after the hardware capability is first introduced. Also, I'm pretty sure that Apple doesn't care about bitcoin at all. When they banned wallets from the app store, it was prior to the 2013 FinCEN guidance. At the time many of us, myself included, assumed USG would take the same stance with bitcoin as they did against e-gold. It wasn't clear at all that bitcoin didn't violate legal tender laws or who knows what. When Apple allowed wallets back in, it was just weeks before Apple pay launched. It's seems clear that bitcoin is too small for them to be concerned about in the slightest. Aaron Voisine co-founder and CEO breadwallet.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
