Bitcoin Forum

Валидным адресом в сети bitcoin и альткоинах, считается любой адрес,
являющиеся просто base58Check encoded - ripemd-160 хэшем.
В том числе и адреса для сжигания монет (https://www.blockchain.com/btc/address/1BitcoinEaterAddressDontSendf59kuE), которые не имеют приватного ключа.

Консольная команда
проверяет лишь контрольную сумму Base58Check (https://awebanalysis.com/en/bitcoin-address-validate/).

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

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

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

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

Однако, любой адрес,
может быть сгенерирован локально, client-side (https://username1565.github.io/brainwallet.github.io/#generator),
и для проведения транзакции на этот адрес,
вовсе не обязательно, чтобы он был каким-то образом - "зарегистрирован" в сети.

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

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

Ещё один вариант - это наличие цифровой подписи от получателя.
Если подпись может быть проверена (https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=%D0%AD%D1%82%D0%B0%20%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%8C%20%D0%BC%D0%BE%D0%B6%D0%B5%D1%82%20%D0%B1%D1%8B%D1%82%D1%8C%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%B0.%20%D0%9F%D0%BE%D1%81%D0%BB%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8%20%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20%D0%B0%D0%B4%D1%80%D0%B5%D1%81%20%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D1%82%D0%B0.&vrSig=G%2BWQZf92eEuSoJCGvx4JZkD83esKOV%2BXxM0xy%2FAs8aYGOAViv5Z%2BHrHCvKZl%2Bqh9D42OwhSHXCFr9X3znlHSYng%3D&vrstrMessageMagic=Bitcoin%20Signed%20Message%3A%0A),
то на выходе, после проверки её, возвращается адрес подписанта.
Его можно сверить с адресом получателя.
Наличие цифровой подписи говорит о наличии контроля получателя над адресом,
то есть о наличии у него - приватного ключа,
так как сама цифровая подпись производится приватным ключём получателя (https://username1565.github.io/brainwallet.github.io/#sign).

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

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

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

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

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

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

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

А продаван тебе скажет, контракт электронный, и в процессе MITM-атаки (https://ru.wikipedia.org/wiki/Атака_посредника) данные были искажены злоумышленниками.
Компания/корпорация не получила баблос, а ты дурашка, адрес не проверил и слился.
И хрен что ты докажешь им, потом.

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

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

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

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

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

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

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

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

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

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

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

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

https://www.anti-malware.ru/files/word-image-23.png

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

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

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

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

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

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

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


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


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