Topic: Technical Details of Bitshares ID System (Read 5281 times)

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.

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

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

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?

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

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.

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?

Each block can contain 10K transactions (about).

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

Unit-of-account.

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

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.  

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

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

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

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.

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

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.

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.

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.