Hmm, I don't think that the longer the wait the less chance of success...
There is some compoetition in the form of dot p2p project.
Topic: BitDNS and Generalizing Bitcoin - page 5. (Read 122493 times)
Hmm, I don't think that the longer the wait the less chance of success...
There is some compoetition in the form of dot p2p project.
How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.
The longer we wait, the less chance of success we will have.
The longer we wait, the less chance of success we will have.
Hmm, I don't think that the longer the wait the less chance of success...
I'm interested in comments about my proposal. I think that it solves much of the issues in a logical manner.
How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.
The longer we wait, the less chance of success we will have.
The longer we wait, the less chance of success we will have.
I am hoping the developers implement Satoshi's ideas which are:
1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.
I especially don't want a fork so my Bitcoins are worth something.
1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.
I especially don't want a fork so my Bitcoins are worth something.
"To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred."
In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.
I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?
In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.
I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?
Amazing that I was just inventing this kind of system (Bitcoin based DNS) only to find this huge thread discussing it.
I actually suggested something like this before with this post: https://bitcointalksearch.org/topic/m.7545 (Bit Stock Broker).
The fundamental key here is verifiable ownership and transfer. The "thing" that is being transferred whether stock, DNS, title, etc should be handled out-of-band.
Every 'thing' needs a name. 100% of all bitcoins (present and future) is the bitcoin 'name/stock'.
Every 'thing' may have partial ownership which may be transferred.
A DNS is just a name owned by one or more public keys.
Assuming we had a means of transferring fractional ownership of arbitrary names then anyone can validate a use of that name with what ever service.
So suppose BitDNS issues a new thing named 'apple' and assigns it a public/private key pair and 100% ownership. Facebook could now require that you sign your account application with the private key of 50+% ownership of the 'apple' name and at the same time a DNS service could make the same requirement.
All over the internet everyone could verify all data that came from some set of owners. So the owner of apple could create a DNS file that contains an IP address and then sign it. That file could be distributed and queried by what ever p2p or server/client system user applications desire.
To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred.
Limit the creation of new 'names' to N per block.
By only storing the hash of the name you enable verification of ownership without giving away anything about 'what is owned'.
The only other feature we would need is to define a transaction such as:
100 BTC From MyBtcAddress -> Block Creator
100% name From NEW -> MyBtcAddress (signed by MyBtcAddress)
When a block is created 'high bid wins' and low bids for name are ignored.
Keep all uses of this name (Facebook, DNS, email, forum login, reputation systems, etc) out of band.
I actually suggested something like this before with this post: https://bitcointalksearch.org/topic/m.7545 (Bit Stock Broker).
The fundamental key here is verifiable ownership and transfer. The "thing" that is being transferred whether stock, DNS, title, etc should be handled out-of-band.
Every 'thing' needs a name. 100% of all bitcoins (present and future) is the bitcoin 'name/stock'.
Every 'thing' may have partial ownership which may be transferred.
A DNS is just a name owned by one or more public keys.
Assuming we had a means of transferring fractional ownership of arbitrary names then anyone can validate a use of that name with what ever service.
So suppose BitDNS issues a new thing named 'apple' and assigns it a public/private key pair and 100% ownership. Facebook could now require that you sign your account application with the private key of 50+% ownership of the 'apple' name and at the same time a DNS service could make the same requirement.
All over the internet everyone could verify all data that came from some set of owners. So the owner of apple could create a DNS file that contains an IP address and then sign it. That file could be distributed and queried by what ever p2p or server/client system user applications desire.
To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred.
Limit the creation of new 'names' to N per block.
By only storing the hash of the name you enable verification of ownership without giving away anything about 'what is owned'.
The only other feature we would need is to define a transaction such as:
100 BTC From MyBtcAddress -> Block Creator
100% name From NEW -> MyBtcAddress (signed by MyBtcAddress)
When a block is created 'high bid wins' and low bids for name are ignored.
Keep all uses of this name (Facebook, DNS, email, forum login, reputation systems, etc) out of band.
Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.
Yes, any strong scripting language language will do. I'll leave it up to the programmers to pick the language.
Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.
C++ is a strong scripting language.
Get the other technical details right. Picking a programming language is the lowest task on the priority list.
C++ is a strong scripting language.
Get the other technical details right. Picking a programming language is the lowest task on the priority list.
In my proposal: http://domainchain.org/wiki/doku.php?id=bitname
The proposal that I have made has covered 3 main areas.
First: Changes to the Bitcoin Protocol.
Expanded templates, (allowing to check transactions based upon what they claim to be). This also allows new services to be run within the chain without changing the protocol. Using a strong scripting language it should be possible to make 'plugins' for generators so that they may accept new types of bitcoin transactions.
Transaction Grouping, this allows transactions to be grouped together by template. Clients will only need to download the summary and the hash tree, unless they want more detail.
Burning transactions. This is a new sort of transaction fee that 'burns' over time. It contains two qualities, firstly total number of coins to be to be burnt, and secondly, the rate (per block) that it is burnt at. This is the basis of the compensation to generators for including extra data in the block chain. When the transaction stops burning, the extra data may be deleted.
Second: BitName
BitName is a named address that has a fingerprint of a public certificate. Instead of sending bitcoins to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP, one could send bitcoins to 'da2ce7'. The BitName concept is built upon burning transactions. Each transaction that declares a name, must include a burning transaction to keep the name active. The higher the rate of burning the more likely that the transaction will be accepted. If the rate is too low, the network will likely ignore or forget the name early.
If a generator accepts a new transaction of the same name as a pre-existing, the network will likely orphan the block, unless the burning fee is so low that the network regards the name as spam.
The other significant benefit from having a BitName is public certificate verification, when one sends a message that is signed, the key signing the message can be check against the known name of the source. The fingerprint included in the block chain then can be used to verify the signer.
Third: BitDNS
BitDNS is derived from BitName. A BitName should be used to make any new BitDNS records. This requirement in the future can be used for spam prevention.
Both the top-level root domains and the 2nd level domains need to be globally unique. Root BitDNS records are expensive and both the initial fee and the burning fees are network enforced. The main purpose of the root domains is top provide a service to the 2nd level domains. To be accepted by a top-level domain, the fees defined by the top-level domain must be paid to its address. This is enforced.
2nd level domains behave much like BitNames, with two main difference: first, to be used the domain must pay registration fees to at-least one top-level domain. Secondly, IP addresses can be binded to these domains.
Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain. Man-In-The-Middle attacks are very, very, very difficult under this system.
I'm still working on the sub-domain structure.
The proposal that I have made has covered 3 main areas.
First: Changes to the Bitcoin Protocol.
Expanded templates, (allowing to check transactions based upon what they claim to be). This also allows new services to be run within the chain without changing the protocol. Using a strong scripting language it should be possible to make 'plugins' for generators so that they may accept new types of bitcoin transactions.
Transaction Grouping, this allows transactions to be grouped together by template. Clients will only need to download the summary and the hash tree, unless they want more detail.
Burning transactions. This is a new sort of transaction fee that 'burns' over time. It contains two qualities, firstly total number of coins to be to be burnt, and secondly, the rate (per block) that it is burnt at. This is the basis of the compensation to generators for including extra data in the block chain. When the transaction stops burning, the extra data may be deleted.
Second: BitName
BitName is a named address that has a fingerprint of a public certificate. Instead of sending bitcoins to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP, one could send bitcoins to 'da2ce7'. The BitName concept is built upon burning transactions. Each transaction that declares a name, must include a burning transaction to keep the name active. The higher the rate of burning the more likely that the transaction will be accepted. If the rate is too low, the network will likely ignore or forget the name early.
If a generator accepts a new transaction of the same name as a pre-existing, the network will likely orphan the block, unless the burning fee is so low that the network regards the name as spam.
The other significant benefit from having a BitName is public certificate verification, when one sends a message that is signed, the key signing the message can be check against the known name of the source. The fingerprint included in the block chain then can be used to verify the signer.
Third: BitDNS
BitDNS is derived from BitName. A BitName should be used to make any new BitDNS records. This requirement in the future can be used for spam prevention.
Both the top-level root domains and the 2nd level domains need to be globally unique. Root BitDNS records are expensive and both the initial fee and the burning fees are network enforced. The main purpose of the root domains is top provide a service to the 2nd level domains. To be accepted by a top-level domain, the fees defined by the top-level domain must be paid to its address. This is enforced.
2nd level domains behave much like BitNames, with two main difference: first, to be used the domain must pay registration fees to at-least one top-level domain. Secondly, IP addresses can be binded to these domains.
Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain. Man-In-The-Middle attacks are very, very, very difficult under this system.
I'm still working on the sub-domain structure.
Ok! I have written out the proposal, hope you like it... the BitDNS part nees fleshing out. However from what I have written you can get the drift.
http://domainchain.org/wiki/doku.php?id=bitname
oh yeah, thanks to ribuck for the wiki.
http://domainchain.org/wiki/doku.php?id=bitname
oh yeah, thanks to ribuck for the wiki.
I am propose to use a TLD .bit for bitdns
3 letters is better than 6
microsoft.bit
linux.bit
facebook.bit
3 letters is better than 6
microsoft.bit
linux.bit
facebook.bit
Let me throw in a rough outline of a completely different idea, that is not based on the Bitcoin chain.
Suppose the rule is this:
Here's how it would work. If no-one else has registered the name that you want, post a mapping from it to your nameservers, together with a hash that represents some proof of work. Now keep on hashing, and every time you find a stronger proof of work, re-post your claim with the stronger proof attached.
As long as you keep hashing, you will occasionally find a stronger hash, which will strengthen you claim on the name.
If someone else also wants your domain name, they can start hashing but you already have a head start. Of course, they can devote more machines to hashing than you, in which case they may be able to generate a better hash and take over your name.
Of course no-one wants to randomly lose their name because someone else was lucky enough to get a very good hash without really trying, so the rule could be that a hostile takeover requires a proof of work 16 times harder. Also there could be a 30-day delay before the takeover, which gives the existing owner a window to hire a server farm and retain the name if it's worth enough to them.
The end result is very different from our current system, but in the end it allocates every domain name to whoever actually wants it the most.
Suppose the rule is this:
Quote
A domain name registration is a mapping from the domain name to a list of (one or more) name servers that are authoritative for that domain name.
The "owner" of a domain name is whoever posts a mapping with the hardest proof of work attached.
The "owner" of a domain name is whoever posts a mapping with the hardest proof of work attached.
Here's how it would work. If no-one else has registered the name that you want, post a mapping from it to your nameservers, together with a hash that represents some proof of work. Now keep on hashing, and every time you find a stronger proof of work, re-post your claim with the stronger proof attached.
As long as you keep hashing, you will occasionally find a stronger hash, which will strengthen you claim on the name.
If someone else also wants your domain name, they can start hashing but you already have a head start. Of course, they can devote more machines to hashing than you, in which case they may be able to generate a better hash and take over your name.
Of course no-one wants to randomly lose their name because someone else was lucky enough to get a very good hash without really trying, so the rule could be that a hostile takeover requires a proof of work 16 times harder. Also there could be a 30-day delay before the takeover, which gives the existing owner a window to hire a server farm and retain the name if it's worth enough to them.
The end result is very different from our current system, but in the end it allocates every domain name to whoever actually wants it the most.
However I'm still in the process of writing out it more formally.
Feel free to write it up on a new page at the domainchain.org wiki if that's convenient for you:
http://domainchain.org/wiki/doku.php?id=start
I have come up with a solution to most of RHorning issues. However I'm still in the process of writing out it more formally. It is quite a big departure from anything that has been talked on the forum yet. But still (mostly) compatible with the bitcoin architecture.
There are also serious problems outlined by RHorning which need addressing.
The problem with this is that the generators themselves can put hundreds of domain names into their own block. Just like generators can include transactions for free in their own block.
I thought of a possible problem with all these proposals: front-running by miners.
Front-running by miners is a flaw of the current proposals, and it's where I'm stuck. I haven't moved my DomainChain proposal further forward in the past couple of days because I can't solve the front-running problem.
The solution to the front running problem has been solved by Hal in https://bitcointalksearch.org/topic/m.29919
A suitably salted hash of the required name is submitted for inclusion into the chain. After it has been confirmed then the name (and salt) are published and everyone now accepts the new registration.
The essential flaw is that domain registrations are contingent on transaction fees. A miner who generates a block can include a large number of speculative high-value registrations in that block, because the transaction fees don't cost them anything. This might be an intractable problem for any domain name registration system that is based around transaction fees.
I agree that the theymos/nanotube "solution" to this problem is ugly.
There are also serious problems outlined by RHorning which need addressing.
ByteCoin
the 100BTC are 'Killed" as in they are transfered to a "dead bitcoins" key. Then the generators can get to claim an extra 0.01 or whatever on the mined bitcoins. If the generator doesn't claim them, they sit around and accumulate until generator dose. What is happening is that we are removing coins from circulation and allowing people to generate them again.
The only rule is that the coins cannot be 'claimed' faster than the set amount per block. If a generator doesn't claim the coins in one block. The next block can claim two lots of it.
The only rule is that the coins cannot be 'claimed' faster than the set amount per block. If a generator doesn't claim the coins in one block. The next block can claim two lots of it.
Subscriptions solve the front-running problem, but how exactly would they work?
So who is the initial 100 BTC paid to? And how do the extra 0.01 in transaction fees get to the next 10,000 miners? Not by means of 10,000 transactions presumably...
For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC. For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.
So who is the initial 100 BTC paid to? And how do the extra 0.01 in transaction fees get to the next 10,000 miners? Not by means of 10,000 transactions presumably...
There is a very elegant way of solving the front-running problem, but you need to think a little bit creativity
BitDNS should be subscriptions, as you always pay the generators as long as it is active.
When one registers a domain, the registration contains the rate that should be paid, (an on-going transaction fee) and the total amount. When the transaction is included in the block chain. The transaction fee is removed from circulation, and added to every generator at the agreed rate until it runs out. When it runs out, the registration expires as well as the domain.
For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC. For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.
BitDNS should be subscriptions, as you always pay the generators as long as it is active.
When one registers a domain, the registration contains the rate that should be paid, (an on-going transaction fee) and the total amount. When the transaction is included in the block chain. The transaction fee is removed from circulation, and added to every generator at the agreed rate until it runs out. When it runs out, the registration expires as well as the domain.
For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC. For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.
Jump to: