Pages:
Author

Topic: Вам не надоели длинные крипто кошельки? - page 3. (Read 20492 times)

jr. member
Activity: 200
Merit: 1
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Это ведь все часть безопасности. Так что нет, не надоели
Понятно, что безопасность, но это все-таки не отменяет неудобства.
sr. member
Activity: 1932
Merit: 288
Вообще, в чём проблема сделать нечто вроде DNS-сервиса для адресов?

Для этого достаточно поднять лишь один сервер, с одной лишь табличкой в базе данных.

Лучше чтобы сопоставление никнейм/адрес было тоже в блокчейне и желательно – в том самом, где существуют адреса.
full member
Activity: 1589
Merit: 214
Вообще, в чём проблема сделать нечто вроде DNS-сервиса для адресов?

Для этого достаточно поднять лишь один сервер, с одной лишь табличкой в базе данных.

Регистрация - простая.
1. Вводим никнейм. При этом, он проверяется на уникальность, через поиск по табличке.
2. Сервер генерирует некое значение, в виде байт или строки, и отправляет его клиенту.
3. Клиент - принимает это значение, и подписывает его, приватным ключём, добавляя к нему - цифровую подпись свою
4. После этого, клиент, отправляет подписанное сообщение с этим значением и подписью цифровой - назад, на сервер.
5. Сервер, берёт подписанное сообщение, проверяет цифровую подпись,
сравнивает значение отправленное клиенту со значением в подписанном сообщении,
берёт адрес клиента после проверки подписи получаемый,
самим фактом успешной проверки цифровой подписи, сервер убеждается в том,
что у клиента есть приватный ключ от этого адреса,
и дальше уже, сервер, просто ассоциирует, в табличке своей базы данных - никнейм и адрес клиента,
и пишет пару этих значений, с свою базу данных.
6. В итоге, на сервере, в табличке базы данных - появляется записанная пара значений: никнейм <-> адрес.
7. Сервер, может резолвить никнейм в адрес, и наоборот (правда, какой в этом смысл - хз).

Дальше... Один сервер - он может упасть, его могут задудосить нахуй, его могут поломать и конфисковать...
Так а почему бы не наделать - хуеву кучу серверов, чтобы они работали децентрализированно?
Тогда, надо базу данных как-то синхронизировать, с этой табличкой, ебучей.
И как же, как-же, всю эту хуйню разрулить?
А можно тупо взять, и записать эту табличку - прямо в бЛОХчейн!
Для этого, достаточно отправить пару транз, с фрагментами таблички, в качестве примечания к транзакциям этим.
И добавлять записи туда, можно с сервера, транзакциями с адреса сервера,
и можно вытягивать их, эти записи, из разных мест, прямо из блокчейна, децентрализированно,
парся последовательно все исходящие транзакции с адреса сервера, содержащие данные в примечании к ним.
И снова собирать эту табличку в базе данных, можно, после этого вот - парсинга блокчейна,
и собирать её можно - на куче других, таких же серверов.

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

Очевидно, что в таком случае, перед резолвингом, сервером, никнейма в адрес,
в самом запросе, клиентом, придётся указать и адрес "доверенного сервера", или же его никнейм/доменное имя...
Что-то наподобие ToxDNS.
Хотя, и так очевидно, что если запрос отправляется клиентом, на сервер, то клиент уже знает адрес сервера.
Но дело не в этом, дело в том, что адреса могут быть разные, и ответы, соответственно - тоже разные.
А, поскольку, таких, "доверенных серверов", может быть куча,
то и количество разных юзеров с одним и тем же никнеймом, тоже может быть - куча.

Поэтому, не смотря на то, что принцип регистрации никнейма, и взаимосвязи его с адресом, описан, и он прост,
можно попросту исключить возможность регистрации никнеймов - другими серверами,
позволив им, лишь вытаскивать данные из блокчейна, и резолвить имена, но не регистрировать никнеймы юзеров.
Тогда, регистрировать никнеймы юзеров, и взаимосвязывать их с адресами, сможет лишь самый первый сервер, а другие сервера - нет.
Однако, опять же, один сервер, может просто упасть, нахуй и всё...
Как тогда быть?

Тогда, можно сделать нечто вроде лицензированной регистрации.
При этом, лицензией, может являться, опять же - старая добрая, цифровая подпись.
Есть подпись - есть лицензия. Нет подписи - нет лицензии, и всё на этом.
Тогда, чтобы другой какой-то сервер мог регистрировать никнеймы клиентов, и взаимосвязывать их с их адресами,
он должен быть:
во-первых, сам зарегистрирован, иметь никнейм и адрес.
во-вторых, он должен будет - принять транзакцию от адреса сервера "с лицензией на регистрацию",
содержащую цифровую подпись приватным ключём сервера.

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

Все другие "лицензированные для регистрации" сервера, перед регистрацией нового клиента,
смотрят в каждом конкретном новом блоке блокчейна,
транзакции на все другие "лицензированные для регистрации" сервера
(ну, мол, не существует ли уже, там, введённый клиентом никнейм?),
и если существует - то он не уникален, регистрация отклонена.
Если не существует, то уникален, регистрация проходит,
но локально, на "лицензированном для регистрации сервере".
При этом, пара значений "никнейм - адрес", пишется лишь локально, в локальную базу,
на этом сервере, а не в блокчейн.
Чтобы для каждого новозарегистрированного клиента, не делать по одной транзакции.
Транзакции с фрагментами базы данных, отправляются только когда клиентов уже зареглено дофига,
скажем, 100 клиентов, 200, 1000, вот тогда транза в блокчейн пиздует, и там уже увековечивается так.
Пока не набралась куча клиентов, сервер, вместо того, чтобы засирать блокчейн транзами,
может просто приконнектится к другим "лицензированным для регистрации" серверам,
и подслить им свою, неполную базу данных, чтобы она обновилась там.
Но поскольку сеть из этих серверов, она может быть децентрализирована,
и они могут, фактически находится в разных, невзаимосвязанных подсетях,
и связи с ними может и вовсе не быть,
то тогда, здесь, в этом случае, возможно наличие одновременных регистраций,
на разных, не связанных между собой, "лицензированных для регистрации" серверах,
и существование в их, локальных базах данных - одинаковых никнеймов, с разными адресами.

И чё с этого? А ничё страшного. Значит, надо, просто прождать пока наберётся куча клиентов,
пока серв скинет кусок своей базы в блокчейн, как примечание к транзе,
и конечно же - подождать пока наберутся подтверждения этой транзы!

Но... Что если два "лицензированных для регистрации" сервера,
которые содержат в своих локальных базах, одинаковый никнейм с двумя разными адресами,
одновременно сольют фрагменты своих баз в виде примечаний к двум разным транзам,
которые попадут в один и тот же блок?
А тогда... Тогда, надо как-то продискриминировать их, блядь,
и заорфанить одну из транз, при парсинге блоков блокчейна всеми другими серверами,
как "лицензированными для регистрации", так и серверами,
которые не могут регистрировать, а только резолвить могут никнеймы - в адреса.

Как же как же, продискриминировать эти ебучие транзы?
Ну, по времени транзакции, например - мол, у кого микросекунды пижже, тот и заебат.
Или по количеству записей во фрагменте сливаемой базы - мол, у кого их больше, того транзу не орфанить.
Или же, в конце концов, лицензирующий сервер,
или тот, кто был им лицензирован первее, но доступен сейчас, и на связи,
может принять решение, мол чья транза заебата, а чья - нет, и подписать это решение подписью цифровой,
и сунуть его в качестве примечания к транзе со своего адреса.
А сервер, который был лицензирован раньше этого лицензированного сервера, в том числе и самый первый сервер,
может изменить это решение, приняв своё решение, и тоже подписав его и сунув его,
в примечании к транзакции, но уже на свой адрес.

Ну и... В конце концов... Перед сливом части базы в примечании к транзе, можно просто проверить мемпул,
взять хэши raw-транзакций из мемпула, и сделать decoderawtransaction,
и там уже, в декодированном JSON'е, глянуть нет ли транзы с другого сервера,
и если она есть - декодировать примечание, проверить никнеймы,
и если один из них есть, то существует конфликт - транзу не отправлять,
регистрацию этого клиента отменить, базу пересобрать, и снова - транзой переслить...

Как-то так, вся эта херня, могла бы позволить вести пиздатую базу,
из одной таблички состоящую, и содержащую в себе значения:
"nickname,address;nickname2,address", где никнеймы - обязательно уникальны, а адреса - могут быть дублями.
А вся эта децентрализированная система из серверов состоящая,
позволяла бы платить прямо на никнеймы, резолвя их в адреса,
без необходимости запоминать сабж - надоевшие длинные крипто-кошельки.

Я намеренно написал здесь про возможность существования дублей адресов,
потому что у меня вертелась на уме другая трабла.
Что если никнейм, введённый клиентом, при регистрации, он уникален, но введён некорректно?
Надо же его перерегистрировать, да?
А нафига, пусть будет два никнейма, ёпрст.
Повторная регистрация с валидным никнеймом - решает проблему, ИМХО.
Хотя, такое решение и засирает блохчейн.
И чтобы бЛОХчейн не засирался, пока клиент зарегистрирован локально, и пока его записи не скинуты в блокчейн,
он мог бы, на сервере, его зарегистрировавшем, просто удалить, нахрен, невалидную запись этого рукожопого клиента,
пока одминчег сервера не забанил его, за высочайший уровень рукожопости, потому что руки из жопы растут.

Ещё одна проблема... Рандомный васян из хуйнадцатого переулка, улицы Пушкина, где Дом Калатушкина,
регистрирует никнейм, вроде Microsoft, Apple, Amazon, Google. А они, потом - не может зарегаться, лол.
Тогда, что делать?
Можно было бы отобрать имя, подписав регистрирующим сервером - отвену регистрации...
Но... Так не честно, и это может открывать пути для манипуляций "регистрациями" и отменой регистрациий...

Тогда... Можно выкупить имя!
Смотрите, короче...
Пусть некий Васян, чисто по приколу, зарегал себе Google, увязал на свой адрес, и сидит и ржёт.
Гугл - пытается зарегаться, а нельзя, там Васяна адрес уже завязан.
Гугл, конечно же, может сделать форк блокчейна, лол...
Но, гугл умнее, и короче, и попросту пишет регистрирующему серверу,
мол так и так, не могу зарегаться, какой-то Васян занял имя.
Регистрирующий сервер, пишет Васяну, и предлагает сделку.
Если васян неактивен, и не отвечает, то сервер просто аннулирует его регу,
временно, пока Васян не обратится к нему, мол чё за херня?..

Казалось бы, как по блокчейну можно связаться с адресами?
Ну, во-первых, можно отправить транзакцию с примечанием, и контактные данные там.
А можно, прямо в кошеле написать владельцу адреса, через smsg-методы в консоли:
https://trezarcoin.com/trezarcoin-2-0/ - раздел TrezarMessage.
Только надо publicKey ещё, чтобы эти сообщения всплывали в кошельке.
PublicKey от временного адреса, для переговоров созданного,
можно отправить васяну, не светя контактные данные - спамерам.
sr. member
Activity: 1932
Merit: 288
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?

Интересная мысль. Мне по аналогии напомнила с адресами сайтов, ведь когда мы вводим в адресную строку к примеру ютуб.сом то этот адрес из букв имеет ip адрес из цифр к примеру 5.5.101.28 согласитесь легче запомнить буквы чем такой набор цифр, это днс адреса.

Уже давно существуют сервисы сопоставления адресов кошельков (BTC, ETH) и их коротких текстовых представлений (аналог DNS). Проблема в том, что необходимо еще обеспечить надежность таких сервисов.
jr. member
Activity: 41
Merit: 3
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Интересная мысль. Мне по аналогии напомнила с адресами сайтов, ведь когда мы вводим в адресную строку к примеру ютуб.сом то этот адрес из букв имеет ip адрес из цифр к примеру 5.5.101.28 согласитесь легче запомнить буквы чем такой набор цифр, это днс адреса.
copper member
Activity: 203
Merit: 3
Наличие длинного сложного адреса на который мы отправляем деньги - это залог безопасности и надежности, да, это бывает немного не очень удобно, но зато надежно. Короткие адреса, или любые способы которыми можно будет привязать такой адрес к телефону ли или еще чему-то - это посредники которые удлиняют схему и делают ее менее безопасной.
newbie
Activity: 33
Merit: 0
Короткий кошель это конечно хорошо,но мне кажется не так безопасно
newbie
Activity: 33
Merit: 0
Да,надоело,вот бы их можно было бы сокращать,например как ссылки Cheesy
member
Activity: 980
Merit: 48
то можно спокойно написать в тетрадь и длинный кошелек, просто используя линеечку Smiley А если серьезно,  то длинные кошельки сложно(практически не реально) хранить в памяти, слишком много перемешано символов и цифр.

А почему в тетрадь? Отправь номера себе на почту. А потом это перенаправь своим друзьям или еще кому.
Сейчас у каждого смартфон, зачем вообще что-либо записывать в тетрадки авторучками?
Создай текстовый файл, и запиши(скопипасть) там все.

sr. member
Activity: 1932
Merit: 288
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?

Уже решено, например, в Pascal: простые адреса (12345) и не обязательно тянуть всю историю транзакций.
full member
Activity: 560
Merit: 106
Я тоже задумывался над этим, но для таких целей и существуют ранее созданые электронные кошельки. Задача сети биткоин - анонимность и банальность переводвода средств, а за анонимность и отвечает сгенерированый адрес кошелька. Как то так Roll Eyes
Если можно чуть подробней про банальность. Анонимность -понятно, а что такое банальность? простота в смысле?
jr. member
Activity: 224
Merit: 2
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Это ведь все часть безопасности. Так что нет, не надоели
newbie
Activity: 42
Merit: 0
Я тоже задумывался над этим, но для таких целей и существуют ранее созданые электронные кошельки. Задача сети биткоин - анонимность и банальность переводвода средств, а за анонимность и отвечает сгенерированый адрес кошелька. Как то так Roll Eyes
newbie
Activity: 154
Merit: 0


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

Ошибка в одном символе черевата полной потери средства поэтому такое совсем не подходит увы.
ИДея с короткими кошельками очень хорошая не понимаю почему не одна из монет это еще не релазиовала как я выше писал, что-то на уровне алиасов.
Но ребята из TON писали в доках, что будет что-то подобное мб не совсем сокращеные но меньше обычных
Конечно, было бы не плохо  если бы  хотя бы в 2 раза сократили... Может технически кошельки запрограммированы на большое количество символов? И изменить сложно.
Но ребята с тон много чего пишут, но не всегда исполняют...
sr. member
Activity: 378
Merit: 252
Так как пока ещё не придумали более коротких крипто кошельков то приходится пользоваться такими,в принципе мне  это не доставляет сильных хлопот но хотелось бы что бы кошельки были более удобными и безопасными.

Длинна кошелька не составляет ни каких трудностей, ведь мы их вводим не ручками, а копипастом!  Grin

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

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

Ошибка в одном символе черевата полной потери средства поэтому такое совсем не подходит увы.
ИДея с короткими кошельками очень хорошая не понимаю почему не одна из монет это еще не релазиовала как я выше писал, что-то на уровне алиасов.
Но ребята из TON писали в доках, что будет что-то подобное мб не совсем сокращеные но меньше обычных
newbie
Activity: 154
Merit: 0
Так как пока ещё не придумали более коротких крипто кошельков то приходится пользоваться такими,в принципе мне  это не доставляет сильных хлопот но хотелось бы что бы кошельки были более удобными и безопасными.

Длинна кошелька не составляет ни каких трудностей, ведь мы их вводим не ручками, а копипастом!  Grin

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

Если не лениться, то можно спокойно написать в тетрадь и длинный кошелек, просто используя линеечку Smiley А если серьезно,  то длинные кошельки сложно(практически не реально) хранить в памяти, слишком много перемешано символов и цифр.
member
Activity: 672
Merit: 25
Так как пока ещё не придумали более коротких крипто кошельков то приходится пользоваться такими,в принципе мне  это не доставляет сильных хлопот но хотелось бы что бы кошельки были более удобными и безопасными.

Длинна кошелька не составляет ни каких трудностей, ведь мы их вводим не ручками, а копипастом!  Grin

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

Тут конечно не поспоришь, короткий кошелек тут более подошёл бы!
member
Activity: 546
Merit: 30
Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?

Идея криптовалют и ваше предложение по разную сторону баррикад. Мы жертвуем удобством для получения более справедливой и качественной системы в будущем.
sr. member
Activity: 378
Merit: 252
Так как пока ещё не придумали более коротких крипто кошельков то приходится пользоваться такими,в принципе мне  это не доставляет сильных хлопот но хотелось бы что бы кошельки были более удобными и безопасными.

Длинна кошелька не составляет ни каких трудностей, ведь мы их вводим не ручками, а копипастом!  Grin

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

Да нужно просто реализовать алиаасы и все на многих биржах уже это реализовано ты просто прикручиваешь адрес и потом вписываешь к нему специальный алиас и уже дальше работаешь непосредственно с ним а не с большим адресом но опять же это функционал только внутри биржи а нужно более масштабная реализация
sr. member
Activity: 742
Merit: 250
Так как пока ещё не придумали более коротких крипто кошельков то приходится пользоваться такими,в принципе мне  это не доставляет сильных хлопот но хотелось бы что бы кошельки были более удобными и безопасными.

Длинна кошелька не составляет ни каких трудностей, ведь мы их вводим не ручками, а копипастом!  Grin

Копипастом бывает скопировать не получается с первого раза,поэтому если кошельки были намного короче,то было бы копировать их на много проще,и такие кошельки можно было бы написать в тетрадь,чтобы их там хранить.
Pages:
Jump to: