Technical Details of Bitshares ID System

[bytemaster]

Most humans (probably including you and me) 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.

Darn it AnonyMint... you are the most annoying forum troll because you come across as reasonable despite having fundamental problems.

I submit that immoral actions that result in theft, murder, and destruction are not economically rational for either the individual or the whole of society.  It is always better to cooperate than to fight.  Every voluntary exchange increases value of both parties.  Every involuntary exchange (death, theft) decreases value of one person and redirects scarse resources to security.

So perhaps a starving person will steal to stay alive.  The result will be a harm to the economy.   You may be able to prevent starvation of some through reallocation of resources, but in the end you will undermine capital accumulation required to increase production and end future starvation.   Therefore, I submit, morality is always the best choice for the wellbeing of society and almost always the best choice for the well being of an individual.   Sure, theft may 'profit' you in the short term, but it hurts you in the long-term because it is not sustainable.  It is a misjudgment and economic miscalculation.

[bytemaster]

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?

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

[AnonyMint]

Darn it AnonyMint... you are the most annoying forum troll

Hey, hey. Please put that "J" in a box, or you will chase me away. I am merely trying to perceive. I am stating my perceptions. Sometimes they will be wrong, sometimes correct. That is what opensource is about. It is frustrating sometimes, but surely I won't expend all my time here forever. I am trying to come a decision by evaluating everything.

Please don't get frustrated. I don't think anyone is trying to shoot down your project. I think people just want to see you not waste effort down a wrong road. Yet in the end, you will decide and you might be correct. And don't think we are trying to get other readers to think negatively of your project. Well at least I am not.

Upthread I said I liked the idea of users having to pay a market based CPU cost for names that reflected the resource scarcity of the scalable blockchain.

[bytemaster]

Darn it AnonyMint... you are the most annoying forum troll

Hey, hey. Please put that "J" in a box, or you will chase me away. I am merely trying to perceive. I am stating my perceptions. Sometimes they will be wrong, sometimes correct. That is what opensource is about. It is frustrating sometimes, but surely I won't expend all my time here forever. I am trying to come a decision by evaluating everything.

Please don't get frustrated. I don't think anyone is trying to shoot down your project. I think people just want to see you not waste effort down a wrong road. Yet in the end, you will decide and you might be correct. And don't think we are trying to get other readers to think negatively of your project. Well at least I am not.

I was just chatting about this... I meant trolling in the loosest terms because you suck me in to discussion with your civil arguments and thought provoking posts.    You are clearly not the kind to provoke fights and that is much appreciated.

[AnonyMint]

Apology for interrupting your coding with curve balls. Me too. Need to get back to coding.

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

It is impossible to prevent people from charging for a resource. There is a value of what ever resource you tie into the system proof. If you attempt to price too low, the resource will be oversubscribed.

The problem with Bitcoin is it makes keys free, but keys are not free which is why the blockchain won't scale. Meaning I think to design a scalable blockchain will require charging for keys. But I am trying to work this out now, especially w.r.t. to laundries.

[bytemaster]

Apology for interrupting your coding with curve balls. Me too. Need to get back to coding.

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

It is impossible to prevent people from charging for a resource. There is a value of what ever resource you tie into the system proof. If you attempt to price too low, the resource will be oversubscribed.

You are correct, miners could make money 'off chain' selling CPU resources.    I actually envisioned this as companies wanting to provide web-based account creation services.  Chances are this mining would be paid for with advertising, or to draw users to your service and not actually result in a cash transaction.   Users would still experience name registration as 'free' like a gmail account (even though the cost of gmail account is your privacy).

[bytemaster]

Apology for interrupting your coding with curve balls. Me too. Need to get back to coding.

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

It is impossible to prevent people from charging for a resource. There is a value of what ever resource you tie into the system proof. If you attempt to price too low, the resource will be oversubscribed.

The problem with Bitcoin is it makes keys free, but keys are not free which is why the blockchain won't scale. Meaning I think to design a scalable blockchain will require charging for keys. But I am trying to work this out now, especially w.r.t. to laundries.

It isn't keys, but block sizes that must be limited.  This is why BitShares commits to a fixed limit on block sizes and forces transaction fees to go up rather than have unlimited block sizes.

[AnonyMint]

Apology for interrupting your coding with curve balls. Me too. Need to get back to coding.

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

It is impossible to prevent people from charging for a resource. There is a value of what ever resource you tie into the system proof. If you attempt to price too low, the resource will be oversubscribed.

The problem with Bitcoin is it makes keys free, but keys are not free which is why the blockchain won't scale. Meaning I think to design a scalable blockchain will require charging for keys. But I am trying to work this out now, especially w.r.t. to laundries.

It isn't keys, but block sizes that must be limited.  This is why BitShares commits to a fixed limit on block sizes and forces transaction fees to go up rather than have unlimited block sizes.

So you don't scale on the transaction volume vector. You still don't get Visa-scale.

[AnonyMint]

So you don't scale on the transaction volume vector. You still don't get Visa-scale.

Now to interrupt your regularly scheduled programming, with a conspiracy story.

[AnonyMint]

I suggest you artificially keep the price free to get momentum (top-down=expedient) and have it switch to free market pricing after so many blocks (bottom-up=longevity/scalability).

[bytemaster]

Apology for interrupting your coding with curve balls. Me too. Need to get back to coding.

Miners do not make money.   Everyone is merely out to mine their own name, and as a side effect earn non-transferrable reputation points.

It is impossible to prevent people from charging for a resource. There is a value of what ever resource you tie into the system proof. If you attempt to price too low, the resource will be oversubscribed.

The problem with Bitcoin is it makes keys free, but keys are not free which is why the blockchain won't scale. Meaning I think to design a scalable blockchain will require charging for keys. But I am trying to work this out now, especially w.r.t. to laundries.

It isn't keys, but block sizes that must be limited.  This is why BitShares commits to a fixed limit on block sizes and forces transaction fees to go up rather than have unlimited block sizes.

So you don't scale on the transaction volume vector. You still don't get Visa-scale.

I don't scale on a single chain (configurable parameter), but I do scale to many chains.  Because BitAssets can track arbitrary other assets (if they work according to design) users don't care about BitUSD on chain A vs chain B except for the network effect, transaction costs, and dividend rate.   Because I support cross-chain trading it is possible to be decentralized and support any transaction volume where each chain, 'operating as a for-profit, decentralized, autonomous corporation' would be competing to strike the right balance between centralization and transaction fees based upon consumer demand.  

[AnonyMint]

Unit-of-account.

I will explain more another time. Or just read my prior post in another thread (click my name).

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

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

So that means roughly 100,000 blocks per year - but if everyone who wants to register a name (not even talking about changing names in addition) needs to put that in a block header, how exactly can your system then scale to your required "1 billion" users??

[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.

So that means roughly 100,000 blocks per year - but if everyone who wants to register a name (not even talking about changing names in addition) needs to put that in a block header, how exactly can your system then scale to your required "1 billion" users??

Each block can contain 10K transactions (about).

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

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

So that means roughly 100,000 blocks per year - but if everyone who wants to register a name (not even talking about changing names in addition) needs to put that in a block header, how exactly can your system then scale to your required "1 billion" users??

Each block can contain 10K transactions (about).

Then please revisit my original question, which was about how the operations doable in "transactions" and only "block headers" differ.  From your whitepaper it looks (to me) as if you could only put name operations into the block header, because you want light clients to have them.  But this would mean you can't put 10k name registrations in a block, right?  So what exactly is the purpose of transactions and what of the things stored in the block header?

[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.

So that means roughly 100,000 blocks per year - but if everyone who wants to register a name (not even talking about changing names in addition) needs to put that in a block header, how exactly can your system then scale to your required "1 billion" users??

Each block can contain 10K transactions (about).

Then please revisit my original question, which was about how the operations doable in "transactions" and only "block headers" differ.  From your whitepaper it looks (to me) as if you could only put name operations into the block header, because you want light clients to have them.  But this would mean you can't put 10k name registrations in a block, right?  So what exactly is the purpose of transactions and what of the things stored in the block header?

You can register, renew, and update reputation points in transactions.  But you can only change public keys of registered names in the headers.   Changing public keys resets your reputation and age and therefore is not a common operation and therefore 'demand' for header space should not be high as most people would never need it.

Note: the design could work without allowing transfers at all  and light client support isn't even that critical.

[bytemaster]

The logic for this system is already implemented and lightly tested.   You can check the rules in the source if you have any detailed questions about what happens when.


https://github.com/InvictusInnovations/BitShares/blob/master/src/bitname/bitname_db.cpp

[AnonyMint]

But how does the light client know if a key was registered if it doesn't load all the merkel trees?

You mean the person using the key sends the tree-of-hashes that prove it was registered/updated in a particular block?

So only the revocations need to be in the headers, so the light client can invalidate that sent proof if necessary.

Clever. Correct?

[domob]

You can register, renew, and update reputation points in transactions.  But you can only change public keys of registered names in the headers.   Changing public keys resets your reputation and age and therefore is not a common operation and therefore 'demand' for header space should not be high as most people would never need it.

But my point was exactly that I don't think 100,000 name registrations (which to me associating a public key with a name is) per year will even remotely allow you to reach your target scale of 1 billion users.  Each of them has to at least once put his/her public key to their name, no?  (Namecoin, which you seem to see as scaling too badly, already has 100,000+ names registered with values/public keys (Namecoin addresses), so if your system can every year only achieve so many, I don't see why Namecoin seems too restrictive in the amount of possible names to you.)

You mean the person using the key sends the tree-of-hashes that prove it was registered/updated in a particular block?

So only the revocations need to be in the headers, so the light client can invalidate that sent proof if necessary.

Now that's an interesting idea.  However, even there I'd say that the number of revokations should be linearly related to the number of names ... thus all you get is a constant factor, which IMHO doesn't really justify all your claims about "better scaling".

[AnonyMint]

I submit that immoral actions that result in theft, murder, and destruction are not economically rational for either the individual or the whole of society.  It is always better to cooperate than to fight.  Every voluntary exchange increases value of both parties.  Every involuntary exchange (death, theft) decreases value of one person and redirects scarse resources to security.

So perhaps a starving person will steal to stay alive.  The result will be a harm to the economy.   You may be able to prevent starvation of some through reallocation of resources, but in the end you will undermine capital accumulation required to increase production and end future starvation.   Therefore, I submit, morality is always the best choice for the wellbeing of society and almost always the best choice for the well being of an individual.   Sure, theft may 'profit' you in the short term, but it hurts you in the long-term because it is not sustainable.  It is a misjudgment and economic miscalculation.

I almost know what this feels like.

Until this happens to you (which it sort of did to me last year), you don't understand the pain and the feeling. It is excruciatingly (and that is understatement) worse than horrific. I suggest you put your arm in fire for 3 days and hold it there if you want to understand this feeling.

https://www.youtube.com/watch?v=Pv0fpCtemQs

This may be coming to us.

They always think it won't come to them, then finally they come for you. (Nazi Germany and many other instances that spoiled westerners don't realize because they grew up sheltered and never studied history realistically)

I feel terrific anger and crying at the same time while watching the above.

Non-aggression doesn't exist. It is a figment of the imagination of people who have been consuming 25% of the world's resources, 25% of the world's debt, and only 5% of the global population. Eventually that glass house is going to break.

(and no I don't believe the Syrian government gassed his people, but that is besides the point, because I can't know for sure)

Looks like perhaps the UK legislature and the US congress are waking up enough to tell these war mongers they don't have the permission to start WW3.

The point is. WHO DEFINES MORALITY WHEN IT IS AMBIGUOUS. And how this is gamed.

Religion is another form of morality when it is not practiced alone (Matthew 6:5 Jesus says to pray in your room where no one can see you, but I am not trying to argue for Christianity here). Morality is always a collective action, thus it is never non-aggressive. Passive aggressive shit like feminism, etc.. None of that has any place in technical excellence.

Morality is a tool to defeat rationality.

Fitness is a tool for individuals to optimize away from the harm.

I choose tools that work.