Bitcoin Forum

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

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

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.

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 (https://bitcointalk.org/index.php?topic=279771.msg3034195#msg3034195).


Phishing.

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 (http://blog.jim.com/economics/bitcoin-scaling-problems.html/comment-page-1#comment-310205).

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.

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

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. 

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?


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.   

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.

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.

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

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.

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

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.

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

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!

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

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?

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.

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

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.

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.

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


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.

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

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.

Now to interrupt your regularly scheduled programming, with a conspiracy story (https://bitcointalk.org/index.php?topic=160612.msg3034633#msg3034633).

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

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.  

Unit-of-account.

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

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.

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

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?

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


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

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 (http://esr.ibiblio.org/?p=5034).

(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 (http://esr.ibiblio.org/?p=4757), thus it is never non-aggressive. Passive aggressive shit like feminism (http://esr.ibiblio.org/?p=4934), 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.

Regarding the secure messaging feature, be aware of:

Signcryption

Digital Signcryption or How to Achieve
Cost(Signature & Encryption) <<
Cost(Signature) + Cost(Encryption)

Claims to eliminate the need to sign and encrypt in separate steps as PGP does. I didn't read it yet, just passing it along.

I think signcrypt is useful for signing and encrypting short messages most efficiently, i.e. setup stage. Especially a designated verifier.

Check out Salsa20 encryption, I think it has superior qualities (e.g. faster, can send blocks out-of-order) over AES for encrypting the message content.

I am not a cryptography expert. Just based on what I have read.