Bitcoin Forum
March 19, 2024, 07:57:50 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 122381 times)
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
November 15, 2010, 03:02:31 AM
Merited by ABCbits (6), realdantreccia (3), EFS (2), nutildah (1), F2b (1)
 #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
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710835070
Hero Member
*
Offline Offline

Posts: 1710835070

View Profile Personal Message (Offline)

Ignore
1710835070
Reply with quote  #2

1710835070
Report to moderator
1710835070
Hero Member
*
Offline Offline

Posts: 1710835070

View Profile Personal Message (Offline)

Ignore
1710835070
Reply with quote  #2

1710835070
Report to moderator
1710835070
Hero Member
*
Offline Offline

Posts: 1710835070

View Profile Personal Message (Offline)

Ignore
1710835070
Reply with quote  #2

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

Activity: 489
Merit: 504



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
Merit: 2164


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 (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


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 (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


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: 489
Merit: 504



View Profile WWW
November 16, 2010, 06:53:15 AM
Merited by F2b (1)
 #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 (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


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: 489
Merit: 504



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
Merit: 277


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 (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


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
Merit: 500


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
Merit: 0


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
Merit: 1014


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

Quick! Offer a bounty in bitcoin!

sandos
Sr. Member
****
Offline Offline

Activity: 436
Merit: 250


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
Merit: 1014


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: 308
Merit: 100


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
Merit: 1014


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
Newbie
*
Offline Offline

Activity: 56
Merit: 0



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
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


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


retarded means "slowed" which ironically is the case here

Huh

tyler
Newbie
*
Offline Offline

Activity: 56
Merit: 0



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
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


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
Merit: 141


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
Merit: 1014


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

How would domain name renewal work?  Huh

RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


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
Merit: 1014


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
Merit: 141


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Merit: 141


View Profile
December 02, 2010, 06:46:01 PM
Merited by F2b (1)
 #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: 308
Merit: 100


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
Merit: 141


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: 308
Merit: 100


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
Merit: 1014


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
Merit: 1014


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
Merit: 3797



View Profile
December 04, 2010, 07:47:51 PM
Merited by F2b (1)
 #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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 141


View Profile
December 04, 2010, 08:44:11 PM
Merited by F2b (1)
 #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
Merit: 1014


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
Merit: 3797



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
Merit: 1005


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
Merit: 1014


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
Merit: 1014


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
Merit: 1014


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
Merit: 141


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
Merit: 0


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 251


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
Merit: 141


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 101


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
Merit: 1014


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
Merit: 141


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
Merit: 141


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 101


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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

I have no complaint.

ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 10


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
Merit: 1014


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
Merit: 141


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
Merit: 141


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
Merit: 101


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
Merit: 3797



View Profile
December 06, 2010, 09:18:07 PM
Merited by OgNasty (100), EFS (100)
 #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
Merit: 251


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
Merit: 141


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
Merit: 3797



View Profile
December 06, 2010, 09:53:13 PM
Merited by F2b (1)
 #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
Merit: 141


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
Merit: 251


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 141


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
Merit: 1014


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
Merit: 141


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
Merit: 10


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
Merit: 141


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
Last edit: December 07, 2010, 12:44:33 AM by noagendamarket
 #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
Merit: 3797



View Profile
December 07, 2010, 12:29:38 AM
Merited by OgNasty (25)
 #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
Merit: 1014


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
Merit: 141


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
Merit: 101


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
Merit: 141


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
Merit: 1014


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
Merit: 3797



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
Merit: 1014


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
Merit: 141


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
Merit: 141


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
Merit: 1014


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
Merit: 251


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
Merit: 3797



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
Merit: 251


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 07, 2010, 04:56:51 AM
Last edit: December 07, 2010, 05:21:28 AM by em3rgentOrdr
 #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
Merit: 1014


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


I RAGE.

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434
Merit: 251


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
Merit: 1014


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
Merit: 3797



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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Merit: 101


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
Merit: 141


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Merit: 101


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
Merit: 141


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
Merit: 1014


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
Merit: 141


View Profile
December 07, 2010, 02:13:34 PM
Merited by F2b (1)
 #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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 1014


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
Merit: 141


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 07, 2010, 04:51:20 PM
Last edit: December 08, 2010, 04:03:46 PM by ribuck
 #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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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: 5138
Merit: 12565


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 3797



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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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: 482
Merit: 501


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
Merit: 251


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
Merit: 1014


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
Merit: 251


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
Merit: 141


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
Merit: 3797



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
Merit: 1016


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
Merit: 1014


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: 5138
Merit: 12565


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
Merit: 101


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
Merit: 1016


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
Merit: 1016


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
Merit: 101


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
Merit: 1014


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: 5138
Merit: 12565


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: 482
Merit: 501


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
Merit: 1014


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
Merit: 101


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
Merit: 3797



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
Merit: 141


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 141


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
Merit: 141


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
Merit: 1014


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
Merit: 141


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
Merit: 1014


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 141


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 3797



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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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: 5138
Merit: 12565


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
Merit: 251


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
Merit: 141


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
Merit: 1014


View Profile
December 09, 2010, 12:39:12 AM
Last edit: December 09, 2010, 12:56:57 AM by kiba
 #204

Miners are rejecting the [edit]isStandard.

RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


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: 1708
Merit: 1007



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
Merit: 1014


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 (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


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: 5138
Merit: 12565


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: 1596
Merit: 1091


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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


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
Merit: 1014


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
Merit: 1016


Live and Let Live


View Profile
December 09, 2010, 10:27:57 AM
Last edit: December 09, 2010, 10:54:27 AM by da2ce7
 #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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 251


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 251


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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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
Merit: 1014


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
Merit: 6610


View Profile
December 09, 2010, 09:02:42 PM
Merited by garlonicon (100), o_e_l_e_o (4), ABCbits (3), realdantreccia (3), BitcoinFX (1), elianite (1), Traxo (1)
 #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
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


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: 482
Merit: 501


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: 1596
Merit: 1091


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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
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: 482
Merit: 501


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
Merit: 6610


View Profile
December 09, 2010, 10:46:50 PM
Last edit: December 09, 2010, 11:19:08 PM by satoshi
Merited by EFS (100), garlonicon (100), realdantreccia (3), ImHash (1), vjudeu (1)
 #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
Merit: 0



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
Merit: 1016


Live and Let Live


View Profile
December 10, 2010, 12:10:07 AM
Last edit: December 10, 2010, 12:24:56 AM by da2ce7
 #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: 5138
Merit: 12565


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
Merit: 141


View Profile
December 10, 2010, 01:23:10 AM
 #233

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.



While I like the idea in general, it doesn't really solve the problem in terms of parallel currencies.  I don't think the idea of where the CPU power was going to come from for powering this network was ever an issue.  People who got into mining would go wherever the money was at and find solutions to "earn" whatever coins happen to be around.

I do like the idea of pooling Bitcoin-like block chains in terms of attempting to "earn" hashes, and if there were more ways use CPU power to generate hashes it can only be beneficial to everybody involved.

I still would like to use miners for "authentication" of the DomainCoin registrations in some way and I'm trying to come up with a good system to get that done.  By authentication I'm referring to basic "rules" that can verify that a domain hasn't been claimed, and a "miner" who doesn't follow those rules as accepted by the rest of the network gets that block rejected.  That is happening right now with Bitcion in regards to transactions, but doesn't happen with any other data and won't happen with other data at least as it is presented.

It still gets to the issue I presented earlier on another thread:

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

I think I've asked this question a number of times getting the run around.  Perhaps I'll be more clear with this example as proposed by Caveden:

If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?

If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.

This is an intractable problem if you want to include the data itself in an authenticated form in a chain block and have that chain block directly connected to Bitcoin without a parallel currency.  Theymos simply ignores the issue entirely with his protocol.... which is fine as far as that goes but a miner isn't really being paid to process domain registrations and certainly isn't authenticating bad registrations.  The real "work" in terms of a DNS system is to authenticate precisely who "owns" the domain and make sure that somebody else can't claim that domain.  The Theymos/Nanotube protocol forces authentication into a free good, and puts potential attacks on the protocol into the hands of the Bitcoin network... where I don't think it belongs either.

I firmly believe that the data for domains must be in an authenticated system, preferably its own independent chain (perhaps linked to Bitcoin), where all of those serving this data can agree upon the same information and there is no ambiguity about the data.  Previous proposals that shove the data into the transactions of Bitcoins fail to get that accomplished.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 11:23:32 AM
 #234

The incentive is to get the rewards from the extra side chains also for the same work.

You don't really get any extra reward. Either you are collecting generation fees + transaction fees from the Bitcoin side, plus some profits from the Domain Name side. Or, everything is in the Bitcoin block and you earn the same total profits, but all from the Bitcoin side (due to the additional Domain Name transaction fees on the Bitcoin side).
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 12:21:34 PM
 #235

[edit: nevermind this post. I haven't been able to express my idea clearly here.]

Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.

To register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.

So obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.

A domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 10, 2010, 12:29:00 PM
 #236

Introduction of BitX reduces the likelihood that will be invented a way to cut the chain?

Or is it generally no longer considered a necessity?

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 10, 2010, 01:39:27 PM
 #237

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
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.

The thing is that the miner receiving the transaction fee is just getting that as a sort of free lunch.  The fee may be in place to cut out spammers, but they aren't doing any work so far as anything to do with the DNS system.  Those computers which are processing and authenticating the raw data are not getting any sort of fee at all and the generators are not being compensated in Bitcions.  All that is happening is that the miners are getting paid essentially as a data storage service entirely, and that is of marginal utility in my opinion.

This is also why there are some huge complaints about using the Bitcion blockchain as a generic data storage system... rightfully so I might add.

Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.

Let's assume for a minute we have another block chain which contains just domain data which is cryptographically hashed, but may or may not have proof of work (let's ignore that for now, which I'll address below).  The purpose of the block chain is for the authentication of the data primarily where the "network" of domain servers can "certify" that the data fits the network rules and that domain data within that chain is valid in terms of who "owns" what domain.  As a public block chain, it also shows what the majority of the "network" agrees ought to be in that chain too.  Improperly formatted data that is not agreed to by the majority of the network is rejected from this block.  Since it is a chain it also verifies against tampering and does a timestamp, and more importantly by being outside of the main Bitcoin chain it reduces the data payload for what is admittedly a specialized service which not all Bitcion users are necessarily interested in.  These are the features of the Bitcoin transaction database that are being desired to be applied to other sets of data.

So far that is the easy stuff.  We also want to set up some system where the "registrar" putting data into this chain is going to be "paid" for the registration and authentication of this system.  I emphasize this as this is both going to be a reason to be a registrar as to even exist as a registrar has a strong financial stake in maintaining the database to receive more registrations, and provides a reason to have fees to cut down on spamming domain names or abusing the public commons.  The fees are being paid to maintain the database, which is the important thing here.  Without this fee, at best this database is being authenticated and supplied to the world at large strictly as a public service for free.  Some people like that but I hope that those involved with the Bitcoin project can appreciate how being paid for such a service can be very useful and motivating.  The Theymos/Nanotube proposal and for that matter all registrations into the Bitcoin database through extra data in a transaction sidestep this issue entirely by ignoring authentication and only using the timestamp ability of Bitcoin, where this database would have to be built anyway but derived from Bitcoin and thus provided as a public service for free.

Here is the real issue, however:  Since there is no central server, the registrant wants to make sure their registration is put in by whatever registrar happens to be in line to put in the next record onto the block chain, however that is decided (by proof of work or some other agreed upon system).  They want to send out some sort of generic transaction that can be received by the "authenticator" of their registration application who puts this registration into that block chain.  Only if their registration is accepted into the block chain should that authenticator be paid.

A problem arises here:  A bitcoin miner may know that a fee is available from a registrant, but how do you decide where those coins properly belong?  Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute (it likely will happen just like it is happening with Bitcoin even now) those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block.  Some other registrar may pick up the registration and simply out of the kindness of their heart decide to include it in another block, but they won't be receiving any fee at all for that service.  Some system could be perhaps set up where after a block is down to a given depth in the block chain that the fee can be "released".  Still, regardless of how you set this up there will be some trolls who will be collecting fees, pretending to put stuff into the domain registry but not really caring about the domain registry protocols and siphoning off the fees for themselves, perhaps in collaboration with a Bitcoin miner.  Since this represents serious money, there will always be some trolls doing this.  Even an "honest" registrar is still going to make some mistakes due to a bug or something similar which may on occasion capture fees when they are deserved under this system.

I believe the fee system is critical to the success of this domain registration system.  That ensures selfish behavior on the part of the registrars which puts it into their self-interest to maintain the databases, computer equipment, and everything else which makes this work.  Yes, there are other ways that a domain name server can earn some coins, and perhaps that ought to be done too, but registration fees are already a part of the marketplace and something which this system is trying to capture as well.

In short, I am trying to demonstrate here that the authentication simply must happen with an entirely different currency, or that authentication of the data (not merely the time stamping) must happen within the Bitcoin client and that data at least in some fashion or another included more directly into the Bitcion block chain with the data authenticated by the miner itself.  A Bitcoin miner may choose not to process domain data, but some system must be set up that can certify that a given block including the domain data meets some sort of authentication standard to be accepted into the block chain to "earn" those registration fees.  Otherwise the system falls apart and any talk of fees other than as a pure transaction fee to a Bitcoin miner alone is meaningless, with that transaction only to be used to preserve the transaction database.

I am also suggesting that to ensure promptness of registration, that it may also have to be a separate currency simply because not all miners are going to want to bother with domain registration authentication and over time the latency of even getting a domain registration into the system may be intolerably long (on the order of days or weeks) depending on the setup of the Bitcoin network and other priorities of the miners.  I'm not suggesting an alternate currency to drive this project out of Bitcoin as useless data, but to point out that it is unworkable even from the perspective of the goals of the peer to peer domain server concept too.  Putting the data into transactions isn't authentication and is also losing much of the power of what Bitcoin offers in terms of the authentication too.  The proof of work system as used by Bitcion is also the only reasonable way to ensure that the system stays decentralized in terms of deciding who gets to put in the next block.  Certainly some sort of common protocol for finding the next proof of work hash can be set up through a common mining pool between multiple currencies like this, but that is a completely separate issue from if it is to be a separate currency or not which I don't think has been decided on this thread.

The only other solution would be for Bitcoin to fully embrace this and other similar concepts that might come along and provide hooks and some sort of standard protocol to authenticate data of this nature on the main Bitcoin network.  I think in theory that could be done and may be done in the more distant future in terms of "unifying" the proliferation of currencies that may result if it isn't done.  I just don't see how that is going to get into the main Bitcoin chain anytime soon and even that has a whole bunch of drawbacks which I haven't fully explored either.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 10, 2010, 02:41:39 PM
 #238

I have not yet read all the posts but I have a few thoughts:

Need to divide the creation of a domain name and change of authoritative servers for him:
First is the expenditure limited domain name space and must be expensive.
Second only settings that can be changed frequently and should be generated in large quantities and cost little.

Names should be allowed to specify the relative and absolute value (with dot at the end). Absolute in case the system will supplement or replace the main in the conventional TLD.

Also names should be allowed to specify 3rd or more level domain names too.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 10, 2010, 02:51:50 PM
 #239

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.

2. "powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 02:57:37 PM
 #240

... Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block

That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee.

There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 02:59:27 PM
 #241

"powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.

No-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 03:01:40 PM
 #242

I have fleshed out the DomainChain spec quite a bit more:
http://domainchain.org/wiki/doku.php?id=start

Also names should be allowed to specify 3rd or more level domain names too.

Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 10, 2010, 03:11:21 PM
 #243

"powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.

No-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.

bind9 is not the best format. pdns have a simple interface for plugins, do not worry.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 10, 2010, 04:50:01 PM
 #244

... Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block

That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee.

There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.

I think you got the context mixed up here.  The reason why the payment is irreversible is because it is derived from a completely different chain.  If there is a chain split in the domain registry chain, the fees spent as bitcoins (going into a completely different system) will have already been spent for those block in the "losing" chain.  Transaction going into that "losing block" are essentially a wasted effort.

I'm suggesting that somebody simply sets up enough of the protocol to be able to appear to be following the domain processing rules so as to appear "legit", but they only have to make an appearance to get a block accepted.  Perhaps they even get some blocks accepted, but then start to make up stuff or somebody attempts to register an existing name (as a scammer claiming they can hijack a domain from somebody else or however).  If there is any reason why the rest of the network doesn't accept the block, for any reason, all of the fees collected by that "miner" or "registrar" would still be collected by that scammer regardless of if it actually gets into the chain.

On the other hand, if the block being "authenticated" is a part of the same chain that creates the currency, this isn't a problem.  If the blocks get rejected by the network, any fees (set up in a system like how transaction fees are done with Bitcoin) are also similarly rejected by the network too.  Any chain splits remove any fees paid to "losing" blocks and therefore can be ignored.  This is why the authentication must happen in the same chain as the transaction.  Either that is in Bitcoin or a parallel currency, but if it is with Bitcoin, the authentication must happen within the Bitcoin network too.  Otherwise, there isn't a way to get payment to the miner with an outside currency that is similar to Bitcoin without fraud and a significant attack on the payment system.  This is fraud because a service is being claimed and paid for, but the service isn't being rendered.

Hacking the data into Bitcoin transactions does not perform authentication of the data and pushes that need somewhere else.  In effect, it permits "double spending" of a domain name or allocation of a domain name to more than one person with ambiguity over who actually owns that domain.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 04:58:15 PM
 #245

The reason why the payment is irreversible is because it is derived from a completely different chain.

Got you now. Yes, keeping two chains synchronised is fraught with difficulty.
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6610


View Profile
December 10, 2010, 05:29:28 PM
Last edit: December 11, 2010, 12:28:48 PM by satoshi
Merited by EFS (100), garlonicon (100), ABCbits (59), OgNasty (50), pooya87 (10), vapourminer (5), BlackHatCoiner (4), BitcoinFX (1), DdmrDdmr (1), Vispilio (1), DaCryptoRaccoon (1), vjudeu (1), darosior (1)
 #246

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 10, 2010, 06:55:35 PM
 #247

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

If you say "no" after you've seen how this runs on the test network, I will totally respect that and won't generate domain registrations on the live network.

Bitcoin is your bird, and if you don't want it to soar as high as it can, that's OK.

But even if the domain name stuff is on a separate chain, there is still going to be a Bitcoin transaction for every DNS registration. So having two chains would cause no reduction in the number of Bitcoin transactions, just 40 or 50 bytes reduction in the size of the transactions in the Bitcoin chain.
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 10, 2010, 07:03:24 PM
Last edit: December 10, 2010, 07:13:50 PM by RHorning
 #248

Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

I dont see how this was a red herring.  Unfortuantely if you use a Bitcoin-like system of authentication of a transaction, you can't conduct that transaction in Bitcoins, at least for authentication transaction fees.

Quote
If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.

I'm really curious about how you make this sort of transaction risk-free without having it integral to Bitcoin as some sort of authentication mechanism.

One thing that really makes this nasty is that the "miner" is unknown until the block is added into an authentication hash tree.  You don't have the two key release mechanism because one of the parties in the transaction is unknown until after the hash is successfully put in, and even that is conditional.

It makes it much more secure and coincidentally easier to scale to treat it as a simple exchange between two currencies, something that happens entirely outside of the system as evidenced by the various exchanges that already exist between Bitcoin and other currencies.  BTW, I agree that Bitcoin or any other monolithic application should not be the ultimate repository of all human knowledge and interaction, as I don't think any sort of system can possibly scale to that size.  I'm not even sure TCP/IP itself can scale to that size.

This is much of what Jgarzik has said that it is unworkable, but going from a different perspective.  The problem is that everybody is trying to get these fees paid for with bitcoins, and I don't think that can be done at all, at least directly.  As an indirect mechanism, perhaps, such as a floating currency that isn't locked down until after the exchange takes place.

BTW, the idea of a "locking exchange" would be a fantastic idea for a peer-to-peer currency exchange network, particularly for electronic currencies like Bitcoin or Liberty Reserve.  I just don't see how you can put any sort of authentication transaction fee in a block that is denominated by a currency other than the currency represented by that block itself.
MoonShadow
Legendary
*
Offline Offline

Activity: 1708
Merit: 1007



View Profile
December 10, 2010, 07:11:28 PM
 #249

Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.

"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'
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 10, 2010, 07:14:04 PM
 #250

Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?

Hal Finney
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 10, 2010, 07:20:44 PM
 #251

Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.

This is indeed something that can be tweaked, but the issue has to do with network latency, which is independent of the purpose for which the "currency" was created.  10 minutes is a guess that has worked out pretty well.  Yes, it could be longer or shorter.  Shorter intervals increase hash collisions from multiple "miners" and a longer intervals decrease those collisions.  10 minutes is also something tolerable on average to somebody used to using computers, certainly if you have experienced sending information and expecting a reply by e-mail.  Domain registrations in particular may take a day or so for processing, depending on the registrar and the method of payment, so anything less than a 10 minute interval seems like a waste of effort.

In short, the reasons why 10 minute intervals would apply to Bitcoin apply equally well to any other peer-to-peer cryptocurrency with what other applications are using similar principles.
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
December 10, 2010, 07:22:40 PM
 #252

Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?

It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.

The possibilities are endless.

Bitcoin rewards you, essentially, with a piece of [digital] property.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 10, 2010, 07:35:48 PM
 #253

It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.

The possibilities are endless.

Bitcoin rewards you, essentially, with a piece of [digital] property.

If you are a miner and you "win" the block, yes, you can throw in any domains to the chain for free I suppose, and the network could accept or reject your block depending on whatever rules that network sets up to regulate that behavior.  That is like a Bitcoin miner can throw any transactions they care for as much as they care without having to pay a transaction fee, since they are paying for themselves.  Including a transaction fee in the process is just rearranging coins and doesn't change the net amount actually being spent or received.

I think that is of limited utility, unless you are saying that miners can eventually "earn" the "right" to a top-level domain after a certain number of hashes and inclusions into the domain registry.  That would be an artificial form of scarcity that would be interesting to implement, but it still fails to get fees paid by registrants to the registrar.  It would just make you "god-king" over a particular TLD... if you really "owned" that.

Such a non-coin "reward" also doesn't provide any incentive to maintain the database, while a coin-based reward would.
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
December 10, 2010, 07:41:41 PM
 #254

bitcoin itself is artificial scarcity.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6610


View Profile
December 10, 2010, 07:55:12 PM
Last edit: December 10, 2010, 10:16:10 PM by satoshi
Merited by EFS (100), OgNasty (50), ABCbits (2), Aveatrex (1)
 #255

additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would float.

A longer interval than 10 minutes would be appropriate for BitDNS.

So far in this discussion there's already a lot of housekeeping data required.  It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain.  Some transactions:

Changing the IP record.

Name change.  A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken.  This would encourage users to free up names they don't want anymore.  Generated domains start out blank and the miner sells it to someone who changes it to what they want.  

Renewal.  Could be free, or maybe require consuming another domain object to renew.  In that case, domain objects (domaincoins?) could represent the right to own a domain for a year.  The spent fee goes to the miners in the next block fee.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 10, 2010, 08:03:14 PM
 #256

bitcoin itself is artificial scarcity.

The supply of bitcoin is just an integer determined by network. Otherwise, bitcoin are non-scarce. I can copy a wallet a millllllllllllioooooooooon of time and it will contain the same integer. It's a very weird form of scarcity and non-scarcity.

Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 10, 2010, 08:12:02 PM
 #257

OK so if there are going to be bitdnscoins (aka DCCs, DomainChain Coins) then they have to be useful for something. Otherwise every BitDNS miner is going to fill every block with his own domain name registrations, rather than replace one with someone else's registration in exchange for a transaction fee in a useless currency.

The rules have to be that you have to spend a certain amount of bitdnscoins/DCCs in order to register your names and/or do other BitDNS transactions. That's the only way to make this alternative currency desirable and valuable.

(Well we could do like Bitcoin and say there would only ever be 22 million DCCs ever created, so they'd get valuable from scarcity just like bitcoins. But that seems weak.)

Hal Finney
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6610


View Profile
December 10, 2010, 08:19:39 PM
Last edit: December 11, 2010, 12:30:09 PM by satoshi
 #258

I agree.  All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.

You might consider a certain amount of work to generate a domain, instead of a fixed total circulation.  The work per domain could be on a schedule that grows with Moore's Law.  That way the number of domains would grow with demand and the number of people using it.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 10, 2010, 08:41:45 PM
 #259

Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.

Then be sure to add the ability to specify multiple authoritative servers for one domain. This is possible for DNS as I know (MS Windows AD does it)

So those who do not want what their site to be able to shutdown can make a lot of spare servers and when they turned off by Big Brother name owner just change the settings by removing old servers and adding new ones.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 11, 2010, 12:01:00 AM
Last edit: December 11, 2010, 03:43:57 AM by da2ce7
 #260

It seems like killing two birds with one stone isn’t enough on the bitcoin forum; one has to kill three.

Firstly, I would like to commend nanotube's+theymos proposal.  I like it because it makes economic sense, and it is simple.
The design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the ‘issues’ said. (I still think there is really nothing wrong about how it is proposed to work as it is.  However, if there is a better way of doing it, why not?)

Before we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply.  Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.

If a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.
So with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.


The main concern on the forum is the inclusion of ‘other data’ in the block chain; the problem isn’t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.
In discussions elsewhere, it has been shown that:
1.   Generators will happily include any data that is profitable to include.
2.   The block size will grow to a size that balances data demands and the profitably of the miners.
3.   Clients only need to ‘keep’ data that they interested in.  Data that is irrelevant to the client may be forgotten once processed.
4.   Transaction balances may be used to cull the chain of old transactions.
Therefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want).  The only outstanding issue is: transfers.

What has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it.  Only after processing may a client delete any data that it doesn’t want.  This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.


I propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

Finally include a ‘summary’ group that contains only the changes to the transaction balances accumulated in all the other groups.

A Block could contain something like this:


Once one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes.  This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.

The important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.


Nanotube and Teymos’s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries.

One off NP-Hard.
dtvan
Newbie
*
Offline Offline

Activity: 2
Merit: 1


View Profile
December 11, 2010, 07:43:08 AM
Merited by F2b (1)
 #261

After reading through this whole thread, I've got a couple of comments that I think would be helpful:

1)  Everyone in the thread seems intent on replacing the entire DNS infrastructure in one fell swoop, which I think is the wrong approach.  The real problem with the DNS system as it exists today is that somebody has to own the root.  At the end of the day, you have to trust ICANN.  What the DomainChain/BitDNS system should strictly focus on is establishing ownership of domain names.  All it needs to track is that the holder of Key A owns domain foo.bar.  Once we've established this shared trust, we can support many different DNS infrastructures that can be implemented independently from this project.  Whatever new systems are created use DomainChain/BitDNS to establish which key owns the domain, and only allows that individual to insert records for that domain.  This works out well, since all participants in the system can validate that the record they've looked up is valid.  Right now it is easy to get bogged down in all the details of managing DNS records, when all we need to do is establish a trusted, distributed authority that can form the root of DNSSEC, some new p2p DNS, or whatever.

I'm also thinking this could be used to solve the CA problem with HTTPS, since signing your certificate with the same key would prove that I've reached the correct server.  But I digress...

2)  Limiting the TLDs should be a requirement.  If this system doesn't inter-operate with the existing DNS infrastructure by preventing name collisions, it will undermine the trust you are trying to generate.  Even I'm not sure I'm ready to sign up for a distributed DNS system if someone new can pick up www.mylocalbank.com and cause havok.  I'd humbly suggest .web as the TLD to use, but anything will work as long as it is short and not currently in use.

Right now the focus should be on getting this up and running in a way that doesn't conflict with the existing system.  If this system becomes dominant at some point and needs to tackle additional TLDs, that is a "problem" that can be dealt with then.

3)  Personally, I think expiring domain names are the way to go.  Even with relatively expensive renewals today, there is still a ton of junk out there.  I can't imagine how bad it would be if you owned a domain forever.  It isn't asking much to say that you have to renew your domain periodically to keep it, especially since this shouldn't be the ripoff that the existing system is today.

I'd like to close out by saying that this is really exciting stuff.  I've read a number of different ideas about how to solve the DNS problem, and this is the first one I've seen that could actually solve it (and not just replace ICANN with pick-your-new-benevolent-dictator).
joe
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
December 11, 2010, 10:53:58 AM
 #262

What is Bitcoin? A decentralized way to keep track of ownership of a fixed quantity of things.

The DNS problem is a specific example of a more general functionality: keeping track of ownership of a fixed quantity of things, where each member of the set is distinguishable.

It turns out that bitcoins are already distinguishable. They are well ordered, mathematically speaking, so a number can be assigned to every bitcoin, for example 0 to 21 million.

So, for a DNS functionality, this is all we need to do:
1. create a second coinbase, possibly forked from the main coinbase (bitcoin)
2. interpret each coin in the second coinbase as a well-defined interval of the sha256 hash space of all DNS names.

Ownership of DNS names is therefore determined by which coins in the second coinbase you own.

Some months ago I was opposed to adding DNS stuff to the existing bitcoin network protocol and client, because I argued bitcoin should stay true to its limited purpose. However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.

In fact, maybe anyone should be able to create a new coinbase on the main network, and specify rules such as quantity and distribution rate. In the case of DNS, everyone will just have to agree that a particular coinbase is to be interpreted as the DNS rights to different parts of the sha256 hash space for the DNS names.

I agree with the idea put forth by da2ce7, which he says is derived from an idea put forth by Satoshi. I think it is compatible with my idea of allowing arbitrary creation of new coinbases on the same network.

I cannot find the nanotube+theymos proposal so i cannot comment on it.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 11, 2010, 11:45:24 AM
 #263

I cannot find the nanotube+theymos proposal

It's here. The simpler DomainChain proposal is here.
Anonymous
Guest

December 11, 2010, 11:48:31 AM
Last edit: December 11, 2010, 12:49:12 PM by satoshi
 #264

It seems like killing two birds...

This seems like a sound plan. It includes the proposal of theymos and nanotube and includes what satoshi is wanting. I like the fact that there is no free lunch and everyone would have to pay their way.
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364
Merit: 6610


View Profile
December 11, 2010, 01:08:30 PM
Merited by EFS (100), OgNasty (50), ABCbits (1)
 #265

@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS.  And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.

However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.
Avoiding CPU power fragmentation is no longer a reason.  Independent networks/chains can share CPU power without sharing much else.  See: http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 11, 2010, 01:45:52 PM
Merited by F2b (1)
 #266

I propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

While I like this general architecture, the largest problem is how you set up the schema for authentication of the non-financial transaction data.  A node could deliberately ignore such data, but if a node is going to carry some data not directly related to financial transactions it should follow some sort of authentication rules for that data.  The question is mainly how that is going to be performed.

Keep in mind one of the things that made the update with Bitcoin v. 0.3.18 sort of earth-moving is that the authentication rules for the network changed.  Many have assumed that the miners control the rules of what goes into a block chain but that is only partially true.  The nodes themselves also have a huge rule with that too, where even a non-generating node "participates" in the network deciding which node is going to be accepted by its corner of the network, and acting as gatekeepers over what data is passed along to miners.

There are three things that are gained from using a bitcoin architechture that must all be necessary for the data to be effectively using the Bitcoin architecture to its largest extent:

  • Time stamping - certifying the temporal order of events
  • Cryptographic Integrity - certifying that the data hasn't been tampered with
  • Authentication - certifying that the data meets some basic standards

Any sort of general or specific proposal for something like BitDNS really must include all three aspects.  Most of the proposals I've seen ignore the authentication or dismiss it as something irrelevant.

The authentication rules are indeed different for domain names than currency, but the principles are similar.  With currency you don't want to have people "double spend" coins or creating coins "out of thin air" except under strongly proscribed rules.  In the case of domain names, you want to ensure that the same domain hasn't been "claimed" by more than one person.  Furthermore, you also want to make sure that if "ownership" of a domain has been transferred (thus giving authority to change properties associated with that domain), that such a transition is orderly.  Also, any properties associated with that domain such as IP addresses related to the domain or contact information can only be modified by the person who either created or has "ownership" of that domain.  If there are expiration rules, those rules ought to be enforced and managed as well.

All of that is fairly easy to do in a monolithic central server, but it gets much more complicated when trying to do this on a peer to peer network.  If the authentication doesn't happen with some standard rules, you end up with chaos as different "domain servers" all end up pointing to different computers.  Even for computers trying to follow "the rules", without authentication being guaranteed with inclusion into a database of some sort they may still end up displaying the "wrong" information compared to a peer.  For domain registration, that is to me something fatal.  That is why I think pushing the domain authentication down to individual servers to decide for themselves as an optional thing and not integral to the network is a bad move.

Furthermore, I am trying to suggest that the role which "registration fees" can play will both strengthen the network and to improve authentication shouldn't be underestimated.  This isn't just the transaction recording fee, but also the authentication that the data really belongs in the chain too.  The fees also help out on the problem of a tragedy of the commons, as it provides an additional incentive to not "spam" registrations, but that the resources or in this case a "domain" is really something needed.  Cybersquatting is reduced simply because it can be expensive to engage in hundreds or thousands of registrations.  

A miner is double-checking to make sure that the data really does belong in the chain.  If a miner is being sloppy and doesn't do the authentication, or at the least is in error because of a bug in the software, the block containing the "bad" data should be rejected by the network.  Again, this is happening with financial transactions, and I'm saying that it should be happening with other data too.  A miner not doing proper authentication shouldn't receive authentication fees.  

This is one of the reasons why I have suggested that this data be done in a completely separate block chain and currency system, as that way the authentication is done by miners with a self-interest to make sure that the authentication takes place.  A network dedicated to a particular kind of data would also root out people trying to abuse that data format.  Setting up currency exchanges is something that is already a well established principle with Bitcoins, and there is no reason to presume that it can't be used for other "parallel" currencies made for more dedicated purposes, particularly if they are allowed to float.  Apparently this concept of a separate currency is being rejected so let's explore including this into Bitcoin for a moment.

If this is included into Bitcoin, both interested miners and network nodes wanting to perform authentication checks on a particular set of data should have some way to get the rules for that data.  So far the presumption is that the rules should be "hard coded" into the software itself.  Perhaps that could change too in some way.  What would the consequences of having some sort of "scripting language" that could be used for authentication of data that could be injected into the network?  I'm proposing this as a way to make Bitcoin extensible too so other forms of data could be applied to the network.  How a node obtains these scripts can be debated, as that may be something a node or miner can obtain from Source Forge, Git, or perhaps some protocol could be set up for spreading these scripts through the network itself.  It wouldn't need to be an ongoing issue as there only needs to be one script per data type, but the role of the script would be to ensure the authenticity of the data.

If a miner doesn't want to bother with authenticating some data, they simply don't have to include that data at all in a block.  That miner would also be giving up authentication and transaction fees associated with that data, so it seems rather unlikely any miner would ignore that kind of data, but it still is completely optional.  The data can be authenticated, and on the positive side the network isn't just restricted to a very limited number of data types too.  I am doing some handwaving here as I'm not specifying the scripting language, but I think that can be developed.

The one weakness I see here with this alternate system of actually including non-financial data into the Bitcoin Merkle tree is that for non-financial data the authentication is going to be weaker when used in a general network.  Far too many nodes are not going to be interested in authenticating the non-financial data or even passing it along.  Then again, that might be a reason to accept fees or set up a system to charge for network bandwidth between nodes.  Data storage and network bandwidth don't have to be free goods either.
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 11, 2010, 02:06:26 PM
 #267

After reading through this whole thread, I've got a couple of comments that I think would be helpful:

1)  Everyone in the thread seems intent on replacing the entire DNS infrastructure in one fell swoop, which I think is the wrong approach.  The real problem with the DNS system as it exists today is that somebody has to own the root.  At the end of the day, you have to trust ICANN. 

There is no need to trust ICANN, except for perhaps acknowledging that there are other systems for domain allocation that aren't going to go away and that other people will be interested in using.  I don't see any sort of DNS replacement system suggesting that the ICANN domains should be ignored, merely that they ought to be depreciated with new systems.  The history of ICANN is one of a small group of self-appointed individuals trying to gain control over the resources of the internet for their own personal financial gain.  It also concentrates this authority in such a way that allows governments to exert political influence upon the allocation of domain names for political purposes that have nothing to do with the technical operations of the internet.  One of the points of setting up a peer-to-peer domain allocation system is precisely to get away from this central authority.

There is a sort of libertarian/anarchist bent to the whole notion of creating an alternate DNS system, which is one of the motivations for why this is being set up in the way being described.  Otherwise, I guess you can accept the system as promoted by ICANN.

Quote
2)  Limiting the TLDs should be a requirement.

I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

Quote
3)  Personally, I think expiring domain names are the way to go.  Even with relatively expensive renewals today, there is still a ton of junk out there.  I can't imagine how bad it would be if you owned a domain forever.  It isn't asking much to say that you have to renew your domain periodically to keep it, especially since this shouldn't be the ripoff that the existing system is today.

I happen to agree here that domains should expire.  Various proposals have also debated the term lengths, but charging fees to maintain those domains also has a side benefit of also helping out the network in terms of paying for data storage costs and network bandwidth to support the registration system.  That is also true for the ICANN system of domain registration too.

Quote
I'd like to close out by saying that this is really exciting stuff.  I've read a number of different ideas about how to solve the DNS problem, and this is the first one I've seen that could actually solve it (and not just replace ICANN with pick-your-new-benevolent-dictator).

That is the feature I love about this system too, as it does put the "ownership" of domain registration to a network as a whole instead of a single person.  It also lowers or practically eliminates the barriers to entry for becoming a domain registrar.  Wouldn't it be nice if you could be like "GoDaddy" and start accepting fees for domain registration?
nanotube
Hero Member
*****
Offline Offline

Activity: 482
Merit: 501


View Profile WWW
December 12, 2010, 12:18:15 AM
 #268

<some stuff> Smiley

besides the possibility of storing NS records in addition to just registrations... the theymos+nanotube spec does exactly what you suggest.

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
Merit: 251


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
December 12, 2010, 12:35:42 AM
 #269

It seems like killing two birds...

This seems like a sound plan. It includes the proposal of theymos and nanotube and includes what satoshi is wanting. I like the fact that there is no free lunch and everyone would have to pay their way.

I second da2ce7's suggestion as well.  Makes it more flexible.  It is similiar to the last suggestion in theymous's http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity here:

Quote
Thirdly, we could push off the data handling bits to the root dns servers themselves. The only features we /really/ need from the bitcoin block chain is a timestamped proof that you spent X btc by way of a transaction fee. The rest can be accomplished on the dns server, wherein the user creates an account on a root dns server of his choice, submits a message signed with the ECDSA key of the recipient address, and claims a domain name of his choice. The root server publishes the relevant DNS record, including a TXT record with the details of the transaction that is being claimed. This allows a person to claim one and only one domain, based on the timestamp and fee paid with the transaction to the address in question. In this latter mechanism, we have left only the bare essentials in the block chain - the transactions required are absolutely normal bitcoin transactions, unblockable by the developers.

Separating the data part of the DNS transactions from the p2p distributed timestamping part means that we all don't have to be carrying around all this DNS transaction queries in our block chain, and it means that DNS transactions aren't limited to 120 bytes.  Theremous, could you elaborate a bit more on how this above suggestion would work?

Quote
2)  Limiting the TLDs should be a requirement.

I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

I second this.  Limiteing TLD is totally arbitrary.  Major internet entites like Wikipedia or Google or YouTube or Facebook or blogspot should be free to compete for and obtain a TLD with their name.

"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
Merit: 141


View Profile
December 12, 2010, 03:13:12 AM
 #270

Thirdly, we could push off the data handling bits to the root dns servers themselves. The only features we /really/ need from the bitcoin block chain is a timestamped proof that you spent X btc by way of a transaction fee. The rest can be accomplished on the dns server, wherein the user creates an account on a root dns server of his choice, submits a message signed with the ECDSA key of the recipient address, and claims a domain name of his choice. The root server publishes the relevant DNS record, including a TXT record with the details of the transaction that is being claimed. This allows a person to claim one and only one domain, based on the timestamp and fee paid with the transaction to the address in question. In this latter mechanism, we have left only the bare essentials in the block chain - the transactions required are absolutely normal bitcoin transactions, unblockable by the developers.

Separating the data part of the DNS transactions from the p2p distributed timestamping part means that we all don't have to be carrying around all this DNS transaction queries in our block chain, and it means that DNS transactions aren't limited to 120 bytes.  Theremous, could you elaborate a bit more on how this above suggestion would work?

I know I'm starting to sound like a broken record here, but the time stamping isn't the only issue here.  Fees are being proposed for inclusion with the "registrations", but I see absolutely no financial incentive to even recognize those transactions at all with the Theymos/Nanotube proposal.  These fees aren't going to registrars or anybody associated with the domain data control.  There is also absolutely no standard to establish which domain actually belongs to which set of IP address, much less any sort of other kind of authentication standard with this proposal.  It does include a hook to make sure that the data isn't tampered with, but that isn't the same thing.  Authentication is presumed and mentioned as coming from the Bitcoin block chain, but it isn't happening.

I am strongly suggesting that the economic principles for sustaining this network with this proposal are not present in the proposal.

I guess it will take seeing how it really works out, but I see so many potential "attacks" if this is implemented that I don't see it being sustainable.
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 12, 2010, 04:36:56 AM
 #271

If this is included into Bitcoin, both interested miners and network nodes wanting to perform authentication checks on a particular set of data should have some way to get the rules for that data.  So far the presumption is that the rules should be "hard coded" into the software itself.

Yes, this is what I was implying by having 'templates' for the data.  To be accepted into the BitDNS 'group' one must follow the BitDNS template, otherwise the block that is created is orphaned.

The rules of the 'template' is whatever a majority of the network decides to requite; for instance, it could include a rule that the same domain name cannot be registered more than one. Or not.  But this is a longer term thing.

It is important to note, that when somebody claims a BitDNS address, then another claims the same address, it doesn't need to be network enforced, as those using the BitDNS information will just ignore the later claim as junk.

One off NP-Hard.
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 12, 2010, 12:27:50 PM
 #272

It is important to note, that when somebody claims a BitDNS address, then another claims the same address, it doesn't need to be network enforced, as those using the BitDNS information will just ignore the later claim as junk.

This in turn leads to multiple assumptions as to which domain is junk.  If one client recognized a 10BTC "fee" as proper for registration (going back to the Theymos/Nanotube proposal) but another expects a 20 BTC "fee", where somebody else made a registration for 20 BTC, that is the domain registration that will be recognized.... with a completely different IP address that it is pointing to.  If another "registrar" recognizes a 5 BTC "fee", it could be still another IP address.  In other words, the whole concept of a fee here needs to be rethought too if that has any meaning at all.  Even if the role of the "fee" is simply to get miners to include the regsitration into the block, there are other problems to worry about too.

This goes back to authentication that isn't happening, at least to give a "definitive" version of what is in fact the correct IP address or any other meaning to the domain name.  Even slight differences in interpretation of the formatting of the data can lead to some "registrations" being recognized and others being ignored.  I see chaos particularly as multiple implementations of clients try to interpret this data in various ways each with their own assumptions as to which "registration" is definitive.  There is also no means to enforce that a particular piece of software is necessarily going to be the definitive and "authorized" software for this application.

With such chaos in terms of trying to determine the validity and authentication of a domain, I fail to see how it would actually be accepted as a directory of IP addresses, which really is the purpose of a domain registry when you get down to the whole issue on a basic level.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 13, 2010, 05:11:13 PM
 #273

Are we...dead?

SmokeTooMuch
Legendary
*
Offline Offline

Activity: 860
Merit: 1021


View Profile
December 13, 2010, 08:13:08 PM
 #274

I guess he is hinting at the very chaotic planning of .p2p which makes the developement really slow because they can't really start before the specifications are clear.
Ignore that post. I was looking on the wrong page.

Date Registered: 2009-12-10 | I'm using GPG, pm me for my public key. | Bitcoin on Reddit: https://www.reddit.com/r/btc
nanotube
Hero Member
*****
Offline Offline

Activity: 482
Merit: 501


View Profile WWW
December 13, 2010, 08:14:29 PM
 #275

Are we...dead?

no. 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
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 13, 2010, 08:18:11 PM
 #276

Do we have enough uncontroversial detail that somebody can start coding?

RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 13, 2010, 08:32:23 PM
 #277

Do we have enough uncontroversial detail that somebody can start coding?

There are some very different philosophies here, so I think we may have a couple of different applications being developed, perhaps jointly.  I'm certainly not going to be implementing the Theymos/Nanotube proposal at least initially, but somebody else might.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 13, 2010, 08:46:29 PM
 #278

Seems like everyone's tugging in a different direction. Here are some of the specific issues:

1. Bitcoin main chain vs start a new chain, with DCCs ("DomainChain coins").

2. Permanent name registration vs renewal necessary.

3. Support for an unlimited family of applications vs just focus on DNS.

4. DNS "gateway" servers setting minimum transaction fees vs burning a DCC to register a domain.

5. Include in the block chain, in addition to domain name: just ownership public key, vs ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.

6. Single TLD .web or .p2p, etc., vs "advisory" TLDs which may be ignored, versus all TLDs being allowed in names.

Any other issues/design choices which can be factored out?

Hal Finney
SmokeTooMuch
Legendary
*
Offline Offline

Activity: 860
Merit: 1021


View Profile
December 13, 2010, 09:04:50 PM
Last edit: December 14, 2010, 07:10:12 PM by SmokeTooMuch
 #279

Maybe we should start a poll about what we think is best and accept the result as a democratic decision.

For me it looks like this was the best:

[ ] Bitcoin main chain
[X] start a new chain, with DCCs ("DomainChain coins").

[ ] Permanent name registration
[X] renewal necessary
(registration for 1 year ?)

[ ] Support for an unlimited family of applications
[X] just focus on DNS.

[ ] DNS "gateway" servers setting minimum transaction fees
[X] burning a DCC to register a domain.
(not sure if I got all the details about this)

[ ] Include in the block chain, in addition to domain name: just ownership public key,
[ ] ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.
(actually I don't care about this)

[ ] Single TLD .web or .p2p, etc.
[ ] "advisory" TLDs which may be ignored
[X] all TLDs being allowed in names.
(up to 4 or 5 Unicode letters)

Date Registered: 2009-12-10 | I'm using GPG, pm me for my public key. | Bitcoin on Reddit: https://www.reddit.com/r/btc
MoonShadow
Legendary
*
Offline Offline

Activity: 1708
Merit: 1007



View Profile
December 13, 2010, 10:05:31 PM
 #280

Maybe we should start a poll about what we think is best and accept the result as a democratic decision.


If it were truly democratic, there would be a choice of, "don't do anything like this at all" and would require a quorum of 50% or more of bitcoin users.

"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'
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
December 13, 2010, 10:05:50 PM
 #281

Nanotube and I will be developing an implementation to go along with our proposal. If you like your idea, create it and let the market decide.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 13, 2010, 10:22:57 PM
 #282

I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.

Hal Finney
bencoder
Member
**
Offline Offline

Activity: 90
Merit: 10


View Profile
December 14, 2010, 01:04:00 AM
 #283

I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.

This is a very good point. Any domain registration message to the network could potentially be hijacked. It doesn't matter what the system is, if you're loosely connected and you send a registration message into the network, a well connected client on the network could simply resend the message using the same domain and possibly get to a larger proportion of the network faster than the original sender's registration message, causing his registration to be more likely to be included in the block chain. I'm not sure what the solution to that is. Of course the person who does this will have to spend whatever it costs to register a domain to do this attack, which will have a natural limiting effect on it, which may be the best we can hope for.

Can anyone think of a solution? Perhaps having to mine a hash for the domain registration message with much less difficulty than mining for domaincoins/whatever, but just to slow anyone down from being able to instantly register a domain as their own.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 14, 2010, 01:18:53 AM
 #284

I wonder if it would work to put a (possibly salted?) hash of the name into the block rather than the name itself? Then it would not be obvious what name is being registered, but you could still lookup registrations by name. This would not be perfectly secure, short names could be found from hashes by brute force, but it would make front-running much harder.

Hal Finney
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
December 14, 2010, 01:28:45 AM
 #285

I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.

Can anyone think of a solution? Perhaps having to mine a hash for the domain registration message with much less difficulty than mining for domaincoins/whatever, but just to slow anyone down from being able to instantly register a domain as their own.

On the positive side, if somebody wants to become their own domain regsitrar, they can certainly get that done too.  On top of that, the financial incentive offered by a fee to register the domain might be sufficient to prevent domain stealing from happening as they will want to include a domain to collect the fee.  I was hoping that somebody processing registrations would be greedy and selfish.
 
Since a registration is open to everybody and any block at any time could include the registration, somebody trying to capture a domain in this way wouldn't have much time to decide if they wanted the domain for themselves as well, presuming they were running a "corrupt miner".

More importantly, I would think this would have to be automated in some fashion, so how could you algorithmically decide what is a "good" domain name to capture?
dtvan
Newbie
*
Offline Offline

Activity: 2
Merit: 1


View Profile
December 14, 2010, 05:28:23 AM
 #286

There is no need to trust ICANN, except for perhaps acknowledging that there are other systems for domain allocation that aren't going to go away and that other people will be interested in using.  I don't see any sort of DNS replacement system suggesting that the ICANN domains should be ignored, merely that they ought to be depreciated with new systems.  The history of ICANN is one of a small group of self-appointed individuals trying to gain control over the resources of the internet for their own personal financial gain.  It also concentrates this authority in such a way that allows governments to exert political influence upon the allocation of domain names for political purposes that have nothing to do with the technical operations of the internet.  One of the points of setting up a peer-to-peer domain allocation system is precisely to get away from this central authority.

There is a sort of libertarian/anarchist bent to the whole notion of creating an alternate DNS system, which is one of the motivations for why this is being set up in the way being described.  Otherwise, I guess you can accept the system as promoted by ICANN.

I think we're on the same page here.  I didn't make it very clear, but my whole "At the end of the day you have to trust ICANN" line was part of the problem statement, so to speak.  I didn't mean to indicate that was something that is just a given, but rather the principle problem that I'm hoping this can work around.

Quote
I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

In principle, I absolutely agree.  But the reality of the situation is that people are used to the current system, so eliminating TLDs just increases the barrier to entry.  At this point, most web users have a mental model of how web addresses are formed that pretty much assumes a hierarchical system.  We ignore that at our peril.

Furthermore, allowing arbitrary TLDs effectively guarantees that someone is going to register some of the existing domains.  This is a huge problem in how I envision a system like this being used.  Since I doubt most people are going to just cut themselves off from the existing Internet to live in our corner of the network, the best we could hope for right now is a system where you get DNS names from a DNS server supporting BitDNS, and if it can't find it, it falls back to the existing DNS system.  That works great until you have a conflict, at which point you may end up with a different server then intended.  The beauty of using a new TLD, and forcing everything to fall under that, is that you are implicitly declaring your intention to go to a BitDNS name.  There is no surprise that you went to a server specified in the BitDNS network, since it isn't even valid in the existing system.  And vice-versa for standard names.

When we look at the design of the system, we should definitely allow for the possibility of arbitrary TLDs, since that is clearly a desirable feature in the long-run.  But for now, it makes sense to me to limit TLDs so that this new system could be integrated into existing usage models as seamlessly as possible.
abstraction
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile
December 14, 2010, 07:45:49 AM
 #287

So if I understand this correctly, all sorts of random domain names will be randomly generated such as "q8d79rt0y.bitdns", "sfdn345sdf.bitdns", and "goodurl.bitdns"?

I can see this type of scenario unfold as one possibility... BitDNS starts cranking along producing mostly "ugly" URLs. Somebody like Google wants to adapt to the bitDNS system, but doesn't want to wait for "google.bitdns" to be generated (or it can be generated by brute force, in which case Microsoft adapted to bitDNS before Google and brute-forced "google.bitdns" in order to hold it for ransom?). So, they buy "sfdn345sdf.bitdns" (or just use whatever they generate themselves) and create a plugin for their Chrome browser which translates "google.com" to "sfdn345sdf.bitdns". Naturally, other companies would opt for the "ugly" URL instead of waiting for a "pretty" one, and then try to get their translations into the browser DNS plugin. I also think there would be competition between plugin translation "packages". For example, I prefer "en-us" locale sites so I want "google.com" to go to the US English version ("sfdn345sdf.bitdns"), but someone in Austria would want their "google.com" to point to the site in German ("q8d79rt0y.bitdns"). I think a browser plugin could hold all the locations a person would ever want to visit since most people stick to their own little corner of the internet. If I was a Google, I would show a little button on the homepage of "google.com" that encourages the user to load the bitDNS version of the page, which the plugin basically links "google.com" to "sfdn345sdf.bitdns". From there forward, the browser automatically translates "google.com" to "sfdn345sdf.bitdns" and visits "sfdn345sdf.bitdns" whenever the user types in "google.com".

It's another layer of abstraction, but it might smooth the transition to the BitDNS system.
joe
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
December 14, 2010, 09:24:01 AM
 #288

I want to elaborate on a system I alluded to in an earlier post on page 14, that seems to be simpler than most of the other proposals put forth but that no one posted any feedback on.

Under this system, there are no changes to the protocol, except for the work sharing mechanism Satoshi briefly described (that no one else seems to understand completely) whereby clients can do work on multiple networks without choosing one over the other.

To implement this system:
1. Fork the network
2. Map the entire set of all strings (DNS names) onto the coinbase using a hash function (SHA).

Now, the rights to map any given DNS name to an IP address is awarded to whomever owns the coin associated with its hash on the forked network. Note that #2 is possible because every bitcoin is already both distinguishable and traceable in the current system.

This eliminates the need for any new complicated transactions, and eliminates the possibility of introducing any new loopholes or exploits that are not already present in the current bitcoin system. To transfer ownership of a DNS name, simply send the coin associated with its hash, on the forked network.

I also think this can be generalized to all classes of problems where a finite (or infinite) set of items needs to be assigned to people. In other words it should be possible to arbitrarily create forked coinbases for tracking the ownership of different sorts of things.

Any ideas or criticisms for this?
abstraction
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile
December 14, 2010, 10:52:33 AM
 #289

To implement this system:
1. Fork the network
2. Map the entire set of all strings (DNS names) onto the coinbase using a hash function (SHA).

Now, the rights to map any given DNS name to an IP address is awarded to whomever owns the coin associated with its hash on the forked network. Note that #2 is possible because every bitcoin is already both distinguishable and traceable in the current system.

Any ideas or criticisms for this?

How big is the entire set of all strings? And what level of granularity do you need for a bitcoin (10, 1, 0.1, 0.0000001, etc.) so it can hold the entire set of strings?
joe
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
December 14, 2010, 11:16:40 AM
 #290

How big is the entire set of all strings? And what level of granularity do you need for a bitcoin (10, 1, 0.1, 0.0000001, etc.) so it can hold the entire set of strings?
Probably the 8 places of granularity that bitcoin already supports would be sufficient. That is 0.00000001. The set of all strings is infinite but it can be mapped onto all the bitcoins by using a hash function.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 14, 2010, 11:51:36 AM
 #291

I thought of a possible problem with all these proposals: front-running by miners.

Front-running by miners is a flaw of the current proposals, and it's where I'm stuck. I haven't moved my DomainChain proposal further forward in the past couple of days because I can't solve the front-running problem.

The essential flaw is that domain registrations are contingent on transaction fees. A miner who generates a block can include a large number of speculative high-value registrations in that block, because the transaction fees don't cost them anything. This might be an intractable problem for any domain name registration system that is based around transaction fees.

I see that theymos/nanotube are proposing a "solution" to this. Their idea is that it should take more than one transaction to register a domain name; five transactions in fact. The first transaction pays one-fifth of the fee. Then, for the registration to be valid, there must be four further "fee adjust" transactions, each for one-fifth of the fee. These transactions must take place within ten blocks of the first transaction, to be valid.

My first objection to this is that it doesn't solve the problem of miner front-running; it just makes it more difficult. A few of the largest miners will just make an arrangement to mutually-process each other's fee adjust transactions. Almost inevitably, the design will produce a small group of large registrar-like operators.

My second objection is simply that 5-transaction registrations add an enormous amount of clutter to what should be a simple and elegant process.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
December 14, 2010, 11:57:43 AM
Last edit: December 14, 2010, 12:21:38 PM by theymos
 #292

My first objection to this is that it doesn't solve the problem of miner front-running; it just makes it more difficult. A few of the largest miners will just make an arrangement to mutually-process each other's fee adjust transactions. Almost inevitably, the design will produce a small group of large registrar-like operators.

More than 40% of the network would have to cooperate to get free domains. If malicious people are getting that much CPU, we have bigger problems. Even if this happens, servers can raise the limit to 7/10 or whatever.

Smaller percentages will get you a "discount", but I don't consider that to be a big deal. In particular, it'll be pretty easy to get a 1/5th discount if you can ever expect to create a block.

It's not a problem if people buy up names and then sell them on the market. This is an appropriate way to distribute unique resources. It's like homesteading some land in order to sell it later at a profit. We just want to prevent people from claiming millions of domains for free and then not using/selling them.

As for front-running: the first registrant will have an advantage in the race to get 4 adjusts. The first person has to send 4 more messages, while the attacker has to send 5. This can't really be done automatically, either, as people would attack the automated system by registering useless, random domains.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 14, 2010, 12:23:49 PM
 #293

Nanotube and I will be developing an implementation to go along with our proposal.
Will it be open source or proprietary?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5138
Merit: 12565


View Profile
December 14, 2010, 12:27:52 PM
 #294

Will it be open source or proprietary?

Open.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 14, 2010, 12:38:17 PM
 #295

There is a very elegant way of solving the front-running problem, but you need to think a little bit creativity  Grin

BitDNS should be subscriptions, as you always pay the generators as long as it is active.

When one registers a domain, the registration contains the rate that should be paid, (an on-going transaction fee) and the total amount.  When the transaction is included in the block chain.  The transaction fee is removed from circulation, and added to every generator at the agreed rate until it runs out.  When it runs out, the registration expires as well as the domain.

For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC.  For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.

One off NP-Hard.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 14, 2010, 12:44:51 PM
 #296

Subscriptions solve the front-running problem, but how exactly would they work?

For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC.  For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.

So who is the initial 100 BTC paid to? And how do the extra 0.01 in transaction fees get to the next 10,000 miners? Not by means of 10,000 transactions presumably...
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 14, 2010, 12:49:51 PM
 #297

the 100BTC are 'Killed" as in they are transfered to a "dead bitcoins" key.  Then the generators can get to claim an extra 0.01 or whatever on the mined bitcoins.  If the generator doesn't claim them, they sit around and accumulate until generator dose.  What is happening is that we are removing coins from circulation and allowing people to generate them again.

The only rule is that the coins cannot be 'claimed' faster than the set amount per block.  If a generator doesn't claim the coins in one block. The next block can claim two lots of it.

One off NP-Hard.
ByteCoin
Sr. Member
****
Offline Offline

Activity: 416
Merit: 277


View Profile
December 14, 2010, 12:53:19 PM
 #298

I thought of a possible problem with all these proposals: front-running by miners.

Front-running by miners is a flaw of the current proposals, and it's where I'm stuck. I haven't moved my DomainChain proposal further forward in the past couple of days because I can't solve the front-running problem.

The solution to the front running problem has been solved by Hal in http://bitcointalk.org/index.php?topic=1790.msg29919#msg29919
A suitably salted hash of the required name is submitted for inclusion into the chain. After it has been confirmed then the name (and salt) are published and everyone now accepts the new registration.

The essential flaw is that domain registrations are contingent on transaction fees. A miner who generates a block can include a large number of speculative high-value registrations in that block, because the transaction fees don't cost them anything. This might be an intractable problem for any domain name registration system that is based around transaction fees.

I agree that the theymos/nanotube "solution" to this problem is ugly.
There are also serious problems outlined by RHorning which need addressing.

ByteCoin
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 14, 2010, 12:56:30 PM
 #299

There are also serious problems outlined by RHorning which need addressing.

The problem with this is that the generators themselves can put hundreds of domain names into their own block.  Just like generators can include transactions for free in their own block.

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 14, 2010, 12:58:56 PM
 #300

I have come up with a solution to most of RHorning issues. However I'm still in the process of writing out it more formally.  It is quite a big departure from anything that has been talked on the forum yet.  But still (mostly) compatible with the bitcoin architecture.

One off NP-Hard.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 14, 2010, 01:47:18 PM
 #301

However I'm still in the process of writing out it more formally.

Feel free to write it up on a new page at the domainchain.org wiki if that's convenient for you:
http://domainchain.org/wiki/doku.php?id=start
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 14, 2010, 02:03:54 PM
 #302

Let me throw in a rough outline of a completely different idea, that is not based on the Bitcoin chain.

Suppose the rule is this:

Quote
A domain name registration is a mapping from the domain name to a list of (one or more) name servers that are authoritative for that domain name.

The "owner" of a domain name is whoever posts a mapping with the hardest proof of work attached.

Here's how it would work. If no-one else has registered the name that you want, post a mapping from it to your nameservers, together with a hash that represents some proof of work. Now keep on hashing, and every time you find a stronger proof of work, re-post your claim with the stronger proof attached.

As long as you keep hashing, you will occasionally find a stronger hash, which will strengthen you claim on the name.

If someone else also wants your domain name, they can start hashing but you already have a head start. Of course, they can devote more machines to hashing than you, in which case they may be able to generate a better hash and take over your name.

Of course no-one wants to randomly lose their name because someone else was lucky enough to get a very good hash without really trying, so the rule could be that a hostile takeover requires a proof of work 16 times harder. Also there could be a 30-day delay before the takeover, which gives the existing owner a window to hire a server farm and retain the name if it's worth enough to them.

The end result is very different from our current system, but in the end it allocates every domain name to whoever actually wants it the most.

bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 14, 2010, 03:41:38 PM
 #303

I am propose to use a TLD .bit for bitdns

3 letters is better than 6

microsoft.bit
linux.bit
facebook.bit

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 15, 2010, 02:09:22 AM
 #304

Ok! I have written out the proposal, hope you like it... the BitDNS part nees fleshing out. However from what I have written you can get the drift.
 Grin
http://domainchain.org/wiki/doku.php?id=bitname

oh yeah, thanks to ribuck for the wiki.

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 15, 2010, 04:37:38 AM
 #305

In my proposal: http://domainchain.org/wiki/doku.php?id=bitname

The proposal that I have made has covered 3 main areas.

First: Changes to the Bitcoin Protocol.

Expanded templates, (allowing to check transactions based upon what they claim to be).  This also allows new services to be run within the chain without changing the protocol.  Using a strong scripting language it should be possible to make 'plugins' for generators so that they may accept new types of bitcoin transactions.

Transaction Grouping, this allows transactions to be grouped together by template.  Clients will only need to download the summary and the hash tree, unless they want more detail.

Burning transactions.  This is a new sort of transaction fee that 'burns' over time.  It contains two qualities, firstly total number of coins to be to be burnt, and secondly, the rate (per block) that it is burnt at.  This is the basis of the compensation to generators for including extra data in the block chain.   When the transaction stops burning, the extra data may be deleted.

Second: BitName

BitName is a named address that has a fingerprint of a public certificate.  Instead of sending bitcoins to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP, one could send bitcoins to 'da2ce7'.  The BitName concept is built upon burning transactions.  Each transaction that declares a name, must include a burning transaction to keep the name active.  The higher the rate of burning the more likely that the transaction will be accepted.  If the rate is too low, the network will likely ignore or forget the name early.

If a generator accepts a new transaction of the same name as a pre-existing, the network will likely orphan the block, unless the burning fee is so low that the network regards the name as spam.

The other significant benefit from having a BitName is public certificate verification, when one sends a message that is signed, the key signing the message can be check against the known name of the source.  The fingerprint included in the block chain then can be used to verify the signer.

Third: BitDNS

BitDNS is derived from BitName.  A BitName should be used to make any new BitDNS records.  This requirement in the future can be used for spam prevention.

Both the top-level root domains and the 2nd level domains need to be globally unique.  Root BitDNS records are expensive and both the initial fee and the burning  fees are network enforced.  The main purpose of the root domains is top provide a service to the 2nd level domains.  To be accepted by a top-level domain, the fees defined by the top-level domain must be paid to its address.  This is enforced.

2nd level domains behave much like BitNames, with two main difference: first, to be used the domain must pay registration fees to at-least one top-level domain.  Secondly, IP addresses can be binded to these domains.

Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain.  Man-In-The-Middle attacks are very, very, very difficult under this system.

I'm still working on the sub-domain structure.

One off NP-Hard.
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
December 15, 2010, 05:51:21 AM
 #306

Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.

C++ is a strong scripting language.

Get the other technical details right.  Picking a programming language is the lowest task on the priority list.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 15, 2010, 06:26:42 AM
 #307

Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.

Yes, any strong scripting language language will do.  I'll leave it up to the programmers to pick the language.  Grin

One off NP-Hard.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 15, 2010, 05:15:12 PM
 #308

Amazing that I was just inventing this kind of system (Bitcoin based DNS) only to find this huge thread discussing it.

I actually suggested something like this before with this post: http://bitcointalk.org/index.php?topic=701.msg7545#msg7545 (Bit Stock Broker).

The fundamental key here is verifiable ownership and transfer.  The "thing" that is being transferred whether stock, DNS, title, etc should be handled out-of-band.

Every 'thing' needs a name.   100% of all bitcoins (present and future) is the bitcoin 'name/stock'.
Every 'thing' may have partial ownership which may be transferred.
A DNS is just a name owned by one or more public keys.

Assuming we had a means of transferring fractional ownership of arbitrary names then anyone can validate a use of that name with what ever service.

So suppose BitDNS issues a new thing named 'apple' and assigns it a public/private key pair and 100% ownership.  Facebook could now require that you sign your account application with the private key of 50+% ownership of the 'apple' name and at the same time a DNS service could make the same requirement.

All over the internet everyone could verify all data that came from some set of owners.  So the owner of apple could create a DNS file that contains an IP address and then sign it.  That file could be distributed and queried by what ever p2p or server/client system user applications desire.

To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred.
Limit the creation of new 'names' to N per block. 

By only storing the hash of the name you enable verification of ownership without giving away anything about 'what is owned'.

The only other feature we would need is to define a transaction such as:

100 BTC From MyBtcAddress -> Block Creator
100% name From NEW -> MyBtcAddress  (signed by MyBtcAddress)

When a block is created 'high bid wins' and low bids for name are ignored.

Keep all uses of this name (Facebook, DNS, email, forum login, reputation systems, etc) out of band. 









https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3797



View Profile
December 15, 2010, 09:46:24 PM
 #309

"To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred."

In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.

I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?

Hal Finney
jimbobway
Legendary
*
Offline Offline

Activity: 1304
Merit: 1014



View Profile
December 16, 2010, 02:11:03 AM
 #310

I am hoping the developers implement Satoshi's ideas which are:

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

I especially don't want a fork so my Bitcoins are worth something.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 16, 2010, 02:14:14 AM
 #311

How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.

The longer we wait, the less chance of success we will have.

da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 03:31:55 AM
 #312

How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.

The longer we wait, the less chance of success we will have.

Hmm, I don't think that the longer the wait the less chance of success...

I'm interested in comments about my proposal.  I think that it solves much of the issues in a logical manner.

One off NP-Hard.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 16, 2010, 04:22:13 AM
 #313


Hmm, I don't think that the longer the wait the less chance of success...


There is some compoetition in the form of dot p2p project.

appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 16, 2010, 05:55:56 AM
 #314


Hmm, I don't think that the longer the wait the less chance of success...


There is some compoetition in the form of dot p2p project.

I wonder if more thought should be put into the nature of names.  Is providing an abstraction over ip the real intent?

What about registering a public key, so that you could later use the name as a pseudonym and show that you're the true owner?

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
December 16, 2010, 07:41:49 AM
Last edit: December 16, 2010, 08:54:27 AM by bitcoinex
 #315

This system can be used not only for DNS, it can hand out nicknames in various decentralized networks.

For example, sooner or later, the phone numbers will be replaced with names that the user can create their own.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 08:40:41 AM
 #316

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

All the chain needs to include is a name and a fingerprint of a public key.  Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint.

The system is simple and secure.

One off NP-Hard.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
December 16, 2010, 12:15:23 PM
 #317

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

Currency should stay currency, domains should stay domains. This should be separate things.
It is stupid to push something like this on the main client / blockchain.

da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 12:24:32 PM
 #318

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

Domain names shouldn't be 'given' out, it makes no logical scene.  The separation issues is resolved by having 'groups' within the block.  This allows the clients to download what they care about, and ignore the rest.

Bitcoin must be use as the payment method, if we are using the bitcoin CPU power.  Bitcoin already has a built in 'instant' compensation method called 'transaction fees'.

I have proposed a secondary ongoing compensation method called 'Burning transactions' allowing things, like data, to compensate the bitcoin network over it's life.  Then the data can be removed from the chain!

Having a interdependent chain sounds pretty, but would be ugly in practice. Compensation in bitcoins would no-longer be natural and would require messy cross linking.

One off NP-Hard.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 16, 2010, 02:06:45 PM
 #319

Burning transactions sound like a useful mechanism, apart from the fact that they would require changes to Bitcoin. I keep wondering whether there is a way to take the burning mechanism outside of Bitcoin itself, I can't think of a good way to do so.

I also wonder whether it would be a good thing to turn all Bitcoin transaction fees into burning ones, to spread the benefit of processing a transaction beyond the immediate generator.

PS: I don't understand the bit about doing away with Certificate Authorities for secure internet connections, but if this is possible it would be a very popular fringe benefit.
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 16, 2010, 03:45:14 PM
 #320

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

All the chain needs to include is a name and a fingerprint of a public key.  Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint.

The system is simple and secure.

I agree that it is simple.

I think a reliable database of pseudonym to public key (or hash of public key, etc.) mappings could solve a variety of problems.

For example, i2p has an issue distributing eepsite keys in some trusted manner.  And, we're all aware of problems with DNS.

It seems to cover the "irrevocable eternal resource identifier" aspect of DNS but not the "pseudonym to pseudonym transferable virtual property" aspect.
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 16, 2010, 03:59:10 PM
 #321

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

All the chain needs to include is a name and a fingerprint of a public key.  Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint.

The system is simple and secure.

I agree that it is simple.

I think a reliable database of pseudonym to public key (or hash of public key, etc.) mappings could solve a variety of problems.

For example, i2p has an issue distributing eepsite keys in some trusted manner.  And, we're all aware of problems with DNS.

It seems to cover the "irrevocable eternal resource identifier" aspect of DNS but not the "pseudonym to pseudonym transferable virtual property" aspect.

A search for "distributed certificate authority" yields many academic results.  I wonder if any of these provide the same guarantees that a block chain based approach would?
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 04:40:55 PM
Last edit: December 16, 2010, 04:52:41 PM by da2ce7
 #322

@ribuck

Certificate Authority's work by having a 'master private key' that signs people public keys.  The CA (should) check that the public key indeed belongs to the person it claims to belong to.

Such as CA > signs > address.com key.

Web browsers have the public  keys of many CA's installed by default, when a browser comes across a sight that has a public key it
1. Checks if the public key matches the address of the site.
2. Checks if any of the known CA's public keys match the signature included with the sites public key.
3. Checks if the public key hasn't been revoked or expired.

This entire system revolves around the trust that the user has for the CA's.
The problem is that in practice CA's sign anything, including adversaries, so valid sites owned by evil people get accepted in the browser.  But, worse. CA's sign public keys of sites that already have an active private key to 3rd parties (such as governments).  This allows man-in-the-middle attacks that cannot be easily detected, as to the browser the site is perfectly valid.  However in practice it is just a proxy of a site.


The solution to this major mess that we are in is to get rid of the CA!  We let people 'tie' a public key to something that is human rememberable, (such as a user name, or a DNS name).

1.  The owner of Site A, create a private/public key pair, this par contains a Public Key.  The owner then Hashes the public key and creates Hash(KeyA).
2.  The owner of Site A then creates a new BitDNS transaction that contains "SiteA" and Hash(KeyA).
3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)
4.  Then this user, navigates to Site A's IP address, and is sent Key A, and a signed welcome message.
5.  The user checks if Hash(BitDNS KeyA) == Hash of (IP KeyA).  If this is true, then a man-in-the-middle attack is impossible.

For an adversaries to pretend to be Site A, they must re-write the entire block chain from the point that Site A was registered.  This process would be very public, and Site A would quickly work out that it has been attacked.

I believe this system is very secure, and to my knowledge no easy attack has been devised.

One off NP-Hard.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 16, 2010, 05:36:10 PM
 #323

"To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred."

In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.

I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?

Each block is allowed to register a maximum number of new names.   Transaction fees determine the priority of name registration.  Hashing the name prevents 'front running' good names.

By tying a concept such as an 'IP' address into the block chain you end up with a fundamental problem of too narrow a scope (IP based networks) that still depend upon current network design.   Suppose that web 3.0 did away with dedicated servers and instead used a gigantic distributed hash table that mapped keys (domain + filename) to values (files) and verified permission to modify the value stored at domain+filename based upon signing the contents of filename with the private key of the domain.  In this situation content is not looked up by 'ip address', but by a hash of the contents domain + filename.

Now imagine that this gigantic distributed hash table stored an 'ip address' at domain/ip.   So users would buy a named public/private key pair via BitName and then trade it (including partial ownership) using the block list.  Then someone invents a snazzy DNS app that knows how to lookup the IP in the DHT.  Users of the domain lookup would not need the block list, they would simply trust the DHT which would validate all writes against the blocklist.


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 16, 2010, 07:43:18 PM
 #324


1.  The owner of Site A, create a private/public key pair, this par contains a Public Key.  The owner then Hashes the public key and creates Hash(KeyA).
2.  The owner of Site A then creates a new BitDNS transaction that contains "SiteA" and Hash(KeyA).
3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)
4.  Then this user, navigates to Site A's IP address, and is sent Key A, and a signed welcome message.
5.  The user checks if Hash(BitDNS KeyA) == Hash of (IP KeyA).  If this is true, then a man-in-the-middle attack is impossible.


I don't know about step 3.  That is, I wonder if it's sufficient to simply have A's public key and then get the IP address through other means, making sure it's signed by A's key.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
December 16, 2010, 09:09:48 PM
 #325

Thank you, da2ce7, for that explanation. If that blocks man-in-the-middle attacks, I guess my question is why we're not already putting a hash of the public key into regular DNS records (particularly as signing of the DNS system is currently being implemented).

But yeah, I think a lot of people would like to be able to bypass their CA if there was a way.
da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 10:59:51 PM
 #326

3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)

I don't know about step 3.  That is, I wonder if it's sufficient to simply have A's public key and then get the IP address through other means, making sure it's signed by A's key.

Yes, all than needs to be included in the block chain is Site A's name and a hash of Site A's Public key.  Gaining access to the site via their IP address can be done through any method.  The point is that it is impossible to 'pretend' to be 'Site A' without having Site A's private key.

One off NP-Hard.
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 17, 2010, 03:16:10 AM
 #327

3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)

I don't know about step 3.  That is, I wonder if it's sufficient to simply have A's public key and then get the IP address through other means, making sure it's signed by A's key.

Yes, all than needs to be included in the block chain is Site A's name and a hash of Site A's Public key.  Gaining access to the site via their IP address can be done through any method.  The point is that it is impossible to 'pretend' to be 'Site A' without having Site A's private key.

Right.  I'm thinking that this could be a huge boon to security and privacy.

I'm not sure that it makes sense to talk about "sites" in particular, but I think we're on the same page.

One problem with certificates is that sometimes the private keys are secretly leaked to government agencies or "discovered" by other third parties.  I think an important part of this system would be a "kill signal", that is a way for a name to self destruct by signing the order with its private key.

This way, whistleblowers who discover a private key would be able to anonymously convey the message that the site's security has been compromised.  There is no reason for their pseudonym or their public key to appear in the system anymore because there is no way to recover from such a private key exposure.  For instance, if a new public key were created and "blessed" by the old one, we couldn't tell if this was an action taken by the authentic person or the imposter.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 18, 2010, 02:23:58 AM
 #328

So lets assume that the private key for 'bytemaster' has been compromised.   Bytemaster issues the command to invalidate it.  Now 'bytemaster' is up for bids to the highest bidder.  All trust must be placed in the public key and not the name itself.  Transferring the name to a new owner would have to reset the trust.

Seems like the solution to this problem is to have a 'backup key' such that when the primary key is nuked the backup key takes over.  There could be multiple 'backup layers'.    To transfer a name would require signing the transfer will ALL backup private keys.  When a key is compromised the backup key could then be used to replace the primary key without destroying the reputation of the owner.

Now a site like 'google.com' could give out the private key to 'trusted' admins and lock away their 'backup key' in a secure vault without having to assume the risk of their valuable 'name' being destroyed by one dishonest admin.



https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 18, 2010, 02:49:22 AM
 #329

Furthermore, let us generalize this principle.

   - the owner of a key may 'grant' other names privileges such as:
      * may transfer name
      * may sign data
      * is trusted by me

Now you have an encrypted 'web of trust' and companies like google.com can track which admin made changes and grant/revoke permissions. 



https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 18, 2010, 05:47:48 PM
 #330

So lets assume that the private key for 'bytemaster' has been compromised.   Bytemaster issues the command to invalidate it.  Now 'bytemaster' is up for bids to the highest bidder.  All trust must be placed in the public key and not the name itself.  Transferring the name to a new owner would have to reset the trust.

Seems like the solution to this problem is to have a 'backup key' such that when the primary key is nuked the backup key takes over.  There could be multiple 'backup layers'.    To transfer a name would require signing the transfer will ALL backup private keys.  When a key is compromised the backup key could then be used to replace the primary key without destroying the reputation of the owner.

Now a site like 'google.com' could give out the private key to 'trusted' admins and lock away their 'backup key' in a secure vault without having to assume the risk of their valuable 'name' being destroyed by one dishonest admin.

I don't think invalidating a name should put it up for bids.  I think the name is just done at that point.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 18, 2010, 09:45:12 PM
 #331

I am under the impression that nothing codewise is getting done.

bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 18, 2010, 11:42:55 PM
 #332

Actually, I have started work on an implementation (not based upon bit-coin source).   

I think there needs to be a way to recycle a name after it has been killed.  As long as the 'trust' is based upon public keys and the name is just an alias.

In theory one public key could have two names.   

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
appamatto (OP)
Jr. Member
*
Offline Offline

Activity: 36
Merit: 13


View Profile
December 18, 2010, 11:49:14 PM
 #333

I am under the impression that nothing codewise is getting done.

I'm working on bitx.  You can follow my (slow and leisurely) progress at the fossil repository (http://bitx.appamatto.com) and my blog (http://appamatto.com).  Once that's done, I'll work on either the bitcoin on bitx implementation or on bitCA, which seems to be the better way of doing DNS and related services.

I think theymos/nanotube are working on their proposal as well.  There are probably other proposals that don't require additional block chains or changes to changes to bitcoin proper, but even then it seems a little to early for finished products.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 22, 2010, 12:46:07 AM
 #334

Progress report?

bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
December 22, 2010, 04:14:19 AM
 #335

The design of bitcoin as a linked-list of transactions does not apply well for non-linked list state changes.  I have been struggling with how this could all be implemented in a more generic manner an have come to the following conclusions.

Review of Goals:
1) Global name registry, 1 name -> public_key
2) Ability to issue new 'stocks' backed by real commodities or simply 'competing' bit-currencies.
3) Ability to expand block chain to support new commands and state changes.
4) Keep application data outside the block chain


1) Each block in the chain contains one or more 'transactions'.
2) A 'transaction' is a list of 'commands' to perform on one or more 'global database tables'. 
3) Each client must process the commands in order to arrive at the same 'global database state'
4) The changes to the global 'state' must be kept in a BerkeleyDB transaction until confirmed by enough blocks.
          - any changes to the block chain (finding a longer chain) would simply 'abort' the 'db transaction' and cause it to try again.
5) The end result is a block chain able to manage the state of any number of different 'tables' simply by defining
         new commands.

Effectively the block chain would represent 'edits' from the last 'balance sheet' or 'snapshot'.   

Initially there are two commands:

1) register_name  'name'   'public_key'     (name may only contain a-z0-9_)  ('.' is reserved as a delimiter)
     - the command is only successful if the public_key is signed by the private_key and 'name' is not registered
     - if the name is registered, then it must be signed by the old private key to transfer it.

2) transfer  SHARES  'stock_name'  'from_account_name'  'to_account_name'
    - 1 share = 1 / INT64_MAX
    - if from_account_name == 'new' then transfer must be signed by the private key of 'stock_name', otherwise by the private key of 'from_account_name'.  A 'new' stock can only be issued for 'stock_name' once.

    - each 'account_name' may have a different balance for each kind of share it holds.

Eventually there will be other commands to assign 'privileges' from one name to another.  To implement escrow transactions.  To post 'bid' and 'ask' transactions and thus eliminate the need for trusted 'exchanges'. 

   Now you can create commodity backed currencies and trade them as long as you trust the 'issuer'.   In theory you would have a 'name' for every stock on the stock market, every national currency, 'gold', 'silver'.   It would be like the days before central banking where each 'bank' issued its own paper currency backed by gold/silver.   The difference would be that everything would be public and there is a hard limit to the ability to print.   

I have implemented the back-end database, have all of the RSA encryption in place and am working on the block chain now. 

I am still open to ideas / potential pitfalls. 



   

 

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 24, 2010, 12:05:57 AM
 #336

theymos/nanotube, working on your implementation?

FreddyFender
Full Member
***
Offline Offline

Activity: 215
Merit: 100


Shamantastic!


View Profile
December 24, 2010, 06:11:00 AM
 #337

I made a little writeup on the original reason for this post before it became strictly bitDNS topic. There are a few thoughts and would appreciate anybody's input.

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

kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
December 29, 2010, 10:57:06 PM
 #338

Progress report?

hacim
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
January 04, 2011, 06:50:56 PM
 #339

If people are interested in finding working alternative solutions to the existing centralized certificate authority problem, the Monkeysphere project (http://monkeysphere.info) has figured out how to do distributed, web of trust based, https X509 certificates. They have done quite a bit of key translation work and now you can verify a https website via your OpenPGP key and the web of trust, instead of relying on a centralized "authority". It also works for ssh host and user validation as well.

15yns1RVpBHZ8uj8mGVUJVCyPh5ieW3FQx
FreddyFender
Full Member
***
Offline Offline

Activity: 215
Merit: 100


Shamantastic!


View Profile
January 06, 2011, 04:00:37 AM
 #340

http://www.aaronsw.com/weblog/squarezooko
Apparently this topic is now dead...  Huh

em3rgentOrdr
Sr. Member
****
Offline Offline

Activity: 434
Merit: 251


youtube.com/ericfontainejazz now accepts bitcoin


View Profile WWW
January 06, 2011, 09:12:42 AM
 #341

http://www.aaronsw.com/weblog/squarezooko
Apparently this topic is now dead...  Huh

interesting.  didn't know it was 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."
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
January 06, 2011, 03:16:01 PM
 #342

http://www.aaronsw.com/weblog/squarezooko
Apparently this topic is now dead...  Huh

So is BitDNS officially dead ?
Is somebody doing anything at all in here ?

FreddyFender
Full Member
***
Offline Offline

Activity: 215
Merit: 100


Shamantastic!


View Profile
January 06, 2011, 03:55:15 PM
 #343

From what I can tell, the proposal located on domainchain: (see http://domainchain.org/wiki/doku.php?id=start#proposal ) goes against Satoshi's wishes to keep the bitcoin blockchain unencumbered and ties domain assignments directly to bitcoin.
Many community members have stated that this is impractical and will leave bitcoin if attempts continue to include domainchain into bitcoin directly.
Satoshi asked that a new tree be created with a separate currency that floats its value according to demand with the bitcoin service.

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.

What we have here are dedicated coders/hackers that are racing ahead of theorists. The theory must be bulletproof before any proposals are launched.
I think we need mathematical theorists to begin the process and then hand off to coders the basic structure while pointing out weaknesses.

A new chain with grassroot development should excite the miners and coders and calm the fears of the thinkers/theorists among the community.
The funny thing is, once the theory is solid the porting of a new BitDNS(Domainchain?) will be very simple. All the stumbling blocks appear to be centered around including Domainchain into the Bitcoin structure instead of branching it into its own chain.

Domainchain is dead, long live Domainchain!
 Smiley

kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 06, 2011, 05:13:34 PM
 #344


What we have here are dedicated coders/hackers that are racing ahead of theorists. The theory must be bulletproof before any proposals are launched.
I think we need mathematical theorists to begin the process and then hand off to coders the basic structure while pointing out weaknesses.


Satoshi proposed a brilliant solution to the chain problem long ago in the thread.(As well as appamatto but Satoshi's solution is much simpler) We don't need to worry about integrating those information in the bitcoin chain since we can use the same miners to generate 50 BTC and domain name coin.

Only execution will give us something to work with. Theorists are just that, theorists. If the ideas don't get implemented, the idea of BitDNS is simply worthless.

da2ce7
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
January 06, 2011, 10:23:26 PM
 #345

Satoshi proposed a brilliant solution to the chain problem long ago in the thread.(As well as appamatto but Satoshi's solution is much simpler) We don't need to worry about integrating those information in the bitcoin chain since we can use the same miners to generate 50 BTC and domain name coin.

Only execution will give us something to work with. Theorists are just that, theorists. If the ideas don't get implemented, the idea of BitDNS is simply worthless.

The problem with 'domain name coin' is that it doesn't make economic sense. There should be no 'restriction of supply' of domain names. The cost of a domain name should be directly related to the network cost in supporting that domain.  Transaction fees make much more economic scene than a new 'domain coin' as the network compensation mechanism.

One off NP-Hard.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 06, 2011, 11:10:33 PM
 #346


The problem with 'domain name coin' is that it doesn't make economic sense. There should be no 'restriction of supply' of domain names. The cost of a domain name should be directly related to the network cost in supporting that domain.  Transaction fees make much more economic scene than a new 'domain coin' as the network compensation mechanism.

We're going around in circles. All this arguments had been exhausted and now we're just repeating them ad nauseum.

Still, the correct protocol that been derived by argumentation is meaningless without an execution to work with.

RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
January 07, 2011, 12:20:08 PM
 #347

Satoshi proposed a brilliant solution to the chain problem long ago in the thread.(As well as appamatto but Satoshi's solution is much simpler) We don't need to worry about integrating those information in the bitcoin chain since we can use the same miners to generate 50 BTC and domain name coin.

Only execution will give us something to work with. Theorists are just that, theorists. If the ideas don't get implemented, the idea of BitDNS is simply worthless.

The problem with Satoshi's "solution" is that it is only half a solution and doesn't address the key sticking point.  The problem is the desire to use Bitcoins, as we currently use bitcoins, to pay the "fees" for conducting "transactions" with the DNS system or other similar systems and to give that payment some sort of meaning in terms of that payment being something other than a purely voluntary and optional donation system.

Please correct me if I'm wrong in my interpretation, but that is the real issue at hand right now.  I've outlined my ideas clearly, and furthermore Satoshi's "solution" only addresses the issue of forking the mining effort or trying to keep that at least somewhat unified.  Essentially he was suggesting that alternate "currencies" could put together some sort of networking protocol to share the mining effort.  On that point I completely agree, but the unstated elephant in the room, the one thing that everybody wants to avoid but isn't being stated, is the need to create a parallel currency to Bitcoin because Bitcoin itself is inadequate to accomplishing the task at hand.

At the moment I'm working at trying to re-implement the Bitcoin specification as an alternate implementation... for my own benefit and use but I do have some reasons for that as well.  That is a huge hurdle to accomplish, and that is one of the reasons why you also don't see anything happening with this concept at the moment because such an effort takes time.  My goal, as such as it is, that once I create a working alternate client to Bitcoin that I can then make a "fork" to do other things with it such as BitDNS.  We could also fork the main Bitcoin client flat out, but regardless what is needed is to fork the protocol itself.  It is something that most developers involved are trying desperately not to do either, as evidenced by the Nanotube/Theymos effort and the work of others.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 07, 2011, 04:27:43 PM
 #348

Please correct me if I'm wrong in my interpretation, but that is the real issue at hand right now. 


Wrong. The real problem is that there are no execution to work with. Concepts and ideas doesn't matter if we have nothing to work with.

RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
January 07, 2011, 05:34:08 PM
 #349

Please correct me if I'm wrong in my interpretation, but that is the real issue at hand right now. 


Wrong. The real problem is that there are no execution to work with. Concepts and ideas doesn't matter if we have nothing to work with.

If the concept is flawed, there will be no execution of the idea.  That is what I'm suggesting.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 07, 2011, 06:02:40 PM
 #350


If the concept is flawed, there will be no execution of the idea.  That is what I'm suggesting.

The concepts have nothing to do with the execution. The execution will make reality a a flawed concept, but we can alway fix the code.

But if there is no code to fix, there is nothing to work with.

Write crappy code that demonstrate said concept. Fix said concept if it doesn't work the way people like. Then fix said code. Repeat this process.

Then write correct and clean code. Make it fast. Then, make the interface good.

kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 19, 2011, 04:12:07 AM
 #351

* kiba pokes.

joe
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
January 27, 2011, 10:09:36 AM
 #352

Satoshi proposed a brilliant solution to the chain problem long ago in the thread.(As well as appamatto but Satoshi's solution is much simpler) We don't need to worry about integrating those information in the bitcoin chain since we can use the same miners to generate 50 BTC and domain name coin.

Only execution will give us something to work with. Theorists are just that, theorists. If the ideas don't get implemented, the idea of BitDNS is simply worthless.

The problem with Satoshi's "solution" is that it is only half a solution and doesn't address the key sticking point.  The problem is the desire to use Bitcoins, as we currently use bitcoins, to pay the "fees" for conducting "transactions" with the DNS system or other similar systems and to give that payment some sort of meaning in terms of that payment being something other than a purely voluntary and optional donation system.

Please correct me if I'm wrong in my interpretation, but that is the real issue at hand right now.  I've outlined my ideas clearly, and furthermore Satoshi's "solution" only addresses the issue of forking the mining effort or trying to keep that at least somewhat unified.  Essentially he was suggesting that alternate "currencies" could put together some sort of networking protocol to share the mining effort.  On that point I completely agree, but the unstated elephant in the room, the one thing that everybody wants to avoid but isn't being stated, is the need to create a parallel currency to Bitcoin because Bitcoin itself is inadequate to accomplishing the task at hand.


I agree with RHorning on the 3 main problems:
1. Create parallel currency for doing DNS
2. Fork the chains but merge the mining effort to allow miners already working on bitcoin to complete DNS blocks with no additional work.
3. Allow BitDNS miners to be rewarded in bitcoins or any non-voluntary reward system


Here are the solutions to each problem:

1. This is trivial. Start a new chain with a new genesis block and with the network operating on a different port.

2. This was addressed by Satoshi in an earlier post and clarified today in IRC by tcatm. The way bitcoin currently works is we search for a nonce such that, when hashed together with the work (prevhash + merkle tree containing bitcoin transactions) we get a hash with a lot of zeros in front (this makes the difficulty).

The idea is that we create a father merkle tree that contains the work for an arbitrary number of parallel currencies. So miners will use the hash of this tree instead of using the tree of just the bitcoin transactions. Essentially we created a large tree that contains the transactions for many different currencies.

The miner then presents the solution to each parallel currency's network by revealing the specific leaf of the father tree that contains the data specific to that currency, and the rest proceeds as it currently does.

3. The upkeep of the BitDNS network should be paid for either by every domain name owner paying a sort of rent to miners that produce BitDNS blocks, or through DNS transaction fees. Whenever a BitDNS transaction occurs, the recipient will be required to supply a Bitcoin address. Each miner on the BitDNS network will set a block solving fee they feel comfortable with. When a miner works on solving a BitDNS block, he will check the main bitcoin network to verify that domain owners have paid sufficient rent or transaction fees to miners of previous blocks. Any domains that have not paid, the miner will be entitled to make themselves owners of it.


With all of these questions answered, now we can start on the execution and write the code.
Anonymous
Guest

January 27, 2011, 10:45:24 AM
 #353

Nice post Joe.

devrandom
Newbie
*
Offline Offline

Activity: 26
Merit: 0



View Profile WWW
January 31, 2011, 08:39:25 AM
 #354


3. The upkeep of the BitDNS network should be paid for either by every domain name owner paying a sort of rent to miners that produce BitDNS blocks, or through DNS transaction fees. Whenever a BitDNS transaction occurs, the recipient will be required to supply a Bitcoin address. Each miner on the BitDNS network will set a block solving fee they feel comfortable with. When a miner works on solving a BitDNS block, he will check the main bitcoin network to verify that domain owners have paid sufficient rent or transaction fees to miners of previous blocks. Any domains that have not paid, the miner will be entitled to make themselves owners of it.


Rents should be due at specific bitcoin block #s so that any temporary forks on the bitcoin chain won't result in permanent forks on the BitDNS chain.  Once all miners see the same rent payment / non-payment at the said bitcoin block #, the fork will heal by global acceptance or rejection of the take-over block.  Might even want to have a "look-back" of a few hours in the bitcoin chain to eliminate this source of instability.
carp
Member
**
Offline Offline

Activity: 82
Merit: 10


View Profile
February 02, 2011, 02:15:52 AM
 #355

I agree with RHorning on the 3 main problems:
3. Allow BitDNS miners to be rewarded in bitcoins or any non-voluntary reward system
...
3. The upkeep of the BitDNS network should be paid for either by every domain name owner paying a sort of rent to miners that produce BitDNS blocks, or through DNS transaction fees. Whenever a BitDNS transaction occurs, the recipient will be required to supply a Bitcoin address. Each miner on the BitDNS network will set a block solving fee they feel comfortable with. When a miner works on solving a BitDNS block, he will check the main bitcoin network to verify that domain owners have paid sufficient rent or transaction fees to miners of previous blocks. Any domains that have not paid, the miner will be entitled to make themselves owners of it.

With all of these questions answered, now we can start on the execution and write the code.


(all that about a generalized merkel tree is fascinating and makes me think that I need to read up more on that, I think its compatible with what I am proposing below)

Excellent, I look forward to seeing the code Smiley

Though, this last exercise in figuring out payment or "rent" makes me think, maybe there is a bit more to flesh out at the base of the ideas. It seems to me that it would make more sense to associate a name with an "account" than with "a coin". I will try to explain what I mean in terms of bitcoin, since its what we all seem to know Smiley

What if we, starting with bitcoin, change the name to dnscoin, or something equally witty, add a couple of transaction types and change a few definitions. What if you were to say, that the value of every account, decreases by 1 unit every block. Then add a new transaction type that allows an account to assign a mapping to any, currently unused name.... 1 per account. The name becomes "unassigned" when the most recent account to map falls to a value of 0.

Obviously, we need to tweak the mining operations to provide more coins per block, or even build in an inflation to account for expanding need for names... but it easily makes "DNS Coins" something that one can trade for bitcoins. Perhaps allow an account to be "unmapped" and not subject to the implicit fee.

That seems easier to me than trying to coordinate bitcoin payments and having miners set fees etc. Just let them mine a the valuable resource, and sell it as they see fit.

So if each block generated 52,000 "dnscoins" then that would be enough to create 2 domains for 6 months a piece, or fund 1 for a year.... or 52,000 for 10 minutes... or however we want to make the numbers work out.

Interestingly, this would also make helping a friend very easy. If I see that your domain is about to run out of bitdns, I just take the address and send it some coin.... then settle up with you later in some other manner, or tell you to have a merry christmass. Hell, maybe I run a service that watches your domains and keeps them topped up from my reserve of dnscoin.

As the account owner, you can still kill the domain by unassigning it.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1078


View Profile
February 03, 2011, 05:59:39 PM
 #356

If somebody is going to work on the code for this, please consider N alternative chains not just 2. I'm also interested in "BitX" for stuff related to online voting.

The real questions are around how do you cleanly separate the currency parts of BitCoin from the distributed quorum aspects.
phathash
Member
**
Offline Offline

Activity: 75
Merit: 10


View Profile
March 08, 2011, 12:07:16 PM
 #357

Would this payload "domainchain" proposes to use be stored in the block chain indefinitely? How big can the payload be and what is it's purpose in the protocol? Can nodes choose to ignore it?



ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 08, 2011, 02:29:31 PM
 #358

Would this payload "domainchain" proposes to use be stored in the block chain indefinitely? How big can the payload be and what is it's purpose in the protocol? Can nodes choose to ignore it?

AFAIK, BitDNS data will not be stored in Bitcoin main chain... i thought this is already clear.

jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
March 08, 2011, 05:26:30 PM
 #359

Would this payload "domainchain" proposes to use be stored in the block chain indefinitely? How big can the payload be and what is it's purpose in the protocol? Can nodes choose to ignore it?

AFAIK, BitDNS data will not be stored in Bitcoin main chain... i thought this is already clear.

Under the plan by theymos, it would be stored in the bitcoin main chain.

satoshi suggested an alternative, where there would be multiple bitcoin chains, and the non-currency data such as BitDNS would be stored there instead of the main chain.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 08, 2011, 06:15:38 PM
 #360

Would this payload "domainchain" proposes to use be stored in the block chain indefinitely? How big can the payload be and what is it's purpose in the protocol? Can nodes choose to ignore it?

AFAIK, BitDNS data will not be stored in Bitcoin main chain... i thought this is already clear.

Under the plan by theymos, it would be stored in the bitcoin main chain.

satoshi suggested an alternative, where there would be multiple bitcoin chains, and the non-currency data such as BitDNS would be stored there instead of the main chain.

OK, but has any final decision been made ?

Personally i hate bloat and i don't like the idea of storing non-currency data in the chain...

phathash
Member
**
Offline Offline

Activity: 75
Merit: 10


View Profile
March 08, 2011, 08:38:46 PM
 #361


I can't understand why this extra payload feature is in the protocol? Can nodes choose to ignore it?

I was looking at the common structures in the protocol specification. Where does it discuss the size of this payload?
iya
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 09, 2011, 02:36:19 AM
 #362

The discussion is not about the current protocol, but future extensions.

I don't see how any payload could be separated from the main chain.

This is my simple idea: enable the storage of any data in the main chain, for Bitcoin fees, at the miners discretion.

Hosts who do not understand a certain data type, ignore it, and those who do understand verify it.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
March 09, 2011, 02:59:43 AM
 #363

The discussion is not about the current protocol, but future extensions.

I thought we reached a consensus that the domain names will be outside of the main chain.

phathash
Member
**
Offline Offline

Activity: 75
Merit: 10


View Profile
March 09, 2011, 03:39:17 AM
 #364

So there is no "payload" currently in transactions?
iya
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 09, 2011, 04:16:59 AM
Last edit: March 09, 2011, 04:35:49 AM by iya
 #365

@phathash
Currently the only thing the blockchain are Bitcoin transactions. You can call that payload, if you want.

@kiba
Sorry, but I didn't read all pages, only the beginning and the end.

Can you link the post explaining who would rationally provide for the upkeep of a separate chain?

The expense of any chain is storage in the form of disk space and defence/upkeep in the form of compute power/electricity and bandwidth.
This must all be financed by the hosts = miners.

Bitcoin would still hold a special position, because it would be the unit of accounting for all other "transactions".
For example, for a BitDNS transaction with fee, you'd also need a Bitcoin transaction, solely for this fee.

The ability to use the blockchain as a service would provide a kind of real backing for Bitcoins.

Do you think that it would be too much data? The miners surely can meet supply and demand.

Isn't BitDNS Bounty (3500 BTC) for a system of this kind?
I'd start development, but I haven't even compiled Bitcoin, yet. Has somebody a guide for how to compile on Windows?
Starting from scratch is a little too much.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 09, 2011, 11:15:26 AM
 #366

The discussion is not about the current protocol, but future extensions.

I thought we reached a consensus that the domain names will be outside of the main chain.

+ 1
Exactly, i thought that was decided long ago.

0x6763
Guest

March 09, 2011, 09:20:03 PM
 #367


I can't understand why this extra payload feature is in the protocol? Can nodes choose to ignore it?

I was looking at the common structures in the protocol specification. Where does it discuss the size of this payload?


Transaction inputs and outputs contain "scripts", which provide very flexible ways to create different types of transactions (however most of this functionality is currently disabled in the official client).  Arbitrary data (of limited size) can be placed in these scripts.

https://en.bitcoin.it/wiki/Protocol_specification#tx
https://en.bitcoin.it/wiki/Script
Dude65535
Full Member
***
Offline Offline

Activity: 126
Merit: 101


View Profile
March 10, 2011, 06:43:44 AM
 #368

Can you link the post explaining who would rationally provide for the upkeep of a separate chain?

I haven't read this whole thread so this may have been suggested already.

Here is a solution for paying for upkeep of a dns chain. Have dns mining produce credits that are used to create a new domain name. Then provide a way for the credits and domain names to be traded contingent upon a payment to a certain bitcoin address showing up in the bitcoin block chain. I would think that amount of credits per block probably needs to increase over time rather than decrease like bitcoin does.

1DCj8ZwGZXQqQhgv6eUEnWgsxo8BTMj3mT
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
April 15, 2011, 07:13:00 PM
 #369

http://forumserver.twoplustwo.com/29/news-views-gossip/reuters-full-tilt-poker-pokerstars-absolute-poker-charged-illegal-gambling-1020606/

Ladies and gentlemen, it become increasingly clear as to why we need a distirbuted DNS system. We have a 3500 BTC bounty incentive for you!

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1078


View Profile
April 16, 2011, 04:30:49 PM
 #370

I don't think it's clear there needs to be a different naming system. DNS is already distributed. These sites will move to non-US controlled TLDs and carry on just like WikiLeaks did.

The upkeep of alternative chains is not really an issue because with Satoshis plan, mining for additional chains is "free" beyond storage and whatever processing is required to enforce the rules of the system.
fabianhjr
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Do The Evolution


View Profile
April 17, 2011, 04:15:05 PM
 #371

It needs to be decentralized. That way there is no way in hell for politicians to be able to remove DNS entries.

The discussion so far is:
-The blockchain should remain clean and tidy
-The network must not be fragmented

I support the latter and should add support asap.

EDIT: http://www.digitalpolicy.ca/Statement%20On%20Canadian%20Internet%20Sovereignty.pdf

kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
April 17, 2011, 04:31:27 PM
 #372


Isn't large part of that bounty conditional that "it must be done in the next 5 minutes" or something along those lines?

http://bitcointalk.org/index.php?topic=2072.msg26742#msg26742

Not really. It was a call to action to implement a registration system faster than our rival, but I don't think that's a requirement.

marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 05, 2011, 10:00:46 PM
 #373

Sorry maybe i am ignorant, but is not simple to edit our etc/hosts config in order to create our domain and share it among people instead to make a cpu eater with crypt and decrypt. Grin
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



View Profile
May 05, 2011, 10:43:43 PM
 #374

Sorry maybe i am ignorant, but is not simple to edit our etc/hosts config in order to create our domain and share it among people instead to make a cpu eater with crypt and decrypt. Grin
/palm

why use bitcoins? just use a .txt file that you share with your peers!

blockchains is to ensure nothing is tampered with, so someone can't come along and change something.

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 05, 2011, 10:55:37 PM
 #375

Sorry maybe i am ignorant, but is not simple to edit our etc/hosts config in order to create our domain and share it among people instead to make a cpu eater with crypt and decrypt. Grin
/palm

why use bitcoins? just use a .txt file that you share with your peers!

blockchains is to ensure nothing is tampered with, so someone can't come along and change something.

Before a face palm, why someone goes to change for example a domain

xxx.xxx.xxx.xxx marcus

Why someone goes to change marcus to pippo, there is no reason in a cheat like this, i don't think it is important, instead is something useful, for example in order to reach now wikileaks i must write a forgettable address, but thanks that i can write in the hosts, now i can reach wikileaks just wright http://assange  nothing more, all domains com, net, org etc are useless we must be free from icann, but we can also use opendns for other address.
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



View Profile
May 05, 2011, 11:03:43 PM
 #376

Sorry maybe i am ignorant, but is not simple to edit our etc/hosts config in order to create our domain and share it among people instead to make a cpu eater with crypt and decrypt. Grin
/palm

why use bitcoins? just use a .txt file that you share with your peers!

blockchains is to ensure nothing is tampered with, so someone can't come along and change something.

Before a face palm, why someone goes to change for example a domain

xxx.xxx.xxx.xxx marcus

Why someone goes to change marcus to pippo, there is no reason in a cheat like this, i don't think it is important, instead is something useful, for example in order to reach now wikileaks i must write a forgettable address, but thanks that i can write in the hosts, now i can reach wikileaks just wright http://assange  nothing more, all domains com, net, org etc are useless we must be free from icann, but we can also use opendns for other address.
Person A: wants to go to wikileaks.bit
Person A: asks his peers for the IP address
Malicious peer: gives Person A a fake address
Person A: goes to fake address, donates his money to the Malcious Peer, instead of wikileaks

also, I'm having a hard time understanding you. Try to phrase your sentences better.

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 06, 2011, 10:47:30 AM
 #377

Sorry maybe i am ignorant, but is not simple to edit our etc/hosts config in order to create our domain and share it among people instead to make a cpu eater with crypt and decrypt. Grin
/palm

why use bitcoins? just use a .txt file that you share with your peers!

blockchains is to ensure nothing is tampered with, so someone can't come along and change something.

Before a face palm, why someone goes to change for example a domain

xxx.xxx.xxx.xxx marcus

Why someone goes to change marcus to pippo, there is no reason in a cheat like this, i don't think it is important, instead is something useful, for example in order to reach now wikileaks i must write a forgettable address, but thanks that i can write in the hosts, now i can reach wikileaks just wright http://assange  nothing more, all domains com, net, org etc are useless we must be free from icann, but we can also use opendns for other address.
Person A: wants to go to wikileaks.bit
Person A: asks his peers for the IP address
Malicious peer: gives Person A a fake address
Person A: goes to fake address, donates his money to the Malcious Peer, instead of wikileaks

also, I'm having a hard time understanding you. Try to phrase your sentences better.

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks

grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



View Profile
May 06, 2011, 10:07:00 PM
 #378

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks
CIA: seizes official site for "child pornography"

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 06, 2011, 10:25:36 PM
 #379

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks
CIA: seizes official site for "child pornography"

Try to explain your opinion better, the file hosts is present on every OS and can be changed by everyone.

I think that such badass people use a church instead of a site. In my opinion i am against death but for this people i can close an eye. 
anisoptera
Member
**
Offline Offline

Activity: 308
Merit: 10



View Profile
May 07, 2011, 05:01:59 AM
 #380

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks



Who runs the official site? How do we go there? Does it have a normal ICANN DNS entry?

Why do we even have peers to ask for an IP address in this scenario? What data are we getting from the peers that we aren't getting from the list? In other words, for a peer to be unable to forge an IP address, we have to already know what the IP address is, so why are we asking them?

marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 07, 2011, 06:27:03 PM
 #381

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks



Who runs the official site? How do we go there? Does it have a normal ICANN DNS entry?

Why do we even have peers to ask for an IP address in this scenario? What data are we getting from the peers that we aren't getting from the list? In other words, for a peer to be unable to forge an IP address, we have to already know what the IP address is, so why are we asking them?

I hope to be clear, watch the sketch, give me your opinion.

http://img191.imageshack.us/img191/9048/bitdns.th.jpg

Uploaded with ImageShack.us
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



View Profile
May 07, 2011, 06:45:23 PM
 #382

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks



Who runs the official site? How do we go there? Does it have a normal ICANN DNS entry?

Why do we even have peers to ask for an IP address in this scenario? What data are we getting from the peers that we aren't getting from the list? In other words, for a peer to be unable to forge an IP address, we have to already know what the IP address is, so why are we asking them?

I hope to be clear, watch the sketch, give me your opinion.



Uploaded with ImageShack.us

can't read handwriting.

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
marxcoin
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
May 07, 2011, 06:50:13 PM
 #383

Person A: download list from an official site
Person A: asks his peers for the IP address
Malicious peer: cannot fake the list of the official site, or change local configuration without authorization.
Person A: cannot go to fake address, cannot donates his money to the Malcious Peer, and can go to see wikileaks



Who runs the official site? How do we go there? Does it have a normal ICANN DNS entry?

Why do we even have peers to ask for an IP address in this scenario? What data are we getting from the peers that we aren't getting from the list? In other words, for a peer to be unable to forge an IP address, we have to already know what the IP address is, so why are we asking them?

I hope to be clear, watch the sketch, give me your opinion.

http://img191.imageshack.us/img191/9048/bitdns.th.jpg

Uploaded with ImageShack.us

can't read handwriting.

click on it
dikidera
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 15, 2011, 11:03:45 AM
 #384

Why would one want to generate DNSes? That also doesnt seem possible.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
May 17, 2011, 05:26:00 AM
 #385

Sorry for jumping in here, but here is what I want to do with respect to BitDNS...

First lets establish some terminology for what I would like to see.

Assume bitcoins are just "shares" of a total 23M of some *named* stock.  Currently all values are named "bitcoin" which can be tracked back to multiple base shares issued 50 at a time.

Let users introduce a new "base coin" transferring 100% (23M or 2^64-1) of that base coin to an address.  Where as generation fees only transfer 50 "bitcoins" from nothing to a new address.
Imbed a unique "name" into the script for this transaction.  The private key for this initial address "owns the name".

An analogy to this "transaction" would be for a company, "Apple Computer", to issue a new coin type called AAPL and transfer 100% to and address owned by "Apple Computer".  Now shares of AAPL can be traded and change hands, but the "issuer" still owns the name AAPL and can "sign messages" and perform other actions using that "identity".

Now all we need to do to transfer ownership of the name is to issue a new transaction of 0 units for AAPL and no "previous output" and sign it with AAPL's private key.  This can change the private key used to "sign for" apple, but does not change ownership of AAPL shares. 

Now we have a way to create new identities, names, and allow them to issue shares which can be traded like any other bitcoin using a common block chain.

A DNS system can now be validated by having all records signed by the private key of the current holder of the name.  It can be implemented entirely outside the blockchain/bitcoin framework.

All transactions would be limited to dealing with only one type of coin at a time. 

The only fee for registering a name would be the normal bitcoin transaction fee.

This could be implemented without breaking the existing block chain, but it would break clients that did not upgrade.

Questions:
1) Will it always be possible to trace a coin back to its origin?  Or will this info be "discarded" after a while.
2) Can an arbitrary 'name' be entered into the origin script? 
3) Can this 'name' be queried as needed


Benefits:
1) No limit to the number of names that can be issued
2) Can leverage existing bitcoin block chain (without introducing domain specific concepts, just generalize the idea of trading shares of stocks)
3) All "name registration fees" are handled by current bit coin transaction fees
         - this would require 'grouping' two transactions BTC for the fee and AAPL for the shares... *or* it would require changing the CTxOut to specify the desired share type. 
               This would be a breaking change.

4) Names can optionally expire, but shares can never be "reissued". 
5) Your wallet would now contain a unique balance for each type of "coin" it holds.
6) When you "send coins" you would need to specify the type.
7) We just decentralized the stock exchange. 
Cool Anyone can create a "bank" and issue "digital bank notes"

I suspect there are many more benefits... so the main questions are technical.  What would it take to make that happen?

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
December 26, 2013, 10:57:09 PM
 #386

necro...   can anybody point me to or send me the original irc discussion?
coinrevo
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
December 28, 2013, 04:05:30 PM
 #387

Have been looking for those logs as well. 11/14/2010 is missing from here http://bitcoinstats.com/irc/bitcoin-dev/logs/2010/11
ArticMine
Legendary
*
Offline Offline

Activity: 2282
Merit: 1050


Monero Core Team


View Profile
December 28, 2013, 08:17:28 PM
 #388

BitDNS became Namecoin http://namecoin.info/

Concerned that blockchain bloat will lead to centralization? Storing less than 4 GB of data once required the budget of a superpower and a warehouse full of punched cards. https://upload.wikimedia.org/wikipedia/commons/8/87/IBM_card_storage.NARA.jpg https://en.wikipedia.org/wiki/Punched_card
phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1019



View Profile
December 29, 2013, 08:20:05 PM
 #389

Have been looking for those logs as well. 11/14/2010 is missing from here http://bitcoinstats.com/irc/bitcoin-dev/logs/2010/11
Hmm i thought bitcoin-dev and bitcoin were two different channels
kingcarsen
Sr. Member
****
Offline Offline

Activity: 1148
Merit: 369



View Profile WWW
February 14, 2021, 07:29:42 PM
Merited by OgNasty (2)
 #390

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.

Namecoin (NMC) implemented your proposed BitDNS in a better method in 2011.  I am sure you are aware of this Wink

I implemented "BitDNS" into Denarius (D) recently, I was able to complete full integration by hooking into the chain with a separated name database by utilizing the asm OP_DUP OP_2DROP etc.  I know you said 1 TLD .web was a good idea, this will be added in the future, it is trivial. Denarius currently supports .d, .dnr, .denarii, .ipfs, .king, .sys, .btc, and .bitcoin TLDs.  This "NVS" can be extended upon similar to Namecoin for things like text, magnet links, name aliases, and really data of any sort.  The value of the names can handle roughly a limit of 20kB.  Our name values can have dnslink IPFS records set for fully decentralized sites hosted on IPFS with DDNS.

If you want http://satoshi.btc/ or http://satoshi.bitcoin/ just let me know.  I thought .btc and .bitcoin were a bit more fitting for decentralized domains and a good option from the current .bit.
Sathosi0
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
November 29, 2021, 05:50:13 PM
 #391

Hola yo soy sathosi nakamoto nunca me meto y si pase a otras cosas que le vamos a hacer ahora mi correo es lacanoademariete@hotmail.com gracias necesito ayuda
BTC
realdantreccia
Hero Member
*****
Offline Offline

Activity: 665
Merit: 516


Fuck BlackRock


View Profile WWW
May 03, 2022, 03:14:37 AM
Last edit: May 03, 2022, 03:31:28 AM by realdantreccia
 #392

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

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

To quote the Angel McAffee (RIP soldier), I would "eat my own d.. (Italian sausage)"... those mfers are sitting around in mint condition because dumb 8 year old me collected things and believed pumped markets and media at my humble stupid youth.

But I was just reading your IRC logs... There actually begin day before - my analysis on my twitter - see thru my keybase in profile for safe connection. And logs are here:

Day 1 (11/14/10) -- happens in the latter hours: https://web.archive.org/web/20101118020511/http://veritas.maximilianeum.ch/bitcoin/irc/logs/2010/11/14

Day 2 (11/15/10) -- practically whole thread :https://web.archive.org/web/20101118033208/http://veritas.maximilianeum.ch/bitcoin/irc/logs/2010/11/15

- never realized how the Bitcoin Forum systems administrator theymos was so involved til now, but like I said, it helps to see outside in at a network.

Bumping this post is ok because like the email taking 20 years since the Internet had communties already using BBS, or people adopting streaming when I was using VLC to watch NFL on Reddit live for free every sunday in High School, society just takes forever to catch up. Eventually they become so used to the advanced stuff it becomes easier to use to them than the Blackberry Bold they used when this board launched on another domain back in 2009. I bet my father couldn't even figure out how to snap a picture on his 2009 Bold as he's been accustomed to his iPhone 5 (pfffft .. lol boomers and their disregard for support EOL)....

Money is the most misunderstood concept in the world. No one set definition, we didn't first use gold as money. We didn't know how to smelt it even for ages. We didn't print paper money until 300 years after Marco Polo traveled to Venice and became prisoner telling of a whole continent that used paper with elaborate counterfeit characters written on it by mandate of the Khan... while Medici's and Fuggers and my ancestors I won't discuss were using Guldens Florins and double entry book keeping secretly taking in hoards of Spanish Gold secretly when the French thought they ruled Neapolitan Italy.

Point being, it takes a long time. We just expect more hand holding and instant gratification because of the "move fast and break things" era with god knows how many insiders on the other side of our web transactions and publications had eyes on information that would make them rich as they on boarded the world to owning more smart phones than living human beings.

/Relevant Rant. People say bitDNS is Namecoin. It's not. It's an altnon WWW domain registry. Data can be stored securely on blocks. The more you transact the more it knows a human readable name to attach to your accounting records and reputation will spread socially because Namecoin and Bitcoin ARE becoming social networks, you will totally see what the Winklevii meant when they proclaimed that in 2004. If you wanna make a DNS service, what you do it you buy quite a few different dot bit domains (d/). You put a few relay nodes up virtually to load balance traffic world wide and have them all talk to eachother as your supernodes like skype. They all have the same phonebook (in the blockchain). You can charge fees if people want to use your network internally to record things to Namecoin besides dot bit like hashes that can stream music when routed to at a subscription rate for decentralized podcasts/radio. You can even route out to Alohanet and not just get on the Google.dns Public 8.8.8.8 DNS severs, you can draw the public traffic in when they realize your secure service works and scales -- like when David Schmidt and 2 Berkeley students made a bridge from the parallel Usenet to the Arpanet it ran parallel too. Funny how a majority of 1980-1995 Usenet Newsgroups are archived in Google Groups and Schmidt became CEO when that all happened. But that's for you to speculate and me to keep to myself.

Any service you do based on the blockchain tools readily available can be run by the Agent Mike Hearn is credited for on another site but not the internet archive since then its been removed. But its a made for Bitcoin/Namecoin services carrying out payments betwen parties and nodes and even doing auto exchanges internally if say, you prefer some more Bitcoins than Namecoins this week. Just program you Agent, and go.

https://web.archive.org/web/20120612191931/https://en.bitcoin.it/wiki/Agents

Hola yo soy sathosi nakamoto nunca me meto y si pase a otras cosas que le vamos a hacer ahora mi correo es lacanoademariete@hotmail.com gracias necesito ayuda
BTC

No you're trolling. And since I actually found my way from the bitDNS IRC discussions to check up on Jaromil bc I remembered he was the one who changed the directory stucture but no files in the Git that the core devs were running on the day Satoshi emailed Mike Hearn he was out for good on April 23, 2011. Then I remembered Jaromil didn't change any files, just re-organized them to how they look in folders on Github today (back then the host of the web site Git for all to read as they merged and added to the hashes and merkle tree Git uses when your files or changes make it into the mainline. Jaromil <Jaromil@Dyne.org> who made just one commit actually added the COPYING file you  see in Github core dev master branches... He didn't put Satoshi in the copyright, he was the first to write (C) Bitcoin Developers 2009-2011.

The same day Mike Hearn was told Satoshi was gone for good. It's all in this thread.

https://threadreaderapp.com/thread/1521213427112419328.html

Git hashes led me to discover a Korean born US research fellow who received Darpa grants at UWashington CS and worked under some pretty legendary teachers in CS was interning at Microsoft and Google and then got jobs there before moving on to the parent company of who else? LINE in Korea. The Line Blockchain and NFT Market was announced last year. As a Graduate PhD thesis paper he wrote mentioned Bitcoin 10 times and DNS 8, it even referenced Nakamoto and it was focusing on social networks and computing power of something called MetaSync he wrote up about cross-corporation use of their cloud based tools to power a distributed network and said the bitcoin blockchain would be a great model for decentralizing the ledger amongst those parties and the public wasn't a shocker to me.

It's all on my tweets today. Some exist outside the thread.

If anyone who speaks Spanish or Castillian or whatever is Satoshi that's our "develCuy" you can find over in the $DVC altcoin discussion forum or on github where he burst on the scene with Lua and Cryptographic libraries for it in 2014.

From the many one, from one, the source
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!