Quote from: alphaBar on November 07, 2014, 08:40:41 am

Quote from: gamey on November 07, 2014, 07:09:26 am

It is amusing how both myself and TonyK have been some of the more critical people on here. Keep trying to redeem yourself and frame it differently AlphaBar.  No, it isn't just you......

Now it is all poor me! poor me! poor me! Stop with the martyrdom shtick.

Wow you are really obsessed with me, following me around like a little puppy to respond to every comment. Just making yourself look foolish.

It will be good to just try to defend your points of view, instead of trying to point a finger to whomever is preventing you from doing so, in your mind...

 just a suggestion....

I agree, but this guy doesn't stop the personal attacks. Just look at the last few threads I've commented in. Probably better to ignore him though...

Quote from: alphaBar on November 07, 2014, 08:19:55 am

Quote from: gamey on November 07, 2014, 08:09:09 am

The format of the address is not the problem, or at least i don't believe so.  People don't look at the # on the checkbook and say "oh my that is ugly!"

It is all a matter of framing it into a concept people already understand.  "Address" works, but it is a tad abstract.

I think maybe 'account address' since we can't use 'account number'.  Then put some dashes in it.  Every 5 characters for those who need to relay it or type it in manually.   That will make it less ugly and far more usable in the cases where the usability is being questioned.

^^^^ With this you really avoid the problem.  Then once in the client they can register an account if they want.

FYI, it's called "Reed-Solomon" error correction. But unfortunately it only addresses the issue of correcting errors in manually inputting the "ugly hash". My solution avoids the ugly hash entirely.

I wasn't suggesting reed-solomon.  I was suggesting putting dashes in addresses and use the same bitcoin checksum system that is already being used.  The dashes aren't what make it reed-solomon.  Correction is nice, but just having a checksum tell you that the address isn't valid it is almost as useful.

Why do "almost as useful" if you can just use RS? And what is the point in the end if the user has to manually enter a nasty hash address or use a QR code? The whole point of this discussion is to avoid that.

The format of the address is not the problem, or at least i don't believe so.  People don't look at the # on the checkbook and say "oh my that is ugly!"

It is all a matter of framing it into a concept people already understand.  "Address" works, but it is a tad abstract.

I think maybe 'account address' since we can't use 'account number'.  Then put some dashes in it.  Every 5 characters for those who need to relay it or type it in manually.   That will make it less ugly and far more usable in the cases where the usability is being questioned.

^^^^ With this you really avoid the problem.  Then once in the client they can register an account if they want.

FYI, it's called "Reed-Solomon" error correction. But unfortunately it only addresses the issue of correcting errors in manually inputting the "ugly hash". My solution avoids the ugly hash entirely.

Quote from: alphaBar on November 07, 2014, 05:54:36 am

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

This is way too complicated, and ignores the problem completely, relying on third party services for funding.  Stop at #1, you didn't read the original problem.

The problem is having to use an "ugly hash address" to register an account. My solution avoids this entirely and requires the same number of steps as is currently done (though easier). You simply register your account with the faucet and claim it in your wallet. Two steps and done, all with no ugly hash address.

You can just register another account after you use the faucet to get your first account.

Yes but you must still send the funds from the faucet to an "ugly hash address". My proposal avoids this.

This was buried in some debate about personal issues in this thread, so I'm repasting here for feedback:

Problem

Creating a new account requires use of an ugly Bitcoin-style hash address to receive funds. This is not intuitive for most users. In other words, you must have BTS in your wallet in order to register a new account, but you cannot receive BTS easily without already having an account (chicken and egg problem).

Proposed 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. "Free-floating" accounts would be ineligible to receive funds until claimed. 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).

Quote from: alphaBar on November 07, 2014, 06:30:10 am

Quote from: tonyk2 on November 07, 2014, 06:21:43 am

Quote from: bytemaster on November 07, 2014, 06:01:32 am

With respect to "marketing" payouts... those are not for "one guy" but for entire teams working on stuff.

I am not Rune or alphaBar... I do not care if it is one guy or 10...

I just hope the 'stuff' this/those guys are working on, is worth a million bucks upfront...more so than everybody else combined...

after all this amount is what? 65-85% of the whole AGS fund....

How funny to see you singing the same tune in the end... even though you disparage me in the process. I called for (i) a reasonable accounting of all funds (including marketing) and (ii) reasonable accountability in exchange for those funds. Seems you now want the same, but I'm afraid you will be accused of "spreading FUD" by the worshippers.

We might be after the same thing at the end... who knows... at least I am not trying to be disruptive, and I hope you are not too.
And yes I know, I will be unnecessary blamed and I might be also reasonably accused...I will just try to stay open minded for the truth and not only my personal interest.

I think the culture of this forum is somewhat flawed to be honest. There is a lot of groupthink and cheerleading that is celebrated as a virtue. If we weren't so averse to criticism we would be far better off in the end. It's true that we're on the same team, but for a niche technical product like cryptocurrency, I would expect a far less emotional and more rational debate around here. Hopefully things improve, but I think there is a leadership void that contributes to the problem.