donstein unauthorized. check post above. I modifyed it

unauthorized just implies you haven't setup a "contact authorization" with that contact. Generally, you probably won't have any "authorized" contacts right now, as this code is still in development.

This is a separate thing from having your founder ID registered, so it's not a problem.

I used the official binary to reregister my new key . But once i compiled from githib source i could generate the same pubkey from identical inputs :-(

Did you mean you "could" or "could not" generate the same pubkey?

We fixed a problem with KH where the connection to the mail server could drop after the client was running for a couple of hours and it wasn't detected to restart the connection. We're also migrating the code to boost library to version 1.55 to use some new features, so we're taking advantage of the change to upgrade other subsystems as well (openssl, ICU) and we're moving to Visual Studio Express 2013 on Windows. This latter change will allow us to use more C++ 11 features as well (gcc already supported them, but VS 2012 didn't allow several of them). We're already building this way locally on our devel machines with 2013, and there's some work going on now to get jenkins builder to compile it all: jenkins needs to be upgraded from using make to cmake (this will also allow us to make windows binary releases directly from jenkins). Next up is to integrate the p2p code to Dan's blockchain code in bitshares toolkit, bring the new bitshares toolkit code into KH to replace the old blockchain/mining code, and work on the GUI wallet (some prototype GUI committed now, but it doesn't do anything yet).

Quote from: 麥可貓 on April 09, 2014, 01:02:22 am

0409 Keyhotee狀態更新
alt近來指出中文字符的空格能夠用來欺騙Keyhotee IDs，
因此我們更深入地探討
如何避免從從unicode眾多字元當中避免造成欺騙.
我們決議了類似於在DNS名稱當中避免欺騙的方法
(在我們的系統當中限制稍加嚴格)，
使用了ICU函式庫當中SpoofChecker以及Punycode的實作.

alt的炸弹又生效了，看来我们可能真的还要注册一次Founder ID

No, the change didn't affect public key generation, only hashing for the blockchain.

Re-registered in Keyhotee 0.7.0, the public key is:

5Cjgva2jU4cPhKCn83oyg1TeqLThahVa141gK8EqFKsvdhcrJM

Any more do I need to do?

Nope, that's it.

As I understand it, Keyhotee does the same thing as Bitmessage in that every mail you send out is sent to every node in the network, and whoever has the corresponding private key can read it.

I cant think of any other way for a decentralized system, but is there really no alternative to this? It doesnt seem to be very sustainable with millions of users, especially on mobile devices which cant afford to constantly sieve through millions of messages.

Btw perhaps this issue should be part of an FAQ pinned on this forum.

There's plenty of variations on how we can send the messages and eventually KH will support multiple methods. The current method KH uses can be viewed as the "highest security" method, that will "cost" the most CPU power to send. This method definitely only scales so far, so the traffic has to be limited to some level by a proof-of-work.

There will also be lower cost variations, for example direct connection to "authorized contacts" and "dark net" delivery. These alternative methods still provide all the encryption security of the current method, they're just a little more subject to network traffic analysis to detect who is talking to who most often.

Quote from: alt on April 03, 2014, 03:25:05 am

Please disable case sensitive!!
and some other rules for the ID, like disable space.
you can ask toast, he had make some  rules for the  domain name.
It's a good chance!

It's very bad with no rules.
at least we should disable space, I can register a ID of "bytemaster " or "bytemaster               "
who want a ID system like this?

and we should disable utf8 charset
because too much special charset, like chinese space: "bytemaster　"

Case-sensitivity is already accounted for by the name_hash. You get different keys generated with different capitilization, but all the forms of the capitilization will hash to the same hash value, so it's not possible to have someone registered as Alpha and alpha in the blockchain itself. The choice of capitilization used during creation just sets the public key generated (this is why the ID creator should remember the capitilization he used). But phishing attacks based on trying to register Alpha and alpha won't work, since only one will be allowed to register (the first to try).

We're looking into using some ICU functions to eliminate the various unicode spaces in the calculation of the name_hash for keyhotee IDs. Ideally there will also be functions there for taking care of some of the common chars that could allow phishing attacks. This part is still a little fuzzy as we're going thru ICU docs now and they're not fun to read.

Right now we're leaning towards a RFC 3454-style StringPrep to scrub the unicode string, maybe stripping accent marks, then our usual processing of trimming, eliminating consecutive spaces, smashing case, and replacing similar-looking letters

Quote from: taoljj on April 03, 2014, 07:20:17 am

Unsuccessful: "Invalid ID/Founderkey pair"

Same here.

Hi Ashaman,

Ok, I'm guessing you did the same as taoljj then (registered once with 0.7.0, then tried to register again with a different profile), because I see that ASHAMAN did get registered with a new key. The server will only accept one key registration, so if you need to change it now, you will need to fill out the webform and your key will get updated in a day or two. The webform is located at: http://invictus-innovations.com/founder-sign-up/

Note to everyone: the webform should only be used if you have registered with 0.7.0 and now want to change your public key because you lost the profile you registered. In general, it's best to register with the KH client instead.