Зачем проверять открытый ключ и подпись в транзакциях P2PKH?

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

Интересно, почему просто проверки открытого ключа недостаточно. Сценарий публичного ключа содержит его криптографический хеш, поэтому реверсирование должно быть невозможным, и любой, кто хочет потратить UTXO, связанный с этим скриптом, должен иметь правильный открытый ключ. Разве это уже не достаточно аутентифицирует транжиру? Я понимаю, что в транзакциях P2PK необходима подпись, но с P2PKH хэширование и подпись кажутся мне излишними.

Разве простое хеширование сценария погашения не используется для аутентификации в P2SH? Сценарий публичного ключа в P2SH просто проверяет, соответствует ли хэш сценария погашения правильному значению, а затем уже выполняет его. Если хеширование считается безопасным в P2SH, то почему не также и в P2PKH?

Ответы (4)

1) Адреса устареют после одного использования.

2) Если кто-то проводит атаку Сивиллы, он/она может предотвратить ретрансляцию транзакций (что может произойти и сейчас), но также он/она может совершить поддельную транзакцию с этого адреса и ретранслировать ее, так как злоумышленник знает, что такое прообраз является.

3) Даже без атаки Сивиллы кто-то может воспользоваться возможными потерянными блоками и забрать деньги со всех транзакций в них, совершив фальшивую транзакцию для каждой из них.

Не могли бы вы немного уточнить 1) и приглушить 2) для меня, пожалуйста, или объясните это иначе? Я не понимаю, как 2) отвечает на мой вопрос, потому что я едва его понимаю. ^^
@Downvoter Я упрощу и 1, и 2: после того, как будет раскрыт ввод хэша (прообраз), любой может украсть биткойны адреса.
Спасибо. Таким образом, это исключает простое использование открытого ключа для P2PKH, но разве P2SH также не проверяет хэш сценария выкупа? Итак, как только этот сценарий выкупа станет известен, не сможет ли кто-нибудь притвориться владельцем?
@Downvoter Вот почему существуют подписи. P2SH также проверяет подпись.
Здесь показан сценарий открытого ключа P2SH OP_HASH160 <Hash160(redeemScript)> OP_EQUAL. Скрипт подписи есть <sig> [sig] [sig...] <redeemScript>, значит подписи проходят, но проверять их вообще вроде бы не надо. Они проверяются только в том случае, если сценарий выкупа выбирает это. Разве это не очень небезопасно, если кто-то пропустит проверку подписей в сценарии выкупа?
@Downvoter 99% P2SH проверяет подпись. 1% является особым, редким и называется скриптом «Любой может потратить». Никто не «промахнется» для проверки подписи.
Во входных данных P2SH redeemScript передается обратно через интерпретатор сценариев после проверки его хэша. Поэтому, когда вы создаете входные данные, вы помещаете во входные данные двоичный объект, который является redeemScript. Затем этот блоб удаляется из стека и интерпретируется как сам скрипт.

Есть условие расходования и условие владения. Условие траты задается предыдущим отправителем средств в скрипте публичного ключа: «доказательство того, что вы можете создать хеш, который принадлежит этому адресу». С односторонней хеш-функцией это доказывает, что только «вы» можете быть физическим лицом, чтобы в дальнейшем тратить средства. Вы правильно объяснили это зависимостью от хеширования.

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

В своем последнем комментарии вы заявили, что подписи (multisig) вообще не проверяются. Это немного неправильно. Redeemscript имеет в конце OP_Code 0xAE, который проверяет подписи для указанного количества публичных ключей.

Смотрите также ответ здесь

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

Есть несколько недостатков (проблемы практичности), которые следует учитывать, как уже упоминалось MCCCS и pebwindkraft , и большинство из них, если не все, связаны с одноразовыми подписями, как упоминает MCCCS.

адреса устареют после одного использования

Некоторые примеры того, что может пойти не так, включают:

  1. Транзакция не проходит, например, из-за низких комиссий или злонамеренной стороны, препятствующей ретрансляции транзакций, а затем создает поддельную транзакцию с этого адреса и ретранслирует ее на свой собственный ключ (спасибо MCCCS)
  2. Вилка, то один и тот же ключ должен использоваться для каждой разветвленной версии.
  3. Блоки-сироты (благодаря MCCCS)
  4. Ситуация более сложная в транзакциях с несколькими подписями. Не существует очевидного решения, использующего только хэши, в случаях, когда адреса с мультиподписью принадлежат ненадежным сторонам (такие сервисы, как CoinJoin, не могут работать).
  5. Рекламируйте один и тот же адрес для получения средств, т.е. веб-сайт, принимающий пожертвования на один адрес. Тогда вам потребуется потратить все за одну транзакцию (подписать только один раз), и даже если вы можете это терпеть (маловероятно), вы все равно подвержены вышеупомянутым атакам.
  6. Если требуется подтверждение платежеспособности (или подтверждение владения ключом/активами), то один из способов — подписать вызов и доказать, что вы владеете ключом. Как уже упоминалось, вы хотите избежать повторной подписи любыми способами, поэтому вышеизложенное покажет ваш прообраз.
  7. Если скрипт по какой-либо причине дает сбой во время проверки, он фактически уничтожает значение, связанное с любыми входными адресами, поскольку их прообраз будет раскрыт.

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

Зачем проверять открытый ключ и подпись в транзакциях P2PKH?
СпросиСетьПолитика конфиденциальности1y, 0v