Technical Details of Bitshares ID System

[bytemaster]

Recognizing that what has been published about the BitShares ID system so far has been rather light on technical details, I would like to provide a rough draft of a more in-depth implementation details.  There are many ideas that I would appreciate solid feedback on.

https://docs.google.com/document/d/1ShDngXMp-2YMlCjb4NnJVUkRRZxathDdt5aTp3UUJDk

For those who like to see it in code: https://github.com/InvictusInnovations/BitShares/blob/master/include/bts/bitname/bitname_block.hpp

[domob]

I must have missed something - but it seems to me that unlike Namecoin your system (which is apparently meant to be less flexible and just usable for your particular application, gaining a constant factor in scalability) can only store a public key with a name.  This is of course sufficient to establish identities, because once you have the public key you can use it to sign all kind of data transacted "off chain" should that be necessary.  However, what's then the difference between "name operations" that can only be done in the block header and "name transactions"?  It seems to me that the only actual operation someone might want to perform is setting a name's public key (or changing/revoking it), which must be done in the block header.  Thus transactions would be completely unnecessary - which would however also mean that light clients are not possible at all (because a "full node" would also be just validating the block headers) and that new blocks would have to be found at a hilariously fast rate (IIRC you estimated 3 per second for your target scale), which would never work with today's network latencies (and in fact probably never will just because of the finite speed of light).

So, what do I miss here?  For what purpose are the name transactions used, and how can your millions of users associate public keys with their names such that light clients only need the block headers (which presumably can't be 100e6/365/24/3600 = 3 per second)?

[AnonyMint]

How do you stop people from using more than one name, in order to meet your 1 billion limit?

Seems the only way is to auction slots, which conflicts with your plan for them to be free.

It is impossible to give away for free a finite resource.

Registrations fees should go to pay miners to secure the blockchain. It could be merge mined with the coin.

[AnonyMint]

You must also consider the negative impacts of design features when you state the positive impacts.

Reputation has many downsides:

a. It can be stolen, e.g. threaten first to extort private key, then kill, and keep key.
b. Censorship based on metadata which doesn't always correlate rationally.
c. Discriminate against early adopters out of jealously, i.e. retribution for #b.
d. Regulatory authorities can require the BitName same as they now do Social Security # and Id. They can now establish the BitName is real, because it has (duration) reputation.

The high cost to transfer or revoke a name also has many downsides, e.g. see #d.

Remember the principle of top-down economics. You can't do just one thing, so please try to do less. Perhaps add that to the axioms in your whitepaper at the OP of main thread.

will enhance the security of users against subtle bate and switch attacks as well as typos

Phishing.

[AnonyMint]

Excuse my ignorance (and that I'm getting sleepy so maybe not thinking clearly). Why do you light clients need to be able to verify from a block header, and not from the branch of hashes of a Merkel tree that is presented to them?

I thought the point of putting data in the Merkel tree is that then one only needs to know the block header in order to verify someone's claim that a transaction occurred, as long as that someone presents the branch of hashes of a Merkel tree.

I thought the only reason heavyweight clients need all the data is because they don't ask tx senders to provide the branch of hashes of a Merkel tree.

[bytemaster]

Excuse my ignorance (and that I'm getting sleepy so maybe not thinking clearly). Why do you light clients need to be able to verify from a block header, and not from the branch of hashes of a Merkel tree that is presented to them?

I thought the point of putting data in the Merkel tree is that then one only needs to know the block header in order to verify someone's claim that a transaction occurred, as long as that someone presents the branch of hashes of a Merkel tree.

I thought the only reason heavyweight clients need all the data is because they don't ask tx senders to provide the branch of hashes of a Merkel tree.

I can prove a transaction occurred with a merkel tree, but that doesn't prove another transaction didn't occur after that to cancel it or transfer it.

[bytemaster]

How do you stop people from using more than one name, in order to meet your 1 billion limit?

Seems the only way is to auction slots, which conflicts with your plan for them to be free.

It is impossible to give away for free a finite resource.

Registrations fees should go to pay miners to secure the blockchain. It could be merge mined with the coin.

Nothing stops someone from using more than one name, in fact that is encouraged.
These are not 'free' because the price you pay is CPU power. 
People will eventually bid up names with CPU power.

From an economics perspective, people perceive it as 'free' even though it is not free because they do not have to think about 'purchasing something'.

[bytemaster]

I must have missed something - but it seems to me that unlike Namecoin your system (which is apparently meant to be less flexible and just usable for your particular application, gaining a constant factor in scalability) can only store a public key with a name.  This is of course sufficient to establish identities, because once you have the public key you can use it to sign all kind of data transacted "off chain" should that be necessary.  However, what's then the difference between "name operations" that can only be done in the block header and "name transactions"?  It seems to me that the only actual operation someone might want to perform is setting a name's public key (or changing/revoking it), which must be done in the block header.  Thus transactions would be completely unnecessary - which would however also mean that light clients are not possible at all (because a "full node" would also be just validating the block headers) and that new blocks would have to be found at a hilariously fast rate (IIRC you estimated 3 per second for your target scale), which would never work with today's network latencies (and in fact probably never will just because of the finite speed of light).

So, what do I miss here?  For what purpose are the name transactions used, and how can your millions of users associate public keys with their names such that light clients only need the block headers (which presumably can't be 100e6/365/24/3600 = 3 per second)?

The light clients need the block headers plus merkel root.  
Blocks are produced every 5 minutes.

Yes this system is less flexible on purpose because it is serving a very narrow goal and designed to be used even by people that don't want a full currency.    It gets all names into a single namespace while being distributed.  Flexibility has costs.

Note:  The DNS system for domain names is a dividend paying crypto-currency where names are auctioned. 

[AnonyMint]

How do you stop people from using more than one name, in order to meet your 1 billion limit?

Seems the only way is to auction slots, which conflicts with your plan for them to be free.

It is impossible to give away for free a finite resource.

Registrations fees should go to pay miners to secure the blockchain. It could be merge mined with the coin.

Nothing stops someone from using more than one name, in fact that is encouraged.
These are not 'free' because the price you pay is CPU power.  
People will eventually bid up names with CPU power.

From an economics perspective, people perceive it as 'free' even though it is not free because they do not have to think about 'purchasing something'.

I like it. If you are allowing 10,000 mined blocks per annum, then the cost is 1/10,000 of the PoW difficulty, since every name has to renewed annually. Hardware is fungible with money in this case, because a user could offer a bounty (tx fee) to a miner.

Thus it seems you need a way for the user to send his registration request with the name blinded. Or do initial registration requests not get put in the block header? Then what data are Merkel trees storing and why?

Note:  The DNS system for domain names is a dividend paying crypto-currency where names are auctioned.  

The regular system is already an auction as I explained above. Do you mean an individual auction for each name, rather than an auction for the next registration block for any name as is the case above?

[bytemaster]

How do you stop people from using more than one name, in order to meet your 1 billion limit?

Seems the only way is to auction slots, which conflicts with your plan for them to be free.

It is impossible to give away for free a finite resource.

Registrations fees should go to pay miners to secure the blockchain. It could be merge mined with the coin.

Nothing stops someone from using more than one name, in fact that is encouraged.
These are not 'free' because the price you pay is CPU power.  
People will eventually bid up names with CPU power.

From an economics perspective, people perceive it as 'free' even though it is not free because they do not have to think about 'purchasing something'.

I like it. If you are allowing 10,000 mined blocks per annum, then the cost is 1/10,000 of the PoW difficulty, since every name has to renewed annually. Hardware is fungible with money in this case, because a user could offer a bounty (tx fee) to a miner.

Thus it seems you need a way for the user to send his registration request with the name blinded. Or do initial registration requests not get put in the block header? Then what data are Merkel trees storing and why?

Note:  The DNS system for domain names is a dividend paying crypto-currency where names are auctioned.  

The regular system is already an auction as I explained above. Do you mean an individual auction for each name, rather than an auction for the next registration block for any name as is the case above?

This system is first come, first serve name registration.  The auction here is space in the chain and all names are the same price.

The BitDNS system has a dividend paying crypto-currency where you must purchase your name 'at auction'.  You don't own a name until X days pass with no bids higher than yours.   The profits from selling of the name are distributed to the share-holders, ie those who own the crypto-currency.   This system is designed to support perhaps 50 to 100 million names with the same resource requirements as the BitShares ID system while making everyone who owns the crypto-currency a 'domain squatter' on all names and they get a share of the profits.    Combining the fact that high-value names cannot be purchased at below market prices (due to price fixing) and the fact that the profits from squatting are already distributed to everyone.     More details on this system will come out in time, but please don't confuse the BitShares ID system with Namecoin DNS they have different purposes.   

[AnonyMint]

while making everyone who owns the crypto-currency a 'domain squatter' on all names and they get a share of the profits.    Combining the fact that high-value names cannot be purchased at below market prices (due to price fixing) and the fact that the profits from squatting are already distributed to everyone.  

As you know already, I don't agree with moral technical design. It all boils down to economics and trying to fit your morals distorts rationality.

Eliminating non-market pricing is economically efficient. Bribing people not to compete in auctions with a collectivist non-solution is not economic.

With morals, we can NEVER DO JUST ONE THING.

P.S. this the "J" in your INTJ versus the "P" in my ENTP.

[bytemaster]

As you know already, I don't agree with moral technical design. It all boils down to economics and trying to fit your morals distorts rationality.

Some would say that morality is rational.   Economics that are not moral, are not rational.    In my book, morality is boils down to not initiating violence or fraud to harm or steal another person or their property.

Otherwise, you would suggest that economics can be used to justify immoral actions.   The eugenics movement loves this rationale.

[CIYAM]

I think that constantly bringing up the personality types thing adds nothing to the actual point.

Is it possible to just leave that part out and focus on the idea itself (i.e. I don't really care about each person's personality type I care more about whether the system will work or not) ?

[AnonyMint]

Most humans (probably including you and I) if they can't eat without killing will kill.

A lion kills in order to live.

I once lived for a short while very impoverished where I didn't have $1, and I was eating 1 cup of rice and bananas per day. It does weird things to your psychology. When resources are plentiful, we can pretend that morality trumps economy efficiency, then when we waste enough resources with that delusion, we periodically cycle back to learning about resource scarcity.

We live in a world of competing priorities and we are not even in control of every dependency that rains down on our life (e.g. you get cancer). Fitness is the way we optimize resilency. Morality isn't.

[CIYAM]

Interesting and rational point I guess but what exactly has that to do with the OP?

Aha - I replied before you updated - okay then but what about the idea of "rational fitness"?

(have you read the book Shantaram?)

[AnonyMint]

Interesting and rational point I guess but what exactly has that to do with the OP?

It applies to his moral (non-economic) decision to bribe the users from speculating on auctions by offering them a collective ownership of all names. I explained that in more detail in the companion main thread.

Any way, I don't want to push my point. I just wanted to make it. That is all. I am happy to see people try different things. That is necessary in economics. Success can't exist without failure.

[CIYAM]

You have made several good points (and I'm sure others are paying attention to that) so I am only wanting to clarify their relevance.

My hope is that the result should be the creation of a useful technology (hopefully a win-win for all of us)!

[AnonyMint]

what about the idea of "rational fitness"?

(have you read the book Shantaram?)

No, but it boils down to any top-down decision is not fitness, because it can not anneal, and any collective action can't anneal because it moves monolithically (low knowledge, destroys relative knowledge of individuals locked into the collective).

Let me contrast it another way. Top-down is expedient and sometimes optimum for a particular goal, whereas, decentralized is optimal but may not converge to a goal. Closedsource and opensource are good examples.

Thank you.

bytemaster has made several design wins too. Kudos to him!

[CIYAM]

My point with Shantaram was that it's philosophy is based upon *complexity* instead of *morals* and it cleverly describes morals in terms of *complexity*.

The prime example is that: To kill a human is wrong because you are destroying complexity (destroying entropy), to kill an ant is also therefore *wrong* (but less so) and to kill a plant by the same thinking less so again.

It is a very interesting way to re-think things IMO (although maybe not relevant to this discussion so I won't continue - I would recommend you read the book though - it was a "page turner" for me).

[AnonyMint]

Interesting.

I may see a design issue for BitID. The PoW difficulty has to be high enough to protect against 51% attack, yet the $ that the miners earn is based on how much users are willing to pay for names.

bytemaster appears to be trying to keep the difficult low enough that the users don't have to pay in $ and can pay in otherwise idle PC power. This is price fixing and will backfire by leaving the network less secure.

Merged mining with the coin has the advantage of increasing the security.

I remember he mentioned a/some strategy/ies in the whitepaper w.r.t 51% attack, but I will need to read again.

Thoughts?