Quote from: sschechter on November 07, 2014, 04:24:34 pm

Is a one time use ugly hash really a big deal?

What do you propose your solution will cost? How expensive will this be in man hours?  Who will you need to support this idea?

My solution to the same problem.....a label.  That's it.  "Here's your temporary id, this is why you need it, and this is what to do with it." Cost? Trivial.

The hash isn't the problem.  The lack of user friendliness is.  Where is the help screen that explains things like how voting works?  Why is this not there yet? Is it reasonable to assume that the user should leave the app and have to google the forums for help? Absolutely not.  File Menu -> Help -> Dialog Box -> Label.  That's it.  I know the new UI is coming, so it may not do much now, but this type of stuff should have been there 3 months ago. I will be extremely disappointed if I'm using the new UI and have questions that can't be answered inside the app itself.  I know I must not be alone on this.

You are perfectly right. What is cool is that the community as a whole can try to contribute on this, we just have to find how to organize (who?) and implement it (google doc ?). It isn't really the job of the developers to create this help : they have more crucial things to do, and they are so plunged in their stuff that they cannot see what new users experience.

I think I have a solution:

We create a transaction type that involves registering a "free-floating" account name and a password hash. This "free floating" name could then be "claimed" by any wallet by simply broadcasting a transaction that proves they are in possession of the password. This way, faucets and exchanges could pay for account registrations using the regular security mechanisms (captcha) and broadcast those names as free-floating registered accounts. Then a user would simply launch their client, enter the password they have chosen, and link the registered account name to their private keys. Here is a step-by-step illustration:

1) User launches their client which says "visit any of the following sites to register your account: BTSfaucet.com, BTSregister.com, Bter.com, etc. etc.
2) User visits one of those sites (possibly in a web view, or in their own browser)
3) The site has a captcha or requires email verification or whatever else to prevent spam. After passing the challenge, the site asks the user to select a username and a password (at least 10 characters - no need to be super-secure here). The site broadcasts a "free floating" account registration (including fee) and redirects the user back to their client ("Done! Now just open your client to claim your username").
4) The user returns to their client and enters the new username and password to generate a new transaction claiming the username (ie, linking the username to the private keys of that particular client).

The “chicken and egg” problem is not due to a lack of funds. Plenty of faucets and exchanges would pay for the .01 BTS necessary to register accounts. The real problem is the use of the “ugly hash” to receive that first transaction My solution solves this issue directly, without making payment-free registration (which is not necessary).

Future DACs inside BTS will likely NOT honor 10% even if they wanted to it would probably be hard. Stop giving play as example.

Quote from: matt608 on October 31, 2014, 09:57:46 pm

Agree.  Enough visionary thinking, we need code-crunching.  We've got bitUSD and bitassets and other awesome stuff.  Lets get it out there.

We need both. I don't think we can ever stop innovating if you want the Bitshares community to compete with Vitalik and Ethereum. They aren't going to stop having bigger and better visions if you look at their grand designs. Vitalik is always researching, always coming up with new ideas, always willing to try new things.