I think i got it Gavin.
Registar = bitcoin mining pool for simple case.
YesRegistar = bitcoin mining pool for simple case.
Quote
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).
Quote
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?
- 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).