|
![]() |
# 1 |
Сообщения: 252
цитировать ответ |
![]()
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru В транзакции Bitcoin, то TxIn содержит подпись текущего Искупителя и TxOut в hash160 открытого ключа следующего Искупителя. Hash160 определяется как ripemd160 (SHA256 (данные)). Таким образом, невозможно получить оригинальный хэш открытого ключа. Мой вопрос, чтобы проверить подпись ECDSA, один обязательно имеет оригинальный открытый ключ. В какой шаг действительно кажется, этот оригинальный открытый ключ? Является ли этот ключ также направляются в другие равноправные узлы? Поддерживает ли Bitcoin глобальной базы данных открытых ключей для каждого адреса?
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 2 |
Сообщения: 793
цитировать ответ |
![]()
Получил 1806 Биткоинов
Реальная история. Сигнатура поле сделки расходов ( "scriptSig" поле) содержит как подпись и открытый ключ. Для подтверждения сделки, открытый ключ первый хэшируются и сравнивается с хэш в опорном выходе. Если хэши совпадают, то открытый ключ используется для проверки подписи.
Скрипт для вывода является: Код:
и сценарий в сделке расходов: Код: <подпись> <открытый ключ> Те получить concatinated вместе, чтобы сформировать полный сценарий: Код: <подпись> <открытый ключ> которая выполняется в соответствии с правилами, найденных здесь: https://en.bitcoin.it/wiki/Script |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 3 |
Сообщения: 1246
цитировать ответ |
![]() Открытый ключ является частью сделки. Когда расходы от выхода P2PKH, формат ввода выглядит следующим образом
Код: <сиг> <Публичных> |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 4 |
Сообщения: 252
цитировать ответ |
![]() Сигнатура поле сделки расходов ( "scriptSig" поле) содержит как подпись и открытый ключ. Для подтверждения сделки, открытый ключ первый хэшируются и сравнивается с хэш в опорном выходе. Если хэши совпадают, то открытый ключ используется для проверки подписи. Скрипт для вывода является: Код:
и сценарий в сделке расходов: Код: <подпись> <открытый ключ> Те получить concatinated вместе, чтобы сформировать полный сценарий: Код: <подпись> <открытый ключ> которая выполняется в соответствии с правилами, найденных здесь: https://en.bitcoin.it/wiki/Script Благодарю. Таким образом, сделка расходы содержит как оригинальный открытый ключ и его hash160 версию? Если вы хотите потратить свои монеты, вы отправить свой открытый ключ, подпись вместе с hash160 шахтерами, правильно? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 5 |
Сообщения: 1246
цитировать ответ |
![]() Благодарю. Таким образом, сделка расходы содержит как оригинальный открытый ключ и его hash160 версию? Нет. Hash160 не ставится в сделке расходов. Для того, чтобы полностью проверить сделку, вы должны иметь операции, которые он тратит от (или, по крайней мере, их выходов), так что скрипты могут быть объединены, чтобы быть подтверждены.Если вы хотите потратить свои монеты, вы отправить свой открытый ключ, подпись вместе с hash160 шахтерами, правильно? Нет. Вы создаете транзакцию и транслировать эту сделку каждому по сети. Сделка содержит ссылку на выходы, которые вы тратите из, входных сценариев, необходимых, чтобы провести эти выходные, и выходов, которые вы хотите создать. Существуют также некоторые дополнительные накладные расходы для версии транзакций и данных длины. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 6 |
Сообщения: 2002
цитировать ответ |
![]() - чик - Таким образом, сделка расходы содержит как оригинальный открытый ключ и его hash160 версию? - чик - Это неправильно. Как было объяснено в два раза: - чик - сценарий в сделке расходов: Код: <подпись> <открытый ключ> - чик - формат ввода выглядит следующим образом Код: <сиг> <Публичных> При проверке подписи, узел будет первым хэш предоставленного открытого ключа. Затем он сравнивает, что хэш в выводе, затрачиваемых. Это доказывает, что при условии открытого ключа является правильным. Затем он проверяет подпись против предоставленного открытого ключа. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 7 |
Сообщения: 252
цитировать ответ |
![]() Итак, рассмотрим две транзакции Tx1 и Tx2, в этом случае Tx2 затрачиваемое выход Тх1.
Выход Тх1 содержит открытый ключ Hash160 приемника. Когда приемник хочет провести свой Bitcoin, он создает Tx2, который ссылается на вывод TX1 в качестве входных данных. В scriptSig части Tx2, приемник вставляет свою подпись и его оригинальный открытый ключ, а затем транслировать эту транзакцию в сеть. Если scriptSig проходит проверку, то Прд1 проводится Тх2. Разве я объяснить это правильно? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 8 |
Сообщения: 793
цитировать ответ |
![]() Итак, рассмотрим две транзакции Tx1 и Tx2, в этом случае Tx2 затрачиваемое выход Тх1. Выход Тх1 содержит открытый ключ Hash160 приемника. Когда приемник хочет провести свой Bitcoin, он создает Tx2, который ссылается на вывод TX1 в качестве входных данных. В scriptSig части Tx2, приемник вставляет свою подпись и его оригинальный открытый ключ, а затем транслировать эту транзакцию в сеть. Если scriptSig проходит проверку, то Прд1 проводится Тх2. Разве я объяснить это правильно? Да это верно. Чтобы получить более подробно: процесс проверки на самом деле программа, которая работает и выходы "правда" или "ложный" в конце его, или сбои во время работы, которое рассматривается как "ложный", В случае нормального адреса расходов - как ситуации вы говорите - программа: Код: Шаг 1: сохранить подпись под рукой, потому что нам нужно это позже Это полная программа, которая работает. "код" для этой программы "написано" поставив любой код в поле подписи транзакции потратив в перед любым кодом в поле вывода входной сделки, и объединить их вместе, и работают, что комбинированный код в виде одной программы. Если программа работает в обязательном порядке и возвращается "правда", Сделка действительна. Есть, например, "адреса" где выходной "адрес" код просто говорит "возвращает истину" и сделка расходы не имеют какого-либо кода. И, конечно же, сочетающей программа действительно возвращает истину и является действительной сделкой. И здесь "адреса" которые никогда не могут быть потрачены. Вы слышали "OP_RETURN"? Ну, что конкретный бит кода означает "прекратить проверки сделки и вернуть ложь", Вот почему эти выходы не могут быть потрачены. Потому что в конечном итоге кода проверки хитов, что обучение и послушно останавливается проверки и возвращает ложь, что делает сделку недействительной. Срок "адрес" действительно обманывает, потому что на самом деле не адрес. Там нет счета. Есть только эта маленькая мини-программа, которые работают. Срок "адрес" только для нас, людей, чтобы сделать Bitcoin казаться легче. "адрес" это просто выход с куском кода, который запускается на выполнение, когда он уходит. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 9 |
Сообщения: 252
цитировать ответ |
![]() благодаря
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 10 |
Сообщения: 1260
цитировать ответ |
![]() Существуют также некоторые дополнительные накладные расходы для версии транзакций и данных длины. На самом деле, открытый ключ также "накладные расходы", Так как он может быть получен из дайджеста, подпись и hash160. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 11 |
Сообщения: 1246
цитировать ответ |
![]() Существуют также некоторые дополнительные накладные расходы для версии транзакций и данных длины. На самом деле, открытый ключ также "накладные расходы", Так как он может быть получен из дайджеста, подпись и hash160. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 12 |
Сообщения: 252
цитировать ответ |
![]() Существуют также некоторые дополнительные накладные расходы для версии транзакций и данных длины. На самом деле, открытый ключ также "накладные расходы", Так как он может быть получен из дайджеста, подпись и hash160.Каковы подробные шаги для осуществления этого? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 13 |
Сообщения: 1260
цитировать ответ |
![]() Каковы подробные шаги для осуществления этого? Первый шаг ищет ECDSA_SIG_recover_key_GFp Метод в источниках Биткойн Core.Имея открытый ключ экономит время вычислений, поскольку она хешируется и по сравнению, прежде чем Эти линии должны быть напечатаны жирным шрифтом в "ECDSA для чайников" книга делать более дорогостоящие операции проверки подписи. В противном случае злоумышленники могут просто поставить недействительные подписи, которые сначала должны пройти дорогостоящие операции подписи, чтобы получить открытый ключ, а затем сравнить открытый ключ последнего. Это потенциально может быть вектор атаки DoS. |
![]() ![]() |
![]() ![]() ![]() |