- the fields for entering passwords in lock screen should be anti-keylogger

I don't think there's anything we can do to protect users when their workstation has been compromised to that extent.  If you have a specific anti-keylogging mechanism in mind, more details will allow a more specific analysis.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

He's trusting v0.4.22 to verify the hash of v0.4.23 is signed by known key(s).  Which is legitimate.

If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer

Only whoever compiled a given binary version really knows what source code went into that version.  We need to set things up so that every delegate can compile his own version from source and all get the same binaries.  This will require some work though.  So for now we should encourage everyone to compile from source (especially delegates), and sign binaries with a single key for people who insist on using them.

- if the installer detected that there are partitions other than c drive, the default path of wallet data should not be in c drive

I disagree.  On a typical system, a drive letter other than C: might be a recovery partition, an optical drive, a network drive or a removable USB drive.  Installing to any of these by default would be a problem.  If a user is technically un-sophisticated and goes with the default, then C: drive is most likely the right place.  If a user is technically knowledgeable enough to have multiple partitions / drives, then they will be technically knowledgeable enough to decide which drive they want to install it to, and change the installation path from the default.  (And I agree with you that it should be possible to change the installation path in the installer.)

If we install to the same partition as Windows by default, it makes sense:  (1) Users expect it because that is the default behavior of most programs, and (2) The Windows partition is likely to be a partition on a local SATA hard drive.

I am thinking DevShares will have non-zero value above and beyond your typical altcoin.  Because there is non-zero fundamental economic demand for early access to features like atomic cross-chain trading.  We haven't yet determined the feature set of DevShares.  However, I originally conceived of the DevShares idea as a platform to test some of my ideas for interesting approaches to AXCT.

Please keep in mind however:

Nobody, including bytemaster can tell you what DevShares are worth, or what their relative value will be, until they are freely traded on an open market.  All attempts are solely speculation based on opinion.

This post is entirely speculation based on my personal opinion; it is merely an educated guess, which could definitely be wrong.

We are exploring the possibility of reducing the fee for user-created assets when we merge the chains.  bytemaster has expressed openness to reducing the fee to 10 BTSX or even less.  In this post, I would like to address the implications of such a policy.

Disclaimer:  While I am now officially a member of the I3 team, this post has not yet been adopted as an official I3 policy.  As of this writing, we have not yet reached internal consensus at I3 about how to handle the issues I raise in this post.

In terms of network resources, processing user-created asset transactions costs no more or less than processing transactions for built-in BitAssets. From a technical standpoint, implementing issuing, transferring, and market matching of bids/asks for user-created digital tokens already exists in the code.  Reducing the fee charged for these transactions to reflect their cost to the network will encourage new applications and keep someone from forking BitShares and "eating our lunch".

The main problem is that currently user-issued assets and built-in assets live in a shared global namespace.  I think the cleanest way to deal with the problem is to separate the system into two parts.  (1) Internally, each asset should have a unique identifier, a hex string which is the hash of a JSON "asset descriptor" object describing the purpose of the asset, how many are issued, etc.  (2) Then we should provide a mapping mechanism allowing names in a more human-friendly namespace to be mapped to asset descriptor hashes.

Under the mapping mechanism, short or memorable names in the namespace are scarce resources.  A market-based mechanism is the best way to discover their value.  Fortunately, in the merged chain we are already planning to implement a market mechanism allowing price discovery for allocation of names in a namespace -- that is the entire purpose of DNS / KeyID.

I propose the following mapping mechanism:

- All one-to-four character entries in the global namespace come into existence as market-based assets when a majority of delegates publish an asset descriptor indicating their support.
- Five or more character entries belong to the owner of the corresponding .coin domain and are allocated by the DNS auction process.
- Per-account entries such as drltc.titan/mytoken can be allocated to the owner of the corresponding TITAN account.
- .coin URL's such as drltc.coin/mytoken can be allocated to the owner of the corresponding .coin domain.

Each of these namespaces serves a different market.  One-to-four character entries are likely the same as real-world stocks and commodities. The cost and setup time is high -- adding a token requires convincing a majority of delegates to support it.

Five-or-more character entries are usable by people who want tokens inscribed with their brand.  The cost and setup time is medium -- they must obtain a DNS name, which is substantially less difficult than convincing 51 delegates, but substantially more time-consuming and expensive than a single transaction fee.

Per-account or TLD entries are most suitable for small experiments or private-issue tokens.  For these applications, branding is not a concern so long as the coin has *some* human-readable, globally unique identifier.  Speedy turnaround time and low cost are still desirable.  The cost and setup time is small -- simply paying a transaction fee.

For simplicity of implementation, the name-to-asset-descriptor mapping should only be mutable if all tokens have been burned.

On Friday, at I3 we internally discussed an idea based on a hard-coded list of one-to-four letter names representing real-world stocks and commodities.  Upon reflection, I've come to believe that such a scheme is inherently brittle, essentially requiring a hardfork if the hard-coded list is incomplete.

I think there might be some cherry picking effect here.  I.e. there are probably around a couple hundred crapcoins around -- are you comparing us to an average crapcoin, or only to the best crapcoins?

Also keep in mind some of those market caps might be paper numbers only.  Crapcoins can have illiquid markets (so the market cap doesn't accurately reflect real demand), low effective float (due to premining or other manipulation resulting in much of a coin in the hands of a few), or market manipulation (your data may merely be illustrating the pump stage of a pump-and-dump).

I think that it should, in principle, be possible to run BitShares on a completely open source system where the user could theoretically audit the source code of any component.  In particular, there should be no closed-source or pre-compiled components in the BitShares toolkit itself.  The BitShares Toolkit should allow users to audit every line of code that could potentially gain access to the private keys controlling their funds.

Of course, if some individual user want to make an individual choice based on individual convenience / security tradeoff preferences, they should also be free to choose to trust OS vendors, binary package repos, PPA's, precompiled binaries, etc.

There is a binary blob in the BitShares toolkit source tree at https://github.com/BitShares/bitshares_toolkit/tree/c58b14c6dc923929368022af6c1c54a45b67dc2f/CrashRpt/bin.  This binary blob is apparently used for crash reporting functionality.  I requested it to be removed.  This request was overruled; see https://github.com/BitShares/bitshares_toolkit/issues/658.  (However, the dependency was made optional in the build.)  The issue has not been revisited in approximately two months since then.  I'm starting this thread to discuss why it's still there and try to build consensus about how to satisfy the goal of making the source code (in principle) more auditable by (if possible) removing the binary blobs.

What is stopping us from managing this CrashRpt dependency the same way we manage OpenSSL dependency?  We don't put precompiled OpenSSL binaries in the source tree.  Instead we have DLL's, so's or statically linked libraries that come from somewhere else (the package manager on Ubuntu; I'm not really sure what Windows and Mac do, perhaps they require the user to separately, perhaps manually, download and compile OpenSSL from source?).

What is stopping us from managing this CrashRpt dependency the same way we manage LevelDB dependency?  We don't put precompiled LevelDB binaries in the source tree.  Instead we have the LevelDB source code in a submodule, and its build is integrated with the main project's build.

My guess is that the low float also has something to do with re-branding as KeyID.  I've stayed far away from Keyhotee stuff because I'm not really enthusiastic about their business model for a variety of reasons.  So a lot of people probably just skip this subforum in the list.  I'm kind of a forum regular and I didn't know about the re-branding or the launch until Toast told me directly in a private conversation.

The point is, I think the float is so low because people just don't know about the DNS launch.  There has been so little marketing that even people like me, who follow the forum closely, weren't aware of it!