pent (OP)
|
|
February 27, 2012, 10:39:37 PM |
|
Please join the discussions in wiki, I opened registrations.
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
pent (OP)
|
|
February 29, 2012, 09:29:35 PM |
|
Alright, the final strokes. Decentralized P2P DNS System Design version 1.4. Changelog1. Non-linear block chain, block treeEach 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.
|
|
|
|
pent (OP)
|
|
March 01, 2012, 03:02:16 AM |
|
"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/
|
|
|
|
pent (OP)
|
|
March 01, 2012, 12:21:42 PM |
|
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.
|
|
|
|
pent (OP)
|
|
March 02, 2012, 12:05:51 AM |
|
New changes! Ideas just run and run - and not going to stop v1.5 http://dianna-project.org/wiki/Design_ChangelogSummary: 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.
|
|
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 101
Bitcoin!
|
|
March 02, 2012, 04:37:40 AM |
|
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.
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
pent (OP)
|
|
March 08, 2012, 11:46:20 PM |
|
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 TreeNamespacesBlockTransactionFees: 1 2Retargeting RepricingNo independent DifficultyAnd Merged Mining Implementation
|
|
|
|
Red Emerald
|
|
March 08, 2012, 11:58:13 PM |
|
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.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 05:33:50 AM |
|
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_1It illustrates how DIANNA looks for correct fee value and transaction commit time depending on namespace activity.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 08:54:15 AM Last edit: March 10, 2012, 09:07:30 AM by pent |
|
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. bounty=50.0
for z1 in range(1, last): if z1 == 30000: bounty=25 #bla-bla pdiff = domfee/(bounty + bitcom)
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.
|
|
|
|
Red Emerald
|
|
March 11, 2012, 02:48:12 AM |
|
Any answer to this? 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.
|
|
|
|
pent (OP)
|
|
March 11, 2012, 04:52:16 AM |
|
Any answer to this? 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.
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.
|
|
|
|
Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
March 11, 2012, 04:56:04 AM |
|
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.
|
|
|
|
|
pent (OP)
|
|
March 15, 2012, 10:23:46 PM |
|
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.
|
|
|
|
matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
|
March 23, 2012, 07:14:27 PM |
|
Have you thought of creating the block chain so it only exists inside the I2P network for better anonymity or is this not possible
|
|
|
|
pent (OP)
|
|
March 23, 2012, 07:19:27 PM |
|
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
|
|
|
|
matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
|
March 23, 2012, 07:34:12 PM |
|
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
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.
|
|
|
|
bitlotto
|
|
March 23, 2012, 07:49:28 PM |
|
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
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. I'm sure that there will always be TOR exit nodes somewhere in the world that aren't blocked from accessing the DIANNA blockchain.
|
*Next Draw Feb 1* BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR TOR2WEB Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.
|
|
|
|