18 мая 2014, 9:05:09 PM   # 1
 
 
Сообщений: 50
Цитировать по имени
цитировать ответ
по умолчанию Re: Длина redeemScript

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


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Какова максимальная длина redeemScript? Я думаю, что это 8 байт, но я не знаю.
jbis1 сейчас офлайн Пожаловаться на jbis1   Ответить с цитированием Мультицитирование сообщения от jbis1 Быстрый ответ на сообщение jbis1


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


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

Это сообщение было слишком стар и продут
Evil-Knievel сейчас офлайн Пожаловаться на Зла-Knievel   Ответить с цитированием Мультицитирование сообщения от Evil-Knievel Быстрый ответ на сообщение Evil-Knievel

19 мая 2014, 6:23:59 PM   # 4
 
 
Сообщения: 840
Цитировать по имени
цитировать ответ
по умолчанию Re: Длина redeemScript

Когда вы говорите о «redeemscript» Вы должны быть конкретными, какие транзакции вы говорите об этом.

Скажем, у вас есть транзакции B, которая использует в качестве своих входов выходов из транзакции A. 

В транзакции А, «redeemscript» будет фиксированной длиной хэш. (8 байт? 16? Я должен был бы пойти взгляд)

В транзакции B, это две части; первая часть (сценарий) имеет хэш и совпадают с хэш заданной в транзакции A. Обе части (сценарий и данных) должны быть загружены в стек и затем двигатель скрипт запускается. 

Во всяком случае, скрипты ограничены до 201 шагов. 



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

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 OP_EQUALVERIFY OP_CHECKSIG
Pay2ScriptHash Tx: OP_HASH160 OP_EQUAL

Когда технические документы относятся к 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. Вы можете навсегда потерять деньги из-за поврежденные или сценарии Неверного формата.
DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes

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_EQUALVERIFY, OP_CHECKSIG, поэтому первоначальный «сценарий», когда двигатель запускается скрипт

<подпись><Публичных> OP_DUP OP_HASH160 OP_EQUALVERIFY, OP_CHECKSIG.

В «заплатить скрипт хэш» Scriptsig состоит из OP_HASH160 <гашиш> OP_EQUAL и ScriptPubKey состоит из любой подписи и сценариев с транжира ставит, делая первоначальный сценарий, когда двигатель начинает скрипт будет

OP_HASH160 OP_EQUALVERIFY ... подпись .... ... пользовательские расходы скрипт .... 

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

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

20 мая 2014, 1:16:33 AM   # 7
 
 
Сообщения: 1218
Цитировать по имени
цитировать ответ
по умолчанию Re: Длина redeemScript

Да, это право (кроме вас есть опечатка в скрипте P2SH и IIRC он восстанавливается на стеке).

Тем не менее, никто не собирается латать из Pay2Pubkeyhash. Я просто указывая на то, что, поскольку он был добавлен после того, как тот факт, чтобы работать с существующим скриптового движка это своего рода клудж. У вас есть скрипт на выходе, который говорит, чтобы использовать второй скрипт в входе (который находится в подписи всех мест), чтобы определить условие, необходимое для погашения выхода. Это было сделано таким образом, чтобы рожок для обуви scripthashes в Bitcoin 2 года после того, как генезис блока без нарушения совместимости с существующими сценариями.  

Тем не менее, если вы собираетесь построить скриптовый движок, без поддержки старых версий, я думаю, что вы можете видеть, что это не будет построено таким образом. Если начиная с пустой страницы, вывод может содержать ScriptHash. Я не имею в виду ScriptHash похоронена в сценарии, но только ScriptHash (т.е. ScriptHash против OP_HASH160 OP_EQUALVERIFY). Тогда все входы будут иметь поле для redeemScript и там будет отдельная подпись. Все операции будут иметь тот же формат для входов и выходов. Если ничего другого не имело бы изображая чертову штуку намного проще.
DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW