I thought this conversation with cjd will help to clear most things.
The cjd's concept also has several light ideas i'm thinking on.
[15:16] <cjd> pentarh: Thanks for stopping by, I have a few questions about how dianna handles the authority stuff.
[15:17] <cjd> I was trying to read the paper but it had lots of stuff which I know and it was hard to pick out the parts which I don't get.
[15:17] <pentarh> wel, let me excuse for any bad english at first
[15:17] <cjd> nps
[15:17] <pentarh> the paper is atually outdated
[15:18] * cjd knows that feeling
[15:18] <pentarh> we have brainstormed this idea and went too far from initial one
[15:18] <cjd> I gather you resolve long forks just by making it expensive to fork the chain, same idea as bitcoin.
[15:19] <pentarh> The first point. Bitcoin provides pretty good way to main authoritative transactions
[15:19] <cjd> mhm
[15:19] <pentarh> so at first i thought to fork bitcoin
[15:19] <cjd> ...which is a pain..
[15:20] <pentarh> and make there a new transactions where domains (strings) will be instead of coins (integers)
[15:20] <cjd> which spams the bitcoin chain but does work
[15:20] <cjd> also it precludes easy & provable lookups
[15:21] <pentarh> No, I thought to create alternate chain
https://en.bitcoin.it/wiki/Alternative_Chains[15:21] <cjd> yeap
[15:21] <pentarh> But the main pain of all forks is the 51% attack
[15:21] <cjd> yeap
[15:21] <cjd> the long fork attack
[15:22] <cjd> my first idea was a chain of trees and the root hash of each hash tree would be included in a bitcoin transaction
[15:22] <pentarh> The initial design was the idea to create alternate currency, like namecoin, to motivate people maintain network
[15:23] <cjd> yeah and that is full of problems as I'm sure you know
[15:23] <pentarh> but Gavin suggested ne to move financial chain to bitcoin
[15:23] <pentarh> and leave domain data in alternate chain
[15:24] <pentarh> alternate block will be merge-mined against bitcoin parent blocks and against bitcoin difficulty
[15:24] <cjd> ic
[15:24] <pentarh> this makes dianna resitant to 51% attack
[15:24] <pentarh> as long as bitcoin is
[15:25] <cjd> and people will merge mine because they want to get the btc from "registering" domains
[15:25] <cjd> how do you do untrusted lookups?
[15:26] <cjd> one big problem w/ namecoin is you either have the whole chain or you "just trust me"
[15:26] <pentarh> every dianna client will have a dianna block headers chain in local storage. It is short in size enough to put on every client
[15:26] <cjd> k
[15:27] <pentarh> the actual block data i plan to store in DHT
[15:27] <cjd> yeah or anywhere
[15:27] <pentarh> HASH=BLOCK DATA
[15:27] <pentarh> so
[15:28] <cjd> so every diana block will have a hash tree with every domain in existance
[15:28] <pentarh> the headers contain a block merkle root. the client can ask external storage to return him merkle branch of needed domain transaction
[15:28] <cjd> yeah
[15:28] <pentarh> in this way he can easily verify where external storage returned valid data
[15:28] <cjd> yeap
[15:29] <cjd> I wrote about how to implement this, and how to avoid needing the entire database in order to validate a change to it
[15:29] <cjd>
http://ezcrypt.it/LL4n#HzmTvH1pi0G8JtcOTz3xFplq[15:30] <pentarh> thanks, need some time to read
[15:30] <cjd> so we have authority and resolving but the stumbling blocks are in getting people to merge mine
[15:30] <cjd> and in the fact that nobody wants to pay to be an experimenter
[15:31] <pentarh> the price is adjusted to network popularity, so in first stages it will be very low
[15:31] <pentarh> in dianna
[15:31] <cjd> hmm
[15:31] <cjd> that is dangerous stuff
[15:32] <cjd> the smarter you make the governer, the more catistrophically it will fail if it does
[15:32] <pentarh> actually not the price itself
[15:33] <cjd> now the problem I have is we have somewhere between 50 and 100 active nodes experimenting with cjdns
[15:33] <pentarh> price is defined on hardcore tricks to hardcore connect paid money with doing hash work
[15:33] <cjd> and they have crypto derived ipv6 addresses
[15:33] <cjd> (so their addresses suck)
[15:33] <cjd> but nobody is going to adopt something where they have to pay (anything)
[15:34] <s1w> thats a problem ?
[15:34] <cjd> it's a problem for any proposal which requires paying
[15:34] <s1w> heh
[15:35] <cjd> I have maybe 2/3 of a solution in mind but mine is incomplete and there are some lingering problems.
[15:35] <s1w> as are most things
[15:35] <cjd> I'll let you read my document if you like then we can continue.
[16:02] <pentarh> cjd, what is the root if your single merkle tree? tx hash or block hash?
[16:05] <cjd> in that document, the merkle tree would be made of transaction output hashes and the root would have to be placed in the merged mining tree
[16:05] <cjd> kk: nope.. heros wanted
[16:06] <cjd> pentarh: for dns, my thinking was that someone would pay btc to the root of the merkle tree as if it were a key hash.
[16:07] <pentarh> please explain. I want to create some domain in this system. What the process will be?
[16:07] <pentarh> I pay btc to miner and he creates a merkle root with a branch of my domain
[16:08] <cjd> the thinking was if you wanted to add domains, you would recompute the hash tree with the new domains and pay to that root hash as if it were a bitcoin address.
[16:08] <cjd> no need to involve the miners at all, and using only standard transactions
[16:10] <cjd> pentarh: each hash tree would include the hash of the last hashtree so they would function as a chain.
[16:10] <cjd> pentarh: the obvious problem with what I just described is that someone can create a fork by just paying a little more and creating different domains.
[16:11] <cjd> and since there's no way to know that it has forked, they can reveal the fork a year after it is created thus throwing a huge number of domains into dispute
[16:13] <cjd> so idea #2 was to resolve forks by merging the domains from each branch together. This is much nicer since it behaves like namecoin but one can add an arbitrary number of domains with only a single transaction spamming the chain.
[16:14] <pentarh> Well, this is interesting. Can I tell what I propose?
[16:14] <cjd> sure
[16:14] <cjd> the problem with #2 is that there is no effective way to prove that a domain is valid since anyone can add one later on.
[16:18] <pentarh> I propose to create alternate chain as i described above. The transactions will have input as reference to prev key=value and output key with new value. If there is no input, this assumes a new domain creation. The normal Satoshi pend checks are applied, except that system will forget about prev output if it was TTL blocks ago.
[16:18] <cjd> ic
[16:18] <pentarh> The reason of putting a new transaction in alternate chain is bitcoin transaction to miner
[16:19] <pentarh> and nothing else
[16:19] <cjd> your end has to get miners on board
[16:19] <cjd> which is not insurmountable but it's an issue
[16:19] <pentarh> yes, providing them some extra profit for corresponding extra work
[16:20] <cjd> yes, the other matter is that early on, the cost needs to be basicly 0 in order to get people to use it
[16:21] <pentarh> miner gather domain transactions to a dianna block. every domain trans has a ref to bitcoin trans. So dianna will know how much money was piad for all transactions in block.
[16:21] <pentarh> So it adds a proportional difficulty
[16:22] <pentarh> I call it PDiff. PDiff=sum(domain_tr_fees)/(Bitcoin_block_reward + bitcoin_block_fees)
[16:23] <cjd> ok and you'll make everyone have the whole history of headers so any domain lookup can be proven...
[16:23] <pentarh> Miner will merge-mine dianna block with bitcoin difficulty + PDiff addition
[16:23] <cjd> it sounds workable
[16:24] <pentarh> the main rule is the any paid money must be worked
[16:24] <cjd> "must be worked"??
[16:25] <pentarh> must have a ground in work
[16:26] <cjd> how do you prevent a miner from creating thousands and thousands of domains by "paying himself" ?
[16:26] <pentarh> So if miner going to get a profit of 10 BTC in dianna block, and this bitcoin bounty is 50 BTC, he must mine with 10/50 = 25% difficulty addition
[16:26] <cjd> oic
[16:27] <pentarh> paying himself is the next problem, which resolution I try to tell you
[16:34] <cjd> that all makes a lot of sense and I hope you can get it to work
[16:34] <pentarh> So. The DIANNA will announce: In this "week" (week is in blocks) the PDiff is 10%. This means hardcore set of single block domain money turover as a percetile of bitoin block turnover. Miner will have to collect domain orders exactly to this amount. Any difference will cause exponental difficulty grow
[16:35] <cjd> ahh ic
[16:35] <cjd> this deserves an RFC
[16:36] <pentarh> If miners are hard to collect such more orders, the dianna blocks appear frequency will go down. In this case dianna will announce on next week lower PDiff
[16:36] <cjd> because programmers need a dense set of rules and none of the layman's terms and discussion
[16:37] <cjd> will clients need to hold the chain of diana headers or the chain of bitcoin headers?
[16:38] <cjd> hmm I guess you couldn't have them hold the bitcoin headers
[16:38] <pentarh> And visa versa. If miners are easily collect order on that PDiff, the dianna block frequency will rushed to bitcoin block frequency. So dianna will set higher pdiff in next week
[16:38] <cjd> it would be nice since that header chain could be used for other notery type stuff
[16:39] <pentarh> yes, this will cause to hold both headers chain
[16:39] <cjd> I like it. The governer stuff sounds really complex and you have to be prefect on it
[16:40] <pentarh> and this is what version we stopped in
[16:41] <cjd> would be so much easier if the cost was fixed
[16:41] <cjd> not better, just easier to implement
[16:42] <pentarh> The price must not be fixed
[16:42] <cjd> /nod
[16:42] <pentarh> if I set it to 1 btc, and tomorow usd/btc will be 1000, this will be a problem
[16:42] <cjd> indeed
[16:43] <cjd> set to X times the average transaction fee in the last 10 blocks ?
[16:43] <cjd> anything that can be done to avoid the hard work
[16:44] <pentarh> someone can spam system with low transactions to turn it into free data storage
[16:44] <cjd> hmm /mod
[16:45] <pentarh> the only way to know the price is to know how much work is doing for certain money turnover. And this value is bitcoin difficulty per block reward
[16:45] <cjd> oic
[16:46] <pentarh> So I connect the price only to work. And market will decide how much it really costs
[16:46] <cjd> that makes a lot of sense
[16:46] <cjd> equivilent btc to k hashes
[16:47] <cjd> *K
[16:48] <cjd> the biggest problem that I see is the miners
[16:48] <pentarh> yes, but this all in percetiles. so system can adopt to rising power like bitcoin does
[16:48] <pentarh> what with miners?
[16:49] <pentarh> I see they will have a reason to consolidate
[16:49] <cjd> why should minerX mine these where they don't make anything off them unless they put in more work
[16:49] <cjd> when he can mine namecoin and sell it
[16:50] <pentarh> Payment for domain transaction goes directly to miner address
[16:50] <pentarh> He could send this payment by itself, but still have a difficulty overhead
[16:51] <cjd> doesn't the additional difficuly make it impossible for him to make a profit by merging?
[16:52] <pentarh> i didn't understand
[16:52] <cjd> hmm I probably didn't understand it right...
[16:53] <cjd> I thought the prevention against miners paying themselves was to make it so they needed to mine higher difficulty blocks in order to do merged mining.
[16:53] <pentarh> client will send to miner a special transaction with domain name signed by domain key, followed by OP_DROP and then normal bitcoin script
[16:53] <cjd> hmm clever
[16:53] <pentarh> so transaction is marked as " for foobar domain"
[16:54] <pentarh> The miner can pay to himself like that
[16:54] <pentarh> and order a own domain
[16:54] <pentarh> then he will have to do just extra work
[16:55] <pentarh> So the difficulty overhead and associated electricity spends will be a prime cost of domain
[16:55] <cjd> I don't quite understand how the extra work works.. It's extra work on the dianna chain and not the bitcoin chain?
[16:56] <pentarh> dianna blocks are merge-mined with bitcoin blocks. They are mined agains parent block difficulty, dianna does not have own difficulty
[16:57] <pentarh> but it has own difficulty correction
[16:58] <cjd> hrm so in order for a miner to include transactions, he will have to mine bitcoin blocks at higher difficulty than the bitcoin swarm mandates?
[16:58] <pentarh> Miners will mine dianna blocks with BitcoinDifficulty * (1 + Pdiff) in simple case
[16:59] <pentarh> yes, the dianna blocks difficulty will be always a bit higher
[16:59] <pentarh> and dianna will set this "bit" according to its activity
[16:59] <cjd> if a miner is mining at higher difficulty, doesn't this mean a miner who is merged will need to discard otherwise valid bitcoin blocks?
[17:01] <pentarh> Yes, this will control miners greedy
[17:01] <pentarh> because they have a chance to discard valid bitcoin block
[17:02] <pentarh> if pdiff is too high
[17:02] <cjd> well wouldn't they still be able to submit it as a non-merged-bitcoin block?
[17:02] <pentarh> noway. parent bitcoin block hash must be included in dianna block
[17:03] <pentarh> this makes totally shared network power
[17:03] <cjd> nah, I mean if they discover a bitcoin block which is not high enough difficulty for a diana block, they will just submit it as a normal bitcoin block
[17:04] <cjd> *pretend that they don't mine dianna
[17:04] <pentarh> no and yes
[17:04] <pentarh> BitcoinDifficulty * (1 + Pdiff) is the dianna block difficulty
[17:04] <cjd> /nod
[17:04] <pentarh> BitcoinDifficulty remains as is
[17:05] <cjd> I think the biggest problem here is that it requires miners to participate
[17:06] <pentarh> So if miner found a bitcoin block with correct difficulty and still didnt found dianna block. he will have a choice - to submit bitcoin block and continue dianna with new one, or waste some more time to find dianna hash
[17:07] <cjd> time is money for bitcoin miners
[17:07] <cjd> they go to great lengths to catapult their blocks out as fast as possible
[17:07] <pentarh> well, yes, he will continue dianna block with next bitcoin one
[17:08] <cjd> and unfortunately the experimenters and nerds seem to be being overrun by oppertunists and scummy people in the bitcoin community.
[17:08] <pentarh> this will lower dianna frequency and dianna will set lower pdiff
[17:08] <ircerr> can Pdiff be a fraction?
[17:08] <cjd> yeah
[17:08] <cjd> which means that unless the miner gets $$ in pocket, they are unlikely to mine
[17:09] <cjd> esp. if they make money mining namecoin
[17:09] <cjd> who would want to upset that racket
[17:09] <pentarh> namecoin is a dead body
[17:09] <pentarh> from birth
[17:09] <cjd> yeap
[17:10] <cjd> but miners will still mine them because they can sell them
[17:10] <cjd> and way too many people in the bitcoin community would sell their grandmother for a block
[17:11] <pentarh> I asked enough questions in public to make investors doubt where they invest their money
[17:11] <pentarh> buying namecoins
[17:11] <cjd> /nod
[17:11] <cjd> people buy SC2
[17:11] <cjd> people are dumb
[17:23] <pentarh> dumb people will by forks currency while they not realized that only one have a right to live - bitcoin
[17:23] <pentarh> bitcoin probably
[17:24] <pentarh> but only one. All others will have a possibility of 51% attack
