0 Members and 1 Guest are viewing this topic.
Quote from: gamey on November 07, 2014, 08:25:38 amQuote from: alphaBar on November 07, 2014, 08:19:55 amQuote from: gamey on November 07, 2014, 08:09:09 amThe 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.
Quote from: alphaBar on November 07, 2014, 08:19:55 amQuote from: gamey on November 07, 2014, 08:09:09 amThe 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.
Quote from: gamey on November 07, 2014, 08:09:09 amThe 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.
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.
Quote from: gamey on November 07, 2014, 08:09:09 amThe 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.I'd say don't worry about the account address ! Worry about all the steps required in the other systems to get rid of the ugly hash. All this to just to get to the point you already were if we had used a simple 'account address'.^^^^ 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.
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.I'd say don't worry about the account address ! Worry about all the steps required in the other systems to get rid of the ugly hash. All this to just to get to the point you already were if we had used a simple 'account address'.^^^^ With this you really avoid the problem. Then once in the client they can register an account if they want.
Quote from: alphaBar on November 07, 2014, 05:54:36 amI 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.
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).
Quote from: gamey on November 07, 2014, 07:03:42 amSo why do we need account registration to begin with ? Does everyone think TITAN names are wonderful? If BTSX takes off the namespace will be so full people will forever be sending funds to the wrong people. There are numerous scenarios where a name can be misspelled resulting in lost funds. If you say a name, you're far more likely to get it wrong than listing off characters. Put dashes in there ! Thats what NXT did. Credit cards, MS product registration codes.. they all have things that break up the address. I just don't get the account names. It has just opened a whole big security hole with squatters that are using the failure of human memory as a vector for attack. It sounds wonderful at first.. but really really think about all the implications before insisting on them. Sure it is nice to be away from your computer and be able to write down your address.. but what are the other use cases that give much value ?There is a lot I agree with here. I think we put too much emphasis on the globally-recognized, human-memorable (sometimes...) TITAN names. I still think they should exist as an easy way for people to share their online identity with others in the context of a real world meeting (perhaps specifically in a situation where use of modern technology such as smartphones is not possible or inconvenient). But for basically every other situation I think people should use the globally unique hash and for their convenience people should use local aliases for their contacts.What are your thoughts on my comments in the posts here and here?
So why do we need account registration to begin with ? Does everyone think TITAN names are wonderful? If BTSX takes off the namespace will be so full people will forever be sending funds to the wrong people. There are numerous scenarios where a name can be misspelled resulting in lost funds. If you say a name, you're far more likely to get it wrong than listing off characters. Put dashes in there ! Thats what NXT did. Credit cards, MS product registration codes.. they all have things that break up the address. I just don't get the account names. It has just opened a whole big security hole with squatters that are using the failure of human memory as a vector for attack. It sounds wonderful at first.. but really really think about all the implications before insisting on them. Sure it is nice to be away from your computer and be able to write down your address.. but what are the other use cases that give much value ?
...you can't interact like I would expect from a reasonable/educated/intelligent person.
get some meds.
Quote from: gamey on November 07, 2014, 06:40:47 amQuote from: alphaBar on November 07, 2014, 06:32:00 amAll I ask in exchange for my idea is a public shaming of everyone who has accused me of trying to sabotage BTS. Yea, one below average idea and you've redeemed all your over the top hostile negativity. Yea, you got it buddy.It's a great idea, solves the problem completely. But I would expect nothing different from you - accusing me of hostile negativity while constantly disparaging me and my work.
Quote from: alphaBar on November 07, 2014, 06:32:00 amAll I ask in exchange for my idea is a public shaming of everyone who has accused me of trying to sabotage BTS. Yea, one below average idea and you've redeemed all your over the top hostile negativity. Yea, you got it buddy.
All I ask in exchange for my idea is a public shaming of everyone who has accused me of trying to sabotage BTS.
One of the biggest hurdles we face is getting new accounts registered without spamming the network. The cost to register an account is about $0.01 and to grab new users we require going through 3rd party centralized services to help people register their account. This harms the whole experience.I would like to propose we allow new accounts to be registered in exchange for a "proof of waste" of $0.01. A CPU burning 100W for 1 hour at $0.10/KWH would do the trick.From a user experience point of view it would be "slow" compared to using a centralized service would could verify your email in 5 minutes... but the centralized services would cost the network more than $0.01 per user to operate. This would then have to be paid for via delegate pay. A solid user acquisition plan would easily handle the registration for the user and $0.01 trx fee is likely nothing compared to the value of signing up a user. So perhaps the entire the POW registration has no effective value.
Quote from: mira on November 07, 2014, 05:58:13 amQuote from: bytemaster on November 07, 2014, 05:20:50 amMy conclusion is that users will almost always be brought in via a helper service and that this thread was mostly to get the idea out of my head and discarded as well as spur ideas on how to make it easier for people to get into BTS.I was wondering about this on a smaller/niche level - musicians/digital artisans as helper services, offering a particular track/item for a small donation w/entry of account name, and .01 BTS is sent to register your account. Didn't notice this comment by BM, but I think my solution (above) actually solves the issue without circumventing the "helper service", which I agree is the most logical entry point. In fact I think the BTS website could require account registration with a built-in faucet before downloading the client. This way users will simply launch their client and enter their user/pass to get started.
Quote from: bytemaster on November 07, 2014, 05:20:50 amMy conclusion is that users will almost always be brought in via a helper service and that this thread was mostly to get the idea out of my head and discarded as well as spur ideas on how to make it easier for people to get into BTS.I was wondering about this on a smaller/niche level - musicians/digital artisans as helper services, offering a particular track/item for a small donation w/entry of account name, and .01 BTS is sent to register your account.
My conclusion is that users will almost always be brought in via a helper service and that this thread was mostly to get the idea out of my head and discarded as well as spur ideas on how to make it easier for people to get into BTS.
I'm a bit concerned with the amount of effort being made to make it super easy to register. Yes, mass adoption is great, but this is a great product that people will jump through a few hoops to join. How easy is it to get an E*Trade account?The mass adoption of bitUSD and the consumer side of things (vs the trader) is a different story with different front ends. The consumer user of bitUSD shouldn't even need to know about, let alone understand, the underlying mechanisms.How many card carrying customers of Visa and Mastercard have even the slightest idea how the back end works?
Quote from: Riverhead on November 07, 2014, 05:37:16 amI'm a bit concerned with the amount of effort being made to make it super easy to register. Yes, mass adoption is great, but this is a great product that people will jump through a few hoops to join. How easy is it to get an E*Trade account?The mass adoption of bitUSD and the consumer side of things (vs the trader) is a different story with different front ends. The consumer user of bitUSD shouldn't even need to know about, let alone understand, the underlying mechanisms.How many card carrying customers of Visa and Mastercard have even the slightest idea how the back end works?Good point... I think that charging $5 to register an account will end the "spam" and give them greater value. Delegates and services that facilitate brining on legitimate new users can pay that "fee" on behalf of the user and then get reimbursed by delegates. It would end "spam" "self-registration" but otherwise be the same cost to the DAC....
Quote from: bytemaster on November 07, 2014, 05:20:50 amQuote from: MeTHoDx on November 07, 2014, 05:13:34 amQuote from: gamey on November 07, 2014, 05:07:41 amUhh we need it as easy as possible when you are aiming for people to adopt this for everyday use. People hire fulltime employees just to optimize webpages and bounce rates. The more difficult you make getting an account, the more likely people are to bounce before buying funds.Honestly I don't think people need usernames etc when doing this sort of mass adoption. It was a neat feature for crypto geeks, but as time goes on it is less appealing to me from an investor's perspective. Yeah, the drawbacks seem to be way more than the value it adds. Can usernames be made optional? If a user could send BTS to an ugly hash address and THEN register, that would be ideal. Whatever the system, it has to be dead simple or conversion will massively suck.You can send funds to an ugly hash address. But the goal is to eliminate that from the user experience. We also want to eliminate delays.My conclusion is that users will almost always be brought in via a helper service and that this thread was mostly to get the idea out of my head and discarded as well as spur ideas on how to make it easier for people to get into BTS.So I guess the trick would be incentivising helper services in some way.
Quote from: MeTHoDx on November 07, 2014, 05:13:34 amQuote from: gamey on November 07, 2014, 05:07:41 amUhh we need it as easy as possible when you are aiming for people to adopt this for everyday use. People hire fulltime employees just to optimize webpages and bounce rates. The more difficult you make getting an account, the more likely people are to bounce before buying funds.Honestly I don't think people need usernames etc when doing this sort of mass adoption. It was a neat feature for crypto geeks, but as time goes on it is less appealing to me from an investor's perspective. Yeah, the drawbacks seem to be way more than the value it adds. Can usernames be made optional? If a user could send BTS to an ugly hash address and THEN register, that would be ideal. Whatever the system, it has to be dead simple or conversion will massively suck.You can send funds to an ugly hash address. But the goal is to eliminate that from the user experience. We also want to eliminate delays.My conclusion is that users will almost always be brought in via a helper service and that this thread was mostly to get the idea out of my head and discarded as well as spur ideas on how to make it easier for people to get into BTS.
Quote from: gamey on November 07, 2014, 05:07:41 amUhh we need it as easy as possible when you are aiming for people to adopt this for everyday use. People hire fulltime employees just to optimize webpages and bounce rates. The more difficult you make getting an account, the more likely people are to bounce before buying funds.Honestly I don't think people need usernames etc when doing this sort of mass adoption. It was a neat feature for crypto geeks, but as time goes on it is less appealing to me from an investor's perspective. Yeah, the drawbacks seem to be way more than the value it adds. Can usernames be made optional? If a user could send BTS to an ugly hash address and THEN register, that would be ideal. Whatever the system, it has to be dead simple or conversion will massively suck.
Uhh we need it as easy as possible when you are aiming for people to adopt this for everyday use. People hire fulltime employees just to optimize webpages and bounce rates. The more difficult you make getting an account, the more likely people are to bounce before buying funds.Honestly I don't think people need usernames etc when doing this sort of mass adoption. It was a neat feature for crypto geeks, but as time goes on it is less appealing to me from an investor's perspective.
Or if they have BTS on the exchanges, they can just withdraw the money to their BTS Active key directly (have BTER and BTC38 enabled this functionality yet btw?).
So I guess the trick would be incentivising helper services in some way.
My problem with using POW is that I expect 90%+ users will be interfacing with the blockchain through mobile devices. If a viable solution cannot be found, I propose TITAN be removed as default. It seems to prevent adoption rather than promote it...
Can usernames be made optional? If a user could send BTS to an ugly hash address and THEN register, that would be ideal. Whatever the system, it has to be dead simple or conversion will massively suck.
It currently isn't that easy to get an account at a traditional bank. Even Paypal and Coinbase have you jump through a few hoops. I don't think we need to be THAT slick if we're offering a good product.I like the idea of some sort of challenge/response mechanism; just enough to make it hard to automate spam accounts. Will have to think about how to do that in a decentralized way.
Quote from: Thom on November 07, 2014, 04:28:32 amI'm totally confused by this thread. Why "waste" anything to register new users? It seems totally counter intuitive since the point of BitShares is to eliminate waste. Fine, so that refers to mining waste but I'm totally confused why people just don't buy their account registration for what you seem to be saying here is only a few pennies anyway.I feel like I'm missing something fundamental (yet again). Someone care to pls explain?How could we allow people to register names without going through a central service like a faucet or forum?And how do we prevent spam accounts?
I'm totally confused by this thread. Why "waste" anything to register new users? It seems totally counter intuitive since the point of BitShares is to eliminate waste. Fine, so that refers to mining waste but I'm totally confused why people just don't buy their account registration for what you seem to be saying here is only a few pennies anyway.I feel like I'm missing something fundamental (yet again). Someone care to pls explain?
Quote from: roadkill on November 07, 2014, 04:27:28 amQuote from: gamey on November 07, 2014, 04:20:10 amI guess captcha's don't work because the entropy source would be the blockchain and thus someone could hack around it and spam the network ?If delegates can be trusted to generate captchas, we could do cool things like adjusting captcha difficulty based on velocity of registrations. But that could be also done with the POW approach.This is very smart (using delegates to register users).
Quote from: gamey on November 07, 2014, 04:20:10 amI guess captcha's don't work because the entropy source would be the blockchain and thus someone could hack around it and spam the network ?If delegates can be trusted to generate captchas, we could do cool things like adjusting captcha difficulty based on velocity of registrations. But that could be also done with the POW approach.
I guess captcha's don't work because the entropy source would be the blockchain and thus someone could hack around it and spam the network ?
Not sure if this would be sufficient to prevent an attacker with existing idle hardware from bloating the blockchain at no cost...
Quote from: roadkill on November 07, 2014, 04:05:51 amSounds like a hack though. What if the registration fee was 5 BTSX?Delegates could set the proof of waste like they set fees.
Sounds like a hack though. What if the registration fee was 5 BTSX?