8 февраля 2013, 1:42:07 AM   # 1
 
 
Сообщений: 32
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Не очень долго, и я вернулся с большим количеством вопросов. Я узнал совсем немного о Bitcoin через мои занятия на здесь и сейчас у меня есть еще технические вопросы. Сейчас я учусь в scriptSig входной части сделки и scriptPubKey выходной части сделки. Я нашел ответы на некоторые вопросы и понять аспекты, но другие не знаю.

Относящийся к scriptSig я вижу два аспекта, открытый ключ и подпись. Я а м комфортно с открытым ключом аспектом. При попытке провести BTC вы отсылаете к выходу предыдущих ОМУ и программа хэш, таким образом, ваш публичный ключу найти адрес и так как предшествующий выход послал BTC на свой адрес он проверяется у вас есть ключ. Это кажется простым для меня, теперь, по крайней мере.

Когда речь идет о подписи части этого я потерял. Я знаю, что какой-то образом ваш секретный ключ вы предоставляете проверяет ваш открытый ключ через хэш. Это имеет смысл, я понимаю, как это происходит. Мой вопрос заключается в том, как вы обеспечиваете свой частный ключ к входу вашего ОМУ, чтобы обработать его и найти линейку с вашим открытым ключом, не подвергая ваш личный ключ в записи? Есть ли способ использовать только частный ключ, но ничего не делать с этим? Также я знаю, что вы подписываете хэш ТХ, и я понимаю, как хэш сделан из ТХ. Но что именно эта подпись? Это хэш сочетания частного и открытого ключ? Я нашел эту информацию:

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

Вот: https://en.bitcoin.it/wiki/Transactions

и я пытаюсь понять часть выделенного курсивом.
BitcoinScholar сейчас офлайн Пожаловаться на BitcoinScholar   Ответить с цитированием Мультицитирование сообщения от BitcoinScholar Быстрый ответ на сообщение BitcoinScholar


Как заработать Биткоины?
Без вложений. Не майнинг.


8 февраля 2013, 2:12:58 AM   # 2
kjj
 
 
Сообщения: 1302
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Получил 1806 Биткоинов
Реальная история.





Не очень долго, и я вернулся с большим количеством вопросов. Я узнал совсем немного о Bitcoin через мои занятия на здесь и сейчас у меня есть еще технические вопросы. Сейчас я учусь в scriptSig входной части сделки и scriptPubKey выходной части сделки. Я нашел ответы на некоторые вопросы и понять аспекты, но другие не знаю.

Относящийся к scriptSig я вижу два аспекта, открытый ключ и подпись. Я а м комфортно с открытым ключом аспектом. При попытке провести BTC вы отсылаете к выходу предыдущих ОМУ и программа хэш, таким образом, ваш публичный ключу найти адрес и так как предшествующий выход послал BTC на свой адрес он проверяется у вас есть ключ. Это кажется простым для меня, теперь, по крайней мере.

Когда речь идет о подписи части этого я потерял. Я знаю, что какой-то образом ваш секретный ключ вы предоставляете проверяет ваш открытый ключ через хэш. Это имеет смысл, я понимаю, как это происходит. Мой вопрос заключается в том, как вы обеспечиваете свой частный ключ к входу вашего ОМУ, чтобы обработать его и найти линейку с вашим открытым ключом, не подвергая ваш личный ключ в записи? Есть ли способ использовать только частный ключ, но ничего не делать с этим? Также я знаю, что вы подписываете хэш ТХ, и я понимаю, как хэш сделан из ТХ. Но что именно эта подпись? Это хэш сочетания частного и открытого ключ? Я нашел эту информацию:

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

Вот: https://en.bitcoin.it/wiki/Transactions

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

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

Страница википедии объясняет, таким образом, как подпись фактически вычисляется. Страница OP_CHECKSIG на Bitcoin вики идет в некоторые детали на этапе упрощения.
kjj сейчас офлайн Пожаловаться на kjj   Ответить с цитированием Мультицитирование сообщения от kjj Быстрый ответ на сообщение kjj

8 февраля 2013, 3:38:03 AM   # 3
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Другой компонент представляет собой подпись ECDSA над хэш упрощенной версии сделки.

Магия открытого ключа криптографии является то, что вы можете дать кому-то открытый ключ, некоторые данные, и подпись, и они могут быть уверены, что:

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

Им не нужно знать частный key-- вы держать его в секрете.

"хэш над ..." бит является способом цифровой подписи work-- вы подписываете хэш данных, а не сами данные, так как хэш гораздо меньше.

"... упрощенная версия сделки" немного сложно. Данные подписали это сделка минус все эта подпись scriptSig, плюс (почти всегда) scriptPubKey предыдущей сделки. Смотрите страницу OP_CHECKSIG на вики для всех окровавленных деталей.
Гэвин Андресен сейчас офлайн Пожаловаться на Гэвин Андресен   Ответить с цитированием Мультицитирование сообщения от Gavin Andresen Быстрый ответ на сообщение Гэвин Андресен

8 февраля 2013, 4:17:32 PM   # 4
 
 
Сообщения: 2002
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Это звучит для меня, как вы боретесь, чтобы понять, что ECDSA (эллиптические кривые Digital Signature Algorithm) и как он работает. Это хорошо известно и широко используется криптографический алгоритм "подписание" информации с использованием закрытого ключа таким образом, что любой человек с соответствующим открытым ключом может доказать, что подпись может быть предоставлена ​​только владелец закрытого ключа. Секретный ключ никогда не раскрывается (поэтому она называется "частный"), Но публичный ключ должен открыться (именно поэтому его называют "общественности"). Я не в полной мере понять процесс, но он был проверен на достаточное количество людей, которым я доверяю его.

Вы можете найти некоторые из процесса, участвующих здесь:
http://en.wikipedia.org/wiki/ECDSA

При отправке Bitcoin, то Bitcoin адрес предоставляется на выходе, но открытый ключ не является. Это не представляется возможным определить, что открытый ключ, если у вас есть только адрес Bitcoin.

Поскольку открытый ключ требуется для проверки подписи, а так как владелец секретного ключа может легко / быстро вычислить как открытый ключ и адрес Bitcoin, владелец закрытых ключей сканирует blockchain для выходов, которые связаны с адресами, может быть получено из этих частных ключей. Затем они выбирают один и вычислить открытый ключ от секретного ключа. Открытый ключ затем представлен вместе с подписью в scriptSig.

В настоящее время существует достаточно информации, чтобы доказать, что транжира имеет право сделать это. Будучи дано открытый ключ в scriptSig означает, что каждый может:
Код:
Base58Check (СЦЕПИТЬ (версия, RIPEMD-160 (SHA-256 (открытый ключ)), SUBSTR (0,4, SHA-256 (RIPEMD-160 (SHA-256 (открытый ключ))))))
Для того, чтобы убедиться, что полученный Bitcoin адрес такой же, как по адресу, указанному в предыдущем выходе.

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

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

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

Вы, вероятно, хотите, чтобы искать криптографию форума, если вы действительно хотите, чтобы понять внутренний SHA-256, RIPEMD-160 и ECDSA.
DannyHamilton сейчас офлайн Пожаловаться на DannyHamilton   Ответить с цитированием Мультицитирование сообщения от DannyHamilton Быстрый ответ на сообщение DannyHamilton

8 февраля 2013, 4:30:37 PM   # 5
 
 
Сообщения: 1218
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Это звучит для меня, как вы боретесь, чтобы понять, что ECDSA (эллиптические кривые Digital Signature Algorithm) и как он работает.

Или в более общем смысле понятие асимметричной криптографии (также известный как криптографии с открытым ключом).

Действительно, чтобы начать понимать, Bitcoin нужно иметь очень хорошее представление о следующих понятиях:
Криптографические хэш-функции
Асимметричная криптография
Цифровые подписи
Криптографическая Нонс  <- используется в горнодобывающей промышленности не сделки

(Некоторая Википедия ссылка, чтобы получить OP начала).

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

Тогда один должен быть знаком с алгоритмами, используемыми:
SHA-256 (криптографической хэш-функции)
RIPEMD-160 (криптографической хэш-функции)
ЕСС (эллиптическая криптография)
ECDSA (ECC Digital Signature Algorithm)
SECP256K1 (специфическая кривая ЕСС используется Bitcoin

Не нужно знать, например, внутренний поток данных из SHA-256, но один действительно нужно знать, что это и на высоком уровне, как это работает. Цель? Размер блока? Hash размер?


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

Это было бы как попытка узнать двойную запись bookeeping без понимания арифметики. Это просто не может быть сделано.  

DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes

8 февраля 2013, 5:54:54 PM   # 6
 
 
Сообщения: 2002
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

. . .
Действительно, чтобы начать понимать, Bitcoin нужно иметь очень хорошее представление о следующих понятиях:
Криптографические хэш-функции
Асимметричная криптография
Цифровые подписи
Криптографическая Нонс  <- используется в горнодобывающей промышленности не сделки

(Некоторая Википедия ссылка, чтобы получить OP начала).

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

Тогда один должен быть знаком с алгоритмами, используемыми:
SHA-256 (криптографической хэш-функции)
RIPEMD-160 (криптографической хэш-функции)
ЕСС (эллиптическая криптография)
ECDSA (ECC Digital Signature Algorithm)
SECP256K1 (специфическая кривая ЕСС используется Bitcoin
. . .

Я вижу что ты тут делал. 

Я обманул. Я ответил, большинство из них. , , затем отправил, а затем вернулся и очистке пост и добавил дополнительные детали.
DannyHamilton сейчас офлайн Пожаловаться на DannyHamilton   Ответить с цитированием Мультицитирование сообщения от DannyHamilton Быстрый ответ на сообщение DannyHamilton

9 февраля 2013, 11:26:51 PM   # 7
 
 
Сообщений: 32
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Я понимаю scriptSig и scriptPubKey в основном в настоящее время. Что происходит в транзакции Секретный ключ проходит через процесс, в конечном счете доказать, что адрес БТД было "послал" на матчи. Это изначально "знаки" это, но тогда она должна быть проверена с помощью открытого ключа. С открытым ключом, то также проверяет подпись и является еще одним доказательством, что подпись действительна. Это в настоящее время открыто для перехода к части scriptPubKey сценария, который ultimatly только определяет, какой адрес является получателем БТД или подписи. В выходе также количество отправлено. Тогда, когда это получает новый владелец, они должны пройти через тот же процесс ввода, доказать владение адреса, хранящее значение, и т.д., и т.д., таким образом, система действует как серия электронных подписей.

Глядя на необходимые вещи для входной части сделки, я вижу, что они являются 1) предыдущий TX 2) индекс и 3) scriptSig. Я понимаю scriptSig сейчас (В основном способе я считаю) и индексом, который как раз отношусь к конкретному выходу ОГО в вопросе. Я не понимаю, однако, как "предыдущая ТХ" представляет предыдущую транзакцию (звучит странно, но позвольте мне объяснить). Представляет ли предыдущий ТХ хэш готовой подписи предыдущего ТХ? И как это используется в качестве неотъемлемой части ввода.

У меня есть несколько маленьких теорий. Может быть, "предыдущая ТХ" сечение ввода только хеш ссылочного выходного адреса? Опять же, может быть, это просто хэш предыдущей ТХ подписи? Но тогда, я думаю, scriptPubKey только дает выходной адрес. Если scriptPubKey дает больше, чем просто выходной адрес я думаю, что было бы объяснить этот последний кусочек головоломки, и я бы понять основы процесса сценария. У меня сложилось впечатление, что scriptPubKey содержит только значение и выходной адрес.
BitcoinScholar сейчас офлайн Пожаловаться на BitcoinScholar   Ответить с цитированием Мультицитирование сообщения от BitcoinScholar Быстрый ответ на сообщение BitcoinScholar

4 мая 2014, 12:42:48 PM   # 8
 
 
Сообщений: 14
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Другой компонент представляет собой подпись ECDSA над хэш упрощенной версии сделки.

Магия открытого ключа криптографии является то, что вы можете дать кому-то открытый ключ, некоторые данные, и подпись, и они могут быть уверены, что:

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

Им не нужно знать частный key-- вы держать его в секрете.

"хэш над ..." бит является способом цифровой подписи work-- вы подписываете хэш данных, а не сами данные, так как хэш гораздо меньше.

"... упрощенная версия сделки" немного сложно. Данные подписали это сделка минус все эта подпись scriptSig, плюс (почти всегда) scriptPubKey предыдущей сделки. Смотрите страницу OP_CHECKSIG на вики для всех окровавленных деталей.


делает подписи в сделке, как это:
ECDSASignature (Hash (Transaction-scriptSig) + PreTransaction_scriptPubKey)

?

fengshu сейчас офлайн Пожаловаться на fengshu   Ответить с цитированием Мультицитирование сообщения от fengshu Быстрый ответ на сообщение fengshu

4 мая 2014, 1:05:26 PM   # 9
 
 
Сообщений: 56
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Видеть эта страница вики для получения более подробной информации, данные, которые подписаны эффективно:
Код:
SHA256 (SHA256 (modified_transaction))

Модифицированная сделка очень сложно построить и удаляет подпись и открытый ключ и материалы, которые не подписали.
telepatheic сейчас офлайн Пожаловаться на telepatheic   Ответить с цитированием Мультицитирование сообщения от telepatheic Быстрый ответ на сообщение telepatheic

4 мая 2014, 3:42:19 PM   # 10
 
 
Сообщения: 1218
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Видеть эта страница вики для получения более подробной информации, данные, которые подписаны эффективно:
Код:
SHA256 (SHA256 (modified_transaction))

Модифицированная сделка очень сложно построить и удаляет подпись и открытый ключ и материалы, которые не подписали.

К сожалению, это, вероятно, один из худших решений Satoshi сделал. Сложность ничего не добавляет и одна из основных причин для tansaction пластичности. Не совсем уверен, что Сатоши пытается для того чтобы достигнуть. Обычно подпись ВНЕ полезной нагрузки и пытается вставить его обратно на вход не добавляет никакой ценности.

Было бы гораздо проще сделать что-то подобное.

Шаг 1) Построить всю транзакцию (минус подписи) в канонической форме
Шаг 2) Hash всей транзакции. Это становится tx_id, а также дайджест для подписи
Шаг 3) Подписать хэш в шаге 2 с закрытым ключом (ами) и приложить к телу подписи.

Вы бы в конечном итоге с чем-то вроде:
заголовок ТХ
в [п] (список входов)
из [п] (список выходов)
знак [п] (список подписей)

Проверять:
Шаг 1) Удалите подписи из организма ОГО и сохранить.
Шаг 2) Hash оставшиеся ТХ. Это ТЙ идентификатор и дайджест для проверки подписи.
Шаг 3) Проверка каждой из подписей с использованием Публичных (ов) и хэш транзакции.

Честно говоря, я понятия не имею, что Satoshi пытался достичь с чрезмерно сложной беспорядок, который Bitcoin ТХ подписей, но, учитывая несколько других сомнительных решений (с использованием несжатого pubkeys, неканонические подписей, в том числе Публичного в входах, когда они могут быть восстановлены из подписи и т.д.) Я считаю, что такой умный, как Satoshi был ECDSA не его конек. Он использовал его, но он не был экспертом в этом.





DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes

4 мая 2014, 4:52:39 PM   # 11
 
 
Сообщений: 56
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Чтение исходного кода Satoshi является чрезвычайно проницательны. Файл script.cpp имеет в основном не изменились с Satoshi написал. Все были слишком напуганы, чтобы предложить изменить его на что-то логично. Я пока не вижу реальное использование функциональных сценариев за мульти-подпись. Там был какой-то большая идея позади него, но никто не знает, что, даже Гэвин не имеет ни малейшего понятия, почему Satoshi написал, как он сделал.
telepatheic сейчас офлайн Пожаловаться на telepatheic   Ответить с цитированием Мультицитирование сообщения от telepatheic Быстрый ответ на сообщение telepatheic

4 мая 2014, 7:16:07 PM   # 12
 
 
Сообщения: 700
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Вчера я опубликовал статью, в которой я объясняю, что
Пожалуйста, обратите внимание, если вам это нравится, голосование http://www.codeproject.com/Articles/768412/NBitcoin-The-most-complete-Bitcoin-port-Part-Crypt
код Satoshi является довольно трудно читать для кого-то не используется для C ++ разработчика,
Мой порт более легко понять: https://github.com/NicolasDorier/NBitcoin]https://github.com/NicolasDorier/NBitcoin]https://github.com/NicolasDorier/NBitcoin (Класс Script)
Подпись представлена ​​типа TransactionSignature.

Процесс определения хэш, который нужно подписать с ключом указан в методе Script.SignatureHash.
https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin/Script.cs#L358
Николя Dorier сейчас офлайн Пожаловаться на Николя Dorier   Ответить с цитированием Мультицитирование сообщения от Nicolas Dorier Быстрый ответ на сообщение Николя Dorier

4 мая 2014, 8:02:26 PM   # 13
 
 
Сообщений: 56
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Ваш код выглядит очень хорошо. Какие тесты блок вы используете (как вы убедитесь, что вы не нарушает совместимость с ядром Bitcoin)?
telepatheic сейчас офлайн Пожаловаться на telepatheic   Ответить с цитированием Мультицитирование сообщения от telepatheic Быстрый ответ на сообщение telepatheic

4 мая 2014, 8:06:38 PM   # 14
 
 
Сообщения: 700
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Ваш код выглядит очень хорошо. Какие тесты блок вы используете (как вы убедитесь, что вы не нарушает совместимость с ядром Bitcoin)?

Я портирована единичные тесты Bitcoin ядра, наряду с их собственными данными ведомых испытаний. (На самом деле, я должен был реализовать некоторые ошибки реализации ядра, чтобы не нарушить совместимость, как OpenSSL ошибку я документированной в методе ScriptEvaluationContext.CheckSig)
Клон моего проекта, я дал категорию "ядро" для испытаний, поступающих от реализации ядра.



На самом деле я портировал их испытания до их реализации.

Моя реализация узла сервера не 100% сделано, но вы можете начать говорить с сетью.
Крипто часть полностью портирована хотя.
Николя Dorier сейчас офлайн Пожаловаться на Николя Dorier   Ответить с цитированием Мультицитирование сообщения от Nicolas Dorier Быстрый ответ на сообщение Николя Dorier

4 мая 2014, 10:50:53 PM   # 15
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

К сожалению, это, вероятно, один из худших решений Satoshi сделал. Сложность ничего не добавляет и одна из основных причин для tansaction пластичности. Не совсем уверен, что Сатоши пытается для того чтобы достигнуть. Обычно подпись ВНЕ полезной нагрузки и пытается вставить его обратно на вход не добавляет никакой ценности.

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

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

Эта "замки" сделка на месте и предотвращает любые изменения, не нарушая подпись.

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

Хэш ОГО-идентификатор зависит от подписанной части сделки и добавленных подписей.  

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

В коде псевдо:

Код:
подписания хэш = Hash (транзакция с входами удаленных)

подпись = знак (подписания хэш, секретный ключ)

Окончательные транзакции = транзакция с подписью добавляется к входам

TX-ID = хэш (конечная tranasction)

Подпись в основном два числа. Это было бы как кодированию 123, 456, как 0123, 0456. Они оба представляют ту же пару числа, так что оба действительных подписей.

Идеальное решение было бы использовать хэш подписи [*] для обозначения предыдущих входов и (текущий) TX-ID только для вычисления Merkle дерева в блоках.

[*] Хеш подписание является хэш сделки со всеми входами устанавливается равным нулю

Вы бы в конечном итоге с чем-то вроде:
заголовок ТХ
в [п] (список входов)
из [п] (список выходов)
знак [п] (список подписей)

Проверять:
Шаг 1) Удалите подписи из организма ОГО и сохранить.
Шаг 2) Hash оставшиеся ТХ. Это ТЙ идентификатор и дайджест для проверки подписи.
Шаг 3) Проверка каждой из подписей с использованием Публичных (ов) и хэш транзакции.

Он уже работает таким образом, за исключением знака [п] значения добавляются к входам после подписания.
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

4 мая 2014, 10:59:46 PM   # 16
 
 
Сообщений: 56
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

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

Это не так просто, текущий вход, с подписью и ничего до последнего OP_CODESEPARATOR удалены, подписываются (На самом деле даже это грубое упрощение). Видеть https://en.bitcoin.it/wiki/OP_CHECKSIG
telepatheic сейчас офлайн Пожаловаться на telepatheic   Ответить с цитированием Мультицитирование сообщения от telepatheic Быстрый ответ на сообщение telepatheic

4 мая 2014, 11:26:41 PM   # 17
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Это не так просто, текущий вход, с подписью и ничего до последнего OP_CODESEPARATOR удалены, подписываются (На самом деле даже это грубое упрощение). Видеть https://en.bitcoin.it/wiki/OP_CHECKSIG

Для сделки пластичности, это не имеет значения. Если скрипт для вывода отправляется не имеет OP_CODESEPARATOR в нем, то вы можете игнорировать этот эффект. 

Если предположить, что транжира тратит стандартные операционные монеты, не будет никаких OP_CODESEPARATORS, чтобы иметь дело с.

При нормальных операциях, чтобы получить хэш подписи

- вы вымарать все входы
- Вы можете скопировать scriptPubKey на выходе вы тратите на вход вы подписывающие
- добавить hash_type в конце транзакции (расширена до 4 байт)

Все, что подписываемое заблокированное.

Проблема в том, "пустые все входы" шаг, это означает, что входы не влияют на хэш подписи, но они влияют на TXID хэш.

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

Вы отправляете деньги на конкретный TX-идентификатор, а затем сделка меняется, и поэтому средства зачисляются на другой выход транзакции. Это нарушает возврат сделку, взятую на себя определенный ТЙ-идентификатор.
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

4 мая 2014, 11:32:08 PM   # 18
 
 
Сообщения: 1218
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Он уже работает таким образом, за исключением знака [п] значения добавляются к входам после подписания.

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

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

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

DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes

5 мая 2014, 12:02:15 AM   # 19
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

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

Есть некоторые преимущества в возможности пустой часть сделки вне. 

Сам Ковкость можно было бы исправить, если ТХ-идентификатор входа не был включен в процессе подписания.

Сказав это, я в целом согласен. 

Основной процесс подписания должен просто использовать хэш (транзакцию без входов | hash_type) в качестве хэша-подписи. Хэш подписи должен использоваться для обозначения предыдущей операции.

Дополнительные сложности могут быть добавлены с различным hash_types, если это абсолютно необходимо.

Все, в том числе подписи, должны быть включены в хэш для блока корня Merkle, хотя. Это делает его гораздо проще для архивирования и начальной загрузки.
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

5 мая 2014, 1:10:48 AM   # 20
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: Вопрос о scriptSig и scriptPubKey

Основной процесс подписания должен просто использовать хэш (транзакцию без входов | hash_type) в качестве хэша-подписи. Хэш подписи должен использоваться для обозначения предыдущей операции.
О нет, это не было бы хорошо в целом, по крайней мере, если вы не могли отказаться от него.

Рассмотрим, Вы платите Элис. Сделка не подтверждая, потому что ваши платежи не были конкурентоспособными. Таким образом, вы дважды тратить свои входы в новой транзакции с лучшей платой для достижения атомного исключения. Упс: Моменты после замены сделки предшествующего плательщик, Peggy, создает параллельный платеж и в вашем нынешнем положении это не привилегия, так как ее выплаты в паре: цена и Публичной повторила. Пресечение предотвращено изобилием параллельного имущества, как платежи обрабатываются и Алиса, довольный своей прибыли, части оставив вас раздражительным.
 
Там certantly случаи, когда было бы хорошо, чтобы быть в состоянии замаскировать ВВОД вообще, где вы делаете что-то интересное, где вы должны быть абсолютно уверены, никогда не повторно использовать открытый ключ, как часть вашего, но от протокола в общем случае, точность управления дополнения очень важна, не только против предотвращения глупости, но, чтобы избежать потерь страдания из-за несогласованности, которая присуща в распределенной системе.

И fengshu, это как правило, предпочтительно, чтобы люди не врезаться старые темы.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW