Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Ok, agreed. I will submit a pull request to BIP72 then. Not sure about escaping though. It is indeed not critical for bitcoin URIs, but still it is a part of RFC, don't think we should go against it. Andreas, we will implement this on our side, with bluetooth on r= and web address on r1=. 2014-07-01 18:59 GMT+01:00 Mike Hearn m...@plan99.net: Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect that escaping is largely unnecessary in many cases. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Hmm, r1, r2 etc is actually interesting. It takes less chars then array (yes, array brackets have to be escaped) and provides unlimited number of options, uniformed approach and priority definition. I'd say that is the way to go. Any objections? On 1 Jul 2014 16:39, Andreas Schildbach andr...@schildbach.de wrote: Ok, one more idea: r= is used for the first URL, and we *think* of it as r0= additional URLs are appended as r1= r2= and so on. This would also define an ordering in case we need it. On 07/01/2014 05:07 PM, Michael Wozniak wrote: Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other. I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
It took some time but we have finally implemented bluetooth integration offered by Andreas in our bitcoin payment terminals. However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. There is a way to define alternative URIs inside payment request itself, but that doesn't really work as client first needs to get payment request message itself somehow and this is exactly the problem. As far as I see there is three ways to solve that: 1. add new URI parameter for bluetooth address (e.g. r=http://web_addressrbt=bt:BT_MAC_addres). 2. allow multiple r parameters (e.g. r=http://web_addressr=bt:BT_MAC_addres). 3. allow r to be an array (e.g. r%5B0%5D=http://web_addressr%5B1%5D=bt:BT_MAC_addres). Option #1 isn't great at all, as it solves existing problem, but not provides any way to solve same problem appearing again for another possible protocol. Options #2 #3 may be working and seem to be nearly equal, and both are not great in the way that URI parser behavior in these cases is not clearly defined. I've checked through relevant RFCs and found nothing specific about this. According to my limited web experience the array scheme is working better than multiple repeating parameters. So I'm looking for some advice on which route of three proposed may be better here, or if there are any other ways I'm missing. 2014-03-27 13:31 GMT+00:00 vv01f vv...@riseup.net: Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation. Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only. Am 27.03.2014 um 11:08 schrieb Mike Hearn m...@plan99.net: But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Hi Lawrence/All I'm afraid with this BIP for TTP of instant transactions we will end up in VISA world again. As I see it - it's not about if the TTPs will centralize, it's only when. Simply because if economy of scales makes growth profitable and coming into this market is at least a little expensive - this (centralization, VISA world) will happen, sooner rather than later. And while some may argue that coming to market in Bitcoin world is cheap so the crowd will always have a chance to come in and beat the monopolists - think of one thing. Right now Bitcoin is not seen as money and not regulated accordingly anywhere in the world, thanks God, but how many years away we are from the point when it will start to be regulated that way? And once it is - the monopolies will make sure that rules are restrictive enough to prevent competition, especially in conjunction with economy of scales playing against the small newcomers. The instant providers list is susceptible to regulatory influence, and once in place and widespread - it will be a timebomb under Bitcoin. We need to solve the doublespend issue without TTP involvement, or at least without even a slight chance of making this involvement regulateable. Otherwise I think the Bitcoin experiment will fail. Best regards, Alex Kotenko 2014-06-16 18:16 GMT+01:00 Lawrence Nahum lawre...@greenaddress.it: Mike Hearn mike at plan99.net writes: As long as miners stick to Satoshi's first seen rule, which is the default, it's useful: https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 (this is the famous snack machine thread from 2010) If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they don't collectively lemming us all off a cliff by doing that ;) I assume we can't enforce to miners rules about which tx will go in and which won't and therefore whether this will cause more or less double spends. I mean, you can try but I would rather have to option to pick an third party instant provider explicitly than enforce bigger rules on mining which would IMHO lead to implicit centralization. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Hi all It took some time, but now my testnet seed is fully operational. In fact I've dropped an earlier idea of DNS forwarding and now serving only testnet seed, as it is more important atm than a mainnet one. Testnet seed is available at testnet-seed.alexykot.me. Please check and let me know if all looks fine with this seed from your side. Best regards, Alex Kotenko 2014-05-22 9:58 GMT+01:00 Andreas Schildbach andr...@schildbach.de: Hi Alex, I'm not sure if you saw this message. Your seeds are not reachable from my ISP unfortunately. Cheers, Andreas -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
So generally it seems impossible to have both DNS seeds running on same IP address. Too bad. Ok, I'll switch to serving only testnet DNS on this server for now, as this seems to be a much bigger problem than mainnet. Later I might buy second IP to setup mainnet DNS also. Best regards, Alex Kotenko 2014-05-30 15:51 GMT+01:00 Robert McKay rob...@mckay.com: No, I don't think so. The problem is the 'aa' flag is missing (see the 'flags' section in dig). Perhaps if you could suppress the authority records the recursor would give up and just accept the non-authorative answer, but that isn't a good solution even if it might work for some resolvers. Rob On Fri, 30 May 2014 15:13:36 +0100, Alex Kotenko wrote: Hmm, you might be right, as queries dig @node.alexykot.me [8] testnet-seed.alexykot.me [9] and dig @node.alexykot.me [10] -p 18353 testnet-seed.alexykot.me [11] are giving different authority sections. Hmm, but if I setup custom SOA record for it - it should work, right? What SOA name should it be actually, assuming that NS record for testnet-seed.alexykot.me [12] is pointing at alexykot.me [13]? Best regards, Alex Kotenko 2014-05-30 14:41 GMT+01:00 Robert McKay : Hi Alex, I think the problem is with my suggestion to use bind forwarding.. basically bind is stripping off the authorative answer bit in the reply.. this causes the recursor to go into a loop chasing the authority server which again returns a non-authoritve answer with itself as the authority again. Im not sure if this can be fixed without hacking the bind src, so maybe it wasnt such a great suggestion in the first place. Basically I think if bind was returning authorative answers it would work, but I cant see any way to make that happen in the bind configuration. Rob On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote: Hi Peter Ive setup DNS seeds myself a week ago, at testnet-seed.alexykot.me [1] [6] and bitcoin-seed.alexykot.me [2] [7], but there is a problem with DNS settings that we with Andreas couldnt sort out quickly. The problem itself is that I can reach my nameserver and get dnsseed response if I query it directly with dig @node.alexykot.me [3] [8] testnet-seed.alexykot.me [4] [9] dig @node.alexykot.me [5] [10] bitcoin-seed.alexykot.me [6] [11] But when I try nslookup testnet-seed.alexykot.me [7] [12] - it fails. I guess the problem is in my DNS settings but I cant figure out what is it. S o could you share how you configured DNS for your seed to help me debug mine ? Best regards, Alex Kotenko Links: -- [1] http://testnet-seed.alexykot.me [2] http://bitcoin-seed.alexykot.me [3] http://node.alexykot.me [4] http://testnet-seed.alexykot.me [5] http://node.alexykot.me [6] http://bitcoin-seed.alexykot.me [7] http://testnet-seed.alexykot.me [8] http://node.alexykot.me/ [9] http://testnet-seed.alexykot.me/ [10] http://node.alexykot.me/ [11] http://testnet-seed.alexykot.me/ [12] http://testnet-seed.alexykot.me [13] http://alexykot.me [14] mailto:rob...@mckay.com -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
Hi Peter I've setup DNS seeds myself a week ago, at testnet-seed.alexykot.me and bitcoin-seed.alexykot.me, but there is a problem with DNS settings that we with Andreas couldn't sort out quickly. The problem itself is that I can reach my nameserver and get dnsseed response if I query it directly with dig @node.alexykot.me testnet-seed.alexykot.me dig @node.alexykot.me bitcoin-seed.alexykot.me But when I try nslookup testnet-seed.alexykot.me - it fails. I guess the problem is in my DNS settings but I can't figure out what is it. S o could you share how you configured DNS for your seed to help me debug mine ? Best regards, Alex Kotenko 2014-05-30 10:43 GMT+01:00 Peter Todd p...@petertodd.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach andr...@schildbach.de wrote: Hey, really sorry I don't have the time to fix this issue, been travelling for a few weeks for my consulting job. If you want to step up and volunteer please feel free. I'm already volunteering. At least I don't get paid for my efforts in debugging the seed infrastructure. I meant running a seed yourself. Note that I've only received funds to cover expenses and a trivial amount on top to cover some time - about one and a half hours at my usual rates. Gavin: Speaking of, given it looks like my work will be frequently keeping me out of country and unable to provide any more than a best effort attempt at running a seed, I'd like to give back the grant funds for doing so. Email me privately with an address to send them too. I have no plans to take it down, however the expectations users have for it aren't something I can provide. Can you verify if your copy of the seeder contains the commit 8dcc006e6256cb746c2b025daf3df41baa26353e ? It fixed a bug that has exactly the symptoms we currently see. I wonder if the restart of your server actually changed/fixed anything. If you got a SERVFAIL this may be because you were traveling through parts of the world that can't reach your server. Did you actually try at home, before the restart? I checked via the same proxy both times; I believe the endpoint is located in Europe. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJTiFKwMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQFCB/4jypD+xzKVp6fqRUxu v22Rc6PeCbeaPYKmdNu0LbY1G5spB8C8ooaZX6z0Ib/CYobzDPJ+rJNB+c1Fna4N 1IdH7ZsrX0GFaEn7Grnp7D2rtOXGZV+1XGFAateIA/caQ9+rJfqkHLuvOI0Fh+Ua /m857rxUNtA1kObLFS7gfhi2gwXGO6KQ3muS3462hXVVc9j7DhOWQQwJba5PL+Je Eob4WtnF2gVFlCEWevxvflF7j4lW9I/S81yZQDnNW9ATF2mfZVqo26sB0yL6Tm4l KgdKx7+w3khv6QfW9Ilx0Ov3Ml2ZMRhBimpbnENbW4jfklsuRQcM0yx6vXS/lIMz LO5s =Up3N -END PGP SIGNATURE- -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
okay, I've set it up with bind forwarding requests to two dnsseeds running on separate ports. Though I see a problem with testnet DNS seed itself. It runs, but somehow it only returns one IP address. Exactly same DNS seeder looking for mainnet nodes is working fine. You can reach seeds through mainnet seed: dig @node.alexykot.me bitcoin-seed.alexykot.me A or directly dig -p 8353 @node.alexykot.me bitcoin-seed.alexykot.me A testnet seed dig @node.alexykot.me testnet-seed.alexykot.me A or directly dig -p 18353 @node.alexykot.me testnet-seed.alexykot.me A So what can be the problem with testnet DNS seeder? Best regards, Alex Kotenko 2014-05-20 1:50 GMT+01:00 Robert McKay rob...@mckay.com: On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote: On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. This stackoverflow describes a similar situation; http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone you can additionally specify the port to forward too; http://www.zytrax.com/books/dns/ch7/queries.html#forwarders it should be possible to forward to different ports on 127.0.0.1 for each dnsseed instance. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Misunderstanding. Both seeds are available on port 53 via BIND forwarding. Just also each DNS seed is available separately on it's own port. Best regards, Alex Kotenko 2014-05-21 12:03 GMT+01:00 Andreas Schildbach andr...@schildbach.de: Great, thanks for this contribution! Do you plan to have your seeds reachable on port 53 eventually? Currently bitcoinj cannot deal with nonstandard ports I think. On 05/21/2014 11:23 AM, Alex Kotenko wrote: okay, I've set it up with bind forwarding requests to two dnsseeds running on separate ports. Though I see a problem with testnet DNS seed itself. It runs, but somehow it only returns one IP address. Exactly same DNS seeder looking for mainnet nodes is working fine. You can reach seeds through mainnet seed: dig @node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A or directly dig -p 8353 @node.alexykot.me http://node.alexykot.me bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me A testnet seed dig @node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me A or directly dig -p 18353 @node.alexykot.me http://node.alexykot.me testnet-seed.alexykot.me http://testnet-seed.alexykot.me A So what can be the problem with testnet DNS seeder? Best regards, Alex Kotenko 2014-05-20 1:50 GMT+01:00 Robert McKay rob...@mckay.com mailto:rob...@mckay.com: On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote: On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com mailto:rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. This stackoverflow describes a similar situation; http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone you can additionally specify the port to forward too; http://www.zytrax.com/books/dns/ch7/queries.html#forwarders it should be possible to forward to different ports on 127.0.0.1 for each dnsseed instance. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Practically I would approach it from a different angle. We need to make sure that notes we're accepting are still loaded, but assuming it's NFC enabled this is still quite easy for the user and is an acceptable usability drawback. Then what we need to make sure is that when someone is redeeming the notes - he has control over physical object itself, ideally for a period of time. With some active powered electronics in place it would be easy, but how do we do it without anything active in place? Best regards, Alex Kotenko 2014-05-18 21:10 GMT+01:00 Natanael natanae...@gmail.com: The problem with not involving any electronics is that somebody needs to generate a recoverable private key that we have to trust haven't recovered the private key. The only plausible solution is multisignature P2SH addresses where you trust several independent entities to not collude instead, where you combine their paper notes into one piece. And then you still don't know if all the private keys are recoverable to you (failed print?). - Sent from my phone Den 18 maj 2014 20:48 skrev Alex Kotenko alexy...@gmail.com: Erm, few things here. - I can't see really how to embed electronics capable to run an SPV client into printed paper. I know that passive NFC tags can be printed on paper, but not actual chips and/or power modules. So we are talking about a completely different things here. - even with paper notes printed proprietarily by some business the notes itself still can have routes for independent blockchain-based verification, and you won't need to trust anybody to test it. You will have to trust security of the notes itself, but this is same as when you trust the phone manufacturer when you're putting your bitcoin wallet on it. So really I see only issues of technical security in here, and this is the problem I'm seeking solutions for. Best regards, Alex Kotenko 2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com: Now you are talking about Trusted Platform Modules. Like smartcards, actually. Devices that won't leak their keys but let the holder spend the coins. It could even have it's own simple SPV wallet client to make it easier to handle. And they'd use the attestation features provided by the TPM to prove the software it's unmodified top the current holder. But then you still have to trust the manufacturer of the device, and you have to trust it has no exploitable side channels. - Sent from my phone Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com: -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Asking random ignorant stranger to care to protect themselves never works. We need solution that requires strictly zero effort. Best regards, Alex Kotenko 2014-05-19 14:06 GMT+01:00 Brooks Boyd bo...@midnightdesign.ws: 2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de: One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? I think you'd need multiple factors to protect against that attack. Like encrypting with a key that is printed on the note as an QR code. On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko alexy...@gmail.com wrote: Yes, but it must not sacrifice usability. It's paper money, people are used to it and they have rather high standard of expectations in this area. Any usbility sacrifices in this area result into failure of the whole thing. Best regards, Alex Kotenko One thought I had reading through this exchange: I think the general public is becoming more aware of the hacker with a long range antenna sort of attack, since credit cards are getting microchips that can be scanned. There's a few videos I've seen of white hat hackers demonstrating how a suitcase-sized apparatus carried by someone walking down the street can scan and make charges on cards in people's pockets as the attacker brushes past. Hence RFID-blocking sleeves/wallets are on the market, such that your smart credit card can't make a purchase while its in your wallet. Is a RFID-blocking wallet also NFC-blocking? Irregardless of whatever future cash you choose to carry (be it credit card or bitcoin card/coin/cash), perhaps its the wallet/purse that needs an upgrade, to ensure your money doesn't spend itself while its in your pocket, but you can easily remove it and spend it conveniently? Brooks -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Hmm, this is firmcoin thing looks like what I mean. They don't have a solution yet, and prices they quote smartcards are unacceptable, but if they will manage to get down in selfcost - that may work. Ok, I'll follow them and see what it will come to. Best regards, Alex Kotenko 2014-05-19 13:55 GMT+01:00 Sergio Lerner sergioler...@certimix.com: Alex, I think that what you are talking about more or less something like the Firmcoin Check: http://firmcoin.com/?p=92 On 18/05/2014 08:47 a.m., Alex Kotenko wrote: One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? The firmcoin has two capacitive buttons that you have to press in sequence to redeem to coins. No long range antenna can do that. Best regards, Sergio. PS: the device has patents pending -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Hmm, I've mostly setup what's promised, testing DNS seeds now. There is one problem I see that I can't really solve myself. This dnsseed daemon cannot serve more than one name at once, which means that I cannot serve testnet and mainnet seeds off one daemon instance which means I need to buy two IP addresses for it. That's unfortunate as it needs much more spendings from me to operate, second IP address will cost nearly as much as the server itself. Can anybody help with this? I cannot into C++ to fix that myself. Best regards, Alex Kotenko 2014-05-17 13:39 GMT+01:00 Andreas Schildbach andr...@schildbach.de: On 05/17/2014 02:02 PM, Alex Kotenko wrote: So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. Yes, that's my understanding too. If I'll start a DNS seed of my own and make sure it works well, will this help? Yes, definately. I've found this DNS seeder daemon https://github.com/sipa/bitcoin-seeder, and it seems to be exactly what I need to run a DNS seeder myself. Afaik this is what most of the other seeds are using, yes. So if my understanding is correct, I'll setup a DNS seeds for mainnet and for testnet at bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me http://testnet-seed.alexykot.me, and also a well connected nodes for mainnet and testnet on the same server. Is this a good plan? Will this all help? Sound great! Let me know if you've got something to test. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Well, it's possible theoretically, but will need another piece of custom software that will understand DNS protocol and proxy it correctly based on actual incoming DNS queries. On 19 May 2014 21:22, Michael Wozniak m...@osfda.org wrote: I’m not familiar with how the daemon works, however could you set up two daemons listening local on different ports and with a separate daemon or normal dns server that proxies incoming queries to either domain? I don’t know if standard DNS servers would support that, or if you would need a custom proxy application. - Michael Wozniak On May 19, 2014, at 4:14 PM, Alex Kotenko alexy...@gmail.com wrote: Hmm, I've mostly setup what's promised, testing DNS seeds now. There is one problem I see that I can't really solve myself. This dnsseed daemon cannot serve more than one name at once, which means that I cannot serve testnet and mainnet seeds off one daemon instance which means I need to buy two IP addresses for it. That's unfortunate as it needs much more spendings from me to operate, second IP address will cost nearly as much as the server itself. Can anybody help with this? I cannot into C++ to fix that myself. Best regards, Alex Kotenko 2014-05-17 13:39 GMT+01:00 Andreas Schildbach andr...@schildbach.de: On 05/17/2014 02:02 PM, Alex Kotenko wrote: So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. Yes, that's my understanding too. If I'll start a DNS seed of my own and make sure it works well, will this help? Yes, definately. I've found this DNS seeder daemon https://github.com/sipa/bitcoin-seeder, and it seems to be exactly what I need to run a DNS seeder myself. Afaik this is what most of the other seeds are using, yes. So if my understanding is correct, I'll setup a DNS seeds for mainnet and for testnet at bitcoin-seed.alexykot.me http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me http://testnet-seed.alexykot.me, and also a well connected nodes for mainnet and testnet on the same server. Is this a good plan? Will this all help? Sound great! Let me know if you've got something to test. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
I had a long discussion recently with somebody who wants and has resources to do exactly this - paper currency representing bitcoins. Yet we've been thinking mostly about a centralized solution, where one party is producing and maintaining paper currency, with bitcoins tied to each note verifiable via blockchain. The points we've ended up is that it needs to be: - reloadable - NFC based So anybody can verify any notes instantly by just touching it with his phone, and so merchants could redeem the notes at the moment of accepting it, convert it into fully online bitcoins and avoid costs of maintaining paper money turnover. Probably merchant would sell back redeemed empty notes to the issuer for a price of the note issue, and issuer will recharge it and put back into circulation. One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? Best regards, Alex Kotenko 2014-05-17 17:40 GMT+01:00 Gregory Maxwell gmaxw...@gmail.com: On Sat, May 17, 2014 at 9:07 AM, Chris Pacia ctpa...@gmail.com wrote: I can't really just hand someone the note and walk away because they have to scan it to see if it is actually valid. Not just scan it, but they actually must successfully sweep it— otherwise they can be trivially double spent. This is especially bad since any prior bearer can perform such an attack. E.g. record the private key of everyone that passes through your hands and then doublespend race any redemption that happens 24 hours after you spend them. The wrong person would likely be blamed and even if you were blamed you could plausibly deny it (Must have been the guy that gave it to me!). Othercoin seems to have much better properties in the space of offline transactions: https://bitcointalk.org/index.php?topic=319146.0 Separately, Cassius also ran into some regulatory issues selling physical bitcoin artifacts. Especially printing things that seem to be redeemable for a named USD value sounds especially problematic. Some random comments— The base58 encoding is fairly human unfriendly. It's fine for something being copy and pasted, but I've found typing or reading it works poorly due to mixed case. I expect the A/B side to be difficult to educate users about. This side is private is more easily understood, you could just pick one of your sides and call it private. I find it kind of odd that this design seems to have no facility for checking its txouts without recovering the private key, though considering no one should rely on such a measurement without sweeping perhaps thats for the best. (As far as the numbering goes, I think you should be calling these draft-felix-paper-currency etc. As a matter of hygienic practice I will not assign a matching bip number for something that went public with a number outside of the assignment.) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Yes, but it must not sacrifice usability. It's paper money, people are used to it and they have rather high standard of expectations in this area. Any usbility sacrifices in this area result into failure of the whole thing. Best regards, Alex Kotenko 2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de: One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? I think you'd need multiple factors to protect against that attack. Like encrypting with a key that is printed on the note as an QR code. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Erm, few things here. - I can't see really how to embed electronics capable to run an SPV client into printed paper. I know that passive NFC tags can be printed on paper, but not actual chips and/or power modules. So we are talking about a completely different things here. - even with paper notes printed proprietarily by some business the notes itself still can have routes for independent blockchain-based verification, and you won't need to trust anybody to test it. You will have to trust security of the notes itself, but this is same as when you trust the phone manufacturer when you're putting your bitcoin wallet on it. So really I see only issues of technical security in here, and this is the problem I'm seeking solutions for. Best regards, Alex Kotenko 2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com: Now you are talking about Trusted Platform Modules. Like smartcards, actually. Devices that won't leak their keys but let the holder spend the coins. It could even have it's own simple SPV wallet client to make it easier to handle. And they'd use the attestation features provided by the TPM to prove the software it's unmodified top the current holder. But then you still have to trust the manufacturer of the device, and you have to trust it has no exploitable side channels. - Sent from my phone Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com: -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Agree. So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. If I'll start a DNS seed of my own and make sure it works well, will this help? I've found this DNS seeder daemon https://github.com/sipa/bitcoin-seeder, and it seems to be exactly what I need to run a DNS seeder myself. So if my understanding is correct, I'll setup a DNS seeds for mainnet and for testnet at bitcoin-seed.alexykot.me and testnet-seed.alexykot.me, and also a well connected nodes for mainnet and testnet on the same server. Is this a good plan? Will this all help? Best regards, Alex Kotenko 2014-05-17 12:39 GMT+01:00 Andreas Schildbach andr...@schildbach.de: I think the best way to contribute to the infrastructure is actually what we're doing: Test the current infrastructure and point out where it is not working. Trying to find solutions for problems. There is nothing gained by throwing additional hardware at a problem if the problem itself isn't understood well. On 05/17/2014 02:58 AM, Alex Kotenko wrote: Ok, what do I need to do? How do I host a testnet seed myself? Best regards, Alex Kotenko 2014-05-16 23:02 GMT+01:00 Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com: There are only two testnet seeds listed in bitcoind, and one of them returns SERVFAIL (testnet-seed.bitcoin.petertodd.org http://testnet-seed.bitcoin.petertodd.org) and the other just returns one A record (testnet-seed.bluematt.me http://testnet-seed.bluematt.me). No idea what seeds bitcoinj uses. If you are going to depend on testnet, especially for an important demo... contribute to the infrastructure! This stuff doesn't just fix itself for free. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Hi guys Just wanted to let you know that Andreas' testnet Bitcoin Wallet doesn't work because of fail in the peer discovery, and this caused us problems as we cannot properly demonstrate my XBTerminal POS on the Bitcoin Conference. Right now I'm booting up an own full node that I will set as trusted peer in the Wallet settings, hopefully this will work. However this DNS discovery problem is really a problem, even for testnet. Btw, I had problems firing up the full bitcoind node also, of the same reason - discovery failed. I had to ask Andreas to paste me his node list to manually seed the nodelist. So I've set up and will run a well connected testnet node, as we need it for the XBTerminal. Please let me know if I can somehow help to fix the DNS discovery issue also. Best regards, Alex Kotenko 2014-05-16 17:46 GMT+01:00 Laszlo Hanyecz las...@heliacal.net: It looks like it might be firewalled, probably just need to fix the ACL in EC2. -Laszlo On May 16, 2014, at 4:34 PM, Andreas Schildbach andr...@schildbach.de wrote: Apparently British Telecom also cannot speak to Peter Todd's server. That another very large ISP in Europe. On 05/15/2014 01:50 PM, Andreas Schildbach wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds taken from bitcoinj): mainnet: seed.bitcoin.sipa.be OK dnsseed.bluematt.me OK dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs seed.bitcoinstats.comOK testnet: testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica testnet-seed.bluematt.me OK (but only returns one node) Note: Telefonica is one of Europe's largest ISPs. I would try to improve DNS myself, but I'm not capable of writing C. My fix would be to reimplement everything in Java -- I doubt you guys would be happy with that. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Ok, what do I need to do? How do I host a testnet seed myself? Best regards, Alex Kotenko 2014-05-16 23:02 GMT+01:00 Jeff Garzik jgar...@bitpay.com: There are only two testnet seeds listed in bitcoind, and one of them returns SERVFAIL (testnet-seed.bitcoin.petertodd.org) and the other just returns one A record (testnet-seed.bluematt.me). No idea what seeds bitcoinj uses. If you are going to depend on testnet, especially for an important demo... contribute to the infrastructure! This stuff doesn't just fix itself for free. On Fri, May 16, 2014 at 7:07 PM, Alex Kotenko alexy...@gmail.com wrote: Hi guys Just wanted to let you know that Andreas' testnet Bitcoin Wallet doesn't work because of fail in the peer discovery, and this caused us problems as we cannot properly demonstrate my XBTerminal POS on the Bitcoin Conference. Right now I'm booting up an own full node that I will set as trusted peer in the Wallet settings, hopefully this will work. However this DNS discovery problem is really a problem, even for testnet. Btw, I had problems firing up the full bitcoind node also, of the same reason - discovery failed. I had to ask Andreas to paste me his node list to manually seed the nodelist. So I've set up and will run a well connected testnet node, as we need it for the XBTerminal. Please let me know if I can somehow help to fix the DNS discovery issue also. Best regards, Alex Kotenko 2014-05-16 17:46 GMT+01:00 Laszlo Hanyecz las...@heliacal.net: It looks like it might be firewalled, probably just need to fix the ACL in EC2. -Laszlo On May 16, 2014, at 4:34 PM, Andreas Schildbach andr...@schildbach.de wrote: Apparently British Telecom also cannot speak to Peter Todd's server. That another very large ISP in Europe. On 05/15/2014 01:50 PM, Andreas Schildbach wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds taken from bitcoinj): mainnet: seed.bitcoin.sipa.be OK dnsseed.bluematt.me OK dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs seed.bitcoinstats.comOK testnet: testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica testnet-seed.bluematt.me OK (but only returns one node) Note: Telefonica is one of Europe's largest ISPs. I would try to improve DNS myself, but I'm not capable of writing C. My fix would be to reimplement everything in Java -- I doubt you guys would be happy with that. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I know that general approach to interaction design in Bitcoin assumes minimal to no difference between payer and payee, and generally I agree with this approach. However, for the sake of my PoS development this assumption is wrong by default, as PoS is a specialized hardware, and one who cared to buy and install it is probably not in the same situation as the other party that didn't care to by anything dedicated. In short - from PoS point of view there is a customer and a merchant. And my goal is to make thing work in assumption of fast and reliable connection on merchant side and no connection requirement at all from customer side. I didn't put a silly example, as of my experience there are really a lot of places where cellphone connection isn't good enough for reliable Bitcoin operation. However, if we're talking about merchant establishments - we can hope for private local WiFi or wired connection on PoS side, so PoS internet connection shouldn't be an issue. So this is the use case I'm designing around and this is why bluetooth based BIP70 implementation is important for me. I partly agree with Mike on user interface and IOU idea, but I have no intention to implement anything like that right now. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
2014-03-21 9:47 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 05:14 PM, Alex Kotenko wrote: Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/ random_id_of_payment_request would be more usual and easily understandable. Agreed. I used the dash because I feared a slash would need to be escaped if used in an URL parameter. It will need to be escaped, but HTTP URLs used in BIP72 have it already, so don't see why we should bother. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. Thought of that as well. On the other hand, HTTP might be overkill and we inherit its potential downsides as well. It definitely is an overkill. Don't think we should do it now unless we will see later during implementation that we really have to. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. Agreed. All I wanted to say support for QR is still small enough that we might be able to switch to an incompatible standard. If we're determined that is. Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode it's limited to about 600 chars, so really I can include only unsigned and rather short payment request. Signed requests longer than few hundred bytes will not work. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. Base 64 via binary QR: 64 chars / 256 chars == 6 bit / 8 bit = 0.75 Base 43 via alphanum QR: 43 chars / 45 chars == 5.43 bit / 5.49 bit = 0.99 That would be efficiency in terms of PR data size vs. amount space used in a QR code. Of course, the visual QR encoding also plays a role, for example its size is increased in discrete steps. Ok, so base43-aphanum is winning about a quarter of capacity against base64-binary. I probably will skip this anyway and go with bluetooth URI scheme we've just agreed + old style payments over p2p network as fallback. So no payment requests in QR codes at all from my side. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
2014-03-21 14:51 GMT+00:00 Andreas Schildbach andr...@schildbach.de: Quoting from RFC 3986, Section 3.4. Query: The characters slash (/) and question mark (?) may represent data within the query component. Ok. So BIP72 with a BT URI in the 'r' parameter? Yes. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
2014-03-20 8:08 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 03:22 AM, Alex Kotenko wrote: Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. We could use Bluetooth in the r parameter, not unlike we use Bluetooth in the payment_url. However, since multiple devices could access your machine at the same time, we need some for of adressibility of different payment requests. Something like bt:btmac- random_id_of_payment_request. I guess this would be best option. I'm also worried about potential QR code capacity, since as I imagine we can encounter device that has your Wallet installed and bluetooth enabled, but no NFC available, so we will have to operate via onscreen QR codes + bluetooth. Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/random_id_of_payment_request would be more usual and easily understandable. Really I don't think my PoS will now support multiple simultaneous payments, but it's good to have this thing in place for the time I will need it. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? Alphanumeric QR codes have an alphabet of 45 chars, of which I am using 43. I skipped Space and '%' because they're not allowed in URIs. When I invented the Base43 format back in 2011, wanted it to be URI compatible so we can use the Android intent dispatcher. If we let go of the URI requirement, we can use binary QR codes as well. This means users will always have to manually start their Bitcoin app first. (Also, there is an implementation issue with the ZXing scanner I'm using, it returns Strings rather than a byte array so it will choke on \0 characters.) And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? I took this into consideration. It would be space inefficient. The Base58-encoded address from BIP21 forces the QR code into binary mode. Still you can't encode the payment request extension (probably an URL parameter) as binary because it needs to stay compatible to the URI standard (RFC 3986). You could use one of the Base64 variants for the PR in this case, but still it would be inefficient. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. I can find out base64 size, but I don't have a working base43 implementation (since the only existing is in Java, and I don't speak it). Can you give me a sample uncompressed PR file of moderate size and a base43 encoded version of it? And I'll convert it into base64 and compare. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com: On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote: Whats a sensible limit on practical/convenient QR code size? Extremely limited. Preferably under 100 bytes. You will see increasingly poor operating in varying light conditions, such as paying via QR code on a printed receipt in a pub at night. That was one of the motivations for BIP 73. Hmm, in this case I think base43 discussion is irrelevant. Even with best space utilization we can get we will not be able to fit in anything bigger than a smallest unsigned payment certificate. And that is not so useful. So probably we should stick with BIP73 approach and bluetooth URI scheme we're inventing. On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach andr...@schildbach.de wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
We'll see how it will go, maybe I will get to implement this somewhere soon. Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth. I'll also look into using PKI inside the PoS for the merchant. It would be great user experience if we would be able to provide a signed payment request with human recognizable merchant identity name in the way you described much earlier in Bitcoin 0.9 FAQ. 2014-03-20 18:31 GMT+00:00 Mike Hearn m...@plan99.net: With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket, address, 1234, true) to wrap a bluetooth socket in SSL. However I have not tried it. For now, just prototype and build your product without the security. We can find someone to experiment with this, if you don't want to . Bluetooth needs encryption and MACs as well as signing to be secure, because there could be radio MITM. Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things. On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko alexy...@gmail.com wrote: Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn m...@plan99.net: Thanks Andreas. For BIP standardisation, I think the VIEW intent seems like an obvious one. Bluetooth support probably should come later if/when we put encryption/auth on the RFCOMM link (probably SSL). -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
2014-03-08 8:52 GMT+00:00 Jan Vornberger j...@uos.de: On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote: Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Very interesting, thanks for sharing! Are the two devices on the same wifi network in the demo? In my experience transaction propagation through the Bitcoin network takes a couple of seconds longer on average, so I'm surprised it's that fast here. No, devices on this video are not on the same network, and even if they would - I cannot control what remote hosts my phone would connect to, so transaction may anyway travel around the globe before coming to the POS even if they would be on one LAN. As for transaction times - I'd say it varies. From my extensive testing most of transactions usually come through within 2-5 seconds, but roughly one in ten transactions may take more time, sometimes much more time. You probably share this view, but I just wanted to repeat, that from my experiments, I think that sending the transaction only over the Bitcoin network should be a rarely-used fallback. It usually takes a little longer than you would like for a POS solution and every so often you don't get the transaction at all until the next block. And then what do you do? Maybe you would need to ask the customer to pay again, to get things done now, and put the previous transaction in some kind of refund mode, where - when you finally get it - you send it back somewhere. But it's really a problematic corner case - but yet it will happen occasionally with network-only propagation. Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. In the context of this discussion, I would also like to share a video of a prototype system: https://www.youtube.com/watch?v=mguRpvf3aMc Here shown is the (currently no longer working) Bridgewalker client, but it is also fully compatible with Andreas' wallet. The client picks up the payment details via NFC (as a Bitcoin URI - could and should be updated to use payment protocol) and transmits a copy of the transaction via Bluetooth (using the simple convention first implemented by Andreas). One optimization I did in the Bridgewalker client is, that it already opens the Bluetooth connection when presenting the user with the confirmation dialog. This results in a little additional speed-up, as the connection is already warmed up, when the user confirms. All code of this prototype is open source, as is the Bridgewalker client. Yes, I've seen this demonstration, I think it was on reddit about two month ago. Looks interesting, but by that time most of my client software was already done, so I couldn't really use this. From my testing, I can say that NFC for getting the payment details + Bluetooth for transmitting the transaction back works well. I'm a bit skeptical about using NFC also for the back-channel, but maybe for cases where there is no additional user confirmation it could work. NFC as back channel definitely will not work . Mike proposed something like a threshold to define minimal amount available for spending without confirmation, but I don't see this thing becoming widely used any time soon, and before that we will need to have confirm button tap. One problem with Bluetooth I see is, that it seems to be mostly turned off by users and many seem to perceive it as insecure, to have it active, as a result of earlier Bluetooth hacks. So I'm not sure if that will turn out to be a problem for usability when rolled-out in practice. Yes, this is a problem, I think bluetooth is offline on many devices, and keeping it on all the time will harm security (if not real security, then at least perceived by users) and also harm battery life, which will be seen as huge problem by the users. Would be great to be able to control BT state automatically from within the wallet app with user permission given once on installation time, but not sure if it's possible in Android. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
It heavily depends on where you use it. Here in UK any card payments are often limited to minimum of £5 in small shops that have heavy transaction fees burden and low margins. Big networks with more resources often let you pay as little as you want by card, and they more often have NFC enabled POS devices. So it's not an NFC or POS limit, but a business decision for these small merchants. Bitcoin can address this issue for sure, but this doesn't concern NFC. 2014-03-10 16:14 GMT+00:00 Jean-Paul Kogelman jeanpaulkogel...@me.com: Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less. I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved. jp On Mar 10, 2014, at 9:04 AM, Mike Hearn m...@plan99.net wrote: I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future. A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage. By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they: a) Reject cards entirely because the payment is too small b) Don't have the right hardware, or the hardware just mysteriously fails to work. c) Require a PIN because the payment is too large I'm sure Bitcoin can do better than this. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Ah, I see, so it's only payee who has to enable it, payer side is on by default. Then fine, situation is better than I thought. We'll look at implementing BIP70 asap. Best regards, Alex Kotenko 2014-03-10 19:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Hi Mike Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. For now this is just an NDEF URI message with Bitcoin URI inside, and then transaction itself propagated to the network by the phone using it's own Internet connection. Far not ideal, but even this is supported only by Andreas' Wallet, so we cannot move ahead alot really until other wallets will have some support in this area. As you see - it's taking just few seconds, most of which is manual payment confirmation. Btw, ignore my first screen tap, where I'm selecting wallets - it's an unlikely thing to happen IRL to have several wallets installed at the same time. Also, I think many people may not know about Oyster cards, so this might need little bit of explanation. And btw, have you been to London lately? Oyster readers now accept contactless cards directly along with Oyster cards itself. I wonder if eventually in future we could add bitcoin support into that system directly, without hardware replacements. I cannot put much into the actual protocol discussion, but I'm happy to provide feedback on the side of actual POS implementation needed and testbase if required. Have an idea - it's a good thing to cap confirmationless payments, but the actual cap value definition can be tricky considering Bitcoin volatility. Inless you want to tie it to some external price definition thirdparty service it could be tied to transaction fees. I mean - if with Bitcoin v0.9 transaction fees will become really floating, and it should eventually reach equilibrium that will reflect some real world value. Probably a tiny value, but probably also rather stable value. So confirmationless payment cap may be defined as current_average_transaction_feex1. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
