Topic: Автоматическая пересылка биткойнов - page 4. (Read 19681 times)

Я немного в предыдущем моем сообщении мог запутать вас.
Ссылку вам дал на транзакцию
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 на тестовой сети - могу дать. За время экспериментов на тестнете я себе "напереводил" достаточно много - могу поделиться бесплатно, то есть даром

В данном конкретном случае — да, 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) не будет принята, ибо минимальная комиссия здесь равна размеру переводимых средств Только «снежным комом».

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

транзакция
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-транзакцию

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



sendrawtransaction 01000000015739f766ec33a3e72b6a5d59dd91a583cdcfd19235e9cb9ed0e098d55573a3a401000 0000c510181086e879169907c9087ffffffff0150a30000000000001976a91492b8c3a56fac121d dcdffbc85b02fb9ef681038a88ac00000000

7540ae6c483d904488da765294f5d36994a042f44a4d5bc2c84c034cbfd35da3

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5а) unspendable - выход сделан таким образом, что никто и никогда не сможет перевести биткойны. ярким (но не единственным) примером является блок 150951 описание тут: https://bitcointalksearch.org/topic/a-lot-of-btc-just-destroyed-block-150951-50232
из-за ошибки чьего-то самописного софта 2609 BTC были просто отправлены в небытие (не путайте с комиссией)

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

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

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

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

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

createrawtransaction

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

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

Суть вот в чем. Есть "скомпроментированные" приватные ключи, на биткойн-адреса которых иногда поступают какие-то небольшие суммы. Самый известный такой адрес это
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 и жуткие тормоза.

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

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