Topic: DIANNA: the IANA Decentralized design concept - page 2. (Read 16097 times)

I'm sure that there will always be TOR exit nodes somewhere in the world that aren't blocked from accessing the DIANNA blockchain. 

Then it would be totally anonymous if the blockchain only existed inside the I2P network.  The problem with Tor is you have to rely on a certain number of output nodes which could all/most be monitored and also blocked.

If I do this, I automatically make this DNS closed to other anonymous networks, as they will require i2p router to run. The DNS client must be light.

However it is possible to add i2p BOB transport protocol as additional layer along with TCP/IP

Have you thought of creating the block chain so it only exists inside the I2P network for better anonymity or is this not possible 

Yes, they will not settle down until ICANN not submit its authority to feds.

I have opened a forum for futher conversations so far .

http://dianna-project.org/forum/

For a near weeks unfortunately I dont have enough time for this project. I definately need contributors.

The whole idea got its own form now in wiki. It is time to start coding.

^^ like

http://www.ip-watch.org/2011/10/25/us-to-seek-bids-to-manage-key-aspect-of-the-internet/  just came across this which is interesting.

It takes up to 24 hours for current DNS changes to go through and propagate. I don't think a delay with DIANNA will be an issue.

Every namespace will have its own block appear time and yes, it will be higher than Bitcoin, as namespace will have always a bit higher difficulty than bitcoin.

For example, users of potentional CJDNS namespace will be not so active as users of I2P, or users of Tor namespace. All them have their optimal activity and network adjusts block frequency and price to this activity.

DIANNA is a domain system, not financial. I don't see problem of transaction approve time from 20 minutes to a hour.

Modern ICANN domain registars process domain request from minutes to days.

Any answer to this?

Also, immitation of Bitcoin block reward change from 50 to 25 BTC.

How this will affect on DIANNA price?

In a region of step 30000 change bounty to 25.


What happens with price?



Note, the price graph is based on example simulations. For real activity price can be different, but it is explicitely linked to network activity, so it has a feedback, so it will change to community expectations.

And we have the first simulation of single namespace running with graphs!

It includes dynamics graphs of:
* Domain price
* Block solving time
* Miners profit
* Number of handled transactions

Please follow: http://dianna-project.org/wiki/Calc_1

It illustrates how DIANNA looks for correct fee value and transaction commit time depending on namespace activity.

At first I wasn't sure why you didn't just work on Namecoin, but now that you have more on your wiki, I am understanding more.

Um. Are you sure having the difficulty being higher than Bitcoins difficulty is a good idea? Not everyone merge mines namecoin with bitcoin. They have different difficulties and there isn't a problem that I'm aware of.  DIANNA Blocks are going to be WAY slower than bitcoin blocks.  Even if half (which is probably a high guess) of the bitcoin network merge mines DIANNA, won't block time be worse than 20 minutes?  Is this what you want? Maybe I'm just missing something.

So. I decided do not complicate system with any contracts procedures. If anyone scaried to loose his money during name update, he can consider using escrow services.

The current 1.6 rawhide preview is almost on track. This design looks perfect. Does anyone see the vulnerabilities in it?

So, here is the DIANNA internals with bunch of tech details:

The Block Chain Tree
Namespaces
Block
Transaction
Fees: 1 2
Retargeting Repricing
No independent Difficulty
And Merged Mining Implementation

Have your read this page: https://en.bitcoin.it/wiki/Contracts ?  I think there's probably something in there that could be adapted for what you want to do.

I need help.

Is there any possible way to send a bitcoin transaction with fee to some address/hash and this transaction can be widthdrawn later only by miner who lately merge-mined DIANNA block with correspondent domain transaction?

I want to depersonalize mining pools in this scheme, so domain transaction can be processed by any miner, not miner who was paid directly by client for processing.

This is related to Miners consolidation possible (last?) issue.

Detailed problem: https://bitcointalksearch.org/topic/difiicult-question-related-to-merged-mining-66959

New changes! Ideas just run and run - and not going to stop v1.5
http://dianna-project.org/wiki/Design_Changelog

Summary: Replace forced PDiff system definition by forced domain transaction fee definition, remove Difficulty penalty. Fee is now set by DIANNA for particular Namespace.

* Remove forced PDiff system definition (Pentarh Udi, rpMan)
* Add forced domain transaction fee definition (Pentarh Udi, rpMan)
* Remove Difficulty penalty (Pentarh Udi, rpMan)
* Use cases clearification

DIANNA now will define a price (hallelujah!!!) for domain operation instead of PDiff. Price will be dedicated to each namespace and depend on its network activity. Thanks to rpMan.

Dear Ukigo, I had a talk with cjd (CJDNS leader) in IRC, IRC log is somewhere above in this topic.

He said he will use DIANNA as DNS as long as its domain price would be free or almost free.

His requirement brought DIANNA design to version 1.4 (current), where namespaces have been isolated and non-linear block chain added.

This will allow small networks, having small activity - to have a correspondent small domain fee. I think in CJDNS case it will be almost free.

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete" Buckminster Fuller

"Never doubt that a small group of committed citizens can change the world." Margaret Mead

Quotes from http://p2pfoundation.net/

Alright, the final strokes.

Decentralized P2P DNS System Design version 1.4. Changelog

1. Non-linear block chain, block tree

Each Namespace will have its own block chain, its own activity, its own PDiff, and thus, its own domain operation price.

Total namespaces isolation. I2P namespace and chain branch will not contain any data from Tor namespace and branch and any other. And visa-versa.

Small namespaces will have small domain operation price. Bigger namespaces will have bigger one.

Attack on single block chain branch will not affect other branches. And attack on whole DIANNA block tree will be just huge, difficult work.

2. Single domain transaction contains only 1 input and only 1 output, and both about single domain. So 1 domain = 1 transaction. And nothing else.

Since miners process only domain transactions which were directly paid with fee for them, there is no need to include many domain operations in single transaction.

This also will make domain lookup easier. So the authoritative domain reply lookup will be as follow:

For first, DNS client queries for particular domain and network returns a last domain transaction hash and block hash. Highest block wins - as always. Here client can verify that block hash is present in local headers chain and has a particular height.

For the second, client queries the network for Merkle Tree branch for needed domain transaction and transaction data itself. Here he can verify that transaction data are correct by reassembling Merkle Tree and comparing its root hash against local stored block header in chain.

Since client ensured that network returned *valid* *last* transaction for this domain, he can easily resolve domain into VALUE containing in transaction output.

Peace a cake

I need volunteers to code this tree of freedom. Primary, I need the project manager which will coordinate programmers. For the first steps I can be ideologist, project manager and programmer in one But I really need a help.

Please join the discussions in wiki, I opened registrations.