Topic: DIANNA: the IANA Decentralized design concept - page 6. (Read 16104 times)

Look, you are hotel owner.

I come to you a want to rent a room for night. How much? $100. Okay.

I giving you $100, you tearing this bond and giving me a key from room.

Good business, huh?

NameCoin and any other fork always vulnerable to 51% attack.

Also, if you set correct dynamic fee, it will destroy namecoin, as it destroying it.

I see the acceptable domain price around icann values ~$10/year.

Are namecoin going to destroy all these money?

Thanks again for your help !

<>
We can't improve NMC cuz of Namecoin is, so to say, private property of
Vinced to some degree.
He is good guy with its own ideas.
We are not capable to change his decisions and so be it.

Also we don't want to hardfork Namecoin.

did you ever give a real explanation for that claim? I still don't see why it should not be possible to add dynamic fees to namecoin.

Not true. Namecoin is opensource. We can't fork it because dianna's design went far away from namecoin design. We cant improve it, because we will destroy it by this improvement.

Actually we need to find a correct formula of domain transaction fee to be not more or less than needed

From related russian thread :
 We are begging for your help  
 
 For our DIANNA experiments we need to figure out this :

                  How to measure ( mathematically that is) :
                           
            What is the relation between the change of mining difficulty
             and mathematical estimation of finding right block hash

Is this function exponential or not ?
And exact formula of course also needed if possible  

Thank you  
Sorry for my vague English.
                                        

looking for this?: https://en.bitcoin.it/wiki/Difficulty#How_soon_might_I_expect_to_generate_a_block.3F

still think you should rather improve Namecoin

OK, I'll check it out.

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.

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?

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!

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.

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:


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

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.

Yes
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).


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).

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.

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?

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.

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

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

What prevents miner to do this without registar?

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

What is the motivation of DHT nodes to maintain network?