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
at
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.
--
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 ent
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
> > s
> > 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:/
>
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
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 paymen
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* t
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,
> h
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
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
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
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
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
+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
>> ent
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.
---
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 convi
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
--
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. Probabl
19 matches
Mail list logo
