Исключение утери монет на плохих адресах

[crypto_trader#43xzEXrP]

Валидным адресом в сети bitcoin и альткоинах, считается любой адрес,
являющиеся просто base58Check encoded - ripemd-160 хэшем.
В том числе и адреса для сжигания монет, которые не имеют приватного ключа.

Консольная команда

validateaddress    <bitcoinaddress>    Return information about <bitcoinaddress>.    N

проверяет лишь контрольную сумму Base58Check.

Однако, на самом-то деле, валидным является адрес,
ripemd-160-хэш от которого является хэшем публичного ключа, соответствующего определённому ключу - приватному.

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

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

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

Однако, любой адрес,
может быть сгенерирован локально, client-side,
и для проведения транзакции на этот адрес,
вовсе не обязательно, чтобы он был каким-то образом - "зарегистрирован" в сети.

Более того, хранить кучу "новосгенерированных пустых адресов", уж тем более в блокчейне - не очень хорошая идея.

Можно было бы получить адрес, хешируя pubkey получателя, а затем, проверить его ripemd-160.
Мол, если у получателя есть pubkey, и его хэш соответствует его адресу, тогда, наверняка, у получателя этого есть и privkey.
Однако, pubkey потому и хэшируется, чтобы его "не светить",
ведь при наличии pubkey, скажем, может быть проведено какое-нибудь,
дискретное логарифмирование на эллиптической кривой в конечном поле,
и получение privkey из pubkey - ага, за триллиард мильярдов лет...

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

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

Ещё варианты?

[kzv]

А что плохого в сжигании монет? Ну кроме того, что UTXO загаживается, чем еще это грозит?

[crypto_trader#43xzEXrP]

А что плохого в сжигании монет? Ну кроме того, что UTXO загаживается, чем еще это грозит?

Да ничего плохого, вообще-то. Я же поэтому и говорю, что отдельный какой-то системный адрес для сжигания,
он имеет право на существование, и должен бы быть прописан в качестве исключения.
Как у эфира, например, это адрес: 0x0000000000000000000000000000000000000000.
Глянь какой там баланс по токенам, в баксах...

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

А вот спонтанное "сжигание" - вполне себе грозит.
Покупаешь какой-нибудь "гелик", а тебе в контракте пишут, переводи давай, на какой-нибудь 1BitcoinEaterAddressDontSendf59kuE,
вот столько-то сот петуховенов, и когда мы их РЕАЛЬНО НЕ ПОЛУЧИМ,
тогда мы вам "гелик", конечно же, закономернейшим образом, втупую - НЕ ДАДИМ, лол.

[kzv]

Если в контракте написано: переводи на этот адрес и получишь тачку, то если будет транзакция на этот адрес - покупатель требование контракта выполнил. Каким образом продаван будет доставать бабло с этого адреса -  никого не ебет. Не будет продаван исполнять условие договора, получит иск в суд и заплатит в итоге раза в три больше.

[crypto_trader#43xzEXrP]

Если в контракте написано: переводи на этот адрес и получишь тачку, то если будет транзакция на этот адрес - покупатель требование контракта выполнил. Каким образом продаван будет доставать бабло с этого адреса -  никого не ебет. Не будет продаван исполнять условие договора, получит иск в суд и заплатит в итоге раза в три больше.

А продаван тебе скажет, контракт электронный, и в процессе MITM-атаки данные были искажены злоумышленниками.
Компания/корпорация не получила баблос, а ты дурашка, адрес не проверил и слился.
И хрен что ты докажешь им, потом.

И вообще, там может быть так написано, что ты даже не поймёшь.
Например,

Компания гарантирует выдачу тачилы, когда получит она получит бабки. Адрес компании на отдельном листе контракта.

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

[kzv]

Если продаван имеет намерение наебать с контрактом, а лох этого не заметил, то уж защита от сжигания монет - последнее, что может пригодиться лоху ))

[imhoneer]

А продаван тебе скажет, контракт электронный, и в процессе MITM-атаки данные были искажены злоумышленниками.
Компания/корпорация не получила баблос, а ты дурашка, адрес не проверил и слился.
И хрен что ты докажешь им, потом.

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

Никакая атака, кроме, как компроментация хеша здесь не сработает.

Поэтому нет смысла морочиться и kzv полностью прав:

Если в контракте написано: переводи на этот адрес и получишь тачку, то если будет транзакция на этот адрес - покупатель требование контракта выполнил. Каким образом продаван будет доставать бабло с этого адреса -  никого не ебет. Не будет продаван исполнять условие договора, получит иск в суд и заплатит в итоге раза в три больше.

[crypto_trader#43xzEXrP]

А продаван тебе скажет, контракт электронный, и в процессе MITM-атаки данные были искажены злоумышленниками.
Компания/корпорация не получила баблос, а ты дурашка, адрес не проверил и слился.
И хрен что ты докажешь им, потом.

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

Никакая атака, кроме, как компроментация хеша здесь не сработает.

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

Такая же фигня, кстати, успешно срабатывает и при RSA-шифровании/подписи,
и с SSL-сертификатами, и с обменом ключами по алгритму Diffie-Hellman'а.

А придёшь к продавану, он тебе реальный, но уже другой контракт, с другим хэшем выдаст, подписанный даже,
а баблос ушёл уже и хрен что докажешь.

Что ты на это скажешь?

[kzv]

почитай про ссл сертификаты

[crypto_trader#43xzEXrP]

почитай про ссл сертификаты

Ну ты откуда этот сертификат-то берёшь? Он тебе вгружается, да?
И откуда же он вгружаются-то? Не от атакующего ли?
https://cryptoworld.su/wp-content/uploads/2018/09/MITM-атаки.png

[kzv]

Нет не от атакующего. Список доверенных сертификатов у меня вшит в дистрибутив браузера.

[crypto_trader#43xzEXrP]

Нет не от атакующего. Список доверенных сертификатов у меня вшит в дистрибутив браузера.

Говоришь так, как будто у тебя в браузере, заранее вшиты - все SSL-сертификаты,
даже от ещё не зарегестрированных доменных имен, где когда-либо будут хоститься сайты c HTTPS,
а ещё звучит так, как будто эти сертификаты и ключи к ним - не генерируются, а статичные какие-то.
Не, ну реально, когда ты заходишь на сайт с HTTPS, он тебе вгружает свой SSL-сертификат.
Если он подписанный, этими твоими, прошитыми у тебя - центрами сертификации, то проблем нет.
Если он не подписанный, а самоподписанный, скажем - то появляются проблемы,
то подписи нет, то она не от доверенного источника,
либо же сертификат не соответствует доменному имени, а подсунут от другого доменного имени...
Но есть такие атакеры, что и из центров сертификации этих твоих,
неактуальных и протухших, кстати - подпись умудрятся получить,
для совершения, этой своей - MITM-атаки,
и фиг что ты заподозришь при этом. Открыл сайт, там всё зелёненькое, проверено. Ага... Лол.

[kzv]

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

Все, на этом остановись 

[imhoneer]

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

Такая же фигня, кстати, успешно срабатывает и при RSA-шифровании/подписи,
и с SSL-сертификатами, и с обменом ключами по алгритму Diffie-Hellman'а.

А придёшь к продавану, он тебе реальный, но уже другой контракт, с другим хэшем выдаст, подписанный даже,
а баблос ушёл уже и хрен что докажешь.

Что ты на это скажешь?

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

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

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

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


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


Да и специально сидеть и ждать сообщений от какой-то фирмы, это слишком накладно.