но большинство людей или скажем обычные пользователи используют кошельки и часто на мобильных устройствах, надо чтобы это как то попало туда. Да вот кстати недавно появился keybase и там можно отправлять XLM по логину в keybase, вот только в биткоине кошельков слишком много и согласия между ними не будет
Так можно какую-нибудь веб-морду запилить, аля "frontend",
и через API дёргать блок-эксплорер, отправляя и принимая данные в JSON.
Что-то вроде веб-кошелька, только с именами, вместо адресов.
Подисывать тоже можно локально, client-side.
Многие тилибоны могут в JavaScript же.
По сути, никаких проблем с длиной кошельков лично у меня не возникает. Как правило, эти кошельки постоянно новые и генерируются автоматически системой, смотря куда делать депозит. Если я пользуюсь одним кошельком долгое время, то я просто запоминаю несколько первых символов и парочку в конце.
Они не всегда генерируются, адреса эти.
В том же web-кошельке:
https://login.blockchain.com/#/loginПосле импорта privkey в аккаунт, и перевода биткоинов, сдача - падает на предыдущий адрес, privkey от которого указан.
И ничего не перегенерируется.
Можно конечно указать другой адрес для получения сдачи, но это уже в настройках.
И если адрес используется один, ключ от которого импортирован, и находится у владельца адреса,
то и ник легкозапоминающийся, можно было бы привязать к этому адресу - один.
А так-то, ясен пень, что если адреса будут генерироваться рандомно,
как в Bitcoin Core,
где сдача каждый раз переводится на новосгенерированный адрес,
то их дофига будет, адресов этих, и тогда - нет смысла их связывать как-то,
с каким-либо именем, ведь каждое из них, должно быть, тогда - уникальным.
Хотя, наверняка, и при таких раскладах, можно было бы резолвить имена - в адреса,
если использовать -
цепи адресов для генерации,
а легкозапоминающееся имя (ник), ассоциировать - с хэшем от seed'a,
давая возможность юзеру - присвоить целую пачку адресов.
Например, сходим-ка в "
chains -> Electrum".
Вводём туда какой-нибудь seed: "grasp couple awe action silver clean mumble know instead curse approach hero"
И получаем пачку из 10 адресов, ну или 100 даже, 1000.
Дальше, считаем
sha256-хэшот этой seed-фразы "grasp couple awe action silver clean mumble know instead curse approach hero":
b8fcf471d772053ccdc3c9c1563d2e6def6256e51356c688af90647021653dbcПосле чего - ассоциируем "username" и "хэш seed-фразы",
а сам username - подписываем приватным ключём одного из адресов.
Тогда... При указании "username", автоматически мог бы подставляться - самый первый адрес из цепи адресов,
а если указать username15 - то 15-й адрес, если username987 - то 987-й адрес...
Ну ты понел.
Прикол в том, что все эти рассчёты, в процессе генерации адресов - производятся client-side,
и юзеру достаточно запомнить лишь 1 seed и username.
Ну а, поскольку, на сервере, где могло бы связываться легкозапоминающееся имя и адреса,
эти адреса не генерируются, то юзеру достаточно было бы отправить пачку адресов на сервер,
скажем 1000 адресов и всё, и подписать сообщение - одним из них.
Такая шняга не гарантирует фальсификации адресов, но и угрозы никакой не несёт.
Кто будет подставлять чужой адрес региструя его на своё имя, так ведь?
Но для пущей гарантии,
при подвязке имени к пачке адресов,
сервер мог бы запросить цифровую подпись
со всех этих адресов,
или даже цепь из подписей, где одна подпись вложена в другую,
ну чтобы знать наверняка, что приватные ключи от адресов - имеются у пользователя,
который хочет подвязать своё имя на целую пачку адресов.
Также, как вариант, можно было бы просто замкнуть имя пользователя не на хэш от seed-фразы,
а на хэш от пачки адресов, сгенерированных рандомно, и отправленных на сервер в JSON-формате,
и уже после - ассоциировать это имя пользователя с адресами, указанными в этой пачке,
при наличии цепи из подписей, от каждого из адресов.
Таким же образом, можно было бы и изменить ассоциацию,
и даже расширить диапазон адресов, изменить эти адреса,
или же удалить адреса - некорректные.
Например, цепь из вложенных подписей, длиной в 10 адресов,
могла бы отвязать сразу 1000 адресов от имени пользователя, и подвязать другие 1000.
Потому что с большой долей вероятности,
тот, кто держит 10 приватников от подвязанных адресов - является владельцем никнейма,
а не каким-то челом с горы, случайно сгенерировавшим сразу 10 адресов реального владельца никнейма.
Ведь вероятность сгенерировать privkey хотя-бы от одного уже сгенерированного адреса - ничтожно мала,
а от нескольких адресов из цепочки - она ещё меньше.
