Author Topic: Using Proof of Waste for Account Registration  (Read 13593 times)

0 Members and 1 Guest are viewing this topic.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
just charge the spammers. the delegates need the fees and maybe we need in the future machine accounts.

i would set up different ways to register

1. pay 5 BTS to register your account
2. take your time and make some chapta or twitter, facebook registration

two simple solutions

Offline Riverhead

A reminder of the dangers of PoW in a client. Clearly not really the same thing but to the law the distinction may not be clear or important.


http://www.wired.com/2014/09/mit-students-face-aggressive-subpoena-demanding-source-code-bitcoin-mining-tool/


TurkeyLeg

  • Guest
For the record - I am not technically savvy regarding most of this stuff...but...I created my E-Trade account in about 10 minutes, it cost me nothing, and it is was very easy to link my fiat checking account and deposit funds...no registration required...similar experience with PayPal...the most time consuming part was verifying my checking account with PayPal and even that was fairly user friendly...I understand there are some technical requirements of the blockchain to ensure security and efficiency...however, we need to keep in mind that account registration needs to be as simple and painless as possible...and as similar to various fiat account creations as possible...if we are interested in attracting the outside world...which we better be.
« Last Edit: November 07, 2014, 01:33:35 pm by TurkeyLeg »

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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.

It is called cutnpaste.  Is RS even compatible with the BTC address styles ?  I thought it was a NXT thing only.

Ok, I get you would prefer having a multi-stage process instead of someone just cutnpasting an "ugly" address.  (To me the whole idea of calling it ugly is LOL)  So we're on different pages.

The whole point of this discussion was about using POW to avoid having to fund accounts to have them registered and what could be done to improve on that.  You've chosen your own little subset.  ok !

Would RS allow us to continue having the same address styles as BTC?  If not then please go back to your drawing board.
I speak for myself and only myself.

Offline bobmaloney

How about requiring a SQRL ID for registration?

It seems to solve many of these issues while helping to jump start SQRL, which walks the user through basic account registration and security setup in a fairly simple way.
"The crows seemed to be calling his name, thought Caw."
- Jack Handey (SNL)

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
Proof of destruction
Proof of hoarding
Proof of rejection
Proof of extravagance
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline alphaBar

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
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.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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.

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.

« Last Edit: November 07, 2014, 08:27:46 am by gamey »
I speak for myself and only myself.

Offline alphaBar

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
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.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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.
« Last Edit: November 07, 2014, 08:12:13 am by gamey »
I speak for myself and only myself.

Offline alphaBar

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
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.

Offline sschechter

  • Sr. Member
  • ****
  • Posts: 380
    • View Profile
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.
BTSX: sschechter
PTS: PvBUyPrDRkJLVXZfvWjdudRtQgv1Fcy5Qe

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

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 ?

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?

I don't disagree.  I would have to think through all the edge cases etc of your idea. 

I would like to migrate from the importance of account names and really really try to migrate towards something that is compatible with a standard bitcoind api.  I don't get all the repercussions involved and I'm sure they're quite challenging or I assume it would have been done.

Account names are something that should be important after people become active users.  They shouldn't be an issue preventing adoption.  :(
I speak for myself and only myself.

Offline joele

  • Sr. Member
  • ****
  • Posts: 467
    • View Profile
Why not lend one account name for new registered user.
This lend account cannot transfer or private key is not viewable unless you pay a fee.