Автоматическая пересылка биткойнов

[amaclin]

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

Суть вот в чем. Есть "скомпроментированные" приватные ключи, на биткойн-адреса которых иногда поступают какие-то небольшие суммы. Самый известный такой адрес это
https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
соответствующий дефалтовому примеру "correct horse battery staple" в брейнваллете
Анализ сделок показывает - что как только кто-то кредитует этот адрес - сразу же кто-то другой оттуда выводит. Некоторые такие выводы делаются с комиссией, а некоторые - по принципу "снежного кома"

Допустим, у меня есть личный (нескомпроментированный) аккаунт ХХХ, на котором лежит 1 BTC.
Я отслеживаю все транзакции в сети, и как только вижу транзакцию перевода на 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T (допустим 0.001 BTC) то еще до включения этой транзакции в блокчейн формирую транзакцию с двумя входами - первый вход: 1.0 BTC с моего аккаунта, второй вход 0.001 с "correct horse". В результате, если я успеваю это сделать до того, как это сделает кто-то другой - на моем аккаунте оказывается 1.001 Это я и называю "снежным комом", когда мы к большому куску "наматываем" еще

Стандартный клиент для этого не подходит - во-первых, он не даст сделать перевод без подтверждений, во-вторых нужно следить за трафиком, и самое плохое - попытка в него импортировать ключ типа "correct horse" вызывает рост wallet.dat и жуткие тормоза.

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

Я уже порядком задолбался писать эту программу. Решил написать в форум, чтоб какой-то стимул появился.
Буду тут если вы не против описывать детали протокола и степень готовности программы.
Разумеется, опенсорс, разумеется все на виду у всех.

[1714768609]

1714768609

[1714768609]

1714768609

[1714768609]

1714768609

[1714768609]

1714768609

[1714768609]

1714768609

[1714768609]

1714768609

[rPman]

createrawtransaction

p.s. я так понимаю, это основывается на том что транзакции без комиссии обрабатываются с большим приоритетом если они большие по монетам?

[neiros]

Я уже порядком задолбался писать эту программу. Решил написать в форум, чтоб какой-то стимул появился.

Знакомое состояние...

Только профит, по-моему, от всей этой затеи более чем сомнительный.

[amaclin]

createrawtransaction

Да, но у этой команды весьма ограниченное применение. ну либо я не разобрался
В общем, я планировал обойтись без RPC-JSON вообще и без bitcoind
Ну или свести по минимуму работу с ними

p.s. я так понимаю, это основывается на том что транзакции без комиссии обрабатываются с большим приоритетом если они большие по монетам?

Это скорее связано с ограничением на транзакции без комиссии.
Логика стандартного клиента примерно такая: умножаем пересылаемую сумму в биткойнах на количество дней сколько эти биткойты лежали без движения. Если получилось больше единицы - можно отправить без комиссии, если меньше - надо заплатить комиссию. На приоритеты я особенно не обращал внимания. Может быть потом еще вернусь к этому вопросу

Только профит, по-моему, от всей этой затеи более чем сомнительный.

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

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

1) перевод на публичный ключ. бывает два варианта - обычный и компрессированный
Скрипт, соответственно, "<data65> OP_CHECKSIG" либо "<data33> OP_CHECKSIG"
По слухам, Сатоши Накамото не знал про то, что можно использовать компрессированный вариант, это уже позднее в клиенте имплементировали. Потратить такой выход (перевести биткойны себе) можно только если мы имеем соответствующий приватный ключ

2) перевод на хэш публичного ключа - это то что мы обычно используем. важно понимать, что у классического и у сокращенного варианта публичного ключа разные хэши. Например, у "correct horse battery staple" обычный адрес 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T , а адрес из компрессированного ключа 1C7zdTfnkzmr13HfA2vNm5SJYRK6nEKyq8
Условия траты те же самые

3) перевод на хэш скрипта (P2SH) - имеет вид "OP_HASH160 <data20> OP_EQUAL"
В блокчейне может быть вы видели переводы на адреса, которые начинаются не на 1, а на 3 - так вот это оно самое
Чуть ниже буду рассказывать подробнее.

4) мультисиг-выходы. Нашел несколько разных вариантов - скрипт заканчивается командой "OP_CHECKMULTISIG"
Вообще не занимался пока ими.

5) все остальные транзакции, которые условно можно назвать нестандартными по выходам. вот тут много всяких вариантов.
я насчитал около 40 разных вариантов output-скриптов, которые опять же можно разделить на категории

5а) unspendable - выход сделан таким образом, что никто и никогда не сможет перевести биткойны. ярким (но не единственным) примером является блок 150951 описание тут: https://bitcointalk.org/index.php?topic=50232.0
из-за ошибки чьего-то самописного софта 2609 BTC были просто отправлены в небытие (не путайте с комиссией)

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

5в) потратить теоретически можно, но непонятно как.

Продолжение следует. Завтра расскажу немного про P2SH-выходы

[yurm]

Суть вот в чем. Есть "скомпроментированные" приватные ключи, на биткойн-адреса которых иногда поступают какие-то небольшие суммы. Самый известный такой адрес это
https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
соответствующий дефалтовому примеру "correct horse battery staple" в брейнваллете
Анализ сделок показывает - что как только кто-то кредитует этот адрес - сразу же кто-то другой оттуда выводит. Некоторые такие выводы делаются с комиссией, а некоторые - по принципу "снежного кома"
...
Стандартный клиент для этого не подходит - во-первых, он не даст сделать перевод без подтверждений, во-вторых нужно следить за трафиком, и самое плохое - попытка в него импортировать ключ типа "correct horse" вызывает рост wallet.dat и жуткие тормоза.

Я тоже думал над этой идеей Считаю, что подобную вещь лучше делать именно на базе стандартного клиента. Т.е., патчить bitcoind. Посмотрите на последние зачисления и списания на этом адресе — интервал между ними всего несколько секунд, явно кто-то уже постарался с таким патчем. Чтобы его опередить, придётся повесить доп. функциональность сразу на получение новой транзакции. И стоит стать полноценным узлом сети, дабы не терять шансы из-за увеличения числа «хопов», пройденных транзакцией кредитования от отправителя до нас.
Да, а чтобы клиент не тормозил при добавлении ключа, можно попробовать опцию "txindex=1".

p.s. я так понимаю, это основывается на том что транзакции без комиссии обрабатываются с большим приоритетом если они большие по монетам?

Да. Точнее, не то чтобы бо́льшим, просто высокоприоритетные транзакции поступают в отдельный буфер независимо от комиссии (размер этого буфера регулируется опцией "blockprioritysize=<n>"). Впрочем, что будет в ближайшем будущем из-за планируемого перевода комиссий на конкурентную основу, не знаю.

[amaclin]

Т.е., патчить bitcoind. Посмотрите на последние зачисления и списания на этом адресе — интервал между ними всего несколько секунд, явно кто-то уже постарался с таким патчем.

Как вы по времени между транзакциями определяете тип клиента который это отправил? 

Я не вижу смысла завязываться на bitcoind.
Тягаться с кем-то ради трех рублей отправленных на 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T смысла нет - меня интересует скорее технология, а е результат. Собрать биткойн из его сорцов я даже и не пытался - у меня нет всех нужных компонентов, а загромождать машитну всякими бустами я не хотел. Пока что достаточно иметь стандартный комплект Qt и в дополнение к нему OpenSSL.

Схема у меня пока приблизительно такая - мой "клиент" (будущий) сам работает по протоколу https://en.bitcoin.it/wiki/Protocol_specification , виден с других узлов сети как обычный узел. При поступлении транзакции он, как и обычный клиент, ее анализирует и при совпадении каких-то условий формирует, подписывает и отправляет в сеть новую транзакцию. Да, для подписи транзакции моему клиенту нужны все приватные ключи и он будет вынужден их хранить в практически незащищенном виде (у обычного клиента при включении шифрации wallet.dat приватные ключи защищены пользовательским паролем). Это действительно самое слабое место, что "левая программа" знает все ваши "приватные ключи" и хранит их несекьюрно. Но для меня эта программа не "левая", и как по-другому сделать я не представляю пока.

Вообще-то я больше склоняюсь к тому, чтобы сделать следующий вариант: на компьютере запущен стандартный bitcoind, а мой клиент соединяется с 127.0.0.1:8333 (то есть не тратит лишний сетевой трафик). Раз в мой клиент поступают только те данные, которые проверил и отрелеил стандартный ктиент - я могу этим данным доверять и практически не проверять - они и так корректны. Обратная сторона медали - если я отправляю нестандартную транзакцию - мне надо чтобы она дошла до пула, а скорее всего она даже не попадет в сеть - ее зарубит за нестандартность bitcoind. Но об этом позже. Сегодня я обещал рассказать о P2SH

Итак, "OP_HASH160 <data20> OP_EQUAL"
Сразу скажу, я могу лажать с терминологией, я так и не понял что называется какими словами.
Так что по-деревенски.
Если мы видим в сети перевод типа указанного, а мы хотим перевести эти биткойны дальше, мы должны сформировать такой скрипт, который положит в стек такое значение, hash160 от которого равен указанному

Понятно я выражаюсь? Если непонятно - повторю еще раз

Все транзакции в биткойне похожи на телевизионную игру, где сперва называют ответы, а потом надо к этим ответам придумать вопросы. Или вспомните Дугласа Адамса и его окончательный ответ на Главный Вопрос Жизни, Вселенной и Всего Такого. У нас есть ответ, но нет вопроса.

Путь перебирать все возможные варианты паттернов, брать от них hash160 - это бессмысленно. 2^160 степени - криптографически надежно. Пойдем с другой стороны. - возьмем hash160 от пустого массива байт, потом возьмем hash160 от всех однобайтных массивов, потом 65536 раз от двубайтных, от трехбайтных... ну дальше будет сложнее, придется остановиться на этом. И посмотрим - нет ли в блокчейне таких хешей. Самое любопытное - они есть! И на некоторых из них даже непотраченные ненулевые балансы!

Заинтриговал? Продолжение следует. Задавайте наводящие вопросы.

[yurm]

Как вы по времени между транзакциями определяете тип клиента который это отправил?  

Не определяю, а лишь подозреваю

Я не вижу смысла завязываться на bitcoind.
Тягаться с кем-то ради трех рублей отправленных на 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T смысла нет - меня интересует скорее технология, а е результат. Собрать биткойн из его сорцов я даже и не пытался - у меня нет всех нужных компонентов, а загромождать машитну всякими бустами я не хотел. Пока что достаточно иметь стандартный комплект Qt и в дополнение к нему OpenSSL.

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

Загромождение машины «всякими бустами» — это отдельный холивар, особенно с учётом наличия всяких bcp, но сейчас не о нём А вот о безопасности уже скомпрометированных ключей я бы не особо беспокоился.

Итак, "OP_HASH160 <data20> OP_EQUAL"
Сразу скажу, я могу лажать с терминологией, я так и не понял что называется какими словами.
Так что по-деревенски.
Если мы видим в сети перевод типа указанного, а мы хотим перевести эти биткойны дальше, мы должны сформировать такой скрипт, который положит в стек такое значение, hash160 от которого равен указанному
…
Путь перебирать все возможные варианты паттернов, брать от них hash160 - это бессмысленно. 2^160 степени - криптографически надежно. Пойдем с другой стороны. - возьмем hash160 от пустого массива байт, потом возьмем hash160 от всех однобайтных массивов, потом 65536 раз от двубайтных, от трехбайтных... ну дальше будет сложнее, придется остановиться на этом. И посмотрим - нет ли в блокчейне таких хешей. Самое любопытное - они есть! И на некоторых из них даже непотраченные ненулевые балансы!

Тут проблема в том, что для новых транзакций (после 1 апреля 2012) такая последовательность ("OP_HASH160 <data20> OP_EQUAL") считается особой и обрабатывается отдельно. Если раньше для траты достаточно было в scriptSig просто положить такое значение, чей хэш был бы равен <data20>, то теперь это значение само считается скриптом; сейчас после проверки на совпадение хэша оно подставляется на место последовательности "OP_HASH160 <data20> OP_EQUAL" и теперь уже оно становится частью общего скрипта («ребуса»).
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
В общем, не факт, что эти ненулевые балансы можно будет вообще извлечь.

P.S. Да, чуть не забыл — стандартный клиент умеет делать перевод без подтверждений, надо только пользоваться createrawtransaction/signrawtransaction/sendrawtransaction. Кстати, использование signrawtransaction позволяет не добавлять скомпрометированный приватный ключ (типа sha256(«correct horse battery staple»)) в wallet.dat, а просто указывать его в командной строке.

[mrmaks]

Вот что пишет Wiki про Brainwallett

so hackers can collectively try multiple trillions of passwords every second in the privacy of their own homes with the very same equipment they use for mining bitcoins (in the usual sense). Your bank might tell you that a 10 character password with uppercase, lowercase, numbers and symbols is a strong password, but it is not strong enough to secure a brainwallet. A password that might be strong enough for traditional banking or a social website is typically unacceptable for a brainwallet.

Поэтому стоит ли игра свеч ? Все украдено до нас.
С такой же вероятностью можно просто генерить коллизии адресов. 10^45 не так уж много )

[yurm]

so hackers can collectively try multiple trillions of passwords every second in the privacy of their own homes with the very same equipment they use for mining bitcoins (in the usual sense). Your bank might tell you that a 10 character password with uppercase, lowercase, numbers and symbols is a strong password, but it is not strong enough to secure a brainwallet. A password that might be strong enough for traditional banking or a social website is typically unacceptable for a brainwallet.

Поэтому стоит ли игра свеч ? Все украдено до нас.
С такой же вероятностью можно просто генерить коллизии адресов. 10^45 не так уж много )

Если под "very same equipment" имеются в виду sha256-майнинговые ASICи, то это ни разу не так. Впрочем, речь в топике не о поиске адресов, соответствующих слабым паролям, а о слежении за уже скомпрометированными — вдруг кто прикола ради на них битки переведёт.

[amaclin]

В общем, не факт, что эти ненулевые балансы можно будет вообще извлечь.

Да, пока у меня получилось это сделать только на тестнете
Я удивлен (впрочем не очень сильно) зачем нужен тестнет, который по функциональности отличается от основы.

P.S. Да, чуть не забыл — стандартный клиент умеет делать перевод без подтверждений, надо только пользоваться createrawtransaction/signrawtransaction/sendrawtransaction.

Для "снежного кома" (это пока моя цель) надо подписывать транзакции ключем, на котором не "dust"-количество денег. И так как это делать надо автоматически (то есть не ждать подтверждения пользователя, когда он подойдет к компу и введет свой пароль на wallet.dat) - то это будет весьма уязвимая (для троянов и прочего) часть программы.

Вчера попытался вывести себе какую-то мелочь с P2SH-выходов
Пришлось немного запатчить дефалтовый клиент, а то он не хотел принимать нестандартно оформленные транзакции. Потом долго искал IP пула Eligius - вроде бы единственные майнеры, которые включают нестандартные транзакции в свои блоки. Нашел вот этот адрес -connect=68.168.105.168 , но во-первых у меня нет полной уверенности, что это Eligius (хотя по тому, что в логах много хлама при коннекте именно к этому IP - это он), во-вторых, я не уверен, что мой патченный клиент пересылает им мои самосформированные транзакции (надо снифить мой исходящий сетевой трафик). В-третьих, не факт действительно, что даже у Eligius не стоят серьезные проверки на "нестандартность" транзакций.

[icreator]

В общем, не факт, что эти ненулевые балансы можно будет вообще извлечь.

Да, пока у меня получилось это сделать только на тестнете
Я удивлен (впрочем не очень сильно) зачем нужен тестнет, который по функциональности отличается от основы.

P.S. Да, чуть не забыл — стандартный клиент умеет делать перевод без подтверждений, надо только пользоваться createrawtransaction/signrawtransaction/sendrawtransaction.

Для "снежного кома" (это пока моя цель) надо подписывать транзакции ключем, на котором не "dust"-количество денег. И так как это делать надо автоматически (то есть не ждать подтверждения пользователя, когда он подойдет к компу и введет свой пароль на wallet.dat) - то это будет весьма уязвимая (для троянов и прочего) часть программы.

Вчера попытался вывести себе какую-то мелочь с P2SH-выходов
Пришлось немного запатчить дефалтовый клиент, а то он не хотел принимать нестандартно оформленные транзакции. Потом долго искал IP пула Eligius - вроде бы единственные майнеры, которые включают нестандартные транзакции в свои блоки. Нашел вот этот адрес -connect=68.168.105.168 , но во-первых у меня нет полной уверенности, что это Eligius (хотя по тому, что в логах много хлама при коннекте именно к этому IP - это он), во-вторых, я не уверен, что мой патченный клиент пересылает им мои самосформированные транзакции (надо снифить мой исходящий сетевой трафик). В-третьих, не факт действительно, что даже у Eligius не стоят серьезные проверки на "нестандартность" транзакций.

в конфиге пиши
connect=елигнус
и смотри есть ли связь с сетью

[yurm]

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

Обкатка новых технологий.

Для "снежного кома" (это пока моя цель) надо подписывать транзакции ключем, на котором не "dust"-количество денег. И так как это делать надо автоматически (то есть не ждать подтверждения пользователя, когда он подойдет к компу и введет свой пароль на wallet.dat) - то это будет весьма уязвимая (для троянов и прочего) часть программы.

Мда, слона-то я и не приметил. Впрочем, если очень беспокоитесь за свои монеты, можно сделать так: заранее подписать транзакцию с одним входом и одним выходом 1BTC→0.99BTC (со своего на свой адрес) с использованием sighash=SINGLE|ANYONECANPAY, не передавая её в сеть; когда на одном из наблюдаемых адресов появятся монеты, дорисовать вход и выход к подготовленной транзакции (например, если появилось 0.001BTC, то получится транзакция 1BTC+0.001BTC→0.99BTC+0.011BTC) и подписать новый вход с любым sighash. Увести смогут максимум 0.01BTC

Вчера попытался вывести себе какую-то мелочь с P2SH-выходов
…
В-третьих, не факт действительно, что даже у Eligius не стоят серьезные проверки на "нестандартность" транзакций.

Отпишитесь по результатам. Мне почему-то кажется, что не получится — если в scriptSig передано только одно значение, соответствующее хэшу в scriptPubKey'ном "OP_HASH160 <data20> OP_EQUAL", то это не нестандартная, а некорректная транзакция, разве что этим значением не закодирован тривиальный скрипт, разрешающий тратить монеты кому попало.

[amaclin]

Ладно, еще сегодня-завтра поковыряюсь с нестандартными транзакциями
Потом, наверно, вернусь к основной цели
Вот смотрите что получается

транзакция
http://webbtc.com/tx/6e058c1d413cb5c5a42b24960bdbc746c02dc817dace651c03fbbcbb90da8cf1
(удобно использовать webbtc - позволяет сохранить в bin-формате)
выход #2 : OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL - израсходован

смотрим как его израсходовали. транзакция
http://webbtc.com/tx/567a53d1ce19ce3d07711885168484439965501536d0d0294c5d46d46c10e53b


0000000000: 01 00 00 00-01-F1 8C DA  90 BB BC FB 03 1C 65 CE
0000000010: DA 17 C8 2D C0 46 C7 DB  0B 96 24 2B A4 C5 B5 3C
0000000020: 41 1D 8C 05 6E-02 00 00  00-0C 51 01 81 08 6E 87
0000000030: 91 69 90 7C 90 87 FF FF  FF FF-01-A0 BB 0D 00 00
0000000040: 00 00 00-19-76 A9 14 9B  C0 BB DD 30 24 DA 4D 0C
0000000050: 38 ED 1A EC F5 C6 8D D1  D3 FA 12 88 AC-00 00 00
0000000060: 00

Я уже научился читать дампы просто глядя на них.
Версия транзакции 1
Инпутов 1
Дальше хеш F18C...056E - в другом порядке байт
Выход #2
Длина скрипта 0x0C
Собственно скрипт 51 01 81 08 6E 87 91 69 90 7C 90 87 - не так уж важно что он делает, раз это сработало
Sequence = -1
Выходов = 1
Amount= 0x0dbba0 (little-endian)
Дальше ничем непримечательный скрипт длиной 0x19 - перевод на хеш пубкея
lock = 0

Теперь смотрим на транзакцию
http://webbtc.com/tx/9e15fb351d034b76ecab5a2d9839a115cc43094321c3bbb6cbc650bb4ea41593
Обращаем внимание, что у этой транзакции такой же самый скрипт выхода:
OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL
Но он не израсходован.

Формирую raw-транзакцию

Code:

01 00 00 00 -01-57 39 f7  66 ec 33 a3  e7 2b 6a 5d
59 dd 91 a5  83 cd cf d1  92 35 e9 cb  9e d0 e0 98
d5 55 73 a3  a4-01 00 00  00-0c-51 01  81 08 6e 87
91 69 90 7c  90 87-ff ff  ff ff-01-50  a3 00 00 00
00 00 00-19  76 a9 14 92  b8 c3 a5 6f  ac 12 1d dc
df fb c8 5b  02 fb 9e f6  81 03 8a 88  ac-00 00 00
00

По идее она должна сработать, если отправить ее на Eligius.st



sendrawtransaction 01000000015739f766ec33a3e72b6a5d59dd91a583cdcfd19235e9cb9ed0e098d55573a3a401000 0000c510181086e879169907c9087ffffffff0150a30000000000001976a91492b8c3a56fac121d dcdffbc85b02fb9ef681038a88ac00000000

7540ae6c483d904488da765294f5d36994a042f44a4d5bc2c84c034cbfd35da3

[yurm]

Собственно скрипт 51 01 81 08 6E 87 91 69 90 7C 90 87 - не так уж важно что он делает, раз это сработало
…
Теперь смотрим на транзакцию
http://webbtc.com/tx/9e15fb351d034b76ecab5a2d9839a115cc43094321c3bbb6cbc650bb4ea41593
Обращаем внимание, что у этой транзакции такой же самый скрипт выхода:
OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL
Но он не израсходован.
…
По идее она должна сработать, если отправить ее на Eligius.st

В данном конкретном случае — да, scriptSig ("51 01 81 08 6E 87 91 69 90 7C 90 87") соответствует такой последовательности команд:

51	OP_1	"push 1"
01 81		"push -1"
08 6E 87 91 69 90 7C 90 87	redeemScript	"push 6E 87 91 69 90 7C 90 87"

Хэш redeemScript'а — это, собственно, и есть fe441065b6532231de2fac563152205ec4f59c74
Теперь сам redeemScript:

6E	OP_2DUP
87	OP_EQUAL
91	OP_NOT
69	OP_VERIFY
90	OP_ABS
7C	OP_SWAP
90	OP_ABS
87	OP_EQUAL

Т.е. redeemScript требует, чтобы положенные в стек числа (1 и -1 в нашем случае) были равны по модулю и противоположны по знаку. Эксперимента ради их можно поменять на 2 и -2, например. Реальные redeemScript'ы с некопеечными балансами обычно заканчиваются командой OP_CHECKMULTISIG (как в примере), простым копированием scriptSig'а оттуда монеты не снять.

P.S. Да, сама по себе приведённая вами транзакция (txid==7540ae6c483d904488da765294f5d36994a042f44a4d5bc2c84c034cbfd35da3) не будет принята, ибо минимальная комиссия здесь равна размеру переводимых средств Только «снежным комом».

[amaclin]

Я немного в предыдущем моем сообщении мог запутать вас.
Ссылку вам дал на транзакцию
http://webbtc.com/tx/9e15fb351d034b76ecab5a2d9839a115cc43094321c3bbb6cbc650bb4ea41593
а ввыводить моя raw-транзакция будет из
http://webbtc.com/tx/a4a37355d598e0d09ecbe93592d1cfcd83a591dd595d6a2be7a333ec66f73957
там точно такой же неизрасходованный OP_HASH160 fe441065b6532231de2fac563152205ec4f59c74 OP_EQUAL

В общем, у меня пока нашлось поиском по блокчейну 7 таких неизрасходованных выходов суммой аж цельных BTC0.03 
На тестнете прекрасно все выводится на свой адрес, на мейннете проблемы с нестандартными транзакциями - обычные клиенты их не пересылают, так что для добавления транзакции в блок после "патченья" клиента надо еще как утверждает вики соединиться с Elegius
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

И даже при этом не выводится. Не могу понять в чем дело. Возможно, Elegius хранит в своем пуле корректные и бесплатные/низкоприоритетные транзакции, но не добавляет их в блок из-за их низкого приоритета. В принципе - имеет на то полное право. А другие узлы просто не принимают такие транзакции. Поэтому теоретически средства могли зависнуть "навсегда" (по крайней мере пока не найдется другой "добрый майнер" на что надежда слабая)

Вопрос по приведенному мной скрипту 51 01 81 08 6E 87 91 69 90 7C 90 87
Кладем в стек +1, кладем в стек -1, кладем в стек "6E 87 91 69 90 7C 90 87"
С какой стати после этого надо выполнять top-элемент стека как скрипт?

Да, кстати. Если кому-то нужны BTC на тестовой сети - могу дать. За время экспериментов на тестнете я себе "напереводил" достаточно много - могу поделиться бесплатно, то есть даром

[yurm]

И даже при этом не выводится. Не могу понять в чем дело. Возможно, Elegius хранит в своем пуле корректные и бесплатные/низкоприоритетные транзакции, но не добавляет их в блок из-за их низкого приоритета. В принципе - имеет на то полное право.

«Снежным комом» пробовали? По крайней мере приоритет выше будет. Рекомендую подождать пару дней, если не пройдёт — удалить транзакцию из wallet.dat и повторить с одним крупным инпутом (кстати, вы в курсе, что транзакцию можно подписывать последовательно в разных кошельках и таким образом избежать засвечивания приватных ключей с большим балансом?).

Вопрос по приведенному мной скрипту 51 01 81 08 6E 87 91 69 90 7C 90 87
Кладем в стек +1, кладем в стек -1, кладем в стек "6E 87 91 69 90 7C 90 87"
С какой стати после этого надо выполнять top-элемент стека как скрипт?

Повторюсь:

Тут проблема в том, что для новых транзакций (после 1 апреля 2012) такая последовательность ("OP_HASH160 <data20> OP_EQUAL") считается особой и обрабатывается отдельно. Если раньше для траты достаточно было в scriptSig просто положить такое значение, чей хэш был бы равен <data20>, то теперь это значение само считается скриптом; сейчас после проверки на совпадение хэша оно подставляется на место последовательности "OP_HASH160 <data20> OP_EQUAL" и теперь уже оно становится частью общего скрипта («ребуса»).
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

Точнее, top-элемент стека, да. Именно от него хэш (OP_HASH160) считается и сравнивается.

[amaclin]

«Снежным комом» пробовали? По крайней мере приоритет выше будет. Рекомендую подождать пару дней, если не пройдёт — удалить транзакцию из wallet.dat и повторить с одним крупным инпутом (кстати, вы в курсе, что транзакцию можно подписывать последовательно в разных кошельках и таким образом избежать засвечивания приватных ключей с большим балансом?).

Нет, еще не пробовал. Рисковать на mainnet "живыми" деньгами немного ссыкотно. Да и "большого баланса" как такового у меня нет. Я ж говорю - биткойном заинтересовался только в конце прошлого года. Я даже могу сказать почему до этого это было вне сферы моих интересов - когда я впервые увидел публикации несколько лет назад там были слова что-то типа "...позволяет пересылать на IP-адрес..." - это я счел потенциальной уязвимостью (а это она и есть, так как все идет по открытым каналам и легко перехватывается) и не обратил внимание на технологию в целом.

Тут проблема в том, что для новых транзакций (после 1 апреля 2012) такая последовательность ("OP_HASH160 <data20> OP_EQUAL") считается особой и обрабатывается отдельно.

Говорила мне мама: "Учи английский"

Вообще-то вставление "костылей" подобного рода в алгоритм - странный прецендент.
В какой-то момент разработчики предложат считать последовательность
"OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG" тоже "особой" и таким образом "поднимут из небытия" биткойны, которые уплыли в Лету ( см. https://bitcointalk.org/index.php?topic=50232.0 ) Большинство пользователей просто скачает новый клиент, тем самым проголосовав "за" изменение в алгоритме.

[amaclin]

Смотрю внимательно пока что их себя представляет BIP-16
Пока нашел "весёлую транзакцию", которая была валидной по "старым правилам", но перестала быть валидной по "новым правилам".
https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться

[icreator]

а как удалить транзакцию из wallet.dat ??

[yurm]

Вообще-то вставление "костылей" подобного рода в алгоритм - странный прецендент.
В какой-то момент разработчики предложат считать последовательность
"OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG" тоже "особой" и таким образом "поднимут из небытия" биткойны, которые уплыли в Лету ( см. https://bitcointalk.org/index.php?topic=50232.0 )

Это вряд ли. Одной из целей такого «костыля», насколько я понимаю, было сокращение размера scriptPubKey. В будущем, когда мультисигнатурные адреса будут часто использовать на практике и когда блокчейн разрастётся до неприличных размеров, большинство узлов (в т.ч. условно-полноценных) будут хранить только последние блоки и список непотраченных выходов. И вот тогда будет разница, хранить

52410491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db5 5bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f864104865c40293a680cb9c020 e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8 722084861c5c3291ccffef4ec687441048d2455d2403e08708fc1f556002f1b6cd83f992d085097 f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d46 21353ae

или

a914f815b036d9bbbce5e9f2a00abd1bf3dc91e9551087

Сама по себе последовательность "OP_HASH160 <data20> OP_EQUAL" изначально, как вы верно заметили, являлась потенциальной уязвимостью, ибо там ничего не подписывалось и любой майнер мог заменить адрес получения на свой. А среди таких потенциально уязвимых последовательностей эта, пожалуй, одна из самых коротких, включающих хэш.

https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться

Это да, последний майнер попытался её включить в блок аж через полгода, в октябре Насколько я понял тот скрипт, по новым правилам там нужно перед redeemScript'ом добавить подпись приватным ключом, соответствующим публичному "029c7187ecea7f09146820075c3a8de5d33ffbc293b63228ea1667c8d3796aff3f" (соответственно, адресу "1GgPeoTkagdppaZ1TbeCSPcihFhr4HRue2").