Bitcoin Forum
November 06, 2024, 12:08:35 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
Author Topic: Вам не надоели длинные крипто кошельки?  (Read 20551 times)
Anatoll
Member
**
Offline Offline

Activity: 672
Merit: 25


View Profile
November 04, 2019, 03:13:57 PM
 #181

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

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

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

Тут конечно не поспоришь, короткий кошелек тут более подошёл бы!
Malenkov
Newbie
*
Offline Offline

Activity: 154
Merit: 0


View Profile
November 04, 2019, 08:36:12 PM
 #182

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

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

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

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

Activity: 378
Merit: 252


View Profile
November 05, 2019, 01:03:37 AM
 #183

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

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

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

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

Ошибка в одном символе черевата полной потери средства поэтому такое совсем не подходит увы.
ИДея с короткими кошельками очень хорошая не понимаю почему не одна из монет это еще не релазиовала как я выше писал, что-то на уровне алиасов.
Но ребята из TON писали в доках, что будет что-то подобное мб не совсем сокращеные но меньше обычных
Malenkov
Newbie
*
Offline Offline

Activity: 154
Merit: 0


View Profile
November 05, 2019, 11:47:32 AM
 #184



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

Ошибка в одном символе черевата полной потери средства поэтому такое совсем не подходит увы.
ИДея с короткими кошельками очень хорошая не понимаю почему не одна из монет это еще не релазиовала как я выше писал, что-то на уровне алиасов.
Но ребята из TON писали в доках, что будет что-то подобное мб не совсем сокращеные но меньше обычных
Конечно, было бы не плохо  если бы  хотя бы в 2 раза сократили... Может технически кошельки запрограммированы на большое количество символов? И изменить сложно.
Но ребята с тон много чего пишут, но не всегда исполняют...
vromaniuk277
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile WWW
March 27, 2020, 11:32:06 PM
 #185

Я тоже задумывался над этим, но для таких целей и существуют ранее созданые электронные кошельки. Задача сети биткоин - анонимность и банальность переводвода средств, а за анонимность и отвечает сгенерированый адрес кошелька. Как то так Roll Eyes
Jes861ter
Jr. Member
*
Offline Offline

Activity: 224
Merit: 2


View Profile
March 29, 2020, 07:34:45 AM
 #186

Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Это ведь все часть безопасности. Так что нет, не надоели
PavelMed
Full Member
***
Offline Offline

Activity: 560
Merit: 106


View Profile WWW
May 02, 2020, 02:46:25 PM
 #187

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

▶▶  BTCitcoin 2  ◀◀    Scalable Bitcoin Fork with instant verified payments
██████████████████████████████
Low Fees! Truly Anonymous Transactions Join the discussion thread
escapefrom3dom
Sr. Member
****
Offline Offline

Activity: 1932
Merit: 288



View Profile
May 17, 2020, 05:22:51 PM
 #188

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

Уже решено, например, в Pascal: простые адреса (12345) и не обязательно тянуть всю историю транзакций.

#Cryptoman
Member
**
Offline Offline

Activity: 980
Merit: 48


View Profile
July 22, 2020, 08:54:23 AM
 #189

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

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


https://indx.ru криптобиржа от вебмоней, не воруют, не требуют доказательств происхождения средств.
Xhoshida
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
July 22, 2020, 01:09:07 PM
 #190

Да,надоело,вот бы их можно было бы сокращать,например как ссылки Cheesy
Dadasso
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
July 23, 2020, 12:47:22 PM
 #191

Короткий кошель это конечно хорошо,но мне кажется не так безопасно
Matiss
Copper Member
Jr. Member
*
Offline Offline

Activity: 203
Merit: 3


View Profile
July 30, 2020, 07:30:23 AM
 #192

Наличие длинного сложного адреса на который мы отправляем деньги - это залог безопасности и надежности, да, это бывает немного не очень удобно, но зато надежно. Короткие адреса, или любые способы которыми можно будет привязать такой адрес к телефону ли или еще чему-то - это посредники которые удлиняют схему и делают ее менее безопасной.
gsandrs
Jr. Member
*
Offline Offline

Activity: 41
Merit: 3


View Profile
July 31, 2020, 11:55:47 AM
 #193

Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Интересная мысль. Мне по аналогии напомнила с адресами сайтов, ведь когда мы вводим в адресную строку к примеру ютуб.сом то этот адрес из букв имеет ip адрес из цифр к примеру 5.5.101.28 согласитесь легче запомнить буквы чем такой набор цифр, это днс адреса.
escapefrom3dom
Sr. Member
****
Offline Offline

Activity: 1932
Merit: 288



View Profile
August 05, 2020, 07:08:32 AM
 #194

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

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

Уже давно существуют сервисы сопоставления адресов кошельков (BTC, ETH) и их коротких текстовых представлений (аналог DNS). Проблема в том, что необходимо еще обеспечить надежность таких сервисов.

crypto_trader#43xzEXrP
Full Member
***
Offline Offline

Activity: 1588
Merit: 214


View Profile
August 09, 2020, 03:16:36 PM
 #195

Вообще, в чём проблема сделать нечто вроде 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 от временного адреса, для переговоров созданного,
можно отправить васяну, не светя контактные данные - спамерам.

STOP RUSSIAN INVASION OF UKRAINE - SUPPORT UKRAINIAN DEMOS
Contact me in TOX: 653D6C2D13B6DF22C4CB93432586398858A608EE5457624A9A728BE1A9252C5DA12B894C54DB, or just crypto-trader@toxme.io.
Also, WAVES - SCAM! ;(
escapefrom3dom
Sr. Member
****
Offline Offline

Activity: 1932
Merit: 288



View Profile
September 02, 2020, 10:21:13 AM
 #196

Вообще, в чём проблема сделать нечто вроде DNS-сервиса для адресов?

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

Лучше чтобы сопоставление никнейм/адрес было тоже в блокчейне и желательно – в том самом, где существуют адреса.

nrgmanuk
Jr. Member
*
Offline Offline

Activity: 200
Merit: 1


View Profile
September 02, 2020, 01:00:33 PM
 #197

Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Это ведь все часть безопасности. Так что нет, не надоели
Понятно, что безопасность, но это все-таки не отменяет неудобства.
johhnyUA
Legendary
*
Offline Offline

Activity: 2436
Merit: 1849


Crypto for the Crypto Throne!


View Profile
September 04, 2020, 02:25:50 PM
 #198

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

Потребует слишком большого изменения в коде многих приложений, того же Электрума. По стандарту значение введеное в поле "send to" используется для формирования транзакции (вап вап вап) и прописывается в sciptpubkey транзакции. Так что это придется делать так, чтобы при введении ника, условный Электрум различал эту разницу (между адресом и ником), делал get запрос на твой сервер, получал оттуда уже адрес и использовал его для формирования транзакции далее.

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

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

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
KpoJluk
Jr. Member
*
Offline Offline

Activity: 154
Merit: 6


View Profile
September 11, 2020, 02:21:08 PM
 #199

Недавно посетила мысль: как же неудобно отправлять крипту на эти длинные 34(42)-ух значные кошельки. Представьте, что вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона. Ваш знакомый просто сообщает вам почту или номер телефона и вы переводите ему битки или эфир, например. Какие условия подобного сервиса вас бы удовлетворили?
Это уже уход обратно в централизацию. Это все равно какой-то сервер должен будет хранить метаданные с этими длинными адресами и сокращенными "ссылками"
Alex-70
Member
**
Offline Offline

Activity: 191
Merit: 10


View Profile WWW
October 14, 2020, 01:13:19 PM
 #200

вы должны какую-то сумму своему знакомому, но он не помнит номер своего 34(42)-ух значного кошелька, но зато он прекрасно помнит свою почту или номер телефона
А нахрена этому знакомому перевод на кошелёк, который он не помнит?
Если человек не помнит публичный адрес, то он всегда может его воспроизвести из приватного ключа.
А если он забыл приватный ключ, то как он будет использовать средства?

Приглашаю получить бонус и протестировать биржу обмена BTC⇔Рубль. Ссылка в профиле.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!