Aim of the BitDNS concept is to have a decentralized DNS system (and domain name registration) which can't be controlled by external entities. You can read the homepage of the dot-bit project and the about page, which is an implementation of BitDNS concept based on the namecoin software. |
|
|
|
Someone explain what a namecoin is, how it is used, and why would we need them. A cursory glance at that wiki says they are used for DNS, but then you go and list DNS servers people can freely connect to? What am I missing here.
I made the about page for you : http://dot-bit.org/AboutDifficult to summarize things in some words :p ps : you can ask additional info in this topic. |
|
|
|
|
You are missing the page : what is namecoin, which still doesn't exist :p
I'll explain that after eating some food :p (or someone else can do it now too)
|
|
|
|
|
A stupid update to get more than 500 domains (default in name_scan )...
If you don't find your new domain in name_scan, use 'name_scan "" 10000' (to list up to 10000 domains).
If you configured your new domain the right way, and my DNS server does not reply an ip for it, this should now work :p
|
|
|
|
Bump. I just realize a reason this is immensely useful (besides Eligius): no longer do transactions require unique destination addresses. A merchant can publish a single address/email pair for all purchases, and clients can send the purchase information via email, signed by the sending address.
Bitcoin is already used as a key storage, to sign bitcoin transactions. So, why not use this feature fully ? :p By the way, would you consider using the compact signatures I proposed some time ago ( http://bitcointalk.org/index.php?topic=6430.0)? This would alleviate the need for separately showing and passing the public key around. [...] I don't think that experimental (though tested) recover-public-key code should be included immediately [...] If prefer to keep things simple for now, but if we want to add that later, it may break the compatibility with this patch (we must chose to use Sign or SignCompact when signing. When verifying, no problem, if a bitcoin address is provided it'll use VerifyCompact, otherwise Verify). What are the other opinions ? |
|
|
|
|
You annoy people for potential security problems that are 100'000 x less frequent than infected/zombie computers and you hope people "wont be entering their password on a compromised machine" ? Are you really serious, guy ?
|
|
|
|
i would totally embed this in my websites...  A new way to fund popular sites? Think Digg and every user contributes as long as he's on the page  That would be awesome. I'm going to have to work on that tonight... It would be like ads, except the website owner gets paid for having a website that people want to stay on, rather than for simple number of pageviews / click throughs. If you want to use my idea, you will need to pay a license :p Edit : mail sent |
|
|
|
I'm curious why you guys would like that feature - is it just to make it easy to stay anonymous? If you're worried about that then until I have this feature you can give a fake/temporary email - I don't validate it, it's only used to email a link to reset your password in case you forget.
Are there other reasons? It's helpful as a developer to know why users want a certain feature, to make sure I give you what you want.
I own several websites where people can donate (no BTC for now). It would be a simple way for them to donate this way and add BTC donation at the same time. More simple => more users. |
|
|
|
Yes, I've got plans for something similar: a link that will open the miner in your name but doesn't require a username/password. So you could have your friends mine for you, or use it on an insecure computer.
Good, i wait for that  Right now there's a trick you can use in the mean time: - log in
- start generating
- open up the "my account" page in a new window
- click "logout"
The miner will still be able to mine for you, but if someone comes to the computer, you're logged out. Not sufficient for my case, but maybe for some others :p It shouldn't be necessary to register with name and email address. It should be sufficient to enter your payout address into a field of the applet (if applets are able to communicate this to the server), otherwise use an HTML form field or allow the Bitcoin receiving address to be appended to the URL of the "generate" page. It could not be more simple :p. A good solution too. |
|
|
|
|
Can you add on option to add other login/pass that have a restricted access to the account (they can just mine and nothing else, even change the password) ?
|
|
|
|
I would suggest : walletpassword <timeout> [password] If password is not on the command line, bitcoin will prompt for it. This will avoid your password to be stored in history files (or anything else) and still allow putting all in 1 command if you prefer. Same for walletpasswordchange rpc. |
|
|
|
I've updated the two linux archives (32 & 64bits) of namecoind with latest patches (ex: Report immature coinbase transactions in listtransactions, and a lot more patches from bitcoins) If someone wants to build the windows version, i would put it on the dot-bit wiki. |
|
|
|
Ton idée me parait difficile à mettre en pratique.
Limiter le hash à une épreuve d'une trentaine de secondes toutes les dix minutes, c'est peut-être faisable techniquement (et encore je vois mal comment), mais de toute façon cela nécessiterait une difficulté bien plus grande (en gros d'un facteur 10*60/30= 20) pour garder un taux de forks comparable. Donc ça s'oppose au but initial qui est de réduire la consommation d'énergie.
Au bout de 30s chaque mineur envoi son meilleur hash sur le réseau, il n'y a plus de notion de difficulté à atteindre. Chaque noeud reçoit ces hashs et les accepte ou pas s'ils arrivent après un certain délai (tout comme les blocks bitcoin qui contiennent un timestamp). Pour limiter le temps de l'épreuve, il faut que les données nécessaires à celle-ci soient connues juste avant le début de l'épreuve, et c'est ce à quoi sert le hash du block précédent (tout comme bitcoin, à la différence qu'ici on sait quand il va arriver). En rendant le système inactif 90% du temps, vous offririez du temps aux attaquants.
Ils pourraient l'utiliser pour donner du poids à des blocs dans lesquels leurs propres transactions ont été modifiées (double dépense).
Le sytème génère toujours des blocks toutes les 10 mn, et il est impossible de connaître leur hash à l'avance, qui est nécessaire pour générer le block suivant. La chaîne de blocks est toujours présente. Un attaquant aura la même fenêtre de temps que tout le monde pour commencer et finir son calcul. |
|
|
|
Et si finalement, se baser sur la puissance CPU n'était pas si mal que ça pour limiter les gains en bitcoins ? La puissance CPU a 2 inconvénients : - les riches peuvent en obtenir plus que les pauvres (chacun peut gagner X fois ses ressources actuelles, ce qui creuse les écarts) - cela gaspille des ressources Le point 2 pourrait être résolu ou très fortement limité. Le 1 est peut-être obligatoire si l'on veut un système anonyme. 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. => On pourrait imaginer un système où la puissance de calcul n'est pas nécessaire en continu pour résoudre ces 2 besoins. Le nombre de hash/s determine la puissance d'un utilisateur, et donc directement ses gains. Au lieu de hasher en continu, les mineurs pourraient hasher pendant 30s (tous en même temps) toutes les 10mn que ça ne changerait strictement rien à leurs revenus, qui seraient toujours proportionnels à leur capacité. Encore mieux, 30s de hash 1 fois par heure ou jour n'y changerait rien. Récap : - 30s par heure les mineurs hashent et envoient leur meilleur solution sur le réseau - les 50 bitcoins par block sont répartis entre toutes les solutions, proportionnellement à la qualité de la solution soumise Les mineurs des 5 blocks suivants (le 1er hash/block étant la meilleure solution fournie pour cette heure) seront choisis "aléatoirement" parmi la liste des solutions soumises (le hash du dernier block pouvant servir à générer de l'aléatoire chaque 10mn). Cette solution a (au moins) 2 inconvénients : 1. celui de générer un paquet d'envoi (chaque solution) tous au même moment 1 fois / heure. La durée d'1h peut être allongée. 2. celui de générer une méga transaction par block (ou par heure) pour payer toutes les solutions Au lieu de payer tout le monde, il suffit de payer 50 ou 6*50 solutions "au hasard" (toujours en utilisant un hash connu de tous pour choisir les solutions), avec des gains toujours proportionnels. Actuellement, les mineurs de pool soumettent des tas de solutions de difficulté 1 en continu sur leur noeud : cela ne serait plus nécessaire. Genre: une cryptodevise, pour être à la fois décentralisée, purement électronique et anonyme, doit nécessairement distribuer la monnaie en fonction de la puissance de calcul des utilisateurs. Cela reste maintenant toujours valable. Cette solution a aussi des avantages : - 120 fois moins de gaspillage si l'on choisit 1h comme valeur (600 fois moins pour 5h) - le réseau n'a plus vraiment autant besoin d'être concentré en pools, ce qui le fragilise |
|
|
|
This shouldn't be a problem, same thing apply for bitcoin scalability. I haven't used Namecoin, so please correct me if I've misunderstood anything. I'm just looking at Namecoin from the point of view of "do I feel satisfied paying out my bounty?".
Here is my understanding. Please correct any errors:
1. 50 namecoins are generated with every block.
2. The block target time is 10 minutes.
3. Generation difficulty scales the same way as Bitcoin.
8. The renewal cost is 0.01 NC, at least once every 12000 blocks. In practice a figure of twice per 12000 blocks seems realistic, to allow for DNS changes and also for people to renew before the 12000-block deadline to avoid the risk of losing their domain names.
True. 4. The number of namecoins per block doesn't decrease. It's 50 forever.
5. There is no 21-million limit to the number of namecoins generated.
I don't think so, but it should be confirmed by vince (the code seems the same than bitcoin). 6. To reserve a domain costs 0.01 NC, so there is a hard limit of 720000 new names per day, but in practice the limit will be much lower because not all namecoins are used to reserve domains. It's the same thing for bitcoin. Just a mater of deciding what value will scale well. 7. To activate a domain costs an amount that started at 50 NC but halves every two months. So after about two years, the activation cost (cost of "first update") will be lower than the renewal cost ("name update"). The lower limit is 0.01NC for a first update. Cost of a domain is constantly decreasing (second per second), at the rate of 50% each 8192 blocks (57 days) if i understood the code. Vince says " The network fee decreases 2x every 2 months" in the FAQ. I've reproducted the formula of the source code here : http://dot-bit.org/tools/domainCost.php?block=3561This is to limit the rush on domain names. 9. Some payments are burned, and some are kept by the miner, and some are retained by the spender to represent names. Is that right? What happens to each kind of payment? Yes. All that you pay is lost, except for the fees that go to miners (like bitcoin), and the special 0.01NC that is send to yourself and reserved. As Vince said, if you want to update sex.bit, it'll cost 0.01NC (lost) + a fee (like bitcoin, miners may refuse your transaction if the fee is too low) If these points can be confirmed or corrected, I'll have a better feel for namecoin's scalability. As you promised a bounty for that, you've the right to put some conditions, and explain them. It's up to the implied people to find them reasonable or not. But, for that part, as i'm not the main developper of namecoin, my opinion imply myself only, even if i implied myself a lot in this project. |
|
|
|
|
Can you say precisely what is limiting the number of domain names ?
The only thing which i'm sure of: the current maximum block size (1M) is limiting the possible number of updates. But, the maximum block size is not a real problem.
Is there any other limit ?
|
|
|
|
|
Your wallet has been created on first launch.
Now, try : bitcoind help
|
|
|
|
I tried to contact vince by PM and on IRC without success (PM : I didn't receive a response, IRC : we don't leave in near timezones i guess), but gsan had some contacts with him. What i can say is this project needs visibility, organisation, documentation, tools and a central web site to find/manage all this, and this can't all be done by 1 person (consequence is a wiki + a forum). * Vince has forked the bitcoin client and launched namecoin. * I've started by creating a DNS bridge for .bit domains and then the dot-bit project. I did not chose the name ' namecoin project' because there was no namecoin.tld available (i discovered later that someone else had reserved some of them and i proposed to switch to this domain name). * gsan has started the second .bit DNS server and written the draft for the domain specification* Some miners are sellings namecoins* People have reserved around 500 domainsHere is a little summary of people involved in namecoin currently (sorry if i miss some). So, i can't really say we are partners, and i would be happy if we can claim it both, but would it change something ? If you want to make some donation to a person directly, because you think his personnal invest is significant for you, you can donate to him directly. If you think that donating to this project may help more, you can do it. Or you can do both :p If you ever asked this to clarify things for the BitDNS bounty, i hope you have enough informations to make your own decision (i cannot be judge and jury). Vince, any comment about all that ? |
|
|
|
|
Show Posts
