Регистрация путём указания аккаунта без ключа регистратора

[denis-skripnik]

В настоящее время для регистрации аккаунта необходимо ввести не только логин, пароль нового аккаунта и логин регистратора (существующего пользователя), но и его пароль. А это плохо.

Текущий метод для создания систем регистрации требует хранения активного ключа на сервере, что не есть хорошо, либо ручной регистрации.

Предложение:

1. Пользователь вводит свой логин и пароль, а также логин регистратора (Либо логин вводит сайт), пишет о себе;
2. Регистратор получает в свой аккаунт транзакцию, которую необходимо подписать. Схема та же, как в мультисигах. Отличие лишь в том, что подпись делает 1 аккаунт, а запрашивает другой, и первый имеет 100% вес в транзакции.
3. Далее регистратор вводит свой логин, логин реферала и свой активный ключ, после чего регистрация проходит. "под капотом" отправляется транзакция с логином и активным ключём реферера, а также с операцией вида:
   [["registration",{"registrator":"your_login","referal":"new_user"}]]
   (На подобии формы для мультисига от @VIKXX). Только она должна ещё содержать подпись, которую будущий аккаунт восстановления получит в уведомлении о запросе на подпись, т.е. регистрацию.

Надеюсь, понятно описал. Если это возможно, было бы очень удобно. А в силу того, что планируется реферальная система данный вопрос считаю (Вопрос лёгкой регистрации новых аккаунтов без хранения ключей на сервере или ручной регистрации) наиболее актуальным.

Благодарю за внимание. Будет интересно узнать мнение. Может есть какие-то уязвимости в данном типе регистрации: в этом не разбираюсь.

[afalaleev]

Какой именно пользователь отправляет транзакцию в чейн?

Сейчас есть в чейне есть пропозалы - можно создать транзакцию с операцией, запушить ее в чейн, и ждать пока она будет подписана.
Это может сделать реферрер.
Но запушить в чейн транзакцию от неизвестного пользователя - это никак не сделать, нужна идентификация того, кто это сделал.

[denis-skripnik]

@afalaleev, есть 2 варианта:

1. Анонимный пользователь с логином, например, free и паролем, состоящим из нулей.
   Он должен быть только для выполнения запросных транзакций;
2. Специальный ключ, который можно светить, так как он будет только для регистрации аккаунта (Другие транзакции с его помощью не отправить).

P. S. пропозалы - хорошая идея реализовать с их помощью.

[afalaleev]

Если это ключ доступный всем, то это ломает идеологию блокчейна - доверия в недоверенной сети.

Я не до конца понимаю, что хочется сделать

• чем плох внешний для БЧ интерфейс?
• в чем именно заключается роль БЧ в схеме, когда анонимная недоверенная информация в нем сохраняется?
• откуда возьмется уведомление о восстановлении аккаунта, если у БЧ нет механизма взаимодействия с внешним миром?
• это резервирование аккаунта?

[denis-skripnik]

@afalaleev, постараюсь объяснить.

Сейчас для регистрации аккаунта необходимо вводить активный ключ регистратора и данные нового аккаунта самостоятельно, либо хранить ключ регистратора на сервере, что не очень хорошо.

Оба случая очень неудобны, если есть необходимость делать приложение без возможного риска получения важного ключа аккаунта регистратора.

Суть в том, чтобы не было необходимости сохранять ключи на сервере либо вводить их вручную на странице, типа https://golos.cf/reg/

Представьте, что можно было бы сохранить в переменной скрипта ключ, который бы позволял только отправлять заявки на регистрацию в блокчейн, удалив поле активного ключа из формы выше.

Ключ позволяет только подавать заявки, а уже регистратор подписывает их или не подписывает активным ключом. Если подпись есть, токены снимаются и аккаунт регистрируется. Если нет - не регистрируется.

Проблемы в том, что этот ключ будет засвечен в коде скрипта, не вижу, так как он будет иметь ограниченные возможности, которые не требуют доверия.

Хотя, сейчас подумал, что таким образом можно спамить заявками на регистрацию. Если эта проблема есть, то предложение было неудачным.

[gropox]

Да, как раз это и есть, что доступный всем аккаунт - дырка в блокчейне. Все таки он не бесплатный, как может показаться. Как минимум делегаты тратят средства на подписание блоков.

Лучше сделать систему инвайтов. Пользователь в специальной форме, своим ключем генерит пропозал на регистрацию аккаунта, пользователь по ссылке приходит, вводит имя и пароль, а регистратор подтверждает пропозал.

А регистратора сделать не так уж и трудно, нужен конечно ключ, но это в любом случае, кто то должен оплатить создание аккаунта, как миниум 0.03 GOLOS + 0.125 GOLOS делегировав.

[denis-skripnik]

@gropox

Да, как раз это и есть, что доступный всем аккаунт - дырка в блокчейне. Все таки он не бесплатный, как может показаться. Как минимум делегаты тратят средства на подписание блоков.

Вот про это я и подумал, когда писал последний комментарий.

Лучше сделать систему инвайтов. Пользователь в специальной форме, своим ключем генерит пропозал на регистрацию аккаунта, пользователь по ссылке приходит, вводит имя и пароль, а регистратор подтверждает пропозал.

Отличный вариант. Мне нравится.

А регистратора сделать не так уж и трудно, нужен конечно ключ, но это в любом случае, кто то должен оплатить создание аккаунта, как миниум 0.03 GOLOS + 0.125 GOLOS делегировав.

Про то, что нужно, чтоб кто-то оплачивал, знаю. Суть была в том, чтобы регистратор сам не регистрировал аккаунты, а давал возможность пользователям подать заявку. Ваш вариант, повторюсь, нравится.

[litrbooh]

@gropox , ты не поверишь!

Я уже полгода назад предлагал golosio решить проблему регистрации через введение инвайт ссылок, тогда они сказали - о круто, у нас почти готово решение. Но, решение до сих пор не родилось. Интересно почему, @jevgenika ?

[jevgenika]

@gropox хорошее предложение
@litrbooh backend и frontend сервиса регистрации новых пользователей готов и тестируется https://github.com/GolosChain/registration-service