[Bitcoin-development] Transifex administration
G'day great devs, How can I gain status of maintainer, admin or / and reviewer in https://www.transifex.com/organization/bitcoin/dashboard ? I'd like to set the description, project logo and whatever is missing on Bitcoin project inside Transifex. I believe if it is better configured it can attract more contributors. Of course my English is not perfect how you can see, but surely I'll copy the description from wiki, source code docs and other fonts written in native English. The logo I'll set the official one. Also, I want to be able to make review in Portuguese BR. Unapologetically my Portuguese is perfect, I studied the grammar several years and I am native speaker. I've been contributing in Portuguese BR and yesterday I completed the 35% missing translations. Thank you so much in advance, Felipe Micaroni Lalli Walltime - https://walltime.info Bitcoin Paranoid Android developer PGP ID: 0x4c0afccfed5cde14 - ED5CDE14 BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N signature.asc Description: Message signed with OpenPGP using GPGMail -- 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 :
>
> 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
SPDY requires SSL and is even more complex than HTTP. Really, the current protocol we've got (length prefixed protobufs) is just fine except for the lack of encryption/authentication. For that you need to do ECDH to establish a shared AES session key, and MAC each packet. Like I said, it's not entirely trivial which is why it's worth trying SSL too, but it's also not a massive effort. On Fri, Mar 21, 2014 at 4:20 PM, Andreas Schildbach wrote: > On 03/21/2014 02:54 PM, Alex Kotenko wrote: > > > > 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. > > Btw. we could also consider SPDY. I'm not sure about the advantages, but > its probably quicker and leaner. > > > > > > -- > 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
On 03/21/2014 02:54 PM, Alex Kotenko wrote: > > 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. Btw. we could also consider SPDY. I'm not sure about the advantages, but its probably quicker and leaner. -- 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, 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:/
> > " 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.
Quoting from RFC 3986, Section 3.4. Query: "The characters slash ("/")
and question mark ("?") may represent data within the query component."
> 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.
Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.
> 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.
So BIP72 with a BT URI in the 'r' parameter?
--
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 10:28 GMT+00:00 Andreas Schildbach : > On 03/20/2014 06:31 PM, Jeff Garzik 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. > > Unfortunately it still is. At least here in Germany. Yes, it is a problem. Even in the middle of London you often can get into situation when cellphone network connectivity is not good enough for quick and reliable payment. Basement pubs, old buildings with thick walls, overcrowded places with overloaded radio environment. We should not rely on mobile connectivity in things like making payments. > > > > > > -- > 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 9:47 GMT+00:00 Andreas Schildbach : > 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:/ > > " 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
Maybe so, but given the relatively minor advantages of ECC certs I can see why a CA might not want to take any risks. They are sitting ducks for patent trolls. I think ECC will still happen, though we end up back into NSA fear territory thanks to the stupid way secp256r1 was defined. *Hopefully* there's no back door. On Fri, Mar 21, 2014 at 1:25 PM, Adam Back wrote: > According to Bernstein it's patent FUD (expired, ancient and solid prior > art). > > http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html > > Adam > > > On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: > >> Oh, one other reason I found - apparently RIM, at least in the past, >> has been telling CA's that they need to pay mad bux for the Certicom >> ECC patents. So that's another reason why most certs are still using >> RSA. >> > -- 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
According to Bernstein it's patent FUD (expired, ancient and solid prior art). http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html Adam On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: > Oh, one other reason I found - apparently RIM, at least in the past, > has been telling CA's that they need to pay mad bux for the Certicom > ECC patents. So that's another reason why most certs are still using > RSA. -- 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
Oh, one other reason I found - apparently RIM, at least in the past, has been telling CA's that they need to pay mad bux for the Certicom ECC patents. So that's another reason why most certs are still using RSA. On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn wrote: > On Fri, Mar 21, 2014 at 11:59 AM, Adam Back wrote: > >> Maybe its time to explore raw ECDSA signed message based certs. >> > > If you want to create and run a new CA, by all means. But I bet you don't. > So we're stuck with the current system for now. > > >> btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in >> der >> format. And they contain a 2048-bit RSA server key, and 2048-bit RSA >> signatures (256byte each right there = 512bytes). And even 2048 is weaker >> than 256-bit ECDSA. > > > But you have to chain up to the root. > > The only reason more certs aren't ECC is backwards compatibility. Some old > browsers don't know how to handle them. It wasn't so long ago that Fedora > and Android were deleting ECC code from upstream libraries before shipping > them, either for patent reasons for disk space saving measures. > > But it's possible to get ECC certs if you want. For example, Entrust is > starting to sell them: > > http://www.entrust.net/ecc-certs/index.htm > > But their intermediate cert is still RSA. My understanding is that ECC > roots for many CA's have been submitted and are now included, but of course > "give up compatibility with lots of users" vs "save a bit of cpu time and a > handful of bytes" is no real competition so it will be a long time until > most websites are using ECC certs. > > Regardless, it's all irrelevant. Who knows when we might want to add > another feature that uses some bytes into PaymentRequests. Stuffing them > into a QR code will never make much sense IMO - it's far more sensible to > just use Bluetooth where the data size constraints are so much easier. > -- 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] Post to list request
Sounds very relevant to what we were just discussing on the other thread, about securing Bluetooth connections and BIP70. On Fri, Mar 21, 2014 at 11:58 AM, Andreas Schildbach wrote: > Access granted. Welcome! (-: > > > On 03/21/2014 10:11 AM, Chris D'Costa wrote: > > Hello > > > > I wonder if I could be granted access to post to the dev list. My > project is the Meek hardware wallet, and we are working on a solution to > avoid MITM attacks when communicating a pay-to information over a > non-secure transport mechanism. > > > > Regards > > > > Chris > > > -- > > 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 > > > > > > > -- > 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
On Fri, Mar 21, 2014 at 11:59 AM, Adam Back wrote: > Maybe its time to explore raw ECDSA signed message based certs. > If you want to create and run a new CA, by all means. But I bet you don't. So we're stuck with the current system for now. > btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der > format. And they contain a 2048-bit RSA server key, and 2048-bit RSA > signatures (256byte each right there = 512bytes). And even 2048 is weaker > than 256-bit ECDSA. But you have to chain up to the root. The only reason more certs aren't ECC is backwards compatibility. Some old browsers don't know how to handle them. It wasn't so long ago that Fedora and Android were deleting ECC code from upstream libraries before shipping them, either for patent reasons for disk space saving measures. But it's possible to get ECC certs if you want. For example, Entrust is starting to sell them: http://www.entrust.net/ecc-certs/index.htm But their intermediate cert is still RSA. My understanding is that ECC roots for many CA's have been submitted and are now included, but of course "give up compatibility with lots of users" vs "save a bit of cpu time and a handful of bytes" is no real competition so it will be a long time until most websites are using ECC certs. Regardless, it's all irrelevant. Who knows when we might want to add another feature that uses some bytes into PaymentRequests. Stuffing them into a QR code will never make much sense IMO - it's far more sensible to just use Bluetooth where the data size constraints are so much easier. -- 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] Post to list request
Access granted. Welcome! (-: On 03/21/2014 10:11 AM, Chris D'Costa wrote: > Hello > > I wonder if I could be granted access to post to the dev list. My project is > the Meek hardware wallet, and we are working on a solution to avoid MITM > attacks when communicating a pay-to information over a non-secure transport > mechanism. > > Regards > > Chris > -- > 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 > -- 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
Maybe its time to explore raw ECDSA signed message based certs. btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der format. And they contain a 2048-bit RSA server key, and 2048-bit RSA signatures (256byte each right there = 512bytes). And even 2048 is weaker than 256-bit ECDSA. Adam On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote: >On 03/20/2014 01:12 PM, Adam Back wrote: > >> Whats a sensible limit on practical/convenient QR code size? > >Technically 3 KB. In my experience codes above 1.5 KB become impossible >to scan (ZXing scanner, 3 years ago). You will want to stay below 500 >bytes for convenient scanning. That said, I'm convinced there is a lot >of room for scanning improvements. > >> How much of the payment protocol message size comes from use of x509? > >As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about >4000 bytes on top of that. > >As you can see, we have quite some room for improvements to PR payload >(PaymentDetails). X.509 certification will probably not be possible via >QR, at least not until specialized CA's will issue space-efficient certs >(using ECDSA?). -- 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
+1 I couldn't do a better job at describing my motivation behind trying to stuff payment requests into QR codes. On 03/20/2014 10:52 PM, Roy Badami wrote: > On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: > >> 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 > > I'm not sure if this what you're getting at, but in a common > face-to-face scenario, it really doesn't overlap so much (in that the > PKI in BIP70 isn't really helpful). > > It's not unusual, in a face-to-face transaction at a bricks-and-mortar > establishment, that you know neither the legal name of the entity > running the establishment, nor any electronic identifier (domain name, > email address) that might be presented to you in an X.509 certificate, > even if such a certificate is presented in the PaymentRequest. > > In many cases I want/need to simply be assured that I am paying "the > person/organisation which operates that machine behind the counter, > right there". > > In many ways I'll miss the simplicity of BIP21 QR codes for > face-to-face transactions - because in this use case the payment > protocol complicates (and in many cases weakens) the assurance that > you really are paying the entity that prepared the QR code. > > roy > > -- > 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 > -- 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
On 03/20/2014 06:31 PM, Jeff Garzik 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. Unfortunately it still is. At least here in Germany. -- 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
On 03/20/2014 01:12 PM, Adam Back wrote: > Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm convinced there is a lot of room for scanning improvements. > How much of the payment protocol message size comes from use of x509? As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about 4000 bytes on top of that. As you can see, we have quite some room for improvements to PR payload (PaymentDetails). X.509 certification will probably not be possible via QR, at least not until specialized CA's will issue space-efficient certs (using ECDSA?). -- 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
[Bitcoin-development] Post to list request
Hello I wonder if I could be granted access to post to the dev list. My project is the Meek hardware wallet, and we are working on a solution to avoid MITM attacks when communicating a pay-to information over a non-secure transport mechanism. Regards Chris -- 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
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:/ > " 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. > 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. > 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. > 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. -- 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
