Topic: Technical Details of Bitshares ID System - page 3. (Read 5281 times)

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)?

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