tld with 1 letter would never be reserved by icann.
Same for .p2p i guess, but without warranty.

Which one do you prefer ?

You must purchase some namecoin (some people are selling on the forum) and register it with the namecoin software (which is a cloned version of bitcoin adapted for domains).



I've just added all OpenNIC domains support : * .bbs, * .free, * .fur, * .geek, * .gopher, * .indy, * .ing, * .null, * .oss, * .micro
   

Thanks. You can send to the address of my bitcoin identity in my sign.
I've added support for ns delegation too (thanks gsan for the help on bind) as it was on my priority list.
So, you can now manage your domains like you do it before, by using this free dns manager https://xname.org for example.

OpenNIC domains will be added very soon.


Edit : my namecoin address => 14hd7ZHP84bjAUNWHqWwbVTqFEDV93AzwP

Here is a good starting page on how to modify your dns servers :
http://wiki.opennicproject.org/ConfiguringYourComputer

spenvo : You must have configured this DNS server not to have timeout :p

I've started a dns serveur on 178.32.31.41 which resolves .bit domains.

There is a small web page to list current valid domains (which have set an ip address in the correct json format : use " and not ') :
http://namecoin.bitcoin-contact.org/

To use it, just modify your dns server and add this ip.
Here is a good starting page on how to modify your dns servers (just put my ip instead of the opennic one :p) :
http://wiki.opennicproject.org/ConfiguringYourComputer

Current domains (it will timeout if you don't have added my dns server) :
- bluishcoder.bit
- tester.bit
- toys.bit

If someone want to donate me some namecoins, i'd be gratefull (i generate and generate but i still get nothing...)

The link on your logo is not in https (just to avoid 1 redirection :p)

You may add the possibility to enter a password before accessing the wallet.

Otherwise, really simple, i like it (even if i won't use a shared wallet system :p).

Totalement d'accord.
Et c'est un défi d'autant plus intéressant que d'essayer de trouver un système qui pallie ce que je considère comme une faiblesse (inciter à consommer du CPU/GPU/ASIC/courant).


Du genre : traduire certains mots en anglais :p

Exactement, ça sera la course aux noeuds et plus précisément celui qui aura le plus de connexions avec des clients qui vont générer des transactions et qui devront transmettre le plus vite possible la transaction.
Cela mènera à une amélioration de la diffusion des transactions, et de la connectivité du réseau bitcoin.

Les clients bitcoin sont souvent limités à 8 connections. Si leur port est ouvert, bitcoin régule aussi les connexions par plage d'ip pour mieux répartir les connexions à travers le monde.


Ah, là je sèche :p. Bitcoin a le même souci (spam des transactions), mais ici, il serait amplifié à cause de "l'élection". Une idée ?

Here is why i'm progressively adding secured methods to verify the different parts of an identity on bictoin-contact : http://bitcoin-contact.org/identity/khal (verified addresses are with the green check, but i'm not satisfied with this display).

You can currently :
- add your OTC identity, verified with a signed GPG message
- add a bitcoin address, verified by sending a payment to self of a certain amount (i explain how to do that when you add the address in your account). I will add the ability to sign message directly with your bitcoin address when my patch will be included : Sign and verify message with bitcoin address and public key]http://bitcointalk.org/index.php?topic=6428.0
- add an email address, verified the classical way


A direct GPG signed bitcoin address will always be better, of course, if you know how to do it and if you know the public key of the person :p

Voici une petite proposition :

Le client qui génère une transaction va l'envoyer aux 8 noeuds auxquels il est connecté.
Au lieu d'envoyer la même chose à chaque noeud, il inclut la clé publique du noeud auquel il envoie le message, puis le signe.
Les transactions sont transmises et chaque noeud du réseau va en recevoir une des 8 (car il va ignorer les transactions qu'il connait déjà).

Pour déterminer lequel comptabiliser, il faudra regarder laquelle des 8 transactions a été incluse dans le block.
If "suffit" ensuite de déterminer à partir de combien de transactions et sur combien de blocks on fait la "moyenne" qui donne droit ou non à être éligible sur la liste des noeuds qui pourront générer un block.

La chaîne du temps... hum, le but est de choisir un block et de le graver dans le marbre pour déterminer sans ambiguïté quelle transaction a la priorité sur une autre potentiellement conflictuelle (double spend). Le système actuel de bitcoin a l'inconvénient de générer des forks de la chaîne.

Imagine maintenant que tu as 50 noeuds éligibles pour le prochain block (parce qu'ils ont leur clé publique inclue dans les transactions des précédents blocks).
Pour déterminer qui va générer le prochain block, il faut utiliser une valeur aléatoire mais determinable par tous les blocks : ça peut être le hash du block précédent. Tu peux aussi générer un ordre de priorité parmi cette liste, au lieu de n'élire qu'un seul gagnant.
Le prochain block sera signé avec la clé du gagnant => pas de fork possible de la chaîne. Si le gagnant ne génère pas le block au bout de 60s par exemple, le deuxième de la liste pourra générer le block. Il aura aussi le même temps pour le faire, et ainsi de suite.

ps : l'idée de l'ip est la plus simple mais pas réellement applicable en grandeur nature, surtout avec ipv6 (/56 /64 , etc) qui arrive.

La solution la plus logique serait de récompenser ceux qui aident le réseau en transmettant les paquets (transactions, blocks, adresses des noeuds, etc).

Mais pour comptabiliser ça, sans rajouter de surcharge, et que tout le monde ait accès aux mêmes stats (est-ce indispensable ?), je ne sais pas s'il existe une solution (un noeud peut s'identifier avec une clé publique, signer ses messages, etc).

Wow... i should be a little less gluttonous though... or really lucky :p
Thanks for the estimation.

This may not be accepted unless there are new security features (such as here : http://bitcointalk.org/index.php?topic=5549.0). But indeed, it may be the time to allow a milli BTC.

Vanity key tried 29'800'000.

How long will it take to find an adress matching : "^1Khalahan[A-Z0-9]" ?

C'est la chaîne des blocks qui définie l'échelle du temps. Elle est certe assurée et garantie par les hashs et la puissance de calcul, mais cela pourrait fonctionner autrement.

Dans bitcoin, la puissance de calcul est utilisée pour :
- générer de l'aléatoire dans la distribution des coins
- limiter la participation de chaque personne

On pourrait imaginer un système où la puissance de calcul n'est pas nécessaire pour résoudre ces 2 besoins.

Solution pour générer de l'aléatoire :
- utiliser le hash du dernier block comme valeur aléatoire pour déterminer la prochaine personne qui pourra générer le block

Si l'on veut faire varier la durée entre les blocks (pour faire comme bitcoin, mais ce n'est pas nécessaire, c'est même plutôt une limitation de bitcoin) :
- utiliser le hash du dernier block comme valeur aléatoire pour calculer le temps du prochain block

Solution pour limiter la participation :
- autoriser 1 participation par adresse IP
- autres ?

Pour générer des bitcoins, il faut s'investir un minimum. Si les bitcoins étaient répartis de manière aléatoire sans besoin de puissance de calcul, peut-être que le système ne serait pas aussi attractif pour les gens :p

ps : c'est un résumé, je vous ai épargné le reste de mes élucubrations

C'est ça. Le porte monaie contient une liste de clé publiques (traduisible en adresse bitcoin) et privées.
Si tu comprends l'anglais, j'ai expliqué le fonctionnement ici : http://bitcointalk.org/index.php?topic=4182.msg63505#msg63505

Oui et oui, c'est pour ça qu'une version qui ne télécharge pas tout est prévue à moyen terme.

La puissance de calcul permet de trouver, parmis des milliards de résultats possibles, certains qui ont des critères particuliers, et qui seront les seuls résultats acceptés par tous les logiciels bitcoin. Ça permet de générer du hasard parmis ceux qui génèrent des bitcoins (faut trouver le bon résultat parmis des milliards), et ça permet aussi de diffuser la monaie de façon pas trop disproportionnée (si tu veux + de bitcoins, il faut t'en donner les moyens, et ça coûte).
Lorsque tout aura été distribué (ou avant), tu paiera, ou pas, un petit prix à chaque transaction, pour que ta transaction sois traitée en priorité. Sur le volume, ça sera rentable car ça s'équilibrera (pas rentable ? des mineurs arrêtent de miner => ça devient + rentable pour les autres)

Qui sait :p

L'adresse doit être au format bitcoin (elle est vérifiée donc) pour que l'envoi fonctionne. Si l'adresse existe vraiment mais n'est à personne, les bitcoins peuvent être considérés comme perdus.

C'est la solution choisie pour répartir les bitcoins de façon pas trop disproportionnée.
La puissance de calcul change la répartition, mais pas la quantité générée qui est constante.

Tu es ta propre banque avec bitcoin, voilà l'avantage. Pas de frais exorbitants, pas de transaction annulée pour rien, pas de dépendance.

I think we don't need to display this message to users, so we can put what we want. It will belong to the internal mechanism of the signing/verifying functions.
The signmessage and verifymessage would still do their job.

I've searched through rpc.cpp and i don't see another way of doing it, so i'll follow the "standard". However, i don't know which code number to use is the json error. What do they correspond to ?

There is no more data except:
If you know how to retreive more info, feel free to modify the code :p

Not really usefull for you, but for other people, go to this web page and click on "Root Certificate (PEM Format)". Firefox will propose you to add the certificate, check "allow for web site" (or somethin like that). That's all
=> http://www.cacert.org/index.php?id=3


ps : it works without this on Debian and iceweasel (custom debian firefox).

Several people are working on different bitoin parts and propose patches (see : https://github.com/bitcoin/bitcoin/pulls).
So we can't say with that that all code has been reviewed, but it's a good start :p