Bitcoin Forum
November 19, 2017, 07:39:10 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [All]
  Print  
Author Topic: BitDNS and Generalizing Bitcoin  (Read 109406 times)
appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
November 15, 2010, 03:02:31 AM
 #1

This is based on a discussion on 11/14/2010 on the IRC channel.

BitDNS

Although there have been attempts to tackle DNS in a distributed way in the past, I don't think there have been solutions that have fully removed authority from the equation.

If there was such a solution, it probably would have been able to implement bitcoin directly on top of it, and we all know that didn't happen.

However, it seems possible to create a bitcoin clone (bitDNS) that provides a solution to distributed authority-free name allocation and transfer.

Basically, the system is a copy of bitcoin where miners generate 50 new name mappings of their choosing whenever they win a block.  The name mappings change hands in a way similar to btc.

This system is separate from btc, and it is likely that escrow services will provide a name market in btc, since any such escrow can leverage the two block chains to verify transactions.  Miners can pick names that are already being bid upon with funds in escrow to make sure they are able to sell generated names quickly.

Generalizing Bitcoin: BitX

This is all well and good, but now there are two block chains, and any given miner can only generate for one at a time.  This will be really bad when even more clever applications are developed that require bitcoin-like properties but will be susceptible to attack in their early development.  Enter BitX, designed to support any and every such application on a single block chain.

BitX has a block chain like bitcoin's.  However, miners choose to distribute arbitrary application data in the following manner:

1) The payload in a block is a mapping from application names to hashes: ["bitcoin": <hash>, "bitDNS": <hash>, "bitHaiku": <hash>, ...]

2) Any given block is only allowed to create one new application that does not already appear somewhere in the block chain.  This is to prevent spam.

3) Any given block may omit data for any application.  Similarly to the current situation, miners have a choice as to what transactions to include, and this extends to the choice over which applications to choose to send data for.

4) Application data is transfered separately, so for instance a bitcoin client will never have to care about haikus or DNS names, as it can simply ask someone for the bitcoin payload and make sure it matches the hash in the appropriate block.

5) On the client side, blocks are only ever rejected for an error relating to the previous four points.  In other words, blocks aren't rejected for carrying a faulty bitcoin payload, because this might result in rejecting valid DNS transfers.  Instead, bitcoin clients accept the most recent block but ignore the invalid bitcoin transactions.

Miners will engage in activities they feel profitable.  For example, miners may not see a profit motive in haikus, but will want to generate DNS names because they can be sold easily.  I think this system could support a very wide range of useful applications while adding only a minimal overhead to the block chain itself.  Application proliferation is kept in check by the interests of the miners themselves.

This also seems to make the block chain more modular, as it separates concerns; the block chain is strictly for creating a universal state of the system for everyone in the world, and application data travels out of band but is verified against the block chain.

One effect of the modularity is that applications can ignore illegal or undesirable application data and only download payloads for the applications they care about.

As a last thought: BitX poses a significant threat to bitcoin, because money may not be the "killer app" for the block chain.  In other words, what happens when bitBeanieBabies becomes bigger than bitcoin?  Suddenly the bitcoin system doesn't seem as secure.  If both were running on top of BitX, they would enhance each other's security, and interfere with one another minimally.

Thanks for reading,
Appamatto
1511077150
Hero Member
*
Offline Offline

Posts: 1511077150

View Profile Personal Message (Offline)

Ignore
1511077150
Reply with quote  #2

1511077150
Report to moderator
1511077150
Hero Member
*
Offline Offline

Posts: 1511077150

View Profile Personal Message (Offline)

Ignore
1511077150
Reply with quote  #2

1511077150
Report to moderator
1511077150
Hero Member
*
Offline Offline

Posts: 1511077150

View Profile Personal Message (Offline)

Ignore
1511077150
Reply with quote  #2

1511077150
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511077150
Hero Member
*
Offline Offline

Posts: 1511077150

View Profile Personal Message (Offline)

Ignore
1511077150
Reply with quote  #2

1511077150
Report to moderator
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
November 15, 2010, 08:40:32 PM
 #2

Just for reference, the discussion on IRC starts here http://bit.ly/9qjLL5

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 15, 2010, 11:43:45 PM
 #3

So....

I want to register a new domain name "gavin.bitdns" in this hypothetical bitdns system.

How do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!

Or I want to buy a domain from somebody; what does that look like in the bitdns system?

How often do you get the chance to work on a potentially world-changing project?
appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
November 16, 2010, 03:06:26 AM
 #4

So....

I want to register a new domain name "gavin.bitdns" in this hypothetical bitdns system.

How do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!

Or I want to buy a domain from somebody; what does that look like in the bitdns system?


It's pretty much the same as starting a separate service.  You have to convince a few people to use your system.

But in this case, there are some incentives for a BitX miner to adopt your new BitX app (in this case, bitDNS).

For one, it doesn't impact the miner's mining speed.  And he would end up with a possibly valuable resource in the form of a very big head start on bitDNS registrations.

Consider the case in which there are 5 big BitX miners that each control large processing pools.  They each generate 20% of bitcoins (which is now running on the BitX protocol) yet the first one to generate bitDNS names would generate 100% of names until the second adopted bitDNS as well, and this would be at no cost to him.

In the case of buying a name, you need an escrow that will temporarily hold the btc and the name until they are both confirmed, and then pass them along to the new owners.  I think it's best to keep btc and dns completely separate so that they can succeed or fail independently yet leverage the single block chain.
appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
November 16, 2010, 03:39:14 AM
 #5

I thought about the BitX block format more today, and (with the help of ByteCoin on irc) decided that block rejection is an important part of the system.  So, the format would work more or less like the following:

<previous block hash>
<timestamp>

<hash of app name> <hash of app data> <previous app block offset>
<hash of app name> ....

<nonce>

Basically, there is the BitX block chain which is maintained in the first field.  But there are also "subchains" for each app.  The "previous app block offset" is the number of blocks to travel backwards in the chain to find the last previous block for this app.

Omitting some details, a Bitcoin fork would appear as follows, inside a non-forked BitX chain:

block 0:
<empty, this is the genesis block>
(bitcoin) datahash... 0

A previous app block offset of zero indicates that this is a genesis block for that app.  Each BitX block is only allowed to specify a genesis block for one app.

block 1:
<hash of block 0>
(bitcoin) datahash... 1

This is a continuation of the last BitX block and it also claims to be a successor of the previous block's bitcoin chain.

block 2:
<hash of block 1>
<empty>

It's perfectly legit for any given application to not appear in a block.

block 3:
<hash of block 2>
(bitcoin) datahash... 3

This is a continuation of the BitX chain, but it has rejected the previous bitcoin block.  Clients will now have to accept one bitcoin app block and reject the other, but there is no reason to reject the BitX block.  The rejected bitcoin app block will stay in the BitX block chain, but it will not be part of the longest valid bitcoin block chain.
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
November 16, 2010, 06:53:15 AM
 #6

Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
November 16, 2010, 02:53:05 PM
 #7

Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.

I think that's exactly what I'm suggesting.  BitX is a block chain service (not sure how this differs from 'p2p proof of work') that supports arbitrary applications, such as bitcoin, bitDNS, ...
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
November 16, 2010, 05:45:11 PM
 #8

So now the question is what kinds of central authorities can be replaced by this type of quorum?

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
ByteCoin
Sr. Member
****
Offline Offline

Activity: 416


View Profile
November 18, 2010, 05:14:20 AM
 #9

I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.

There would have to be some incentive to support an app in this way. Some form of payment.... hmmm

ByteCoin
appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
November 18, 2010, 06:28:58 AM
 #10

ByteCoin, I think you can just keep a pointer to the last valid block per app in the big block chain.

So, when you mined, you would produce new app data for each app you cared about and stick the hash of that data as well as pointer to the previous vaild app block (per app you care about) into the big block chain.

In other words, the big chain has a next pointer to the last valid big block, as well as a next pointer to each last valid app block you care about.  So, if you think there was an invalid app block, you can still add to the longest big block chain and reject the invalid app block by pointing further back in the chain to the last valid (in your view) app block.

You don't have to know about every app in this case.  This plan still retains the bonus that miners can mine for as many apps as they want.
asdf
Hero Member
*****
Offline Offline

Activity: 527


View Profile
November 18, 2010, 06:38:26 AM
 #11

I didn't read the thread, but you might be interested in the Netsukuku solution to distributed dns:
http://en.wikipedia.org/wiki/Netsukuku#A_Netsukuku_Domain_Name_Architecture

Netsukuku:
http://netsukuku.freaknet.org/
Anonymous
Guest

November 30, 2010, 12:54:41 PM
 #12

http://p2pdns.baywords.com/2010/11/30/hello-world/

I just found this from Peter Sunde who wants to create a decentralized dns system.

gekko
Newbie
*
Offline Offline

Activity: 3


View Profile
November 30, 2010, 06:01:02 PM
 #13

A lot of collaboration on a decentralized DNS by the bittorrent community is occurring here:

http://dot-p2p.org/index.php?title=Main_Page

The brainstorming session is here. BitDNS/Bitcoin could provide them with a lot of the source code needed:

http://dns-p2p.openpad.me/1
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
November 30, 2010, 06:06:37 PM
 #14

Quick! Offer a bounty in bitcoin!

sandos
Full Member
***
Offline Offline

Activity: 183


★ BitClave ICO: 08/11/17 ★


View Profile
December 01, 2010, 08:26:14 AM
 #15

If you just allow any number of applications "on top" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!

Maybe make it a tad bit hard to add applications?

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 01, 2010, 05:27:05 PM
 #16

If you just allow any number of applications "on top" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!

Maybe make it a tad bit hard to add applications?

Hmm? I thought we're going to use a separate blockchain than what bitcoin use.

bober182
Full Member
***
Offline Offline

Activity: 196


★ BitClave ICO: 08/11/17 ★


View Profile
December 02, 2010, 12:22:26 AM
 #17

I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Page
http://wiki.opennicproject.org/dotP2PTLD

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 12:25:25 AM
 #18

I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Page
http://wiki.opennicproject.org/dotP2PTLD

Calling something retard and having no substance to back it up is not a good argument.

tyler
Jr. Member
*
Offline Offline

Activity: 56



View Profile
December 02, 2010, 12:30:56 AM
 #19

I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Page
http://wiki.opennicproject.org/dotP2PTLD

Calling something retard and having no substance to back it up is not a good argument.

retarded means "slowed" which ironically is the case here

[ Public Key: http://pdxbrain.com/pubkey.rsa ] [ Donations: 1DGfqRVeoFHyZnTTtCrufNByrcdpgUuQ2K ] [ IRC: tylergillies ] [ Support Project Daemon ]

Agora, Anarchy, Action!
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 12:41:05 AM
 #20


retarded means "slowed" which ironically is the case here

Huh

tyler
Jr. Member
*
Offline Offline

Activity: 56



View Profile
December 02, 2010, 12:51:53 AM
 #21


retarded means "slowed" which ironically is the case here

Huh

retard - cause to move more slowly or operate at a slower rate; "This drug will retard your heart rate"

meaning... using a bitcoin based dns will be slow to adopt

[ Public Key: http://pdxbrain.com/pubkey.rsa ] [ Donations: 1DGfqRVeoFHyZnTTtCrufNByrcdpgUuQ2K ] [ IRC: tylergillies ] [ Support Project Daemon ]

Agora, Anarchy, Action!
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 01:22:43 AM
 #22

retard - cause to move more slowly or operate at a slower rate; "This drug will retard your heart rate"

meaning... using a bitcoin based dns will be slow to adopt

Not really. Since, 144 blocks were generated each day in the bitcoin network, this mean 7200 addresses that can be assigned a domain name. Plenty, if you asked me.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 03:03:16 AM
 #23

I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.

There would have to be some incentive to support an app in this way. Some form of payment.... hmmm

ByteCoin

It is funny how people are thinking about the same issue at the same time.  I have been trying to think of some way that another "chain" using Bitcoin principles of hashing might be able to use Bitcoins as a transaction fee:

http://bitcointalk.org/index.php?topic=2028.0

The issue here is that you would need some way for those "mining" new blocks into this sort of DNS data block chain (or any other kind of similar data protected by a hash chain with miners) to receive some sort of transaction fee for processing that chain.  In this case, the incentive for processing the DNS entries would be to receive these transactions fees.... which could be quite considerable depending on what people would be willing to pay for a domain name under this system.

I have considered perhaps an alternative, which would have the main Bitcoin miners of the main chain have as "optional" transactions to be processing in such a way that could let the miner itself keep these transaction fees.  My main objection to doing that is that it puts far too much processing into miners and makes a bottleneck that I think we would all rather not have.  Bitcoin miners ought to be for bitcoin transactions alone, but it is at least something to consider.

This thread I mention here goes into the technical details, but it is something that could help with this idea too.  I haven't completely "solved" the problem, but I have at least identified what issues need to be solved.

Besides, it would be nice if there were other ways for those interested in using Bitcoins to be able to earn them since the main mining of coins is now being locked up with with stronger computers and GPU miners of various kind including server farms.

The one advantage here of using a fee is to avoid a tragedy of the commons, where those who want to register a domain or transfer "ownership" of that domain would have to put up real money to do so.  The fees don't go to some central processing bureau or organization, but rather to those who are doing the real work, which is processing the actual domain registrations itself.
Anonymous
Guest

December 02, 2010, 04:50:00 AM
 #24

I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Page
http://wiki.opennicproject.org/dotP2PTLD

Bitcoin would be more for buying and selling domains I think. Any profits involved could go to the EFF which already accepts bitcoin donations. In a sense this would tie dns and domain names to the health of the EFF.

 Smiley  Id like to see the government try and seize domains from those guys ,can you imagine the shitstorm that would create  Cheesy

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 05:00:50 AM
 #25

How would domain name renewal work?  Huh

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 05:36:46 AM
 #26

How would domain name renewal work?  Huh

Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 06:33:27 AM
 #27

Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.

I see. Then the miners will set the fee for domain renewal.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 03:29:31 PM
 #28

Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.

I see. Then the miners will set the fee for domain renewal.

Exactly!  It would become a marketplace where those people willing to put resources into building this chain would set the fee they think is most appropriate.  I really don't see this happening without fees getting put in at some point.

This is also something where deflation would be dealt with through the marketplace as well, as there would be increased competition if transaction fees started to get a little high where somebody offering to take on perhaps slightly lower transaction fees would push their way into the block making competition.  So if 0.01 BTC becomes worth $100, there might even be many "miners" willing to charge perhaps only 0.001 BTC or an even smaller amount.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 02, 2010, 05:16:23 PM
 #29

I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.

The fees could come from domain name transfers, and of course the generation of new domain names.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 05:21:15 PM
 #30

I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.

The fees could come from domain name transfers, and of course the generation of new domain names.

If someone lost their wallet, their domain name stay with them forever, with no way to transfer it.

Eventually, you get a long string of really good domain name that can't be used forever.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 02, 2010, 05:30:22 PM
 #31

Eventually, you get a long string of really good domain name that can't be used forever.
It's the same as with bitcoins, it just makes the remaining names more valuable.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 05:33:20 PM
 #32

It's the same as with bitcoins, it just makes the remaining names more valuable.

if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.

It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 02, 2010, 05:49:35 PM
 #33

...if sex.bitcoin is lost ... It doesn't necessary make other domain names more valuable
The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.

I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 05:52:22 PM
 #34

The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.

I concede that one.
Quote
I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.
Then this is a matter of competition between various BitDNS system then.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 05:54:45 PM
 #35

It's the same as with bitcoins, it just makes the remaining names more valuable.

if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.

It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.

In theory you could also put a "lease" on that domain so that after a certain period of time defined within the network protocol the lease would expire.  In this case, if somebody "lost" their wallet the domain could become available after the lease expires.  It wouldn't necessarily make the domain worthless either, as the IP address associated with the domain would still be valid, and the domain would still resolve even after the wallet was lost, but if there was an issue where the person owning the domain switched to another network (and a different IP address) it could be a bit of a problem.

None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or "steal" a domain.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 05:56:31 PM
 #36

None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or "steal" a domain.

Can you please explain what you mean by this?

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 06:05:53 PM
 #37

None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or "steal" a domain.

Can you please explain what you mean by this?

What do you need explained?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 02, 2010, 06:06:53 PM
 #38


What do you need explained?

Why is it so easy? How is it done?

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 02, 2010, 06:46:01 PM
 #39


What do you need explained?

Why is it so easy? How is it done?

It depends on the domain registrar and a few other factors.  Back when ICANN ran domain registrations directly, all you needed to do was to simply spoof the e-mail address of the person who made the registration and change the contact information... hoping that the reply from ICANN would get lost in the junk mail with spam and other garbage.  Once you switched the contact information, switching almost everything else was incredibly trivial and a piece of cake.

It is a bit harder now and the domain registrars do require a bit more identifying information, but nothing that a good private investigator would be unable to provide.  Really, the current domain registration is incredibly insecure and there are even "legal" means to "steal domains" that merely need a pretty competent attorney to cover your back if you want to do it through the judicial system.  That is how nissan.com was taken from a small business in southern California in spite of the fact that the last name of the guy really was "Nissan" running a used car business with the name "Nissan Motors" and registered the domain well before the perhaps more famous automobile company got the domain changed.

On top of that, the DNS system itself is very much open to attack as long as you can somehow get trusted as a "peer" by one of the main root servers.  There are various kinds of attacks upon DNS records themselves which can be done, some easier than others and some of them requiring better knowledge about computer networking than others, although there are some "kiddie scripts" and "hackerwarez" that you can get to do all of this is you really want to.  I'd strongly suggest staying away from those program mainly because they are trojan and virus sources if you try to just Google for them.  In other words a good way to get your system rooted and part of a bot net not under your control if that is your goal.  If you want to go the hacker route, learning about the protocol itself and sticking to discussion groups is a much better route to go.

None of this is new to somebody who is familiar with the DNS system, and it really is just a house of cards much flimsier than what anybody can possibly believe if you aren't familiar with how it was all set up in the first place.

My point is that using a simple sort of cryptographic storage for the registration of the information is vastly more secure in terms of making sure the information doesn't get tampered with or manipulated that the current system.  Even DNSSEC, the supposed "savior" of the DNS system to keep spoofing from happening (and largely unimplemented by most ISPs unfortunately even for that level of security) is only as good as the domain registrar's security.  Social hacking can still happen.

It is for this reason that I think a bitcoin-related system would work much better and be insanely simple to operate.  On top of that, there would be no gatekeeper in terms of who gets authority to decide if you get the registration.  You simply apply, throw in the fees for processing the application, and the domain registration gets put into the system.

In terms of the "leasing" option, the only advantage of doing that which I can see is to make sure that the domain itself remains in the "public domain" at some point.  Domain registration is a public service and unfortuantely there are people who have taken domain registrations as a sort of "land grab" where the earliest get the best stuff first.  By putting a leasing ability into the standard (and the "lease" is from all of mankind, not any individual), it forces those who grabbed the domains early on to do some "work" or at least pay up to maintain those leases.  Presumably if maintaining those domains is expensive, they'll simply let them expire rather than having to constantly renew the domains.  It also provides a source of revenue for those who are mining blocks as well so it also maintains the integrity of the database... in other words the chain of blocks being used to keep track of all of this information.
bober182
Full Member
***
Offline Offline

Activity: 196


★ BitClave ICO: 08/11/17 ★


View Profile
December 02, 2010, 11:10:14 PM
 #40

Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 03, 2010, 05:56:41 AM
 #41

Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.

I don't have a problem with somebody "renewing" their lease in some manner where they have at least "first try" at keeping that lease.  The "public good" coming from paying the lease fees is maintaining the network.

I don't understand this "sending it to yourself" however.  The domain registration would be something confirmed by a network.  If you were mining these blocks, you might get lucky and mine the block you are also using to register a domain, but perhaps you wouldn't be doing that either.
bober182
Full Member
***
Offline Offline

Activity: 196


★ BitClave ICO: 08/11/17 ★


View Profile
December 03, 2010, 11:25:39 PM
 #42

Its like bitcoins but time based old domains get freed up after 365 days, if you want to keep it just send it to someone or to yourself.

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 04, 2010, 09:01:48 AM
 #43

Quote from: irc
<genjix> dot-p2p: "We currently believe the best way to create a stable
    environment for TLDs is to enact a central authority. We know this
    will cause much argument within the community, but we have made the
    decision that we believe will be best for the continued development
    of this project."

Knew it. They sucks.

Our opportunity is now, but unfortunately I think we lack the expertise to create a BitDNS.

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 04, 2010, 09:13:32 AM
 #44

http://bitcointalk.org/index.php?topic=2072.0

Started a pledge drive. Go. Go. Go.

Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 04, 2010, 07:47:51 PM
 #45

Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.

A domain name entry in this system has 3 parts:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)

When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.

Subsequently a name might have two things happen to it:
 - the IP address of the DNS server might change
 - it might be transferred to a new owner

Both of these might be handled the same way, via a BitDNS transaction. The transaction would contain:
 - the domain name
 - the new owner key hash
 - the new IP address of the DNS server
And it would be signed by the old owner private key.

As with Bitcoin, transactions would be broadcast and incorporated into the next block by miners.

Is this what people have in mind?

Hal Finney
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 04, 2010, 08:22:14 PM
 #46

That's very clearly expressed, thank you Hal.

What you describe is almost exactly what I have in mind. Additionally, I would allow the domain name itself to be subsequently changed to any other untaken name:

Quote
Subsequently a registration might have three things happen to it:
 - the IP address of the DNS server might change
 - it might be transferred to a new owner
 - the domain name might be changed

The advantage of allowing domain name changes is that it makes the initial registration easier. Registrars can generate arbitrary registrations, then change the name when they sell them to their customers.

Quote
When you generate a block you get to create 50 of these entries

Exactly. The "50" is arbitrary, but that doesn't matter. The initial scarcity will be reflected in a high price, which will encourage people to generate, which will raise the difficulty and ensure the security of the system.

With 7200 registrations being generated daily, there will soon be plenty to meet the demand. The price will then drop, with transaction fees maintaining the incentive to generate.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 04, 2010, 08:44:11 PM
 #47

Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.

A domain name entry in this system has 3 parts:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)

When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.

I hope we aren't at cross purposes here as there are multiple ideas.  My idea was more that you would throw in a "transaction" that would have a few bitcoins attached (as the transaction fee) so that any potential miner would be encouraged to put that particular "registration" into a block chain like the Bitcoin mining blocks.  The "owner" is merely the person who paid the fee and is identified by a private/public hash like the Bitcoin addresses are being used right now.  In fact, I would propose that the "owner" of a particular domain might as well be a Bitcoin address unless we can think of a more secure way of claiming such ownership.... which would be of value to the Bitcoin project if you can show it would be unsecure.  It is tying the domain ownership to your wallet.dat file making your wallet even more valuable if you got one of these domains.  The actual hash is irrelevant other than it should be defined in the protocol.

A block would have a limited number of "transactions" in it... perhaps just 1 but it could be 50 or slightly more.  I don't mind putting a limit at 50 per block in the sense that it might drive up the value of an individual domain and set up some interesting economic theories so far as supply and demand are concerned.  That is a network rule to define in this case.  Obviously a miner could create one of these "domains records" for "free", but then again they are contributing to defending the integrity of the database through CPU proof of work.

So really a domain entry would be:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - an optional key which could identify a "new" owner in the case of somebody transferring control of the domain
 - the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)
 - transaction fee paid in BTC

A block entry would also have a timestamp that could be rejected if it was for some time in the future

As a network rule any name collisions that can't be resolved as from the same person making a request for changes would be rejected.  The cost to run this network would be through the transaction fees, where a "miner" may be as inclusive or selective as they care based upon the transaction fees involved.  Miners might have a different fee schedule for "new" domains as opposed to existing domains and could discriminate on that basis... or simply only select to process one kind or another.  All of this would be essentially a marketplace where those trying to "register" domains are playing chicken with those making the blocks, presumably with the miners wanting higher fees and those registering domains wanting lower fees.  My bet is that domain registration fees would be considerably lower than what GoDaddy charges or for that matter any other domain registrar other than those who simply do it for free.  Maintaining the DNS records does have a cost, which is the purpose of the transaction fee as well.

The only glitch here that I can see is trying to get those transaction fees to the miner.  The miner needs to be able to demonstrate proof of work before they get paid, and presumably that the proof involved has generally been accepted into the network before they get paid as well.  Otherwise, all I can see is that people are being altruistic and simply mining as a free public good.... which has problems related to a tragedy of the commons as well.  I personally think that you should "pay your own freight" for things like this.  Besides, it provides another way for people to earn bitcoins simply by leaving their computer running if you can get the transaction fees for running such a DNS mining application processing these records.

BTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:

http://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1

I'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this.  It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try.  Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 04, 2010, 08:50:00 PM
 #48

ames. Of course they have to be new names that were not in earlier blocks.

BTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:

http://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1

I'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this.  It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try.  Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.

I am using this document as the BitDNS bounty's protocol document.

Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 04, 2010, 10:25:01 PM
 #49

So really a domain entry would be:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - an optional key which could identify a "new" owner in the case of somebody transferring control of the domain
 - the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)
 - transaction fee paid in BTC

A block entry would also have a timestamp that could be rejected if it was for some time in the future.

I see, that makes sense. I have an idea about the transaction fee. What if this were integrated with Bitcoin itself? This would be a different kind of transaction that would be mixed with regular Bitcoin transactions and included in regular Bitcoin blocks. Then the block creator would automatically receive the transaction fee just like all the other tx fees in the block.

If that sounds good, I see a way this could be implemented into the current Bitcoin system compatibly with current clients. We could use the mysterious and extravagant "scripting" system to add additional data to regular Bitcoin transactions. These would look like NOPs to current clients and be ignored, but BitDNS aware clients would look inside this NOP block and see the extra DNS data, and interpret it as BitDNS transfers.

Specifically i could imagine using OP_NOP1 to mean BitDNS, then OP_PUSHDATA to push the DNS info, then OP_DROP to drop it from the stack, followed by the regular tx opcodes. This will have no effect on regular clients and look like a regular transaction (can be a dummy tx, 0.01 to yourself) but BitDNS aware code sees a BitDNS transaction. This is actually a powerful general technique for adding overlay protocols to Bitcoin.


Hal Finney
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
December 05, 2010, 01:31:31 AM
 #50

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 01:36:09 AM
 #51

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

People already put up links about BitDNS.

Anonymous
Guest

December 05, 2010, 05:12:07 AM
 #52

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

Several bitcoiners have been in the p2p-dns irc chat and have spoken about it.

Its also been written about on their wiki.

http://dot-p2p.org/index.php?title=Draft_Discussion_Paper  they have a discussion paper out but looks like they have opted for using open nic for now plus a .key domain for a decentralized dns.

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 05:14:36 AM
 #53


As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

A domain name key should be so important that people will backing it up, automatically.

Anonymous
Guest

December 05, 2010, 05:23:50 AM
 #54

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

People already put up links about BitDNS.


I added bitdns to the ideas page here
http://dot-p2p.org/index.php?title=Ideas#BITDNS

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 07:33:17 AM
 #55


I added bitdns to the ideas page here
http://dot-p2p.org/index.php?title=Ideas#BITDNS



The likelyhood of the idea getting implemented is likely slim to none.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 05, 2010, 11:07:46 AM
 #56

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

I think this is a good argument against almost any peer-to-peer distributed database of any kind.  This isn't something unique to just Bitcoin.

All of this is sort of strange, as I thought the whole point of the exercise was to try and decentralize the DNS database.  Instead, there is going to be a central point of control for the whole thing and an official "authority" who is going to be acting as a gatekeeper.  Really, this seems to be a betrayal of whatever it is that they were trying to accomplish and they are now becoming an alternate to ICANN, not something which is really a genuine distributed domain repository.  There may be some differences as it may become a sort of Napster of domain registration, but it still has that point of attack, whatever that attack may be from either a digital, legal, or physical kind of attack.

It is too bad that they aren't rethinking the entire issue down to its roots, which is an attempt to create a "directory" of the internet.  They are also getting IMHO hyper-paranoid about trademarks, as if coca-cola.com isn't sufficient to identify a particular corporation that most people know anyway.  So what if somebody creates coca-cola.p2p?  Or for that matter wikipedia.p2p?

There also seems to be a mindset that it must follow the convention of:

<computer> <dot> <domain> <dot> <top level domain>

There was an historical reason for the original divisions for .com, .mil, and .edu.  They represented three distinct and separate networks originally called "COM-NET", "MIL-NET", and "EDU-NET".  It is sort of like how telephone systems used to be completely separated between business exchanges and residential exchanges.  When the three networks were finally linked, they had to use some way to identify how to access computers on one network to another, so the "TLD" system was originally set up and some other side "TLDs" were made for "miscellaneous organizations" (.org), "international organizations" (.int), and generic "network resources" (.net).  When people outside of America were participating in adding their networks to the internet, they were identified by their country code , now the various "country code top level domains".

Mind you, when the codes were handed out, there was the .us domain which seemed redundant (it was) but those already having .com didn't want to go to a longer .com.us.

Anyway, I contend that the whole notion here of a top level domain is something that completely unnecessary, and that viewpoint has been long advocated by Karl Auerbach.  If you've never heard of this guy, it should be important that he was the one and unfortunately only official elected representative of North America to ICANN, and sort of a major rebel.  He was one of the "at-large" directors that had to get a California court to force ICANN to actually show him their books (he was one of the members of their board of directors and supposedly recognized as such by the organization) and because of his efforts his position was dissolved by the appointed board members made up of people hand-picked by major corporations.  The whole experiment of democratically elected representatives to ICANN was killed by the U.S. Department of Commerce... isn't that something?

Anyway, if anybody knows DNS backward and forward, it is Karl Auerbach, and one of his positions when he was on the ICANN board was that there was no need to even have a top-level domain system at all, and certainly the number of top level domains could certainly number in the millions or more.  It is simply a directory.

This history paper about DNS goes into the gritty details of how it finally got started.  This really is a seminal paper on the history of DNS in terms of how we got to where we are today.

Another paper by Karl Auerbach is certainly worth reading so far as to see what a very well thought out objection to the current DNS system as implemented by ICANN was and how when the whole system was created had people proposing some significant alternatives.  Since supposedly we are talking about alternatives to the centralized DNS, I think this ought to be at least one of the key papers worth reading.  It shouldn't be surprising that the problems he identified over twenty years ago are still present in the current system, and it is important to note that there was opposition back then even to the current system.  If you read between the lines, he was even upset over how IP addresses were allocated... which is a completely different beast altogether.

I don't think that those working with this new "dot P2P" effort are really reading stuff of this nature.  I find it too bad as well, as it shows the immoral and arguably illegal actions taken by those who set up the current system almost as if it was a sort of Jekyll Island episode of the Internet.  There are a whole bunch of common parallel themes between the formation of ICANN and the Federal Reserve.  In this sense, perhaps Bitcoin really is a good fit as it sort of is a merger of the two systems that have been corrupted by aristocrats in a supposedly egalitarian and "officially" classless society.

In short, I think that the "dot P2P" effort is doomed to failure if the continue down the path they are going and not addressing the real problems facing the current system.  Many of those problems are being addressed by BitDNS, even if it is a bit marginalized at the moment.  And I also think that the argument about lost keys is not something nearly as significant either compared to the major issues about what is wrong with the current DNS system.
balboah
Newbie
*
Offline Offline

Activity: 17


View Profile
December 05, 2010, 11:27:58 AM
 #57

There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.

Check out http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/
and http://dot-p2p.org/
Anonymous
Guest

December 05, 2010, 12:36:58 PM
 #58

There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.

Check out http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/
and http://dot-p2p.org/


Yes that is what we are discussing. I was in the irc chatroom while all of it was being discussed. I brought up bitcoin several times but was scoffed at,as did someone else. As usual people dont learn from the mistakes of the past and are bent on creating a mirror of ICANN. All I can say is WTF?

I even saw one guy mention how he worked on an email system for the NSA ! and no one even asked the obvious question about someone from  the NSA steering the discussions towards a centralised system.


I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 05, 2010, 02:02:07 PM
 #59

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

If you lose the keys, you can no longer sell the domain name or change the IP address of its DNS, but the domain name itself doesn't immediately stop working. So you have plenty of time to choose a new domain name, set it up, and install redirects from your existing site.

You can protect against this by leaving a copy of your keys with a couple of trusted people. That's a much better solution than leaving your domain name hostage to an untrusted registrar.

In the 1990s, Turkmenistan was selling .tm domain names and I registered one. After a couple of years, the Turkmenistan government decided there were .tm websites they didn't like and they removed access to the domain name. But there was plenty of time to get a new domain and install redirects. It worked just fine.

Ultimately, a name is just a name and it's not the end of the world if one is lost. Even cocacola.com could switch to cocacola2.com and it wouldn't be the end of the world.

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 04:57:59 PM
 #60


I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.

Why it is only 40 BTC at this stage is beyond me.

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 05, 2010, 06:09:00 PM
 #61


I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.

Why it is only 40 BTC at this stage is beyond me.

Where do I pledge?

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 05, 2010, 06:18:24 PM
 #62

Where do I pledge?

http://bitcointalk.org/index.php?topic=2072.0
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 08:43:13 PM
 #63

Best way to get the BitDNS system running off the ground?

Adapt the bitcoin source code?

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 05, 2010, 09:18:14 PM
 #64

Quote from: irc
<genjix> dot-p2p: "We currently believe the best way to create a stable environment for TLDs is to enact a central authority...

Knew it. They sucks.

They are responding to a problem caused by a central authority by enacting ... another central authority. But I don't think it's because "they sucks". I think it's because they haven't been exposed to such a beautiful decentralised design as bitcoin.

Quote from: kiba
Best way to get the BitDNS system running off the ground?

Adapt the bitcoin source code?

Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 09:31:22 PM
 #65


Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.

Ribuck, If only I have the necessary knowledge to adapt it, I would have dropped it and just implement it.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 05, 2010, 10:12:27 PM
 #66

Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.

What kind of time-frame are we talking about here in terms of getting at least a "proof of concept" project going?

If it took a year, it seems like something else would be taking its place, but if we got some software up and going in the next month or two it seems like the "distributed DNS" supporters might really pay attention to BitDNS.  Indeed, with the philosophies of Bitcoin already established, I don't think there is nearly as much "debugging" to get this going as it may seem.  Some, yes. But it isn't the end of the world.  Getting something done by tomorrow may be a bit more difficult.

The time frame of this idea is something that I believe has a short time span to at least get something to the table, even if there might be some competing ideas.  The strengths of using Bitcoins and a Bitcoin-like system are things that solve many of the problems being proposed from what I've seen.

Writing up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 10:17:14 PM
 #67

Speed is of the essence if we're going to show .p2p how to really do distributed DNS.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 05, 2010, 10:33:30 PM
 #68

What kind of time-frame are we talking about here in terms of getting at least a "proof of concept" project going?

I think this schedule may be possible:

1. Two weeks: Prepare, agree and release three documents: an overview in non-technical language, a FAQ, and a technical but informal white paper which expounds the motivation and the design principles.

2. Three months: Demonstrate a "proof of concept" on a test network.

3. Six months: Release a basic but usable version 0.1.

(4. Generate some names while the difficulty is low.
5. Profit!)

Writing up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.

I will start on the documents. I would rather be programming too, but as kiba says: time is of the essence. This is an idea whose time has come. We can't get this done with just RHorning, kiba and me. We have to build a team. And a set of basic documents serves two important purposes: it attracts newcomers to the team, and it helps to keep the whole team working towards the same goal.

Here are some early tasks that fall on the "non-documentation" side, in case you or anyone else is interested.

* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using "BitDNS", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the ".org" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 10:40:35 PM
 #69

* Set up the development environment. Are we going to use SourceForge? GitHub?

Github and git. I like. It's distributed version control system. Any developer can fork the project and continue on their own implementation and they can request pulls as necessary.

Also remember, everything is in version control. If you messed up the code, it's not a big deal. Just revert to the last state. Remember to commit as well push often too.

chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 05, 2010, 10:43:58 PM
 #70

I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic "use value" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that "problem."  This is exciting!
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 05, 2010, 10:45:21 PM
 #71

I would like to be looped into this project.

By all means, pledge some bitcoins if you can't code, or do anything. I can't do any of the real important stuff, but I can show that I am serious.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 05, 2010, 11:17:03 PM
 #72


Here are some early tasks that fall on the "non-documentation" side, in case you or anyone else is interested.

* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using "BitDNS", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the ".org" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.

For the source repository, I am agnostic toward that as long as I can get the source files in and out.  SourceForge has been pretty good to me in the past and it has worked out with other projects I've been involved with, so I sort of lean that way although it appears Kiba love Git.  I'm fine with that too.

As for a project name, how about DomainCoins?  Otherwise I love more obscure ancient dieties/demigods as names and there are a few out there.  I guess the choice here is one that is more functional or one that can be memorable.  Does anybody know a name of some ancient diety of finance or accounting?  Babylonian and Aztec gods would be especially interesting.  Either that or simply a whimsical name that may not mean anything at all.

For a build process, I'm not really particular either but I do insist upon "free" or "open source" tool chains.  I personally am not a big fan of C++ (sort of antagonist about the language) but I'll contribute however anybody else wants to go.  I agree that it should be built on all of those platforms and be capable of going to more.  I have a stronger preference to C# on Mono if that matters any where MonoDevelop is a pretty good environment.

In term of reading up and understanding the Bitcoin source code.... I'm way ahead of you there.  I've been pounding my head against that for awhile now.  There still is more to pour through, but I'm finally starting to get a good grasp of the base network layer now even if some of the details like the block rejection rules aren't quite so firm yet.  Expanding the documentation would be still beneficial.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 05, 2010, 11:54:55 PM
 #73

I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic "use value" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that "problem."  This is exciting!

There still are some technical challenges here that I am not completely sure how to solve.  In this regard, all of the help we can get will be appreciated and there will certainly be some "heavy lifting" where I think there can be some good division of labor in terms of separate parts that can be worked on.

Major areas will include:

* GUI design - coming up with the visual appearance and organization for the project.  Most GUI design is simply awful, and it is something I've struggled with over the course of decades and still don't get done very well.
* Networking communication - How the client will communicate with other nodes?  Even that is something which can be sub-divided after a fashion, but it will be a crucial piece.
* Database organization and communication - Even choosing a database route isn't going to be easy, either from a "roll your own" to something like MySQL or BerkleyDB.  Potentially this is something which could get into the terabyte range for storage requirements, so we do need to be careful on some of the decisions we make here.
* DNS communication - ideally what should happen is that the client would become a source of domain information that could be referenced with other DNS records.  For a home office/small business this could be on the same computer but for some businesses or schools they could even put this in their server room as a part of the main domain resolver path for their network.
* Interfacing with the Bitcoin network - How will the usage of this software connect to the Bitcoin network, transfer payments from "registrants" to "registrars" (aka "miners"), and what is a "fair" way to make sure that the people receiving money are going to be paid?
* Thin client design - How can you set up something that would retrieve the "database" yet not be a miner?  Is this even an issue?

Non technical issues include:

* Establishing Problem Domain - just what is it that this software needs to accomplish?  Who would use it and why?  What is it that they need?
* Potential Social Conflicts - What sort of "legal" requirements might there be for "domain registrations" and what do we do about them?  Do we care?  Even if we ignore the law in this case, what would most network users expect from a domain registration?
* Marketing - How do we sell this software so far as to get people to use it?  How can publicity be spread about it once it becomes available.  What sort of outlets are there which might be interested in using this.  If we told a business they could run a domain server and make money (by "mining" registration applications) simply by having it in their server room, would that be something they might adopt?
* Finding "customers" for domain registration - This is more to the marketing, but with a concentration on just those who might want to use domain registration.  Some of this is also going to be an issue in terms of breadth of the adoption of the concept, but what groups might be interested in using this as registration?  Obviously bitcoin users would be an early adopter, but anybody else?

Some of these have some "milestones" that must be met before other things can happen, but at the same time there are things which can be done simultaneously.  Any other ideas for things that might be facing this in terms of a breakdown of tasks?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 12:00:39 AM
 #74

* Potential Social Conflicts - What sort of "legal" requirements might there be for "domain registrations" and what do we do about them?  Do we care?

When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 06, 2010, 11:45:43 AM
 #75

When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
Kiba is wise.
Anonymous
Guest

December 06, 2010, 11:53:37 AM
 #76

I suggest tahoe lafs if you are looking for a database for storage.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 01:12:33 PM
 #77

I suggest tahoe lafs if you are looking for a database for storage.

Remember, speed is of the essence. We can alway replace the database with something else, but not time.

All non-essential features should be blocked from implementation focus.

That mean the core developers don't work on a fancy GUI. They will focus on:

1. The mechanism to mine, register, and change a domain name.

2. The mechanism to distribute or output the DNS database.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 04:17:38 PM
 #78

I suggest tahoe lafs if you are looking for a database for storage.

Remember, speed is of the essence. We can alway replace the database with something else, but not time.

All non-essential features should be blocked from implementation focus.

That mean the core developers don't work on a fancy GUI. They will focus on:

1. The mechanism to mine, register, and change a domain name.

2. The mechanism to distribute or output the DNS database.

GUI design is important, but it is also something that non-techies can help with even if all you do is make a mock-up in something like MS-Paint or GIMP.  Getting the buttons to work is a bit harder, but not really so much.  The tough part about GUI design is that it is an art skill, something that techies often lack.  There is much more about artistic balance, the golden mean, and selecting colors or icons that aren't offensive to certain cultures (yellow buttons are a bad idea in Chinese culture, for instance, or showing a swastika to a bunch of germans).

I agree that there are priorities in terms of getting the network layer put together first, but if we can get more people involved I don't think it should be dead last in priority either and certainly can be worked on concurrently with other projects.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 04:25:14 PM
 #79

Yes, the core developers should be focused on the network and the protocol.

I am making it my project to write a BitDNS client. I don't need the bitcoins. I just want to help so that the core developers can focus on the important stuff.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 06, 2010, 05:04:01 PM
 #80

I am making it my project to write a BitDNS client.

Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 05:19:08 PM
 #81


Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?

It's easy for me to change the name of the git project, whatever you decide. Still BitDNS is catchy.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 05:40:35 PM
 #82

I am making it my project to write a BitDNS client.

Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?

In a way, we are writing a Domain Name Server.  The hope here is that eventually the data we throw into this database is going to be extracted and used with the current DNS architecture as used on the internet, where computers would have the DNS resolution pointing to this database as a "fall back" position if it can't be resolved through the regular DNS channels.  That is how OpenDNS is currently working right now.

The only differences here is that we aren't relying upon a central server to act as a gatekeeper of this information, and it would be something that you could simply put into the search path through the network configurations of your own.

Getting the DNS protocol hooks working is to me a much more trivial thing than getting the domain registration itself going, however.  Once you can demonstrate that the domain registration is working and that the domain name can be resolved cleanly, getting the DNS portion working is simply plugging through the RFC protocol documents to make sure you get that side working.  The revolutionary thing isn't the DNS server software (which can already be downloaded for free as in beer and speech) but rather the decentralized database keeping track of this stuff and securing the data from getting tampered with.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 06, 2010, 05:53:42 PM
 #83

The revolutionary thing is ... the decentralized database keeping track of this stuff and securing the data from getting tampered with.
Exactly. The domain name block chain.

Anyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 07:17:02 PM
 #84

Exactly. The domain name block chain.

Anyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.

What software are you using for the site?

chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 06, 2010, 07:28:40 PM
 #85

+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 07:30:53 PM
 #86

+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

Bleg. All I need to do is change the name.

In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 08:02:35 PM
 #87

+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

Ooooooo...  I like BitRegister.  DomainChain works out pretty good too and is very descriptive.  I'm so used to BitDNS that I am still somewhat partial to that, but it doesn't exactly explain in a single word what this is going to be other than a shortened form of "Bitcoin DNS".

I'd like to get back to the topic of the scope of the domain naming system itself.  I would like to propose the following specification for actual name of the domain itself:

A domain can include combination of unicode (UTF8) characters with the exception of the period character (U+002E).  We may want to look at some other restricted characters mainly for conformance with normal URL schema as defined in RFCs and avoiding control codes, but I say that right off the start we permit non-latin characters into this scheme.  Other "excluded" characters may include the "/" character (U+002F) or the other non-alphabetic characters common found in the original ASCII specification.  The period character here is something more special, however.

Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu", or any of the standard country codes as currently under the purview of ICANN.  If ICANN wants to get into this game and claim those few domains, I don't mind giving these domains directly to ICANN, but the issue here is mainly to avoid naming collisions with other network resources.  If/when that becomes an issue, a technical solution can be found and it is irrelevant.

"Sub-domains" can also be established using a "dot" structure off of a previously established domain name.  For example a certain oil company could create a domain called "bp" and then create a sub-domain like "usa.bp".  When a registration of this nature happens, some sort of signed public/private hash key confirming permission to create the sub-domain is confirmed (similar to transferring ownership of a domain) before the sub-domain record is kept.  It may be possible to create a domain that is simply a "free-for-all" of sub-domains and defined as such when the domain is created.  An example of this would be a domain named, "bitcoin" and "btc" which would permit the creation of a domain like "mtgox.btc" or "mtgox.bitcoin".  On the other hand somebody creating "this.sucks.coca-cola" may have to negotiate with the domain holder of "coca-cola" in order to create those sub-domains.

Since the sub-domains have their own record, they can also point to separate resources including separate IP addresses.

Essentially, this is also allowing anybody and everybody to create their own top-level domain and charge whatever they want to use that "top level" domain, but it also makes such TLDs essentially worthless for the most part too.

I'll be nice and give "p2p" to perhaps the "dot p2p" folks as well if they want it.  I'm sure somebody would be willing to donate 0.01 BTC to get that record into the database.

Are there any flaws with this idea, or should it "go official"?  
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 08:14:56 PM
 #88

I have no complaint.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 06, 2010, 08:16:02 PM
 #89

I would like to propose the following specification for actual name of the domain itself...

OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system ("punycode") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.

Quote
Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu"

Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?

Quote
"Sub-domains" can also be established using a "dot" structure off of a previously established domain name
If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.
bencoder
Member
**
Offline Offline

Activity: 90


View Profile
December 06, 2010, 08:30:07 PM
 #90

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 08:33:45 PM
 #91

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?

Where the incentive for generators to get paid?

On the other hand, it won't be limited right? It will be a unique name of some kind.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 08:42:21 PM
 #92

+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

Bleg. All I need to do is change the name.

In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.

The only thing I am banging my head against right now is the issue of how to get the block miners of the DNS blocks to get the transaction fees.  I don't know if that is going to require a change in the Bitcoin protocol or if it can be adapted into the existing protocol.  This idea shows some promise as one way to implement the idea, however I really don't like putting this data into the main Bitcoin transaction database and turning that into one huge monster generic database of home cooking recipes, porn, mp3s, Wikileaks documents, Heroin traffic routing instructions, and other miscellaneous junk.  If you thought Bitcoins faced problems before in terms of governments wanting to shut it down because it is a competing currency, I think that puts it completely over the top without any of the protections that Freenet has put into the message routing protocol.

Where I'm having the problem is mainly that I don't think a "DomainChain" miner should get paid until the block they made is accepted deep into the chain, like at least 10 or so blocks deep (perhaps adjustable on that length with some formula too?)  For the most part I don't think most miners are going to care as long as they eventually get paid for the work they did, but those who are attacking the network may want to suck up the bitcoins for themselves and not really doing any work in terms of generating the blocks necessary to keep this whole thing going.

By banging my head on this problem, I really mean that every possible option I've considered has a fatal flaw in it.  I think the registration fees are an important part of this whole concept, however, as it makes the difference between a public commons free good and something where the consumer "pays the freight" for the network.  I also think it will make the difference between limited vs. widespread acceptance of this system too.

If you want me to go over some of the ideas I've had, I'll gladly put those dead ends into another thread, as I've come up with at least a dozen different ways to solve this problem in detail... including ideas I even started to type up in various replies to posts on this forum and then simply hit the "x" on the tab in Firefox before I hit the post button because I realized it wouldn't work.  Even the method of putting the data into the Bitcion transactions has a fatal flaw so far as it turns the BTC miners into DNS miners too (they keep the fees for themselves) and it enables some different kind of attacks on the DNS network as well.  I hate to say it though, it may very well be the best route to take shy of some protocol extension to Bitcoin itself that would recognize independent data chains as a source of transactions.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 09:06:00 PM
 #93

I would like to propose the following specification for actual name of the domain itself...

OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system ("punycode") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.

The existing standard is that ICANN is being very stingy on allocating top level domains.  That, for myself, is a major mistake and if you read some of the links above written by Karl Auerbach he points out that this is completely artificial and arbitrary.  There is no current reason to exclude any alphanumeric sequence for a domain name of any kind.

Quote
Quote
Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu"
Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?

So, who cares if there is a collision?  If somebody registers that domain, somebody at InterNIC can try to find out who owns the domain with DomainChain and negotiate a price to transfer that domain to themselves.  BTW, I think some sort of "comment" field could be put in with domain registration so you can attempt to contact the domain owner (completely optional BTW!) if they might be interested in "selling" the domain.  That seems like InterNICs problem, not ours.

They are the competitors to this protocol and this is something they should have done from the beginning.  That they aren't doing these things is more why this is something that should be done in this fashion.  There is no reason a million or a billion TLDs can't exist.

Quote
Quote
"Sub-domains" can also be established using a "dot" structure off of a previously established domain name
If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.

Yes, I realize that the current DNS structure allows you to use a "dot" off of the previously established domain.  The only reason for sub-domains is to create a system where "ownership" of a sub-domain can be transferred and have that ownership be kept track of through the DomainChain rather than as something arbitrary which can be revoked by the domain owner.  In other words, once "mtgox.btc" is registered as a sub-domain, it in effect becomes a full-fledged domain in its own right with the protections and controls that would go with a proper domain and would be recognized with a separate domain server for any of its sub-domains.  Basically this is a way to create the notion of a "TLD" registration system too if you wanted to stick with the convention of <server> <dot> <TLD>.  In practice I think such notions would eventually be dispensed with entirely, but perhaps there might be a reason to keep it going.  This system also meshes in a bit better with the current DNS system where collisions would be avoided as a natural part of the protocol rather than a hard arbitrary exclusion of certain words and names... thus simplifying the overall protocol.  Those TLDs currently operated by InterNIC and ICANN can be held in "escrow" by a member of the development community until such time as ICANN decides to pay up or take ownership of those "domains".

Note here that you can go to a domain server operator and "pay" them some money to create a subdomain off of say "mmorpg.org" for a game you made called "coolgame.mmorpg.org", but you are still at the mercy of the domain name server in the same way that everybody is at the mercy of ICANN and InterNIC (as well as the other domain registrars) for simply getting into the game.  That sub-domain can be arbitrarily terminated for any reason at all and would force you to go through the judicial system to get the subdomain put back in.  I think that is something the network philosophy is trying to avoid in the first place.  This alternate method would imply that such sub-domains can't be arbitrarily shut off unless the sub-domain owner is willing to relinquish control.
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 06, 2010, 09:10:34 PM
 #94

I don't know how to do this on IRC, but can someone create a #bitcoin-domainchain chatroom or something so that we can get some real time discussion going?
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 06, 2010, 09:18:07 PM
 #95

Here is an idea for how miners can get paid.

Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.

However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.

Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.

And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.

Hal Finney
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 06, 2010, 09:39:41 PM
 #96

Here is an idea for how miners can get paid.

Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.

However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.

Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.

And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 09:48:33 PM
 #97

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?

Well, I've proposed that Bitcoins be used as an incentive for mining the chains, which I suppose is a way to promote the use of Bitcoins as well.  If you are talking about the "miners" simply creating their own floating currency that could then in turn be put into one of the exchanges.... that may solve the problem of getting miners paid (hmmm.... I've got to think about that one for a little bit) but it does create the problem of what anybody is going to do with that "floating currency"?

Just thinking aloud here... if we used a "floating currency" in this system instead that was a "DomainChain coin" similar to Bitcions but not pegged to Bitcions as all, could that work here?  I'm sure Mt. Gox would certainly be interested in exchanging these coins if they had some value, and the point here is mainly to come up with the formula for creating these coins.  The only real use of these coins would be to pay registration fees for domain names, so I think the drop-off could happen a lot faster than is the case with Bitcoins.  

In theory we could even set up some sort of link to Mt. Gox or some other trader so that in the interface you could do a "quick buy" of these "DomainChain coins" in such a way that for an end-user they would be buying them with BTC and then putting those recently purchased coins right into the transaction as a fee for the miner to claim when it gets put into the chain.  If the transaction block is rejected, that miner loses the claim to those coins and they become unconfirmed.... where it is the responsibility for the exchange to worry about the validity of a particular set of "DomainChain coins".  A similar kind of "quick exchange" could even happen with LR Dollars or any other currency that may be tied to some exchange system, or they could simply get the "coins" on a "manual" basis from the exchange if they wanted to get a better exchange rate or have somebody "send" them some of these "DomainChain coins" with a direct hand-over of cash.

I like this a whole lot.  It may "solve" this problem I've been thinking of in terms of getting miners paid.  Are there any other hiccups anybody sees with this situation?  The exchange itself isn't even fixed.

The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value.  Not overnight, but gradually.  We need somebody with a whole lot more economic theory behind them to figure this one out, because I would vote for a "weaker" currency than Bitcions be set up in this situation, however we want to define that.  How would you set up the parameters for a relatively strong currency that the desire would be to trade it in for Bitcions instead when possible?  Would the fact that Bitcions has an absolute limit but these kind of "DomainChain coins" would continue to inflate (aka the 50 DCC produced per block would continue to be produced indefinitely creating a mild sort of inflation over time) be sufficient to make Bitcoins stronger?

I need to think overnight on this particular subject as it is starting to make my head ache thinking about it, but it sounds like an interesting idea to seriously consider.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 06, 2010, 09:53:13 PM
 #98

I also had an idea last night of how/where to tie this into the existing DNS.

When you lookup foo.com, software on your computer called a resolver is responsible. It has some caching and local data, but mostly it just asks a DNS server for the answer. You have one or more DNS servers configured as part of your network setup, and these servers respond to domain name lookup queries either directly, or by initiating their own search of the domain name system.

Obviously we want existing name lookups still to work. Broadly speaking, then, we would change the software to first check if a name is registered in the BitDNS system, and if not, to fall back to the regular handling.

My idea is that the best place to add the BitDNS lookup code is in a DNS server rather than in the resolver. Resolvers are different for every OS, so there's more work. I don't even know if the resolver logic can be changed on Windows. Plus this code is going to need to be tracking the BitDNS block chain, and not every end user should have to do this.

Other 'alternative' DNS systems do it like this, with one or more special DNS servers that know about their extra domains.

We would choose some open source DNS server as a base, fork it and add the code to lookup BitDNS names. Whether these names all have a distinguishing TLD ".bit" or whether we are more aggressive and take over more namespace, either way it could be done.

As I understand it, when a DNS server looks up foo.com, it finds the (or a) name server authoritative for .com, and asks it for what is called a SOA record for foo.com. This tells what name servers are authoritative for foo.com, and the DNS server then tries them to get details on foo.com.

We would intercept this first step, and use the BitDNS code to find the authoritative name servers. Maybe we could create a dummy SOA record to hold the data, to simplify falling back into the regular DNS code.

People who want to use BitDNS would just have to select one of the BitDNS aware DNS servers. Paranoids could run their own name servers locally and track the block chain. All the usual optimizations of DNS in terms of caching, distribution, etc. would work, so it would not have much negative impact on the net.

Hal Finney
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 09:54:39 PM
 #99

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

I'm fine with that.  It is an easy way to allocate the coins.  The role of the halving of the coins "mined" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi.  I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 06, 2010, 09:57:27 PM
 #100

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

I'm fine with that.  It is an easy way to allocate the coins.  The role of the halving of the coins "mined" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi.  I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).

Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 06, 2010, 10:08:45 PM
 #101

The reason for halving bitcoins over time does not really exist for bitdnscoins.

Good. Something everyone completely agrees on!
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 10:09:42 PM
 #102

Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.

Wondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of "change" but is there going to be any need for more than about three or four decimal places?

This is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million "bitcoins" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other "currency" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.

I don't know of any other currency that uses this sort of allocation system even remotely.  Of course that is why this is so groundbreaking.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 06, 2010, 10:12:12 PM
 #103

Good. Something everyone completely agrees on!

So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 10:17:50 PM
 #104

I also had an idea last night of how/where to tie this into the existing DNS.

I know this discussion is going like nuts here.  I think this is a very good idea and should be fleshed out much more.  If you have some experience or knowledge about local domain name servers, your expertise here would be invaluable.  I know just enough to get myself into trouble on that matter and to debate the policy questions, not enough to really dig into the guts of them.  I've operated a domain server for a brief period of time and have experimented with OpenNIC myself.
bencoder
Member
**
Offline Offline

Activity: 90


View Profile
December 06, 2010, 10:18:18 PM
 #105

Anyway, I have registered domainchain.org, in case people like it.

Care to stick a wiki up on there?
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 06, 2010, 10:19:47 PM
 #106

Good. Something everyone completely agrees on!

So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)

I don't see any reason why we should try something different.  If it breaks for us or for Bitcoins, one or both projects should get the issue fixed with an alternative solution.  There certainly are strong reasons to keep this system, as Satoshi's white paper points out in pretty good detail too.
Anonymous
Guest

December 06, 2010, 11:22:26 PM
 #107

Quote
The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value.  Not overnight, but gradually.
Well people couldnt say domaincoins werent backed by anything.   Cheesy

I like the idea of a constant block rate.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 12:29:38 AM
 #108

On the question of how many domain names to create per day:

http://www.domaintools.com/internet-statistics/

There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.

If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.

Hal Finney
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 12:39:57 AM
 #109

If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.

100 domains per block is 25 years.

150 domains per block is 18.5 years.

200 domains per block is 12.5 years.

Personally, I don't feel like I am a rush to do a lot of domain registration fast. 15 years is good enough for me. We don't need to register tons of domain within a few short years, since not everybody will be willing to switch from central to decentralized.

Also, the population of humanity ain't likely to grow forever... So we can expect that growth at some taper off at some point in the future.

However, this generation rate have the potential to spark a long debate..so we need a method that let us decide quickly somehow.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 01:11:25 AM
 #110

On the question of how many domain names to create per day:

http://www.domaintools.com/internet-statistics/

There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.

If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.

The question as to how many domains to include in a block ought to be something dependent upon the miner alone.  This certainly is a useful point to bring up and likely an early "reference implementation" limit will be 50 domains per block merely to increase scarcity.  Still, that up to 300k changes might happen eventually with this system, perhaps more considering that the cost is likely going to be considerably less than the current domain registration system.

----

I have a few other thoughts about this now that we are getting to something a little more concrete in terms of the software architecture.  Would it be reasonable to expect the cost of a domain registration to be 1 DCC (Domain Coin Currency)... at least as the "default" cost expected by the miner to "register" a domain?  I think that would establish at least an initial value to the currency and help to self-regulate those who want to jump in early and grab up a whole bunch of domains early on.  I might even go so far as to say 2 DCC for registration and 1 DCC for information changes.  If you run your own miner, you can "tweak" this if you want to be more competitive, but this is the way that you can spend the currency and what it is based upon and a fair benchmark.

In terms of a social effect that may be negative (depending on your viewpoint) some of the country code TLDs represent a substantial source of income for some of countries involved.  One in particular, the country of Tuvalu, has only a little over 12,000 citizens and is the smallest member-nation of the United Nations in terms of population and pretty close to that in terms of land area.  Only the Vatican has a smaller population in terms of a sovereign state.  Its current TLD (*.tv) is currently run by a company in California but a significant portion of the revenue from that domain goes to the country's government under contract.

On the topic of small countries and their "country codes", it seems like if we could get this software rather stable, we might even want to offer this "service" to some of these smaller countries for their domain registrations, where I'm pretty sure that this would be cheaper than whatever contract they currently have with their current service provider.  That goes under "marketing", but something else to think about.  I certainly think that it would be awesome if we could get a whole country like Tonga to switch to Bitcoins as their national currency, and is much more likely to happen than the major western countries like America or the EU.  Just dreaming there.
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 07, 2010, 01:29:02 AM
 #111

I would like to ask for some clarification on exactly what we are proposing here.  From reading this (lengthy) thread, I gather that we are proposing:
  • A decentralized domain registrar that maps a friendly human readable name (ie: chaord.btc) to an ip address
  • A parallel network bitcoin which will have it's own token currency (represent addresses).  Rather than mining bitcoins, you mine top-level address rights.  Is this correct?

Am I understanding all this correctly? If so, it seems as if in this brave new digital world, bitcoins (BTC) represent a commodity like gold, and domaincoins (DCC) represent real estate.

Lastly, I'm sure this has been discussed, but is there any way that the two system can be combined?  Can the domaincoin system accomplish all things bitcoins can, in addition to domain registration, or no?  IMO the best of both worlds would be if, somehow (not sure how), the domain coin system could use bitcoins as its underlying backing (or vice versa).

Honestly, I feel that something like DomainCoins is the "missing link" that this community is searching for.  Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 02:31:35 AM
 #112

Honestly, I feel that something like DomainCoins is the "missing link" that this community is searching for.  Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!

I think you got the ideas down.  The role that the "DomainCoins" (DCC) are playing here is to give a financial incentive to "miners" who are creating a cryptographically secure domain registration database.  It is also a work-around due to the fact that we can't seem to figure out a way to accomplish the goals of getting Bitcoins directly to the miners, so instead we are going to be using an alternative currency which can be traded for mining.  To me, the only reason for putting any sort of coin generation into the blocks is simply to "prime the pump" to get some DCC put into circulation.  Hopefully what will normally happen is that DCC will be exchanged for Bitcoins in both directions:  Some folks will "buy" some DCC with Bitcoins (or LR Dollars or whatever) so they can pay for domain registrations and the miners will "redeem" the DCC for Bitcoins as earnings.

Trade between DCC and BTC will be almost insanely easy by design and the exchange mechanisms may even be put right into the GUI interface.  I could even see custom clients that might even combine transactions for both "currencies".

This same system could be used in a number of other similar situations, such as an idea I floated about creating a Bitcoin-based Stock Exchange.  If such a stock exchange is set up, a similar parallel currency may have to be implemented to also pay for mining the transaction blocks.  I can see many other kinds of "databases" set up which would require some sort of cryptographic time-stamping.  Something I played with a while back that could be useful here would be "timestamping" police evidence (especially digital evidence such as a dashboard camera video feed from a police vehicle) in a chain of custody system.  An engineering company could set up a custom "bitcoin" system to keep track of engineering documents to be used as a defense against a patent lawsuit to both show date of creation and prove that the document file hasn't been tampered with since its inclusion into the database.  Seriously, this system is something that has a whole bunch of possibilities that I can't even start to describe the kinds of things that would be useful and we are just scratching the surface.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 02:43:43 AM
 #113

Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 03:01:38 AM
 #114

Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.

Hal Finney
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 03:19:51 AM
 #115

Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.


Doesn't seem hard to me. It's a normal trade to me.

Anonymous
Guest

December 07, 2010, 03:21:10 AM
 #116

Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.

Could ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines. Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.


Does .dnc = domain name coins?

We could co-opt the democratic national convention lmao.



Anonymous
Guest

December 07, 2010, 03:22:21 AM
 #117

Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.


Doesn't seem hard to me. It's a normal trade to me.

So you need two clients running?

edit:never mind...
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 03:52:05 AM
 #118

If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.

Doing peer to peer currency exchanges is beyond the scope of this project.  If there is going to be some sort of peer to peer currency exchange (I think it might be possible, especially for non-reversible currencies like Bitcoins and Liberty Reserve Dollars), it should be in a completely different project.  All that I'm suggesting is that some sort of API be set up so one or more "trusted exchanges" can be selected to facilitate the "purchase" or exchange of these "coins" for some other currency.  I just don't see too many people going through the hassle of trying to obtain these "domain coins" by selling other services in these coins, even though that would in theory be possible.

If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

On the positive side, the fancy API and GUI exchange methods won't be strictly needed at all at least initially.  We could even use essentially the existing bitcoin software where all we would do is to simply "tweak" the low level features so we would be including the domain information into the blocks.  If we did that as a quick bootstrap of the network, websites like Mt. Gox could use the same JSON API system for Bitcoin on this system as well, particularly as the exchanges wouldn't have to play with the domain information but rather just the coin trading mechanisms.  Exchanges would want to get into the act as there certainly are arbitrage opportunities between the DCC and BTC currencies.

Our hard part is to define the "rules" of what domain information needs to be present, and when a block can be rejected because of mal-formed domain data.  That is where I think it would be wrong to put this more directly into the Bitcoin block chain, as rejecting Bitcoin blocks because of a malformed domain record seems to be harmful to Bitcoins.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 03:59:11 AM
 #119

Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.


A coin would represent the work or effort to administer the database.  That is the "reward" a miner gets for processing the domain records.  That it might cost 1 DCC to enter a record into the database is just the "fee" to play the game, where you are buying the effort from previous record keeping efforts.
Anonymous
Guest

December 07, 2010, 04:13:05 AM
 #120

Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.


A coin would represent the work or effort to administer the database.  That is the "reward" a miner gets for processing the domain records.  That it might cost 1 DCC to enter a record into the database is just the "fee" to play the game, where you are buying the effort from previous record keeping efforts.

Thanks for clearing that up.

Anything is better than buying another domain from godaddy . Smiley
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 04:30:24 AM
 #121

At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 04:44:45 AM
 #122

Could ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines.

Having ip address themselves be managed by a bitcoin-like system is a very interesting idea...

I never liked how the government and major corporations get to dish out vast swaths of the ip spectrum by dictate and privilege...

Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.

Is this privacy issue because ipv6 address will embed your MAC address?

Quote
IPv6, on the other hand, has 128 bits of address space, enough to provide a billion-billion addresses for each square meter of the earth's surface. How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out.

As you might expect, the address field is so huge that the IETF didn't know how to assign it. So, in a move to get buy-in from established industry standards bodies, the right-most 64 bits were designated to contain EUI-64 format information. This is used by the IEEE to assign Ethernet addresses, which are normally not transmitted outside a user's LAN.

Included in EUI-64 are two interesting pieces of information: the registered manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! Every packet you send out onto the public Internet using IPv6 has your fingerprints on it. And unlike your IP address under IPv4, which you can change, this address is embedded in your hardware. Permanently.

Does .dnc = domain name coins?

We could co-opt the democratic national convention lmao.

LOLFEST!   Cheesy


Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.

Wondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of "change" but is there going to be any need for more than about three or four decimal places?

I agree...there is not as much reason for fractional bitdnscoins. That just complicates the algorithm and operation.  Making bitdnscoin be simple unitary entities is much simpler and easy to understand, so it will increase the likelihood of widespread adoption.  Simpler is better.  Computer hardware and software like things simple.


This is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million "bitcoins" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other "currency" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.

Could you clarify?  Are you talking about because bitcoins have a limited number of digits that it can be divided into (according to the algorithm), that therefore 1 bitcoin could be instead thought of a ~million mini nano-bitcoins that are of fundamental unit of trading size?


Anything is better than buying another domain from godaddy . Smiley

Awesome!  NO need for the middle man!  rent

This brings up another interesting point: most people will not need to have to pay the yearly ~$10 rent to their domain name provider, if they generate the bitdnscoin themselves.  Of course, this does not abolish rent on domain names, as there will be of course some mega bitdnscoin miners will speculate to purchase domain names they think will be in high demand, and will then rent out the popular domains they own.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 04:51:23 AM
 #123

Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?

This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.

Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.

Hal Finney
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 04:56:51 AM
 #124

At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
Anonymous
Guest

December 07, 2010, 05:03:41 AM
 #125

At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  And, keep in mind, people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.

+1 on that.
Anonymous
Guest

December 07, 2010, 05:06:26 AM
 #126

http://www.politico.com/news/stories/1210/46003.html

For motivation  Smiley
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 05:08:43 AM
 #127


I RAGE.

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 05:35:39 AM
 #128


Oh god.  I try not to read the news...it just makes me angry.

Quote
White House intellectual property czar Victoria Espinel said Monday that the Internet community should “expect more” pre-emptive action as the administration combats online copyright infringement — especially the illegal copying and sale of pharmaceutical drugs.

So now we will all have to pay rent for an artificial government-imposed monopoly on life-saving pharmaceutical drugs, just so that we can live longer.  Intellectual Property => have to pay rent for your body.  IP == slavery.  Just because someone is the first to file a patent on a lifesaving drug, doesn't give him the right to exclude others from reverse engineering or independently discovering and producing that lifesaving drug.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
Anonymous
Guest

December 07, 2010, 05:47:00 AM
 #129

Those are the stakes on the table people.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 06:02:13 AM
 #130

Remember, we can't let those .p2p dudes beat us to the punch!

Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 06:13:34 AM
 #131

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.

I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?

The reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.

Hal Finney
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 06:19:10 AM
 #132


I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?

The reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.


Umm, each coin stand for one domain.

However, I don't think we need transaction fee. This is not bitcoin after all.

The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?

I am worried about people who spam change to the DNS database?

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 06:46:07 AM
 #133

Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?

This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.

Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.

One of the reasons to maintain the 10 minute interval between blocks is because of network latency from distant node in terms of "hops" between nodes.  If you shorten the interval you risk more "collisions" between nodes that may have simultaneously created a "successful block".  In turn that also can make even longer "chains" start to compete against each other.

In other words keeping the 10 minute interval may be a very good idea or even increasing the interval could have benefits.  I know of at least some blocks even with this average that have time stamps which even go "negative" where the successive block is timestamped a few seconds before the previous block.  More likely it was created at almost the same time but the other block literally was created a matter of a few seconds earlier.

I would like to put in perhaps a more continuous or shorter interval between difficulty adjustments, but then again there are some network attacks which are thwarted by the two-week readjustment system.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.


The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself.  The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations.  It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too.  Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.  Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 06:56:51 AM
 #134


The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself.  The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations.  It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too.  Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.  Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.

Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?

chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 07, 2010, 07:00:00 AM
 #135

If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 07:02:18 AM
 #136

Umm, each coin stand for one domain.

However, I don't think we need transaction fee. This is not bitcoin after all.

The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?

I am worried about people who spam change to the DNS database?

Coin transfer transaction fees are also important here as well.  It allows the cost to be scaled with the size of the network and note that there will be coin transactions in this network as well.  There will be coin transfers independent of domain registrations as there will at least be transfers to and from exchanges and likely from miners to people wanting to make registrations directly.  There may also be other applications that use these coins that haven't been developed yet.

The "50 coins" they may collect are not going to be generated coins but rather fees collected from processing domain records, presuming they are getting 50 domain registrations in a single block.

The only role that generated coins play is strictly to bootstrap the exchanges.  You have to get the coins from somewhere, and giving them to miners is as good of a way as I can imagine without simply creating them all in the genesis block and then handing them out like the Bitcoin faucet until that feature runs out of coins.

Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?

This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 07:26:08 AM
 #137

This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.

So if you spent a coin to register a domain, then it stay frozen until the domain expire?

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 07:28:44 AM
 #138

If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.

It could be put into the Bitcoin protocol itself, but keep in mind that would require changing the miners in a way that would also have to set up the rules for accepting and rejecting the domain registrations.  It also makes this a hack onto Bitcoins to be performing tasks that aren't financial transactions.  Some Bitcoin miners wouldn't be willing to participate and may end up rejecting blocks with the domain information buried in the block.  This gets back to burying the data into the transaction record itself, and then you get problems again trying to decide what blocks get rejected and which ones don't.  On top of all that, it makes this a one-time only change and is not extensible to incorporating other ideas that may be similar.

Really, the only way this is going to work is for a completely separate block chain for the domain data.  That implies a second currency.

If we could get some hooks into Bitcoin that would open up some additional data types which could be put into the Merkle tree for the blocks and have some way for a miner to bootstrap verification rules for those additional types, perhaps we could put it into the main Bitcoin chain as well.  We would also have to come up with some sort of scripting language that would be used to "verify" those extra datablocks sort of like the current scripting language being used to verify coin transactions.  Would that be worth some extra effort to make a "generic solution" that could be added to Bitcoin for this and other similar kinds of data types to be added to Bitcoin?

It would require a major network-wide upgrade regardless.  Coins wouldn't be lost, but older clients would have to be abandoned with an update of that nature.  Miners would receive any transaction fees for simply following those rules.

Another question here, and this is perhaps the most important:  Would Satoshi be interested in putting in these kind of extra hooks into Bitcoin?  By creating a separate currency that is essentially a fork of Bitcoin for a specific purpose, Satoshi's blessing is irrelevant other than coordinating the effort of the two projects to relay problems identified in the two efforts and to make sure fatal problems get updated in bother projects.  If we decide to put the data (even as a separate data structure) into Bitcoin, Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue.

This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.

So if you spent a coin to register a domain, then it stay frozen until the domain expire?

No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 07:30:55 AM
 #139


No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.

So domain name generation are limited by the velocity of miners spending, but then they have to generate a block to get the coin.

chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 07, 2010, 07:43:13 AM
 #140

RHorning...thank you for the very detailed responses.  It's been helpful that you are so willing to lay down your logic so that some of us can play "catch up" as we wrap our heads around this project.

Quote
Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue.
I completely agree here.  Even though his "blessing" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 08:04:22 AM
 #141

I completely agree here.  Even though his "blessing" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.

We need to get Satoshi's approval if something goes into the main Bitcoin client.  There are other applications involved here besides the DNS system, even if that seems to have high priority at the moment.  We could create a patch that would put hooks into the Bitcoin software to permit these kind of changes, but it could also be for naught if Satoshi rejects that patch.  Since this is also a major architectural change to the software, it seems highly unlikely that it would get accepted unless we can demonstrate a clear need for this idea or show some huge benefits that would help Bitcoin be adopted as a currency.  It is also a whole bunch of software development that depends on just one person accepting that change on essentially a whim.

In short, if we decide to put this into Bitcoin, Satoshi is the gatekeeper.  We could completely fork Bitcoin, which is essentially what we are proposing here anyway as the alternative with these separate coins.  That is our choice.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 08:06:58 AM
 #142

We need a wiki real bad so Rhorning can write down what he means.

RRRRRRRRRRRRRibuck?

Anonymous
Guest

December 07, 2010, 10:19:27 AM
 #143

Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?

After all who wants to download a massive block chain just to buy or transfer a domain name?

Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?

It seems this could be a way for bitcoin to have its own "app" store of different block chain purposes.  Smiley
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 02:13:34 PM
 #144

Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?

After all who wants to download a massive block chain just to buy or transfer a domain name?

Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?

It seems this could be a way for bitcoin to have its own "app" store of different block chain purposes.  Smiley

An interesting thread related to this can be found here: http://bitcointalk.org/index.php?topic=2124.0

Theymos has been discussing how to put miscellaneous data into the transaction blocks themselves, but there are dangers to doing that.  It also shows some incredibly strong resistance to "tweaking" Bitcion itself as a software package to permitting this kind of activity, which seems to me as coming from at least a source that would end up killing any attempt to put a patch into Bitcoin to permit data inclusion for something other than the "stealth" method with transactions.

While the suggestion that Git itself ought to be sufficient for cryptographic timestamping and cryptographic data storage (that is interesting by itself... something I haven't thought about), I don't know enough about Git to say much about it at all in terms of its distributed nature.

I firmly believe you should "pay your own freight" so far as anything which costs others to do, which is why I think this proposal is incredibly useful.  There are costs associated with domain name registration and data storage, and they aren't trivial expenses either.  The concept of Bitcions enables those costs to be borne by those who use the service.  I tried to explore this idea further on this thread:  http://bitcointalk.org/index.php?topic=1764.0

This is indeed a political idea here too, which is where perhaps it is getting some resistance as well.  The idea could be summed up with the concept that "you get what you pay for".  Places like Source Forge offer their "services" for free, but there are hidden costs including being tied to other outside interests.... mainly the advertisers and those who are paying for the "service".  With what we are proposing for BitDNS/Domain Chain is that the service is going to be focused upon those who are paying for the service.... which is those who are making the registrations.  They have the most to lose if this project falls apart.  If the registrants aren't happy with the service, fees are going to go down and the DCC is going to collapse as a currency.  That in turn is going to cause developers to be very strongly focused upon meeting the needs of that community.

The other aspect which is really interesting here is that the process of becoming a "registrar" has a very low barrier to entry.  I'm sure many people would love to have had the chance to do something like being BigDaddy or Verisign in terms of processing domain registrations and receiving the fees for doing that.  Now the chance to perform that sort of "business" at least on a part time basis is at least possible.  No single person or even central organization is going to be receiving the fees but rather a "community" that is open to newcomers and even people with modest technical skills.

I've also seen complaints that "open source software" doesn't pay.  Bitcoin can change that model, including doing things like we are talking about here with the DomainCoin system.  Not only can a bounty system be set up for integrating a specific feature into the system, but the developer can also have a continuing source of income afterward.  BTW, in deference to Kiba, the license itself is immaterial here too and can simply be thrown into the public domain, even though I think that copyleft licenses tend to offer much stronger protections against idiots who would attempt to mess with you in the legal system.  You may want to avoid the judicial system, but sometimes it comes and bites you hard even if you are active in trying to stay out of its reach.  Time is really the one resource that anybody has to sell when you finally get down to the gritty details of economics, and it takes time to be a developer to create projects like this.  Also, even simply maintaining the software afterward takes time and effort, fixing bugs that show up and perhaps putting in tweaks.

Anyway, enough of the issue with the overhead costs.  I am afraid that this is going to effectively split or fork the Bitcoin network, and that isn't a good thing either.  I want to work with the Bitcoin community, but if they won't have us, we may have to move on.  Threats to Bitcoin will still be relevant and I'm not going to leave completely in a huff, but as a separate application it will be essentially a fork of Bitcoin if we proceed with the path I've suggested in terms of a completely separate coin chain and currency.  It might be interesting so far as a social experiment is concerned to see which way is better and which "coin" is going to be more accepted in the long run.  I am challenging some of Satoshi's assumptions here too, but not overly so.  Two very similar project with slightly different goals but which also support each other might be beneficial to each other as well, especially as there is going to be a huge amount of common ground to work with.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 03:10:26 PM
 #145

Anyway, I have registered domainchain.org, in case people like it.

Care to stick a wiki up on there?

Yes I'll do this. Don't panic!

But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 03:23:05 PM
 #146


Yes I'll do this. Don't panic!

But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

We won't make fun of you.

On my Bitcoiner honor!

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 03:34:34 PM
 #147

Trying to predict the exact numbers required is equal to central economic planning, and pointless.
<--- In another thread.

So there's an economic calculation problem. We...cannot reliably predict how many domain name registration are needed each block.

So we going to need to price generation of blocks, somehow?

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 04:00:27 PM
 #148

I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

I'm always interested in alternatives.  Take your time though, and I'd like to see how it is different than what we've proposed here.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 04:51:20 PM
 #149

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Here's a quick summary:

  • Bitcoin already allows for a text "payload" to be included with a transaction. Any bitcoin transaction that is sent with the right payload becomes a domain name registration.
  • To register a domain name, just send any amount of bitcoin to yourself, with a special payload. This payload identifies itself as a DomainChain payload, and contains the desired domain name plus the IP address of the authoritative name server(s). If no-one else already has that name registered, it's yours.
  • To transfer a domain name to someone else, just send them the associated bitcoin (actually any part of the associated transaction will do). The GUI will let you do this in terms of "domain names" rather than in terms of "coins".
  • To change the authoritative name server(s), just send the associated bitcoin to yourself with a payload that identifies the new authoritative name server(s)
  • Registrations last forever unless you terminate them by sending that bitcoin to yourself with a payload that is a DomainChain "cancel" message
  • You can register a domain name with the smallest convenient amount of bitcoins (currently 0.01 BTC), so the system imposes no scarcity of domain names. However, miners will impose transaction fees which increase as the block size increases. This provides a disincentive to registration spammers
  • To resolve (lookup) a domain name, the block chain is scanned for the most recent valid transaction for that domain name. In principle, anyone can run a DomainChain resolver, but in practice most users will use a DNS service that is DomainChain-aware

Advantages:

  • Provides domain name registration with the same level of pseudonymity as Bitcoin
  • Holds registration data in a tamper-resistant distributed manner
  • Strengthens Bitcoin by providing additional economic incentive for generators (because they will be able to charge transaction fees for domain name transactions)
  • Can be implemented much more quickly than any other scheme that has been proposed so far
  • Existing bitcoin clients are unaffected. If they receive coins that are associated with a domain name registration they will see them as coins. do not display domain name registration transactions. No modification is needed.

Disadvantages:

(I'm sure you'll let me know of the disadvantages.)

Implementation:

1. Patch the standard bitcoin client. Run it on the bitcoin test network. The patched client will have a separate panel for domain names that are associated with bitcoins. These bitcoins will not show on the standard panel, nor will they be included in the total balance available to spend. On the DomainChain panel, instead of a "send coin" button there will be buttons for "register a new name", "change nameservers", "transfer a name" and "abandon a name". There will also be a scrolling list of domain names together with their nameservers.

2. Write a program that scans the block chain to determine the authoritative domain name servers for a given domain name. Patch a standard open source domain name server to consult the output of this program as part of its name resolution.

3. If it works well, persuade Satoshi to allow these transactions in the main network. Of course, it would be technically possible to run it on a new network with a new block chain, but who wants competing currencies?

There's obviously a lot to be fleshed out, but I think the design is workable and easy to implement.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 04:59:30 PM
 #150

The DomainChains payloads could look like this:

Registration (with and without nameservers):

Code:
DomainChains my-domain.tld
DomainChains my-domain.tld 201.73.213.92 98.252.10.34

Changes of registration details use the same payloads, but the payloads must be sent with a coin that is already associated with the domain name.

To drop a registration and turn the bitcoin back into a spendable coin, send this payload with a coin associated with the domain name:

Code:
DomainChains drop

Obviously this is just to illustrate the idea. The concrete syntax may differ.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 05:02:48 PM
 #151

Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 07:09:44 PM
 #152

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

The #1 disadvantage:  My complaint about shoving useless and meaningless data into the transaction block.  It would work, but there may be changes to Bitcoin to get rid of this "feature" as it may be seen as an attack rather than something useful for the project.  I am not alone with this attitude.  It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion.  Expect more resistance if you actually get a client to accomplish this task.  Bitcion is not bittorrent. 

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.  Instead you would likely need some other application which is reading all of the transaction and either "accepting" or "rejecting" the domain registrations.  Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear "ownership" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system).  Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

I admit that some of this could be worked out simply by saying that the first "registration" takes precedence, including in the same block.  Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would "apply" the rules which identify a valid transaction.  Competing software could put in different "rules" for the same data as well and put different domains as valid.

It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

This could work.  It would be real nice to see what Satoshi thinks of an "abuse" of the transaction scripts in this fashion.  My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.

BTW, one advantage to going this route is that it would not require any reboot of the network

I do have my reservations about the direction this is going, but I'm willing to have an open mind about it.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 07, 2010, 07:23:34 PM
 #153

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.

Quote
If they receive coins that are associated with a domain name registration they will see them as coins.

You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 07:39:16 PM
 #154

RHorning,

The one objection of yours that I can't address is the one about "shoving useless data into the transaction block". This is something for others to decide, and at this time I would respect whatever Satoshi said. But we should not be concerned about "opening the pandora's box" because the box is already open and lots of people are going to look inside in the future. That "problem" (if it is a problem) is for the owners of Pandora's Block Chain to decide.

What I suggest we do is to try out DomainChain on the test network, and see what bitcoiners think of it when it's able to be experimented with. I'm sure we'll get feedback on whether or not it's welcome in the live block chain.

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

There's nothing forcing generators to include bitcoin payments that piggyback DomainChain data, but why wouldn't generators want to include them if the transaction fee is high enough to cover the extra costs plus a profit margin?

Quote
Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.

That's true, but it's no different from Bitcoin itself. The block chain only has value because a majority of users are prepared to interpret it in a certain way, according to certain rules. If that works well enough for coins, it will work well enough for domain names.

Although we need generators to include the DomainChain transaction data, we don't need the average person's bitcoin client to recognise that data, or act on it in any way. Only the resolver software, and the modified clients used by those who want to register domain names, need to recognize the extra data.

Quote
Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

The first to get their registration into the block chain gets the domain. Ideally the generator who processes these transactions will reject the invalid one. Failing that, the resolver will certainly locate the valid one.

Quote
It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

I don't think there is any problem here. The registration data is re-sent if the domain name is transferred to someone else by spending the coin. All we care about is who has the current registration. We don't care about the history of the domain name.

Quote
This could work.

Let's do the "simplest thing that could possibly work" for the proof of concept. This seems to be it. If people like it, they will accept DomainChain into the Bitcoin block chain. If they don't like it, we go to plan B.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 07:42:44 PM
 #155

I haven't read your spec yet, but...

...Some sort of expiration is required..

That's fine. It's not problematic in my design.

Quote
Normal clients will ignore such transactions.

That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 07:50:56 PM
 #156

Wow, after a first readthrough of the spec by Theymos and Nanotube I am astonished by the similarities. And their spec is so much further developed. This is excellent!

I will look through it in detail tomorrow as I've already spent way too much time on this today.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 08:06:02 PM
 #157

My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.

Hal Finney
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 08:23:58 PM
 #158

My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.


Speculation is natural; even healthy.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 07, 2010, 09:02:28 PM
 #159

My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com.

What do you suggest is a better way to decide who gets sex.domain?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 09:04:01 PM
 #160

Do we have a consensus on nanotube's proposal? Any objection?

nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
December 07, 2010, 09:25:32 PM
 #161

Do we have a consensus on nanotube's proposal? Any objection?

just to be clear, it's nanotube's+theymos's proposal Smiley

and, we're still working out some kinks in the protocol. consider this to be an open RFC period. it's a bit too early for 'consensus'.

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 09:27:23 PM
 #162

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.

Quote
If they receive coins that are associated with a domain name registration they will see them as coins.

You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.

I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.  I like the idea of piggybacking bitDNS on top of bitcoin.  However, putting the domain name registration requests inside of bitcoin transactions as a message does cause concern about compatibility, should the bitcoin developers decide to remove that feature in the future for security or other reasons.  I would suggest, maybe is it possible to have the domain name registration request message be not included directly inside the bitcoin transaction, and instead use some cryptogrphic properties of the block be used to index to a bitcoin registration request message?  For example, somehow have the hash of the transaction/block be directly indexable to a DNS registration request?  In which case, the information about the sender and receiver of the DNS registration request would be embedded in the hash such that it proves that address X is the owner of that DNS registration request?  Thus the bandwidth/traffic of domain name table info/requests would only be paid by those clients who are engaged in domain name registration.


Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.

Expiration fixes the "problem" of domain names being lost for eternity.  My question is, what are the relative benifits/disadvantages of using a block count based expiration (e.g. 52,000 blocks) versus a time-based expiration (e.g. 1 year)?  I would think a time-based expiration would make more sense for average people to understand, since they will know that after a certain fixed period of time, they will need to renew their domain, and can set that in their calendar, instead of being completely unaware if the block count reaches some number?  Never mind...I get it...52,000 blocks is approximately the number of blocks that should be produced in 1-year time assuming a rate of 1 block/10 minutes is maintained.


My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.

Speculation is natural; even healthy.

What Kiba said.  Speculation is a part of any world where there are limited resources.  Speculation allows the market to come to a subjective valuation of the unknown value of such resources.  The speculator takes a risk by buying domains (even if it is just an opportunity cost), and that risk is entirely held by the speculator.


"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 07, 2010, 09:47:58 PM
 #163


I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.


Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 10:08:09 PM
 #164


I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.


Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.

Oh yes, I am perfectly aware.  In fact, the prevalence of simultaneous inventions is a strong argument against the necessity of a patent system to "reward" inventors with monopoly.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 07, 2010, 11:37:16 PM
 #165

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.


I'm looking at the fees, which certainly would be a reason for a miner to include these into a block with a high priority.  Still, I'm trying to find any sort of motivation for a "DNS Server" to recognize any of this data other than as a repository of potential domain information.  There is a reference to a "vibrant market" for the fees being used here, yet this seems very altruistic that one of these servers would recognize any fee at all if they aren't getting any themselves.  I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.

I suppose that this is in effect a way to ensure that the Bitcoin network stays strong, as it certainly is going to be making any sort of mining activity much more profitable by doing this.

What pricing strategies that would be used by a domain server which would have an adjustable price in the interface or config file and why one server would set the "price" at 10 BTC or another at 15 BTC or still another at 5 BTC?  Is this basically "filtering out spamsites" or is there something more serious going on here?  Is this simply an "open bid" for each domain where the most money invested "wins" the domain?

Toward the end of the document there is a reference after a fashion about some more complex fee allocation system that passes around addresses which get deposited into some servers after a fashion.  I guess this is where I'm totally missing the point here perhaps or not understanding what is going on at all with these fees as there is something more implied by this document not written down.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 07, 2010, 11:40:29 PM
 #166

What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

I have a couple questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

When you register a name, there is a fee to a DNS server. In the doc, this appears like a Bitcoin transaction fee. The first example shows 10.01 input and 0.01 output, so the 10.00 difference would be a transaction fee. But tx fees go to miners. Is it assumed that miners are the same as DNS servers? Or would there be a 2nd output, a fee to a particular DNS server to get it to register you, in addition to a tx fee to the miner?

Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

Thanks -

Hal Finney
Anonymous
Guest

December 08, 2010, 12:03:21 AM
 #167

This is exciting stuff. The benefits of having an intrinsic value to bitcoin is inestimable and kills a lot of arguments against it. I would like to hear satoshi's thoughts on this as forking the network is not a decision taken lightly.

Is there a way to reserve the top 1000 domains at Alexa ?  I can see massive issues down the road if say google has their name squatted on. Doing this would bring a lot of goodwill towards bitcoin rather than having all the top companies against it. One way this could be done is for the dev team or a council of bitcoin elders  register all of these names before the client is publicly released and hold them in trust. When a top 1000 company wishes to claim their name the profits could go to benefit bitcoin. Is that a good plan?


da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 08, 2010, 12:18:40 AM
 #168

Is there a way to reserve the top 1000 domains at Alexa ? 

This is a very good and important idea, we should set-up some 'domain trust' where well established domains will be protected until they are claimed (at a good fee) by a verified owner.

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

One off NP-Hard.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 12:22:05 AM
 #169

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

No, no, no. The DNS system should be kept as simple as possible.

There will be no silly voting, or court, or any complicating shit.

Anonymous
Guest

December 08, 2010, 12:34:19 AM
 #170

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

No, no, no. The DNS system should be kept as simple as possible.

There will be no silly voting, or court, or any complicating shit.

I think the delay in releasing the client would be enough for the top 1000 to be locked in
 

theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 08, 2010, 12:37:24 AM
 #171

I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.

That is the point.

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.

Quote
Is this basically "filtering out spamsites"

Exactly.

What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

Bitcoin already supports it technically, though recently a change was made that causes non-standard transactions such as the ones used by BitDNS to be skipped in blocks created by the official Bitcoin client. However, BitDNS transactions produce quite a lot of fees for generators, so if an implementation is created, I expect it will be easy to get a reasonable percentage of miners to ignore this new rule (only like 5% is really necessary).

Quote
Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

The left-most part has to stay the same. "theymos.btc" can be changed to "theymos.bc". Everything but the left-most part is advisory: "theymos.btc" can actually appear as "theymos.btcdns". In particular, if someone registers a top-level domain such as "theymos.", most servers will probably map it to "theymos.btc" or something.

Quote
Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

Anyone can run them. I think the expiry time should be lowered to like 5,000, though, to make it easier to run a server.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 08, 2010, 12:41:42 AM
 #172

I think reserving the top 1000 alexa domains by seeding the genesis block with those "registrations" would be an excellent show of good faith towards the world at large.  A council of bitcoin "elders" could be elected to hold the private keys to those initial 1000 domains, and turn them over when the time comes (for a fee, which will go towards bitcoin/domainchain community funds). 
da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 08, 2010, 12:48:00 AM
 #173

So in theory this is the perfect system for claiming a 'named address'.  If I wanted to send a payment to 'theymos.btcdns' I could. Or is my understanding wrong?

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 08, 2010, 12:51:13 AM
 #174

re-read nanotube's+theymos's proposal! Sound Good  Grin
+1

One off NP-Hard.
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 08, 2010, 01:27:07 AM
 #175

This is all very fascinating stuff.  I read themos+nanotube's proposal, ribuck's proposal, and rhorning's.  While I think I grasp the fundamental differences between them, I am not confident to weigh in.  Could I ask that someone more knowledgeable than I am on these matters create a table (wiki?) that lists the proposals as they currently are?

I'm personally very intrigued by the idea of piggy backing on the existing bitcoin network, if it can be done cleanly and with minimal modification to bitcoin (as per nanotube/themos suggested).

As Kiba pointed out, I am most excited for bitcoin to have it's intrinsic "use-value!"  And it couldn't come at a more needed time what with wikileaks, pirate bay, etc all over the news.

Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a "DomainShadow" system that is only used in the event of crisis (like wikileaks attack, etc)?

Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 02:08:20 AM
 #176


Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)

Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.

theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 08, 2010, 03:28:19 AM
 #177

Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a "DomainShadow" system that is only used in the event of crisis (like wikileaks attack, etc)?

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
December 08, 2010, 04:27:37 AM
 #178

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

just to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
Anonymous
Guest

December 08, 2010, 04:55:33 AM
 #179

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

just to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley

We need a proof of concept.  Smiley

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 04:57:55 AM
 #180

Yes, coding need to be done soon.


Repeating ad nauseum:

Speed is of the essence.

chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 08, 2010, 05:45:40 AM
 #181


Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)

Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.

Ha.  Good point.  I was thinking the two could potentially operate under the same umbrella.  We'll see though.
Anonymous
Guest

December 08, 2010, 06:48:30 AM
 #182

Referencing this thread http://bitcointalk.org/index.php?topic=2129.msg27968#msg27968

I think Gavin is trying to tell us the way forward .




BitDns is not bitcoin.  Smiley

We already have a forked chain.... Get something working on the test network and prove your theories.

Lets get it started in  here..... Cheesy






Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 08, 2010, 07:08:55 AM
 #183


A few more questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.

Names can be changed when registered, but only from one TLD to another. You could change pics.sex to pics.p2p. I don't understand the motivation for this. It seems like something that would seldom be useful.

I'm still confused about fees. I was assuming that fees would be paid to the DNS servers, for the service of acting as a gateway from the Bitcoin block chain to the DNS system. I now see another interpretation, where DNS servers don't receive the fees, but they nevertheless demand that transaction fees of a certain minimum level be paid to miners. As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?

The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today. (I may be misunderstanding this!) Each of these DNS servers publishes a schedule of fees for performing this service. To register a new name... hmm, I am guessing now. Would you contract with one particular DNS server to do something else than host your regular DNS records?

I had thought it would be ok to expect DNS servers to follow the block chain and honor valid domain name transactions without requiring certain minimum fees. Domain names are so valuable (at least at first) that miners already have ample motivation to demand substantial (like $100 = 500 Bitcoins per transaction) fees. Eventually, if the system is successful, virtually all DNS servers would read the block chain.

Hal Finney
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 08, 2010, 02:22:34 PM
 #184

I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.

That is the point.

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each "TLD" would have its own central server where you would have to "pay" to get onto that server?

What I don't see is the mechanism for how or even why a particular DNS server ought to even receive these fees as opposed to somebody else creating a "registrar server" and following this same protocol to put that data into Bitcions for considerably less or even "free".  This issue of where the money goes has been to me the issue all along, and the only place that could be identified easily as having done some sort of "proof of work" in terms of organizing the data is the block miner itself.... that is the Bitcoin block miner and not the DNS block miner as there is no sort of DNS block here at all.

I don't see any rationale for using a particular registrar other than merely because of sheer convenience and the hassle of setting up the software on your computer.

If there is some way that you might show some cryptographic "proof of work" in processing domain records, I might agree that a particular "registrar" deserves some separate fees in addition to the Bitcoin miner, but then the problem is how do you get those fees to that particular "DNS Block miner"?  Otherwise there isn't any sort of effort being put forth by the registrar at all where literally anybody could create some software to put these records into the system.

I could imagine a system where a sort of auction system on a particular domain happens where the person throwing the most number of bitcions in for a registration record "wins" the domain, but something seems a little off on that as well.  It also implies that anybody can "steal" your domain simply by throwing more coins at it than you have.  It is a great idea for miners, but lousy for those trying to register domains.

This is all about the money from my perspective, and this part has not been cleaned up for me upon reading the documentation.  The actual storage of the registration data itself has always been to me a trivial piece of the puzzle.  Throwing those records into Bitcoin transactions are useful as they do provide the time stamping and hashing ability of Bitcoin software, but any fees beyond Bitcoin transaction fees seem to be a pointless exercise without any sort of further proof-of-work.  Any additional fees being thrown with the "registration" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.  I could imagine some "greedy" DNS servers that might expect to be paid for bandwidth and being paid in Bitcoins or some other currency, or perhaps a very small fee for actually putting the transaction into the Bitcoin blocks for those who only have a "thin client" for Bitcoins, but those fees would be subject to a huge and highly competitive market where for most people it would be "free" anyway.

This is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 03:55:05 PM
 #185

I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.

The left-most part has to stay the same. "theymos.btc" can be changed to "theymos.bc". Everything but the left-most part is advisory: "theymos.btc" can actually appear as "theymos.btcdns". In particular, if someone registers a top-level domain such as "theymos.", most servers will probably map it to "theymos.btc" or something.

I really don't get this. What's the point of having a "right-hand-side" if it is advisory? The user doesn't want to have to type theymos.bc into their browser when they're at an internet cafe that uses one DNS, but have to type theymos.btcdns into their browser at home if their ISP uses a different DNS. And if they just type "theymos", what if they are on a LAN that has a node called theymos?

Any default right-hand-side should be explicit in the spec. Also, I don't think something hard-to-pronounce like ".btcdns" is going to work with the public. Can you imagine TV ads saying "go to walmart dot bee tee see dee en ess"?

In the initial phase at least, I suggest that all names registered should be of the form something.domain

I propose ".domain" for this purpose because it's generic and pronounceable. It also somewhat cheekily implies that this is the ultimate all-encompasing domain name registration system.

Three advantages:

  • This establishes clear branding.
  • It helps to keep the system simple, so that we can easily describe how to get up-and-running with these newfangled names.
  • It avoids any clashes with existing domain names.

If people prefer to go for something more ambitious, I suggest that all names registered should be of the form something.tld where .tld can be anything of three or more characters except for existing recognised top level domains. So you could register hamburger.red or silly.fool but not zebra.com
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 04:00:02 PM
 #186

Is there a way to reserve the top 1000 domains at Alexa ?

Please let's drop the idea of reserving the top names. Would you think it was fair if you owned the 1001st domain? It's only going to lead to disputes and hassles.

I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 04:02:27 PM
 #187


We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.
It could set some precedent for protocol change that allow people to shut down certain domains.

I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 04:16:39 PM
 #188

My concern is that there would be a rush to grab hot domains.

If desired, an initial rush could be spread out by a phased introduction.

For example, in the first week only names of ten characters or longer would be accepted for registration. The next week, names of nine characters or longer would be accepted. And so on, until by week ten any length will be accepted.

A more sophisticated phasing would hash the domain name to a number from 1 to 1000. On each of the first thousand days, names that hash to that day's number are added to those that can be registered. So, by day 42 it would be possible to register any domain name that hashed to a number in the range 1 to 42. After day 1000, any name could be registered.

A third possibility is simply to limit the number of registrations. Suppose each block limited the maximum number of domain name registrations to the current generation difficulty divided by 1024. For now, that would mean 8 domain name registrations per block, but the limit would rise over time (quite quickly, I think).

I'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 08, 2010, 04:18:12 PM
 #189

I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.

Agreed.  I suggested in my previous domain allocation system that the standard ICANN/InterNIC domains and perhaps to be fair some of the domains currently being done with other networks like OpenNIC and the .onion "domain" of the Bittorrent network ought to be held in "reserve" as a part of the internal protocol we are setting up here.  My suggested domain allocation system would have that as an organic part of the system although it would be useful to hold these TLD in escrow for whenever or if ICANN wants to have control of them.

Since to use one of the TLDs with a server you would need to have it assigned to an IP address of some sort, somebody like Google could go aver "google.btc" as a trademark violation by searching for the network which assigned the IP address of the server using that name.  If the domain record points to 127.0.0.1, it really isn't a threat to Google until that address changes anyway.  I agree that this is beyond the scope of this protocol to take care of the Alexa top 1000 names and the only real issue is spoofing existing domain names being used by other DNS registries.

As a side note, during the actual reference implementation of one of these servers it would be nice to throw a bone to OpenNIC and the "dot P2P" guys (presuming they set up their own system) to forward DNS requests that might fall under those respective domain registries.  This is sort of a tip of the hat to say thanks for making sure ICANN doesn't have 100% exclusive control over domain registrations and to support what I think are good projects in their own right even if they aren't a P2P distributed naming system.  That might even get a reciprocal agreement with those alternate domain registries to spread these registrations with the DomainChain registries much further at least initially.
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 08, 2010, 04:27:27 PM
 #190

It could set some precedent for protocol change that allow people to shut down certain domains.

I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.

Who would be given the "authority" to remove domain names?  That implies central authority of some sort that has control over this network.

Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to "delist" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your hands up and say "I can't change that, sorry".

The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:24:09 PM
 #191


Who would be given the "authority" to remove domain names?  That implies central authority of some sort that has control over this network.

Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to "delist" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your handseddrli up and say "I can't change that, sorry".

The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.

You have forgotten the rule that I asserted earlier in the thread:

Quote
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 08, 2010, 05:43:54 PM
 #192

Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to "somebody" to take care of that issue.  You could have a "voting" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore "by consensus" drop the domain.  It would also provide an unneeded attack vector on the network as well as the "votes" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.

I just don't know of an effective way to kill a domain record shy of simply letting it expire.  As long as the registration is following the rules of the network (however we set that up), I don't see how it could possibly be removed.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:44:54 PM
 #193


Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to "somebody" to take care of that issue.  You could have a "voting" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore "by consensus" drop the domain.  It would also provide an unneeded attack vector on the network as well as the "votes" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.

You misunderstood me. I didn't suggest anything like voting or whatever.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 05:49:22 PM
 #194

The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.

My design stores the domain name plus a couple of nameserver IP addresses (say, 50 bytes) for an everlasting registration.

The theymos/nanotube design needs much more data: the initial registration, the regular renewals, and the possibility to include actual DNS records themselves up to 520 bytes. There's talk of the renewals being required perhaps as frequently as every 2000 blocks, and certainly no more than every 52000 blocks.

Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.

I'm starting to think that an everlasting registration really is the way to go. In the DomainChain design, the registration would not be affected by block chain compaction, since compaction only affects spent transactions. If you transfer a DomainChain registration, or modify its name servers, all of the necessary information is contained in the latest transaction, which will remain unspent until the registration is deliberately modified. However, the theymos/nanotube design requires a sequence of transactions (registration, extra fee, DNS record, ...) where only the last transaction in the sequence remains unspent.

I think users will be uneasy about having to renew every 2000 or even 52000 blocks. Having to remember to renew, in order to avoid losing your registration, is bad enough. But block generation rates are variable, so that you won't even know for sure when your renewal falls due. Unpredictable renewals are not something that would make me feel good about using such a system for my domain name registrations. I can see many accidental domain name losses occurring under this system.

Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:54:03 PM
 #195


Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.

Time based expiry date rather than block based expiration system. Obviously registrar could remain users to renew as they had done in the earlier system.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 08, 2010, 06:53:43 PM
 #196

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.

Re-reading this, I think I "get" how this is going to work for registrars, at least how Theymos is proposing here.

Each "Domain server" would separately and independently charge a fee for "registering" the domain on that particular server, where essentially everybody would be paid simultaneously when a new domain would be registered.

Something here just doesn't sound right, which is why I keep bringing this up.  I don't see the mechanism for recognizing new domain servers or what criteria ought to be used so far as to whom these fees are going to be allocated.  A domain server which is regularly being used by just a couple computers in a small office would in this case be a "peer" to a domain server at a major university servicing perhaps thousands of computers for domains.  Yet in this case both would be receiving registration fees and from a network perspective would be indistinguishable.  However getting "your domain" recognized by that major university server would be much more "valuable" than the server in a small office.  Any attempt to report usage could easily be manipulated in a number of ways making it to me impossible to realistically distinguish between the two servers, at least algorithmically.

Maybe I'm missing something fundamental here.  I sure hope so.  It seems sort of silly for somebody to set up a "domain name server" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used.  That sounds like a neat gig to get into, but I don't understand what "service" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered "equal" and receive roughly the same amount of money?
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 07:52:14 PM
 #197

I think we should dispense with the complexity associated with paying various servers. We should also dispense with the concept of paying more if we want better visibility for our domain names.

No-one wants a system where some people can reach some.domain and some people can't, depending on which servers are getting their share of the payment. Or a system where a new server can come to prominence and put pressure on people to pay again for the domains they already paid for.

Let's cut it down to the simplest business model that can work.

Suppose there are some generators who will include domain name registrations into blocks that they generate, because they want to earn the transaction fees. Those generators will operate public-facing domain name servers.

Why? They need to do this, to make the domain name service credible so that people will use DomainChain for their domain registrations. For the generators, it's an overhead, but a necessary one. Kind of like how most restaurants provide toilets without charging separately for them.

You could argue that there will also be some operators who would generate, and who would collect the transaction fees for domain name registrations, but who would not operate a server. After all, why incur the overhead if the other generators will operate the servers?

But the market will take care of this. The generators who do operate servers are not going to accept the blocks generated by those who sell domain names without providing domain name servers.

Additionally, a market like this is likely to have two other kinds of players.

There will be a few organizations who are willing to operate a server for free, perhaps for ideological reasons. Those servers will probably be overloaded and slow (like the free Usenet servers), but they act as a backstop which forces the commercial operators to provide something better.

There will also be a few commercial operators who provide enhanced super-fast servers without being generators. They will do this either because they have paying customers who want the best domain name service that is possible, or they will do it for their own business reasons (as Google does with their free-to-access domain name servers).

Here are the advantages of this simpler system:

  • For the domain name owner, the registration is convenient, secure, and lasts forever,
  • For the internet user, the same set of domains is served to everyone,
  • For the generators, it's a worthwhile extra source of income, and
  • For the Bitcoin system, it's an easy way to get extra strength into the block chain with minimal extra data
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 07:57:04 PM
 #198

Time based expiry date rather than block based expiration system.
Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.

Of course, there is nothing that forces the providers of domain name servers to compact their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 08, 2010, 08:10:14 PM
 #199

I agree with ribuck that DNS servers don't necessarily need to get paid, to support Bitcoin domains. After all, what is the purpose of a DNS server? It is to lookup domains for its clients, which are users wanting to connect to computers using domain names. If BitDNS becomes popular, DNS servers will want to be able to lookup those domains too. All that is necessary is to track the block chain and maintain indexes and hash tables to record which domains are in effect and their basic DNS data. DNS servers don't have to be Bitcoin miners. The existing motivations for DNS servers to operate and provide lookup serves to their clients will be sufficient to make them track Bitcoin domains.

Hal Finney
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 10:48:14 PM
 #200

DomainChain wiki is here:
http://domainchain.org/wiki/doku.php?id=start

There's not much there, but I will work on it tomorrow.

Meanwhile, some interesting further ideas on integrating with the Bitcoin block chain have been added to the Theymos/Nanotube wiki.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 08, 2010, 11:36:46 PM
 #201


It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.

This is like that, too. In this system, you're always registering a TLD. Even if I register "theymos.btc", I'm actually getting "theymos.". For better usability, though, BitDNS servers will make this a second-level domain by attaching a TLD like .bitdns or .btc to the registered name. The TLD in the registration is a suggestion for this: in this case, I'm suggesting that "theymos." be followed by "btc" (though the server is free to ignore my suggestion).

The idea is to allow maximum market adaptability. Probably all servers will just use ".btc" or whatever, and totally ignore the suggested value. As an example of something servers could do:
- If your suggested domain suffix is com/org/etc., then your domain will actually overrule .com domains of the same domain for those few users who have configured BitDNS to do so.
- Otherwise, ".btc" is used.

It's a bad idea to hardcode any TLD into the spec. What if ICANN allocates .btc?

A later version might also look at the entire name+TLD for uniqueness. It might be possible in that case to switch from old-style names to new-style names with namechange.

Quote
As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?

Yes. The idea is not to compensate the servers (usually), but to eliminate spam registrations. The BTC is the "proof-of-work".

Quote
The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today.

The servers are analogous to DNS root servers. There may also be registrars, which will interface with several BitDNS servers (as current registrars interface with gtld-servers.net, for example).

In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each "TLD" would have its own central server where you would have to "pay" to get onto that server?

Certainly not. You pay and everyone recognizes you at whatever TLDs they have chosen to see BitDNS domains at.

Quote
Any additional fees being thrown with the "registration" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.

Almost all of the load is carried by the Bitcoin miners, which is why they get most of the money. Some BitDNS servers will provide public lookup services, which demands some payment. I'm thinking that the registrants will pay these to list them, but maybe the people looking up BitDNS domains will pay them instead.

Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.

The average Bitcoin transaction size is 216 bytes. Why does anyone care if BitDNS names are worth 3-500 Bitcoin transactions over 10 years? If miners are taking the transactions, then there is no supply problem. If there is a supply problem, then whoever pays more gets space in blocks. This is fair.

Quote
I'm starting to think that an everlasting registration really is the way to go.

Without an expiration, you need to download the entire block chain to get a current DNS database. Domains must expire if you want to allow end-users to run their own server.

It also destroys unique resources. The pricing scheme would have to control the use of these unique resources appropriately, which requires some market mechanism.


1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 08, 2010, 11:50:14 PM
 #202

You have forgotten the rule that I asserted earlier in the thread:

Quote
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

Kiba is wise beyond his years!

Anyway, I've been thinking outside the box a little bit...and wondering maybe to scratch the whole idea of domain names.  I'm thinking somehow be able to associate a bitcoin address, or maybe some hash of a transaction, with a location on the internet somehow.  Also, it maybe possible to sidestep away from the concept of domain names considering that nowadays search engine technology has improved so much.

Wouldn't it be cool to associate a bitcoin address directly with a webpage/internet location for that product/resource/whatever that is being sold with that bitcoin address?  Anyway, let me think about this some more and write out a concrete proposal.  Obviously, this is sortof off topic from this thread...

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 09, 2010, 12:28:09 AM
 #203

Asking as a general question, is the whole concept of throwing the data into transactions a dead issue now?  With the release of Bitcoin v. 3.1.18 Satoshi has essentially thrown down the gauntlet that adding such data to transactions is considered a form of an attack on the network.  Miners who aren't using a codebase derived from the reference implementation still may add blocks to the network involving these "goofy" transaction packets, but by design the reference implementation will not recognize the transactions.  If we work around the IsStandard() algorithm, it is only going to change to stop whatever changes we make.

This is a subtle but interesting issue where essentially the only way we can guarantee that a domain transaction can be put into a block chain is to create a custom miner and compete for blocks to put those transactions into the network.  That makes for some interesting problems in terms of latency for an effort like DomainCoin.

Should we move onto the forked version of Bitcoin to implement this idea again?
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 09, 2010, 12:39:12 AM
 #204

Miners are rejecting the [edit]isStandard.

RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 09, 2010, 12:52:19 AM
 #205

Miners are rejecting the same.

How are the miners going to get these transactions?  I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.  I'll have to dig into the 0.3.18 source code for the details, but the description is just an initial shot across the bow on this concept.  If you have a miner as a peer who ignores this algorithm, they might get put into the block, otherwise you might just be SOL.  From what I understand, if all of your peers are 0.3.18 clients (and presumably later versions too) they won't even forward transactions to other peer nodes that are "corrupted".

It is a subtle change, but it is a big deal.
MoonShadow
Legendary
*
Offline Offline

Activity: 1694



View Profile
December 09, 2010, 12:57:59 AM
 #206


It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.

This is like that, too. In this system, you're always registering a TLD.


So what would prevent me from registering the domain jackass.theymos.btc? 

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 09, 2010, 12:59:20 AM
 #207

Others elsewhere or previously have suggested we build a chain dependent on the bitcoin chain. Some way to hash the data against a block.

That way, miners would still be strengthening the bitcoin network.

appamatto
Jr. Member
*
Offline Offline

Activity: 36


View Profile
December 09, 2010, 01:27:49 AM
 #208

Hey guys.  I'm really surprised that my post received so much attention!

And, I'm glad that BitDNS (or domain chain?) has generated this level excitement.

However, I urge you to re-read my initial post, as I feel that original formulation of the idea solves many of the problems you are currently discussing, including the (1) business-plan problem and (2) the bitcoin integration problem.  There is also a third problem which hasn't been brought up by anyone thus far, which is (3) the problem of dividing the CPU pool among multiple block chains.

In the original formulation, bitDNS is simply an example of a possible generalization of bitcoin.  It should be possible to dream up many such applications requiring block chains for systems that need some kind of quorum.

We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.

BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.  This way a bitDNS server will only need to download its own app payload without worrying about bitcoin's payload and vice-versa.  As the number of bit-apps increase, this problem of smushing them all into bitcoin will only get worse, and (2) becomes a big problem that has to be solved for each app.  BitX neatly deals with applications liberally, leaving it completely up to them to decide their own protocols but forming a valuable backbone for them.

With bitcoin and bitDNS as separate apps running on BitX, (1) is easily solved with third-party escrows.  Escrowing is a big problem, and perhaps unsolveable, with respect to bitcoin and USD or PPUSD transactions, but it is incredibly reliable when executed between two bitapps.  A trusted escrow can receive both transactions, verify them mechanically and automatically release the assets when both transactions are properly verified.

Note that this also frees bitDNS from bitcoin baggage when bitMoney overtakes bitcoin as the most popular bit-currency.  I believe in fact that bitcoin in its present form will necessarily be overtaken due to problem (3).

The big deal: the CPU pool division problem.  CPU division will occur when bitcoin can't or won't support bit-application bitFoo.  This may occur with bitDNS, or it may occur later, but I think it will occur at some point.

Every miner for bitFoo will be one less miner for bitcoin and vice-versa.  Both of these systems will be twice as susceptible to attack (if they have roughly equal CPU pools), and the problem multiplies as the number of bit-apps and their block chains increases.

BitX cleanly solves this by having every bit-app generate on the same block chain, the BitX chain.  They weave their own block chains within the uber-chain, and unwittingly protect eachother from attack.  It also greatly speeds adoption of any given bit-app; the BitX miners are already generating bitcoins, so why not generate bitDNS names as well?  There is no cost to the miner, and who knows, this new-fangled bitDNS thing might actually take off someday?

Even if the demerits of separate block chains can be mitigated, the merits of a unified chain cannot be overstated in my view.

Finally, I hope that the name will remain BitDNS or BitNames, keeping the trend of revolutionary projects like bittorrent and bitcoin.  There isn't any reason to call it domainchain if it is built upon BitX in any case, because the name registration aspect will be an implementation on top of the BitX chain rather than a full implementation with its own chain.

This separation of concerns makes BitX and bitDNS/bitcoin simple enough that I feel I can implement them myself if necessary, although slowly, in my spare time.  I'm looking forward to some bit fun!

Thanks guys!
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 09, 2010, 01:38:56 AM
 #209

So what would prevent me from registering the domain jackass.theymos.btc? 

Nothing. But hopefully servers will ignore tricks like that.

How are the miners going to get these transactions?  I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.

Right. You can send directly to artforz.ath.cx or any of doublec's pool addresses. I will relay non-standard transactions at theymos.ath.cx.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 09, 2010, 01:50:23 AM
 #210

We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.

BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.

Responded, in this new thread.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 09, 2010, 02:24:16 AM
 #211

I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.

The solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.

EDIT: see http://bitcointalk.org/index.php?topic=1847.0  for info about how the transaction fees will dictate what is included in the chain.

One off NP-Hard.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 09, 2010, 02:30:39 AM
 #212

I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.

The solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.


Bigger stuff mean higher priority. Bitcoin users who didn't load the bitcoin chain data with lards are left with lower priority.

Anonymous
Guest

December 09, 2010, 10:19:17 AM
 #213

Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.

Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.

Whos in?
da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 09, 2010, 10:27:57 AM
 #214

Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.

Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.

Whos in?

Not me! I think that nanotube's+theymos's proposal has real elegance! Creating another chain is all good and well, but the current chain can be used for many things, might as well maximize it's potential.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

One off NP-Hard.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 09, 2010, 11:15:13 AM
 #215

Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.

Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.

Whos in?

I'm not in for a new genesis block. It risks harming Bitcoin. If the alternative block chain is commercially successful, someone will add a currency to the alternate chain and it will overtake Bitcoin.

Anyway, don't think that Satoshi has killed the idea of Domain Names in the block chain. Here's what the latest changes mean:

1. If you register a domain name, you must connect to a miner that supports it (because standard clients won't relay your request). No problem. You will need to be using a modified client anyway (to give you a way to specify the domain name, the IP addresses and the fee) and the client can be designed to connect to known performant miners (which will probably be most of them).

2. The standard Bitcoin clients will accept the blocks generated by the performant miners, but won't see the Domain Name transactions.

So what's the problem? What's not to like?

I say we should continue to develop the ideas, then try them out on the test network.
Anonymous
Guest

December 09, 2010, 11:18:54 AM
 #216

I still hear talking.  Smiley
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 09, 2010, 02:01:16 PM
 #217

I was doing some reasearch into alternatives to DNS, and I was reading about how TOR's hidden services assigned .onion address, and I came across the concept of Zooko's Triangle, which argues that names cannot be global, secure, and memorable, all at the same time:



"Domain names, for example, are global and memorable, but as the rapid rise of phishing demonstrates, they are not secure".  Basically, there will always be imposters who try to claim the domain name of your brand or some misspelling.  So I'm almost wondering if the whole concept of domain names is fundamentally flawed to begin with.  And it seems there is always has to be some sort of centralized means of allocating domain names.  We can't even decide what should be the rate-of-issue for new bitDNS domain names, what the starting price should be for transaction/purchase, how many top Alexis domain names (if any) we should reserve, where/how should the domain directory be located/stored. Maybe we need to stop using domain names entirely, and put our focus more on search engines, links, coupled with public-key cryptography to authenticate the genuity of an internet brand/website/address.  I'm looking into some system called Pet Names...and am trying to figure out a nice way they could be used to assign unique, human-readable (memorable), and global names for bitcoin addresses.  I will start another thread for this, and provide a link here...

Anyway, I think NoAgenda is right here that the Bitcoin block chain, from now on, should be a pure financial vehicle, considering that the latest bitcoin version update removes the ability to include extra text in transactions:

Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 09, 2010, 02:36:11 PM
 #218

Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.

The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.

... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...

Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.
em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 09, 2010, 02:59:24 PM
 #219

Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.

of course, I didn't mean I wanted to redesign the whole DNS.  The conclusion of my musing is: maybe there is some way to associate bitcoin addresses with a unique and human readable (memorable) name using a petname system.

The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.

I think this is important, and I encourage people to work on this.

... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...

Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.

Ok, thanks for clarifying.

"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 09, 2010, 07:41:36 PM
 #220

Of likely interest:

"Gov't crackdown spurs initiatives to route around DNS"
http://www.itworld.com/legal/129947/net-censorship-dns-alternative
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 09, 2010, 07:51:05 PM
 #221

Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.

* kiba is anxious.

satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364


View Profile
December 09, 2010, 09:02:42 PM
 #222

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

Instead of fragmentation, networks share and augment each other's total CPU power.  This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one.  Instead, all networks in the world would share combined CPU power, increasing the total strength.  It would make it easier for small networks to get started by tapping into a ready base of miners.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 09, 2010, 09:05:36 PM
 #223

Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post.

* kiba is anxious.

Don't be anxious. I already said I thought it would take 2 weeks to agree design directions before coding.

There has been excellent development over the past 24 hours. It has become clear that Gavin's changes to handling of non-standard transactions don't rule out domain registration integrated with Bitcoin.

It is also becoming clearer that there is less distance between my DomainChains ideas and the theymos/nanotube design. Their design does not have the tangled ties with domain name server operators, that I previously thought it did.

Hang in there! Two weeks will seem like nothing in the long term outcome.
nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
December 09, 2010, 09:20:40 PM
 #224

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

sounds excellent in theory...

Quote
The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

very curious to hear your further thoughts on this. Smiley

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 09, 2010, 09:32:35 PM
 #225

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

This sounds very very interesting, something to explore.

Can you elaborate on how would it work in practice?  Separate networks and block chains implies hashing one block header for each network, with different resulting hashes, does it not?

The only thing I can come up with is the completely naive and slightly cache-unfriendly implementation...

while (nonce < 0xffffff)
    nonce++
    for each network
        data_block[nonce_offset] = nonce        // ie. our nonce
        scanhash(data_block)

or

for each network
    while (nonce < 0xffff)
        data_block[nonce_offset]++
        scanhash(data_block)

I could easily update cpuminer to poll multiple RPC endpoints for 'getwork'...

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 09, 2010, 09:49:06 PM
 #226

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

Same incentive as the main chain -- you get paid.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Anonymous
Guest

December 09, 2010, 10:23:37 PM
 #227

So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?

Its a simple elegant solution from satoshi.

nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
December 09, 2010, 10:43:26 PM
 #228

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

Same incentive as the main chain -- you get paid.

but if you get paid just as much by mining pure bitcoin without the side hashing...

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364


View Profile
December 09, 2010, 10:46:50 PM
 #229

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work.

While you are generating bitcoins, why not also get free domain names for the same work?

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

You have one piece of work.  If you solve it, it will solve a block from both Bitcoin and BitDNS.  In concept, they're tied together by a Merkle Tree.  To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.

In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal.  You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility.  We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.

Note that the chains are below this new Merkle Tree.  That is, each of Bitcoin and BitDNS have their own chain links inside their blocks.  This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain.  This is two timestamp servers not sharing a chain.
Judson
Newbie
*
Offline Offline

Activity: 22



View Profile
December 09, 2010, 11:00:25 PM
 #230

I agree with satoshi's idea. It seems like the best of both worlds.

da2ce7
Legendary
*
Offline Offline

Activity: 1222


Live and Let Live


View Profile
December 10, 2010, 12:10:07 AM
 #231

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

I'm still trying to get my head around your idea completely.  The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins.

I gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity.  The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number.

In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market.  As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.

One off NP-Hard.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2842


View Profile
December 10, 2010, 12:18:00 AM
 #232

Satoshi's idea eliminates the need for BitX. Alternative chains can be made without splitting CPU power.

Our version of BitDNS would never use its own chain, though, because creating domains should not be tied to a proof-of-work, and we therefore have no generation incentive.

120 bytes with an OP_CHECKSIG is enough for our proposal, I think.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
RHorning
Full Member
***
Offline Offline

Activity: 224


View Profile
December 10, 2010, 01:23:10 AM
 #233