DIANNA: the IANA Decentralized design concept

[pent]

Why this is like that? Why bitcoin devs missed this crap? Mining pools are corruption possibility in system.

[1713929981]

1713929981

[1713929981]

1713929981

[Gavin Andresen]

Many people ask, how much domain will cost? Lets give a formula for people.

I really like your idea of scaling up difficulty based on the number of domain operations in a block to prevent the key:value database from growing arbitrarily big.

It seems to me that should be enough to make domain operation pricing correct; I don't see why there needs to be a block reward or fees, I assume the registrars will charge whatever they need to charge to make a profit, and I would strongly encourage you to avoid making the DNS system yet-another-currency.  I'd like to use dollars or euros or bitcoins (preferably bitcoins) to pay for my domain names, please.

I imagine a system something like:

+ I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna'

+ The registrar makes sure the register/renew/transfer operation is valid

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.

[Bitcoin Oz]

Build it with distributed P2Pool mining built in?

Bingo.

[Bitcoin Oz]

Many people ask, how much domain will cost? Lets give a formula for people.

I really like your idea of scaling up difficulty based on the number of domain operations in a block to prevent the key:value database from growing arbitrarily big.

It seems to me that should be enough to make domain operation pricing correct; I don't see why there needs to be a block reward or fees, I assume the registrars will charge whatever they need to charge to make a profit, and I would strongly encourage you to avoid making the DNS system yet-another-currency.  I'd like to use dollars or euros or bitcoins (preferably bitcoins) to pay for my domain names, please.

I imagine a system something like:

+ I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna'

+ The registrar makes sure the register/renew/transfer operation is valid

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.

Could you use a few different coins to add extra infallibility? Say Litecoin and bitcoin/namecoin. So you need all 3 working in unison or something.

Merged Timestamping :O

[HostFat]

Can this project merged somehow to the Yacy decentralized web search ?

[pent]

I imagine a system something like:

+ I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna'

+ The registrar makes sure the register/renew/transfer operation is valid

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.

Template break.

Looks very interesting.

The funds sent to registar needs to be marked "for domain gavinandresen.dianna", to make miners and storages sure they processed real transaction request. So the extra information needs to added to scriptsig. So dianna will have an influence on bitcoin chain size. Or am I missed something?

[pent]

+ I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna'

+ The registrar makes sure the register/renew/transfer operation is valid

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.

This is totally something new. My interpretation:

We will separate all participants by group:
1. Clients - they want domains
2. Mining pools - they do timestamping
3. Storage pools - they save the timestamped blocks
4. Need possible coordinators - registars. They take money from clients, pay part to miners for timestamping and pay part to storages for saving. And some part leave for themselfs.

The money will be any external financial structure: bitcoin or fiat - this is up to registars what to accept and how to pay to storage and miners pools. And not be an internal of system.

The DIANNA's block chain (to be stored at storage pools) is similar to bitcoin, but:
- Need to store only last TTL full blocks, all others are kept on each storage as headers. Since block with domains expires - system not need to know the full block, so block goes to history as its header.
- Instead of coin transactions there will be a domain transactions

The possible problem here is how to make consistent  block chain of last TTL block distributed by storage pools.

[rPman]

I do not understand why in the basis of a decentralized system, you are going to add a centralized registrar?
We also need to minimize number parasitic financial intermediaries between the DNS and the client.

We do not need a center, deciding whether we can register the domain or not. We need a reliable and simple tool for decentralized storage of information on domains and how they fair / free registration, with minimal protection against cybersquatters.

In the Russian branch of the discussion I invited to discuss the proposals on the mechanism of domain registration and renewal through a decentralized auction. Maybe this idea will continue here.

Of course, namecoin implemented very crudely, ideally it should be a small add-on to bitcoin (as a means to create a reliable database and decentralized means of payment).

Payment for registration and renewal should be charged for maintenance and storage system bitcoin DNS database.
The current system of domain registration, and so looks like an auction between the client and the registrar / cybersquatters and rule 'the first man gets the oyster, the second man gets the shell'. Auto Auction for domain name registration will allow to realize the same thing but without the unnecessary middlemen.

But there are problems arising from the fact that mining pools control the network.
* open registration will allow pools-cybersquatters immediately register the same domain with zero cost (can put any commission, yet also get itself if they do not give out the transaction in the network prior to placement in to the blockchain)
* closed registration will be is technically difficult to implement because you must consider mechanisms for the simultaneous recording of the same domain by different users ... still all rested in the fact that the mining pools have the ability to control the priority between clients.

In any case, all the problems arising from the existence of large pools of mining, and the decision can be ideas development p2pool.

p.s. sorry for my English.

[Gavin Andresen]

I do not understand why in the basis of a decentralized system, you are going to add a centralized registrar?

I should have made it clear:  I imagine there will be an arbitrary number of registrars. They will compete to provide the best service (fastest updates of the DNS database, lowest prices, etc).

If you were willing to do the proof-of-work and insert your own updates into the bitcoin block chain then you could be your own registrar (I assume most people won't be willing to setup the necessary software, run it, etc. just to register a couple of domain names).

[pent]

Gavin: Are you talking about putting extra data to bitcoin blockchain? Have a couple of questions, I am trying to figure out your picture.

+ The registrar makes sure the register/renew/transfer operation is valid

Is this correct? DIANNA has its own chain on DHT, domain double spend performed against this chain.

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

What prevents miner to do this without registar?

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

Block hash of what block? Where client paid for domain, or where miner did merged mining?

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.

What is the motivation of DHT nodes to maintain network?

[rPman]

I should have made it clear:  I imagine there will be an arbitrary number of registrars. They will compete to provide the best service (fastest updates of the DNS database, lowest prices, etc).

If you were willing to do the proof-of-work and insert your own updates into the bitcoin block chain then you could be your own registrar (I assume most people won't be willing to setup the necessary software, run it, etc. just to register a couple of domain names).

What about we are talking here? about 'decentralizing' or 'replacing owners of current DNS system'?

Anybody could be own registrar? Of course, that's is decentralizing, But do it free and zero cost without any restrictions? Under what conditions would create such a domain registrar, after all these rules and the need to develop!

We need conditions, that will protect DNS against cybersquatters, from unhindered registration of any number of domains based on keywords, that will protect the system from the uncontrolled transfer of domain control to third parties.

The best defense is when the only thing that can and should make 'own registrar' is to provide resources for the software, and all the logic and limitations are fully automated.

[pent]

I think i got it Gavin.

Registar = bitcoin mining pool for simple case.

Client sends X BTC to mining pool in a special marked transaction. He signs domain name with domain private key and put it to Script with following OP_DROP for exmple.

Then he goes to bitcoin pool, give it:
- initial transaction_id
- domain name
- domain public key
and asks to register a domain.

Pool gather such domains in a DIANNA block (performing validation and d/spend checks) and tries to find its hash with merged mining of parent bitcoin block. But with bitcoin block difficulty and difficulty correction in my formula.

After success, pool pushes DIANNA block in diana network.

Dianna network has all required data to check this block:
- It has referenced bitcoin transactions
- It has domain names and pubkeys to make sure those a signed by domain owner
- It has a hash of parent Bitcoin block, so it can see its difficulty and number of bounties
- So it can calculate a valid difficulty target to match dianna's block hash

So the grounds of putting domain in DIANNA's chain is the initial bitcoin payment. DIANNA will refuse domain transs without corresponding payemnts.

Abuse activity of mining pools here is not profitable. If pool will send initial transaction from his address to another his address, this anyway will increase the dianna's block difficulty.

In this scheme DIANNA isn't vulnerable to 51% attack, as its basic difficulty and hashing power will be taken from bitcoin.

Am I right?

[pent]

The Gavin's design above is just what I proposed in design, but money flow moved away to bitcoin.

This will enforce mining pool competition and cause more mining pools to appear.

Bitcoin and DIANNA will work for each other, enforcing both popularity and health.

DIANNA will not be a fork of Bitcoin, but an extension.

DIANNA's blocks frequency may be arbitrary and blocks will contain only needed information about domains.

This is freaking awesome idea.

[Gavin Andresen]

I think i got it Gavin.

Registar = bitcoin mining pool for simple case.

Yes

Client sends X BTC to mining pool in a special marked transaction. He signs domain name with domain private key and put it to Script with following OP_DROP for exmple.

Yes, you could do it that way, re-using Bitcoin's Script system for signatures.  I suppose it might be useful to require m-of-n signatures for a domain to be transferred to somebody else.  I wouldn't make them full-fledged Transactions, though (multiple "inputs" to a domain renewal or transfer doesn't really make sense, for example).

Then he goes to bitcoin pool, give it:
- initial transaction_id
- domain name
- domain public key
and asks to register a domain.

Pool gather such domains in a DIANNA block (performing validation and d/spend checks) and tries to find its hash with merged mining of parent bitcoin block. But with bitcoin block difficulty and difficulty correction in my formula.

After success, pool pushes DIANNA block in diana network.

Dianna network has all required data to check this block:
- It has referenced bitcoin transactions
- It has domain names and pubkeys to make sure those a signed by domain owner
- It has a hash of parent Bitcoin block, so it can see its difficulty and number of bounties
- So it can calculate a valid difficulty target to match dianna's block hash

So the grounds of putting domain in DIANNA's chain is the initial bitcoin payment. DIANNA will refuse domain transs without corresponding payemnts.

Abuse activity of mining pools here is not profitable. If pool will send initial transaction from his address to another his address, this anyway will increase the dianna's block difficulty.

In this scheme DIANNA isn't vulnerable to 51% attack, as its basic difficulty and hashing power will be taken from bitcoin.

Am I right?

Yes, I think that's right, although I was imagining that the DIANNA and bitcoin difficulties would be kept separate and not combined. Combining them is probably a better idea (if you find any blocks that satisfy the bitcoin difficulty but not the DIANNA+bitcoin difficulty you can still announce them on the bitcoin network and get the block reward).

RE: what is the incentive for maintaining the DHT:  the registrars/mining pools would, I think, be the primary maintainers of the DHT and their incentive to maintaining it is the registration fees that they charge.

I haven't thought deeply about possible attacks; if a DHT is used then you have to defend against Sybil attacks (you must have some way of checking to make sure the data you get from the DHT is valid, e.g. have the DHT nodes return a Merkle branch down to the data they're returning that you can verify hashes to the correct Merkle root).

[pent]

I haven't thought deeply about possible attacks; if a DHT is used then you have to defend against Sybil attacks (you must have some way of checking to make sure the data you get from the DHT is valid, e.g. have the DHT nodes return a Merkle branch down to the data they're returning that you can verify hashes to the correct Merkle root).

This must be a special DHT implementation. All DIANNA's clients are DHT participants. All of them have a full DIANNA block headers chain in local storage. So they probably will decide to save a block only if its hash matches local headers chain with some threshold for new blocks.

The "thin" clients (network listeneres) will contain headers chain also, so they can verify whether DHT returned valid data.

[rjk]

Would it be possible for all the modifications to the DIANNA chain be confirmed by the Bitcoin chain and associated mining power, without adding too much to the coinbase? The way I imagine it working is as follows:

All the DIANNA transactions are collected in a block and a hash taken of them, and then the hash is submitted as a standard transaction to the bitcoin blockchain for actual confirmation. If this won't work as a standard transaction, perhaps some of the unused Bitcoin scripts could be used instead. Graphically as follows:

Code:

                  ___                                                           ___
DIANNA Transaction   \                                       Bitcoin Transaction   \
DIANNA Transaction   | f                                     Bitcoin Transaction   |
DIANNA Transaction   | u                                     Bitcoin Transaction   |
DIANNA Transaction   | n                                     Bitcoin Transaction   |
DIANNA Transaction   | n >== Hash (SHA256? sure why not) ==> Bitcoin Transaction   | >=== Confirmations by miners ===> BLOCK
DIANNA Transaction   | e                                     Bitcoin Transaction   |
DIANNA Transaction___/ l                                     Bitcoin Transaction   |
                                                             Bitcoin Transaction___/

Unless I completely misunderstand how Bitcoin works, I imagine this is how you could combine the two.

[pent]

Unless I completely misunderstand how Bitcoin works, I imagine this is how you could combine the two.

DIANNA's blocks will be merged mined with bitcoin blocks. The AUX block will be DIANNA block, the PARENT block will be Bitcoin block. The DIANNA block will have reference to PARENT bitcoin block and checked against it. This will be enough i think. Also all transactions in DIANNA block will be refernced to bitcoin transactions.

[ptshamrock]

You guys make my day everyday ! really ! please just tell me where to point my soon to be 50ghash to secure the networks

yay i know this is absolutely useless words lol  but i couln`t resist ! i do understand about 20% waht u talk but i love it and try to geth to the higher percentages !

THUMBS UP!

[rjk]

Unless I completely misunderstand how Bitcoin works, I imagine this is how you could combine the two.

DIANNA's blocks will be merged mined with bitcoin blocks. The AUX block will be DIANNA block, the PARENT block will be Bitcoin block. The DIANNA block will have reference to PARENT bitcoin block and checked against it. This will be enough i think. Also all transactions in DIANNA block will be refernced to bitcoin transactions.

The way I was imagining it, there would be no separate mining for the DIANNA chain, and it wouldn't have any of its own coins or currency either. It would be "merged-mined" in the sense that Bitcoin blocks do all the work of confirming DIANNA transactions, but without the stupid hassle of more coins floating around (like namecoin). Is there some reason that this couldn't work?

Right now if you wanted to, you could solo-mine only namecoins, without mining bitcoins at the same time. I would hope to eliminate any mining as such on the DIANNA chain at all, and force all transactions to be confirmed by the Bitcoin network. DIANNA would maintain its own chain so as to keep the data out of Bitcoin's blocks.

Am I way off base here?

[pent]

The way I was imagining it, there would be no separate mining for the DIANNA chain, and it wouldn't have any of its own coins or currency either. It would be "merged-mined" in the sense that Bitcoin blocks do all the work of confirming DIANNA transactions, but without the stupid hassle of more coins floating around (like namecoin). Is there some reason that this couldn't work?

Right now if you wanted to, you could solo-mine only namecoins, without mining bitcoins at the same time. I would hope to eliminate any mining as such on the DIANNA chain at all, and force all transactions to be confirmed by the Bitcoin network. DIANNA would maintain its own chain so as to keep the data out of Bitcoin's blocks.

Am I way off base here?

Yes. No additional currency. All domain money will flow through Bitcoin increasing its popularity. No separate mining (even not possible). Bitcoin miners will just attach merged mining of DIANNA blocks and offer domain operations for clients increasing profit. All domain data will be kept in separate DIANNA chain which will be stored in DHT and can hold 100's ICANN databases.