Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote: On 25 September 2013 13:15, Mike Hearn m...@plan99.net wrote: It won't fit. But I don't see the logic. A URI contains instructions for making a payment. If that instruction is pay to this address or download this file and do what you find there, it's no different unless there's potential for a MITM attack. If the request URL is HTTPS or a secured Bluetooth connection then there's no such possibility. It depends on the attacker. I think a large entity such as a govt or big to medium size corporation *may* be able to MITM https, of course the incentive to do so is probably not there ... ...until the Bitcoin payment protocol showed up and let anyone with the ability to MITM https turn that ability into untraceable cash. I won't be at all surprised if one of the most valuable things to come out of the payment protocol using the SSL PKI infrastructure is to give us a good understanding of exactly how it's broken, and to give everyone involved good reasons to fix it. Even if the flaws of SSL PKI were exploited as a way to harm bitcoin by governments and other large players - and SSL PKI remained unfixed - I'd much rather have that solid evidence that it was broken than not. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
We could also say that if protocol part (https://) is missing, it's implied automatically. So just: bitcoin:1abc?r=bob.com/r/aZgR I think that's about as small as possible without re-using the pubkey as a token in the url. On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen gavinandre...@gmail.comwrote: On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote: BTW, on the make qrcodes more scannable front -- is it too late to change BIP 72 so the new param is just r instead of request? Every byte helps when it comes to qrcodes ... Not too late, assuming there are no objections. Smaller QR codes is a very good reason to change it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
While it's good to save space, I'm at the moment not convinced that taking a de-route via an URL is a good idea to begin with. The main problem is trust. If you scan a QR code from a foreign phone, you trust that that phone is owned by the one you want to send money to. By adding the HTTP request that trust is voided. As soon as there is a BIP70 implementation, I will begin playing with putting the payment request directly into the QR code. On 09/25/2013 11:27 AM, Mike Hearn wrote: We could also say that if protocol part (https://) is missing, it's implied automatically. So just: bitcoin:1abc?r=bob.com/r/aZgR http://bob.com/r/aZgR I think that's about as small as possible without re-using the pubkey as a token in the url. On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net wrote: BTW, on the make qrcodes more scannable front -- is it too late to change BIP 72 so the new param is just r instead of request? Every byte helps when it comes to qrcodes ... Not too late, assuming there are no objections. Smaller QR codes is a very good reason to change it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On 09/25/2013 01:15 PM, Mike Hearn wrote: It won't fit. Why do you think that? Of course, I would skip the certificate, as its unnecessary if you see your partner in person. But I don't see the logic. A URI contains instructions for making a payment. If that instruction is pay to this address or download this file and do what you find there, it's no different unless there's potential for a MITM attack. If the request URL is HTTPS or a secured Bluetooth connection then there's no such possibility. HTTPS trust is utterly broken unless you fix it by adding the certificate or a fingerprint to the QR code. Bluetooth is not present in every case, e.g. QR codes scanned from the web. (Also, we currently don't have a concept of allowing both. The receiver forces you to either use BT or HTTP.) So yes, MITM is what I'm worrying about. When I'm scanning a QR code from a phone, you don't have that problem (unless sophisticated optical attacks emerge). Also, the HTTP request can fail and/or be slow, making the whole payment process more difficult than necessary. On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: While it's good to save space, I'm at the moment not convinced that taking a de-route via an URL is a good idea to begin with. The main problem is trust. If you scan a QR code from a foreign phone, you trust that that phone is owned by the one you want to send money to. By adding the HTTP request that trust is voided. As soon as there is a BIP70 implementation, I will begin playing with putting the payment request directly into the QR code. On 09/25/2013 11:27 AM, Mike Hearn wrote: We could also say that if protocol part (https://) is missing, it's implied automatically. So just: bitcoin:1abc?r=bob.com/r/aZgR http://bob.com/r/aZgR http://bob.com/r/aZgR I think that's about as small as possible without re-using the pubkey as a token in the url. On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com mailto:gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net mailto:m...@plan99.net mailto:m...@plan99.net wrote: BTW, on the make qrcodes more scannable front -- is it too late to change BIP 72 so the new param is just r instead of request? Every byte helps when it comes to qrcodes ... Not too late, assuming there are no objections. Smaller QR codes is a very good reason to change it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach andr...@schildbach.de wrote: As soon as there is a BIP70 implementation, I will begin playing with putting the payment request directly into the QR code. You may test with Bitcoin-QT right now. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
BitPay experimented with QR codes in low light, restaurant and other conditions. QR codes become difficult to use even at 100 chars. On the merchant side, we prefer a short URL that speaks payment protocol if visited via bitcoin client, but will gracefully work if scanned by a phone with zero bitcoin support -- you will simply be redirected to a BitPay invoice page for a normal browser. On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/25/2013 01:45 PM, Mike Hearn wrote: OK, it might fit if you don't use any of the features the protocol provides :) Now you're dver-dramaticing (-: I'm just skipping one feature which I think is useless for QR codes scanned in person. You can try it here: Thanks. A typical request would be around 60 bytes, which should produce an URL with around 100 chars. That should be fine for scanning, but I will experiment. If you're thinking about governments and so on subverting CA's, then there is a plan for handling that (outside the Bitcoin world) called certificate transparency which is being implemented now. Good to hear. Let's see if it gets momentum. Now when you are getting a QR code from the web, it's already being served over HTTPS. So if you're up against an attacker who can break a CA in order to steal your money, then you already lose, the QRcode itself as MITMd. Sure. I was talking about QR codes scanned in person. In the Bluetooth case we might have to keep the address around and use it to do ECDHE or something like that. Yeah, will look at that as soon as we're implementing the payment protocol fully. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Low light shouldn't be an issue for QRcodes generated by phones. They have backlit screens that should always be bright enough. I can see how it might be an issue for printed codes. If your phone has no Bitcoin app installed then being redirected to an invoice page is pretty useless, you still won't be able to pay the bill no matter what (where do you get the money from?). If they are just raw HTTP URLs then it means the effect of scanning a QRcode with a standalone scanner app is different to scanning it inside the wallet, which is unlike all other uses of QRcodes I know of. So I'm not really convinced by that UX yet. Perhaps we can thrash it out in Amsterdam. Right now I'm thinking QRcodes should always contain bitcoin URIs. On Wed, Sep 25, 2013 at 4:31 PM, Jeff Garzik jgar...@bitpay.com wrote: BitPay experimented with QR codes in low light, restaurant and other conditions. QR codes become difficult to use even at 100 chars. On the merchant side, we prefer a short URL that speaks payment protocol if visited via bitcoin client, but will gracefully work if scanned by a phone with zero bitcoin support -- you will simply be redirected to a BitPay invoice page for a normal browser. On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/25/2013 01:45 PM, Mike Hearn wrote: OK, it might fit if you don't use any of the features the protocol provides :) Now you're dver-dramaticing (-: I'm just skipping one feature which I think is useless for QR codes scanned in person. You can try it here: Thanks. A typical request would be around 60 bytes, which should produce an URL with around 100 chars. That should be fine for scanning, but I will experiment. If you're thinking about governments and so on subverting CA's, then there is a plan for handling that (outside the Bitcoin world) called certificate transparency which is being implemented now. Good to hear. Let's see if it gets momentum. Now when you are getting a QR code from the web, it's already being served over HTTPS. So if you're up against an attacker who can break a CA in order to steal your money, then you already lose, the QRcode itself as MITMd. Sure. I was talking about QR codes scanned in person. In the Bluetooth case we might have to keep the address around and use it to do ECDHE or something like that. Yeah, will look at that as soon as we're implementing the payment protocol fully. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2013 07:35 AM, Melvin Carvalho wrote: It depends on the attacker. I think a large entity such as a govt or big to medium size corporation *may* be able to MITM https, of course the incentive to do so is probably not there ... DLP (data loss prevention) products usually have MITM capability, to make sure that proprietary information isn't being exfiltrated. Also, some companies have full packet capture policies. The technology is out there and people buy and use it. Whether or not they're going to care about Bitcoin URIs in the short term, I don't know. Some of the companies documented here have such products: http://bluecabinet.info/wiki/Blue_cabinet#List_of_companies You are correct in that the incentive to carry out MITM attacks in this use case may not be there. However, detecting transactions may be more useful to an attacker than meddling with them. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Shiloh? Is your name Shiloh? Can I talk to you? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJDC30ACgkQO9j/K4B7F8FungCgyQtkyiQIekhlv1/Nqdd/JAIV 3EgAoKW8wTOI11lEq0ieOsRiQmnkM9w6 =W50W -END PGP SIGNATURE- -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote: BTW, on the make qrcodes more scannable front -- is it too late to change BIP 72 so the new param is just r instead of request? Every byte helps when it comes to qrcodes ... Not too late, assuming there are no objections. Smaller QR codes is a very good reason to change it. -- -- Gavin Andresen -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I think the confidence of the tx is not really the users concern anyway. They wrote it so they know it's valid. If the merchant disagrees for some reason then the user can find out, out of band when the goods/services are not delivered. On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen gavinandre...@gmail.comwrote: On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote: I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. Right now, i would simply put that into memo and come up with my own serialisation mechanism. Two Burgers, one Club Mate seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? No, because the Payment-PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says ask me how the transaction is going at THIS URL in THIS many minutes. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote: I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. Right now, i would simply put that into memo and come up with my own serialisation mechanism. Two Burgers, one Club Mate seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? No, because the Payment-PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says ask me how the transaction is going at THIS URL in THIS many minutes. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
RE: making the bitcoin address in the bitcoin: URI optional: Ok, I'm convinced, sometimes merchants won't want or need backwards compatibility and sometimes it won't make sense for them to put an arbitrary bitcoin: address there. RE: should the customer's machine not broadcast the transaction: I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? The tricky bit in constructing a transaction but not broadcasting it right away is the inputs must be locked, so they're not accidentally double-spent. I'd also like to hear from merchants: any issue with your payment processing server having broadcast transaction functionality? My biggest worry is that the payment protocol will not get wide support if it is too hard to implement. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? The tricky bit in constructing a transaction but not broadcasting it right away is the inputs must be locked, so they're not accidentally double-spent. bitcoinj separates the concept of committing a tx to the wallet from broadcasting it. However by default transactions that weren't seen in the chain yet will be announced when a new peer is connected to. It'd take extra code to suppress that, and it's unclear to me why that's useful. I agree with Pieter that it should be the merchants responsibility to get the tx out there, but having the client do the broadcast as well can't really hurt (except perhaps some privacy impact). -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On 08/07/2013 05:10 PM, Gavin Andresen wrote: I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? The tricky bit in constructing a transaction but not broadcasting it right away is the inputs must be locked, so they're not accidentally double-spent. I have avoided any notion of locking inputs in Armory for offline wallets. The underlying concept of why a seemingly-random amount of funds are inaccessible at a given time is so non-intuitive and difficult to explain to a non-expert, that I haven't even tried to deal with it. Luckily, most users do one operation at a time, so it's not a real a problem. But as more businesses have started to use Armory, it /will/ become a problem that will need to be addressed /somehow/. I have considered at least marking inputs to indicate to the user that the transaction they are creating may not be valid unless all previous transactions have been broadcast. The user will not necessarily understand why, but they might easily comprehend the solution (and perhaps a button that says Forget all previously created transactions that haven't been broadcast. Press this button if there are no transactions waiting to be broadcast). Even if the user somewhat understands the concepts behind locking, you easily end up with a mess of some coins being locked and rejecting transaction creation somewhat randomly, especially when they create transactions that they later decide not to execute. And you have to give the user a way to manually unlock the outputs which they wouldn't know to use because it's so non-intuitive. I'd much rather say either do one transaction at a time, or bundle payments into a single multi-output transaction. Or risk invalid transactions that have to be re-created and signed. -Alan -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I see payment URIs rather as a replacement for bitcoin: URI rather than an extension. It solves everything they did in a much cleaner way, Given that bitcoin: have gotten some traction, we probably want to reuse the moniker, but replace the rest entirely. In other words, if a request is specified, nothing else should be. There is just no useful way to combine them either - payments generalize destinations to arbitrary scripts, messages are handled inline, amounts are defined inline. And if you want to rely on the payment infrastructure to work, you cannot risk people using the old-style static address in the URI. On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami r...@gnomon.org.uk wrote: Very brief comment on BIP 72: I wonder if there should be some discussion included in the specification as to how the BIP 21 amount, message and label parameters should be processed when the payment protocol is used. Presumably amount should be completely ignored? But is the total amount requestd by the PaymentRequest required to match the amount parameter (when present)? Is the client permitted to complain if they don't? And what about message? Presumably the memo from PaymentDetails should take precedence, but if it's not present, and message is? I think this is an area perhaps more suited to SHOULDs and MAYs rather than MUSTs, but it is probably worthy of mention... roy -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
But the reality is that in many applications you need to provide a single URL. Consider existing point-of-sale systems that display QR codes for the user to scan. They live within the limitations of existing bitcoin URLs, but would no doubt benefit from the payments protocol. It's not realistic for the terminal operator in a retail establishment to have to select which protocol will be used before generating the QR code - so the effect of your proposal is to require lowest common denominator and effectively prevent such systems from using the payments protocol (at least until it is sufficiently ubiquitous that they feel happy to simply require its use). roy On Wed, Aug 07, 2013 at 11:54:44PM +0200, Pieter Wuille wrote: I see payment URIs rather as a replacement for bitcoin: URI rather than an extension. It solves everything they did in a much cleaner way, Given that bitcoin: have gotten some traction, we probably want to reuse the moniker, but replace the rest entirely. In other words, if a request is specified, nothing else should be. There is just no useful way to combine them either - payments generalize destinations to arbitrary scripts, messages are handled inline, amounts are defined inline. And if you want to rely on the payment infrastructure to work, you cannot risk people using the old-style static address in the URI. On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami r...@gnomon.org.uk wrote: Very brief comment on BIP 72: I wonder if there should be some discussion included in the specification as to how the BIP 21 amount, message and label parameters should be processed when the payment protocol is used. Presumably amount should be completely ignored? But is the total amount requestd by the PaymentRequest required to match the amount parameter (when present)? Is the client permitted to complain if they don't? And what about message? Presumably the memo from PaymentDetails should take precedence, but if it's not present, and message is? I think this is an area perhaps more suited to SHOULDs and MAYs rather than MUSTs, but it is probably worthy of mention... roy -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so the bitcoin address is optional: If the request parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitted (the URI will be of the form: bitcoin:?request=... ). The spec already said what should happen if both request and address/amount/etc were given: it should ignore the bitcoin address/amount/label/message in the URI and instead fetch a PaymentRequest message and then follow the payment protocol I think this gives us a smooth, clear upgrade path. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote: Is it envisaged to be possible/sensible to have a URI that is *only* a payment request? i.e. something like the following (although I'm not sure this is a valid URI): bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe I think we'll want a bitcoin address in there for a long time for backwards compatibility. If web browser support for arbitrary MIME types is strong enough (I haven't tested), then a payment request can be initiated with just an anchor tag: a href=https://merchant.com/pay.php?3D2a8628fc2fbe; type=application/bitcoin-paymentrequest Doing it that way saves a http round-trip. -- -- Gavin Andresen -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On 31 July 2013 13:33, Gavin Andresen gavinandre...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote: Is it envisaged to be possible/sensible to have a URI that is *only* a payment request? i.e. something like the following (although I'm not sure this is a valid URI): bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe I think we'll want a bitcoin address in there for a long time for backwards compatibility. If web browser support for arbitrary MIME types is strong enough (I haven't tested), then a payment request can be initiated with just an anchor tag: a href=https://merchant.com/pay.php?3D2a8628fc2fbe; type=application/bitcoin-paymentrequest Unless I'm mistaken you cant generally set the Accept header on a browser via a standard href ... one of those annoying quirks Doing it that way saves a http round-trip. -- -- Gavin Andresen -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 (Gavin Andresen)
Since the payment request is available from a location defined in the URI,I think it would be appropriate to attach the PaymentACK once paymentaccepted by Merchant.This would make the request and receipt available for later review.Regards,Tamás BlummerFounder, CEOhttp://bitsofproof.com signature.asc Description: Message signed with OpenPGP using GPGMail -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
I think it's important to expect PaymentRequest-only bitcoin URIs in the future. Some types of payments (exotic transactions) may not make sense to have a single fallback address. Or, a page with a bitcoin URI link may be relying on a separate service provider to assemble the transaction. On Wed, Jul 31, 2013 at 5:33 AM, Gavin Andresen gavinandre...@gmail.comwrote: On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote: Is it envisaged to be possible/sensible to have a URI that is *only* a payment request? i.e. something like the following (although I'm not sure this is a valid URI): bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe I think we'll want a bitcoin address in there for a long time for backwards compatibility. If web browser support for arbitrary MIME types is strong enough (I haven't tested), then a payment request can be initiated with just an anchor tag: a href=https://merchant.com/pay.php?3D2a8628fc2fbe; type=application/bitcoin-paymentrequest Doing it that way saves a http round-trip. -- -- Gavin Andresen -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Thu, Aug 1, 2013 at 9:30 AM, E willbefull ewillbef...@gmail.com wrote: I think it's important to expect PaymentRequest-only bitcoin URIs in the future. Some types of payments (exotic transactions) may not make sense to have a single fallback address. P2SH addresses already support all exotic transactions. Or, a page with a bitcoin URI link may be relying on a separate service provider to assemble the transaction. Do you mean assemble the PaymentRequest message? Because the payment transaction will always be created by the customer's wallet software. IF PaymentRequests take over the world and we get 100% wallet software support, then I'd be happy to write another BIP that says that a bitcoin: URI can be just bitcoin:?request=http... -- -- Gavin Andresen -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
P2SH addresses support exotic transaction outputs, but not all exotic transactions. This payment protocol can allow for combining multiple outputs. A PaymentRequest for sending money to multiple parties, for example, could not fall back to a single address. On Wed, Jul 31, 2013 at 5:38 PM, Gavin Andresen gavinandre...@gmail.comwrote: On Thu, Aug 1, 2013 at 9:30 AM, E willbefull ewillbef...@gmail.com wrote: I think it's important to expect PaymentRequest-only bitcoin URIs in the future. Some types of payments (exotic transactions) may not make sense to have a single fallback address. P2SH addresses already support all exotic transactions. Or, a page with a bitcoin URI link may be relying on a separate service provider to assemble the transaction. Do you mean assemble the PaymentRequest message? Because the payment transaction will always be created by the customer's wallet software. IF PaymentRequests take over the world and we get 100% wallet software support, then I'd be happy to write another BIP that says that a bitcoin: URI can be just bitcoin:?request=http... -- -- Gavin Andresen -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
