Sounds reasonable, I was looking for some extra flexibility, however attack surface area is more important to minimize.

This is the summary of recommendations that modify the bitcoin protocol.  Please discuss:

Proposal One: Templates, Transaction groups, and Burning Transactions

Templates:
Already included in the bitcoin client, described changes make it more powerful and useful to base groups upon

1.   A template must contains three parameters:
   a.   Unique ID
   b.   Human Readable Name
   c.   Codified verification that can rigorously check if a transaction is valid or not for that particular template.
2.   Optionally, a template may include a codified way of modifying the transactions.  (Discussion?) - Not a good Idea
3.   Every transaction must still comply with the existing enforced network rules. Such as no, double spending.
4.   Every non-standard transaction shall claim what sort of transaction it is by including the template ID that it belongs to, and then is verified to comply with the template it claims to belong.
5.   Transaction without a template ID will be assumed to comply only with the 'standard transaction' template.
6.   No transaction shall claim to belong to more than one template.

Transaction Groups:
A group that contains all the transactions that are validated by the same template.

1.   Verified transactions should be placed within a grouped together in each block.
2.   Summary of every transaction accepted into the block should be included as a special group.  The summary must contain information about witch group each transaction belongs.
3.   Every group must be hashed separately.
4.   The hash of every group should be included in the block’s merkle tree.
5.   The p2p network should allow clients to download either the entire block, or just the block and summary group.
6.   Generators must check the entire block for errors before accepting the block.

Burning Transactions:
New sort of transaction that sends the coins contained to null, and contains the rate that the coins are released back into circulation.  This transaction is an extension of the transaction fees.

1.   A Burning Transaction must contain an extra special ‘out’ that specifies:
   a.   The Rate (per block) of release of coins back into circulation.
   b.   Total amount of coins to be released.
c.   A special address that is defined as ‘null’
2.   This transaction can contain normal transaction fees like any other transaction.
3.   The first block after the block that contains this transaction may claim the first part of coins released.
4.   The coins released may be claimed at any point after or on the block that they are released on.
5.   When claiming the coins, the generator must quote the block that contains burning transaction in its block. - Not needed

I am in the process of writing quite significant change about how BitDNS and extensions of Bitcoin.

Talk about my recommendations in this thread.  I will be adding more posts as I complete more of the design (that is in my head atm).

http://domainchain.org/wiki/doku.php?id=bitname  Now using a wiki. 

I have come up with a solution to most of RHorning issues. However I'm still in the process of writing out it more formally.  It is quite a big departure from anything that has been talked on the forum yet.  But still (mostly) compatible with the bitcoin architecture.

The problem with this is that the generators themselves can put hundreds of domain names into their own block.  Just like generators can include transactions for free in their own block.

the 100BTC are 'Killed" as in they are transfered to a "dead bitcoins" key.  Then the generators can get to claim an extra 0.01 or whatever on the mined bitcoins.  If the generator doesn't claim them, they sit around and accumulate until generator dose.  What is happening is that we are removing coins from circulation and allowing people to generate them again.

The only rule is that the coins cannot be 'claimed' faster than the set amount per block.  If a generator doesn't claim the coins in one block. The next block can claim two lots of it.

There is a very elegant way of solving the front-running problem, but you need to think a little bit creativity 

BitDNS should be subscriptions, as you always pay the generators as long as it is active.

When one registers a domain, the registration contains the rate that should be paid, (an on-going transaction fee) and the total amount.  When the transaction is included in the block chain.  The transaction fee is removed from circulation, and added to every generator at the agreed rate until it runs out.  When it runs out, the registration expires as well as the domain.

For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC.  For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.

10 BTC  

A computer system that could produce 100GHash/sec (what is required to attack the network) would involve having 200 ATI 5970 @ $500 + (200 computer) each, that is $140,000 dollars required to control the network... still not prohibitory expensive.

Lets try and not get attacked until attacking the network costs at least 50% of the economy. ~ $500,000 or ~ 350GHash/sec

On the moral side of the coin, I suggest people to read http://www.fee.org/pdf/books/MarxismUnmasked.pdf  It is very good introduction for somebody wanting to understand what freedom is, and why the free-market is so important.

Yes, this is what I was implying by having 'templates' for the data.  To be accepted into the BitDNS 'group' one must follow the BitDNS template, otherwise the block that is created is orphaned.

The rules of the 'template' is whatever a majority of the network decides to requite; for instance, it could include a rule that the same domain name cannot be registered more than one. Or not.  But this is a longer term thing.

It is important to note, that when somebody claims a BitDNS address, then another claims the same address, it doesn't need to be network enforced, as those using the BitDNS information will just ignore the later claim as junk.

I like Grøstl, it is very cool. 

this isn't about protocol attacks, eg double spend and freezing.  Rather implementation security weaknesses.

I am convinced that the foundation of bitcoin (ie. the block chain) is secure from any non-nationally funded attack.  The only attack that makes me scared is a buffer overflow attack that steals the private keys in the wallet, however doesn't spend them.

If a significantly large attack happens to the block chain, we can always make a new branch that doesn't include the attack; with the theft of private keys, there is no easy recovery option, save (in the case of a massive attack), starting the block chain from 0 again.

As I'm not a security expert, I do not know how secure bitcoin is against this sort of attack.  However from my non-expert understanding direct to IP address transfers seems like a obvious surface area to attack.

Two questions: what attack areas dose the current bitcoin software have that could enable the theft of bitcoin private keys?
Secondly, what efforts can be taken to minimize the attack surface area of bitcoin?

It seems like killing two birds with one stone isn’t enough on the bitcoin forum; one has to kill three.

Firstly, I would like to commend nanotube's+theymos proposal.  I like it because it makes economic sense, and it is simple.
The design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the ‘issues’ said. (I still think there is really nothing wrong about how it is proposed to work as it is.  However, if there is a better way of doing it, why not?)

Before we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply.  Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.

If a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.
So with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.


The main concern on the forum is the inclusion of ‘other data’ in the block chain; the problem isn’t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.
In discussions elsewhere, it has been shown that:
1.   Generators will happily include any data that is profitable to include.
2.   The block size will grow to a size that balances data demands and the profitably of the miners.
3.   Clients only need to ‘keep’ data that they interested in.  Data that is irrelevant to the client may be forgotten once processed.
4.   Transaction balances may be used to cull the chain of old transactions.
Therefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want).  The only outstanding issue is: transfers.

What has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it.  Only after processing may a client delete any data that it doesn’t want.  This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.


I propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

Finally include a ‘summary’ group that contains only the changes to the transaction balances accumulated in all the other groups.

A Block could contain something like this:


Once one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes.  This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.

The important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.


Nanotube and Teymos’s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries.

Ah you get around 0.52GHash/sec on one of those... so it already is over a day.

I have seen both of the money as dept videos, while I thought that it brought up many issues with the current baking system, the rational why usury is bad extended to nothing more than "It is bad, because it is bad, mmmmk."

There is nothing wrong with loaning somebody something and expecting a payment in return; if people decide that usury is wrong and enforce it, they infringe on my right to conduct voluntarily transactions with other people.

When a bank uses the money deposited in it for loans, it therefore has risk.  Thus they offset that risk by giving it's depositors a proportion of the income gained upon it.  If somebody deposits into a bad bank and the money is lost, it is their own fault, they obviously didn't audit the bank thoughtfully enough!

A bank that uses fractional lending should qualify for more risk on deposit, so a higher return should be demanded from deposits.  The system is simple, and there is nothing economically or morally wrong with it.

The key difference in the bitcoin world of banking is that instead of trading promises of bank account amounts between people (eg. bank money / checks / cash), you trade the real thing, e.g. bitcoins.  So the world of bitcoin at it's foundations is solid.  If a bitcoin bank goes down, only those who use the 'bitcoin bank notes' and those who have deposited in it will be effected, not everyone like the current cash system.

The bitcoin banking wold will work identically to when we had banks who stored and loaned gold, and all the transactions were conducted in gold also.  However, gold is physical, bitcoin is not.

No, economically speaking, when something is produced in larger quantities the cost per unit goes down.  This is because any overhead for the production in relative terms has less effect on the cost per unit.  I see no reason why a larger block would be any different.

A larger block allows the generators to make more profit at a lower price per data unit charged. This encourages more people to use the service, thus increasing the incentive to generate.  It is a win-win situation.

I'm still trying to get my head around your idea completely.  The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins.

I gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity.  The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number.

In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market.  As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.

I agree with the whitelisting, this allows the generators to be more discerning in what they accept or reject.  That said, as soon as the template for a good BitDNS implementation is released, I'll be sure to add it to my generators whitelist.