|
18 мая 2014, 9:05:09 PM | # 1 |
Сообщений: 50
цитировать ответ |
Re: Длина redeemScript
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Какова максимальная длина redeemScript? Я думаю, что это 8 байт, но я не знаю.
|
18 мая 2014, 9:09:03 PM | # 2 |
Сообщения: 1876
цитировать ответ |
Re: Длина redeemScript
Получил 1806 Биткоинов
Реальная история. Какова максимальная длина redeemScript? Я думаю, что это 8 байт, но я не знаю. 520 байт https://github.com/bitcoin/bitcoin/blob/72f754cf51d09ea9c3daec398da7a8ca7fce8d6e/src/script.h#L24 https://github.com/bitcoin/bitcoin/blob/c3ad56f4e0b587d8d763af03d743fdfc2d180c9b/src/main.cpp#L517 |
18 мая 2014, 9:09:27 PM | # 3 |
Сообщения: 1078
цитировать ответ |
Re: Длина redeemScript
Это сообщение было слишком стар и продут
|
19 мая 2014, 6:23:59 PM | # 4 |
Сообщения: 840
цитировать ответ |
Re: Длина redeemScript
Когда вы говорите о «redeemscript» Вы должны быть конкретными, какие транзакции вы говорите об этом.
Скажем, у вас есть транзакции B, которая использует в качестве своих входов выходов из транзакции A. В транзакции А, «redeemscript» будет фиксированной длиной хэш. (8 байт? 16? Я должен был бы пойти взгляд) В транзакции B, это две части; первая часть (сценарий) имеет хэш и совпадают с хэш заданной в транзакции A. Обе части (сценарий и данных) должны быть загружены в стек и затем двигатель скрипт запускается. Во всяком случае, скрипты ограничены до 201 шагов. |
19 мая 2014, 8:37:19 PM | # 5 |
Сообщения: 1218
цитировать ответ |
Re: Длина redeemScript
котировка Когда вы говорите о «redeemscript» Вы должны быть конкретными, какие транзакции вы говорите об этом. redeemScript имя собственное. Он имеет один конкретный смысл. Сценарии ограничены до 520 байт. redeemScript всегда на входе транзакции, которая ссылающаяся на выход P2SH предшествующего уровня транзакции. котировка Скажем, у вас есть транзакции B, которая использует в качестве своих входов выходов из транзакции A. В транзакции А, «redeemscript» будет фиксированной длины гашиш. (8 байт? 16? Я должен был бы пойти взгляд) Это близко, но не правильно. Это становится немного в сорняк, так кто-то просто хочет знать, что redeemScript это увидеть выше. Выходы определяют условия, надетые как выход может быть использован, это (плохо) названо scriptPubKey. ScriptPubKey имеет (обычно) содержит хэш, но это будет либо scriptHash или PubKeyHash. Оба 32 байт (SHA256 составляет 256 бит), но они не являются redeemScript. scriptPubKey ("Получаемый скрипт") Pay2PubKeyHash Tx: OP_DUP OP_HASH160 Pay2ScriptHash Tx: OP_HASH160 Когда технические документы относятся к redeemScript, он имеет в виду сценарий в ScriptSig (еще один плохо имени элемента) на вход сделок. Существует только redeemScript при погашении в P2SH. scriptSig ("сценарий ввода") Pay2PubKeyHash: <сиг> <Публичных> Pay2ScriptHash: <сиг-0> ... <знак> <redeemScript> Для ввода в силе оно должно соответствовать условиям, надетые ("замок") выход. Для P2SH сделок термины определены, но неизвестно, как выход P2SH только содержит ScriptHash. Таким образом, redeemScript добавляется к подписи в ScriptSig. В Валидация redeemScript хешируется проверить, что он соответствует ScriptHash в предыдущем выходе. Вход затем проверяется, чтобы обеспечить подписи отвечают требованиям скрипта. Там нет redeemScript в качестве вклада, который ссылается на выход Pay2PubKeyHash. Выход содержит фактический сценарий не хэш-сценария. Кроме того, можно создавать другие нестандартные операции, которые определяют условия в реальной продукции, однако те, которые устарели в пользу P2SH выходов. Все, что вы можете сделать непосредственно на выходе может быть сделано в redeemscript и ScriptHash размещено на выходе. P2SH обеспечивает лучший способ справиться с "где ставить условия", Тем не менее использование P2SH почти все, кроме Pay2PubKeyHash любопытное торчит, как это странное специальное исключение. Там нет причин он не может просто работать, как и любой другой P2SH скрипт (т.е. адрес становится не кодированный PubKeyHash но кодированный ScriptHash), то все входы P2SH входов. Если вам интересно, почему у нас есть два различных способа сделать то же самое, видеть пол-OT стороны примечание ниже. примечание стороны (только некоторые бессмысленны D&Т проповеди): Если кажется, что Pay2PubKeyHash трактуется как "особый случай" ну. В более общем смысле сценарий может быть либо в выходной или хэш сценария на выходе (а затем копия сценария добавляется к входу). Все сделки от самых сложных до самых простых можно сделать так или иначе, но нет никаких причин, чтобы иметь два резервных методов для выполнения той же задачи. Причина этого в том, что существует P2SH не существовало в оригинальной Bitcoin. Выходы (даже для "отправка монет на адрес") Всегда скрипты. Это работает для простых сценариев, но более сложные сценарии становятся неуклюжими, как отправитель должен знать весь сценарий не только, какой ключ использовать. Предоставление отправителю хэш сценария превосходит по многим причинам. Это хорошее разделение проблем. Так Bitcoin был раздвоенный, чтобы поддержать P2SH. Технически поддержка Pay2PubKeyHash выходы могут быть удалены (вы можете создать адрес P2SH для одного ключа сценария), но это не было. Поддержка имеющего выхода содержит сценарий остается (в первую очередь для поддержки "нормальный" Pay2PubKeyHash сделки). Весьма вероятно, что P2SH в конечном итоге заменит все другие операции, оставив только Pay2PubKeyHash, который определяет скрипт на выходе, что делает его особым исключением на практике, если не протокол. Если Satoshi думал о P2SH с самого начала она могла бы устранила избыточность наличия скриптов в обеих входных и выходных. P2SH обычно используется для сложных сценариев, но нет никаких причин, очень простой сценарий, как OP_CHECKSIG <Публичных> не могут быть использованы. Вместо того чтобы предоставить отправителю адрес, который декодирует к PubKeyHash (а затем клиент знает, вставить его в специальный выходной сценарий) необходимо предоставить отправителю адрес, который декодирует хэш этого простого скрипта. Вы можете использовать его прямо сейчас для существующих ключей - он будет производить другой адрес для того же самого ключа, хотя *. Если altcoin поддерживает это от нулевого дня, то выход может быть упрощен дальше. Там не было бы никакой необходимости в каких-либо опкоды на выходе. Они содержат только хэш сценария. Это не только сделает сделки меньше было бы более важно уменьшить размер UXTO. * Внимание: Каждый раз, когда вы работаете с пользовательскими скриптами всегда использовать testnet. Вы можете навсегда потерять деньги из-за поврежденные или сценарии Неверного формата. |
20 мая 2014, 12:34:31 AM | # 6 |
Сообщения: 840
цитировать ответ |
Re: Длина redeemScript
Я был смысл смотреть на это более подробно. Благодарим за предоставленную информацию.
https://en.bitcoin.it/wiki/Transactions дает информацию, но это немного трудно понять. Каждый вход транзакции содержит «ScriptSig» и каждый выход содержит «ScriptPubKey». Механизм проверки является то, что ScriptSig объединяется с «ScriptPubKey» и результат трактуется как сценарий для скриптового движка работать, не так ли? И различие между «платить сценарий хэш» и «платить Публичный хэш» является: В «платить в Публичный хэш» scriptsig состоит из <подпись><Публичных> и инструкция сценария находится в ScriptPubKey. ScriptPubKey говорит что-то вроде OP_DUP, OP_HASH160, <подпись><Публичных> OP_DUP OP_HASH160 В «заплатить скрипт хэш» Scriptsig состоит из OP_HASH160 <гашиш> OP_EQUAL и ScriptPubKey состоит из любой подписи и сценариев с транжира ставит, делая первоначальный сценарий, когда двигатель начинает скрипт будет OP_HASH160 Но двигатель скрипта работает точно так же, независимо и даже не понимает, что есть какая-то разница между этими двумя случаями. Вы должны были бы исправить его, чтобы обнаружить и исключить случай, оплата за Публичные, если вы хотите, чтобы оплата за скрипт-хеш формы, не так ли? Это не важно, что в этих областях, он просто сцепляет их друг с другом и обрабатывает результат как скрипт для запуска. |
20 мая 2014, 1:16:33 AM | # 7 |
Сообщения: 1218
цитировать ответ |
Re: Длина redeemScript
Да, это право (кроме вас есть опечатка в скрипте P2SH и IIRC он восстанавливается на стеке).
Тем не менее, никто не собирается латать из Pay2Pubkeyhash. Я просто указывая на то, что, поскольку он был добавлен после того, как тот факт, чтобы работать с существующим скриптового движка это своего рода клудж. У вас есть скрипт на выходе, который говорит, чтобы использовать второй скрипт в входе (который находится в подписи всех мест), чтобы определить условие, необходимое для погашения выхода. Это было сделано таким образом, чтобы рожок для обуви scripthashes в Bitcoin 2 года после того, как генезис блока без нарушения совместимости с существующими сценариями. Тем не менее, если вы собираетесь построить скриптовый движок, без поддержки старых версий, я думаю, что вы можете видеть, что это не будет построено таким образом. Если начиная с пустой страницы, вывод может содержать ScriptHash. Я не имею в виду ScriptHash похоронена в сценарии, но только ScriptHash (т.е. ScriptHash против OP_HASH160 |