I'm pretty sure they haven't shipping anything yet, if they did, we would know about it. I understand that they are being quiet and don't want to be like BFL (two more weeks), but any news would be better than radio silence at this point.
We are working on an announcement -- it will be out soon. |
|
|
|
But what about the mom and pop store who accepts Bitcoin and has no interest or time in learning it? How do they get their store listed?
She asks her son/daughter who has interest and time.  |
|
|
|
How about a "Submit Change" link or button. You could then have a box show up where they pick something is out of date or needs to be added. If something needs to be added they just fill in the box and submit it. It could then automatically be posted in this thread where anyone with the skills could edit it if needed. If anyone has actioned the item they just reply to the post with "Done".
One of the aims of this project is to teach people how to use OpenStreetMap. So no, this is not planned at the moment. |
|
|
|
Is this for the "buy online" ads on localbitcoins.com too or just the cash deal ads?
Online, unfortunately. I'm discussing with LocalBitcoins folks, but until they have a reasonable API for Local Ads, I can't do much. I removed LocalBitcoins data points until: a) LocalBitcoins has full API for querying local ads (at least like they have for online ads) b) I implement hiding/showing of point layers by their type (this should be fairly trivial) |
|
|
|
good, but looklike we lost the displaced info about number of places! Now that i was taking daily this info to make a chart  I found out that calculating LocalBitcoins data points might be tricky, so I removed the number completely. Now I realized it's probably better to have it back, just showing the number of OpenStreetMap venues. |
|
|
|
|
I just finished cleaning up code from the Hive team and deployed it on CoinMap.org. ZipZap support is disabled for now, because I want to learn more about the service before I start advertising it.
But for now you can enjoy around 1000 geo points fetched from LocalBitcoins!
|
|
|
|
I would like to present the growth of coinmap in the last months, there is a way to extract the number of places in function of time?
Thanks
Not at the moment. I plan to add more functionality soon and this is going to be one of the features. |
|
|
|
... that's basically advocating a return to 1-factor verification (using a Trezor instead of a password).
For signing using TREZOR you'd need to provide passphrase/pincode as well. So it is 2FA. |
|
|
|
Tough to compete with a $2 (cost) USB plug.
Right. But Yubikey can't protect you from phishing, while on TREZOR you could check on display if you are trying to log in to the right website. Also TREZOR can hold infinite number of "identities", while Yubikey is just one identity. |
|
|
|
My question is: Is there a BIP in the works that will standardize some type of communication between Bitcoin clients and application/website for those who wish to use "Bitcoin Identities" as a secure method of logging in? Or is a BIP even needed?
We already had some discussion about this with slush and we certainly want to come up with an "Identity" BIP (that builds on top of BIP32). That way it will be standardized and easy to implement. |
|
|
|
I think would be nice to modify the visualization code to give the chance to select only specific activity: B&B, Pubs,restaurant....
That's on my list, but I have very little time nowadays. :-( Pull requests and donations welcome :-) |
|
|
|
|
Ah, I found a bug in my code (used substract function that performs mod prime at the same time, now we use curve order not prime). Now it works. Thanks fpgaminer for kicking me into the right direction (also for new test vector).
|
|
|
|
I've checked with mobiles and computers with different resolutions and operating systems and it seems to be working fine with all of them.
Thanks. I did some limited testing (Galaxy Nexus, iPad, 1024x768 screen, HD screen), but the more tests the merrier. |
|
|
|
The theory behind this is: if you negate K you get the same R and the negated S. Hence you need to negate S as a post-processing step, i.e., S' = prime - S in both cases.
Thanks. That's what I thought but wanted to confirm. Did you use the right prime? It should be the order of the elliptic curve not the size of the prime field.
Tried both with the same result (invalid sigs). |
|
|
|
There are multiple ways to remove this 1-bit of freedom. One way is to make S even. Another way, now used by bitcoin-qt git, is to make s < order/2. The advantage of this way of removing the vs others freedom is that it also reduces the average signature size slightly. I now prefer the s < order/2 version of this just because it produces smaller signatures and the flip is even easier to implement than the even/odd version.
if you look at the current code in git master, it just subtracts order/2 when s > order/2 - pretty simple.
Flip is already being done when you deal with compressed public keys. All software that can process compressed public keys already knows how to do the flip (val = prime - val). It would be nice to be consistent here IMO. FWIW when I used this method on S (if S is odd: S = prime -S) - the code produced signatures that are considered invalid by both my code (microecdsa) and OpenSSL. *puzzled* When I used the other way (if S > prime/2 : S -= prime/2) I ended up with the same result (invalid signatures). Any hints on what is going on? |
|
|
|
I now prefer the s < order/2 version of this just because it produces smaller signatures and the flip is even easier to implement than the even/odd version.
So how exactly K needs to be changed/processed to have S < order/2 ? Or we keep K as it is and just postprocess S ? |
|
|
|
Hi guys! We created a mailinglist trezor-dev for developers on Google Groups which is a better way to discuss technical stuff than forum. Subscribe at Google groupsor send a subscribe email to trezor-dev+subscribe@googlegroups.com to catch it all! Jim: would you be so kind and lock this thread so we don't have two dev discussions going in parallel? Thanks! |
|
|
|
I noticed that the problem came from the parity of 'S'. The 'S' component is odd in your last test vector. Why should S be even? Any citation? |
|
|
|
|
Show Posts
