Bitcoin Forum
July 17, 2019, 11:48:50 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: Автоматическая пересылка биткойнов  (Read 19485 times)
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 12, 2014, 04:57:24 AM
 #1

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

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

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

Я уже порядком задолбался писать эту программу. Решил написать в форум, чтоб какой-то стимул появился.
Буду тут если вы не против описывать детали протокола и степень готовности программы.
Разумеется, опенсорс, разумеется все на виду у всех.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563364130
Hero Member
*
Offline Offline

Posts: 1563364130

View Profile Personal Message (Offline)

Ignore
1563364130
Reply with quote  #2

1563364130
Report to moderator
1563364130
Hero Member
*
Offline Offline

Posts: 1563364130

View Profile Personal Message (Offline)

Ignore
1563364130
Reply with quote  #2

1563364130
Report to moderator
rPman
Legendary
*
Offline Offline

Activity: 1120
Merit: 1003


View Profile WWW
February 12, 2014, 09:15:08 AM
 #2

createrawtransaction

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
neiros
Legendary
*
Offline Offline

Activity: 2492
Merit: 1043



View Profile WWW
February 12, 2014, 09:47:25 AM
 #3

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

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

amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 12, 2014, 07:34:09 PM
 #4

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

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

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

Сперва пришлось просканировать 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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 12, 2014, 09:49:55 PM
Last edit: February 12, 2014, 10:04:08 PM by yurm
 #5

Суть вот в чем. Есть "скомпроментированные" приватные ключи, на биткойн-адреса которых иногда поступают какие-то небольшие суммы. Самый известный такой адрес это
https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
соответствующий дефалтовому примеру "correct horse battery staple" в брейнваллете
Анализ сделок показывает - что как только кто-то кредитует этот адрес - сразу же кто-то другой оттуда выводит. Некоторые такие выводы делаются с комиссией, а некоторые - по принципу "снежного кома"
...
Стандартный клиент для этого не подходит - во-первых, он не даст сделать перевод без подтверждений, во-вторых нужно следить за трафиком, и самое плохое - попытка в него импортировать ключ типа "correct horse" вызывает рост wallet.dat и жуткие тормоза.
Я тоже думал над этой идеей Smiley Считаю, что подобную вещь лучше делать именно на базе стандартного клиента. Т.е., патчить bitcoind. Посмотрите на последние зачисления и списания на этом адресе — интервал между ними всего несколько секунд, явно кто-то уже постарался с таким патчем. Чтобы его опередить, придётся повесить доп. функциональность сразу на получение новой транзакции. И стоит стать полноценным узлом сети, дабы не терять шансы из-за увеличения числа «хопов», пройденных транзакцией кредитования от отправителя до нас.
Да, а чтобы клиент не тормозил при добавлении ключа, можно попробовать опцию "txindex=1".
p.s. я так понимаю, это основывается на том что транзакции без комиссии обрабатываются с большим приоритетом если они большие по монетам?
Да. Точнее, не то чтобы бо́льшим, просто высокоприоритетные транзакции поступают в отдельный буфер независимо от комиссии (размер этого буфера регулируется опцией "blockprioritysize=<n>"). Впрочем, что будет в ближайшем будущем из-за планируемого перевода комиссий на конкурентную основу, не знаю.

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 13, 2014, 04:35:58 AM
 #6

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

Я не вижу смысла завязываться на 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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 13, 2014, 05:28:36 AM
Last edit: February 13, 2014, 05:44:02 AM by yurm
 #7

Как вы по времени между транзакциями определяете тип клиента который это отправил?  Shocked
Не определяю, а лишь подозреваю Smiley

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

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

Итак, "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, а просто указывать его в командной строке.

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
mrmaks
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
February 13, 2014, 11:09:35 AM
Last edit: February 13, 2014, 11:41:03 AM by mrmaks
 #8

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

Quote
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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 13, 2014, 05:21:33 PM
 #9

Quote
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и, то это ни разу не так. Впрочем, речь в топике не о поиске адресов, соответствующих слабым паролям, а о слежении за уже скомпрометированными — вдруг кто прикола ради на них битки переведёт.

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 14, 2014, 05:11:42 AM
 #10

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

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

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

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

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

icreator
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002



View Profile WWW
February 14, 2014, 07:07:28 AM
 #11

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

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

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

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

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



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

Erachain Blockchain is fully ready for use Digital Ecosystem based on blockchain technology for business and government with low transaction costs, identification and built-in functions.
+Decentralized exchange of tokens in Erachain
yurm
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 14, 2014, 07:51:10 AM
 #12

Я удивлен (впрочем не очень сильно) зачем нужен тестнет, который по функциональности отличается от основы.
Обкатка новых технологий.
Для "снежного кома" (это пока моя цель) надо подписывать транзакции ключем, на котором не "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", то это не нестандартная, а некорректная транзакция, разве что этим значением не закодирован тривиальный скрипт, разрешающий тратить монеты кому попало.

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 15, 2014, 09:18:41 PM
 #13

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

транзакция
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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 16, 2014, 01:52:48 AM
Last edit: February 16, 2014, 02:05:12 AM by yurm
 #14

Собственно скрипт 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") соответствует такой последовательности команд:
51OP_1"push 1"
01 81"push -1"
08 6E 87 91 69 90 7C 90 87redeemScript"push 6E 87 91 69 90 7C 90 87"
Хэш redeemScript'а — это, собственно, и есть fe441065b6532231de2fac563152205ec4f59c74
Теперь сам redeemScript:
6EOP_2DUP
87OP_EQUAL
91OP_NOT
69OP_VERIFY
90OP_ABS
7COP_SWAP
90OP_ABS
87OP_EQUAL
Т.е. redeemScript требует, чтобы положенные в стек числа (1 и -1 в нашем случае) были равны по модулю и противоположны по знаку. Эксперимента ради их можно поменять на 2 и -2, например. Реальные redeemScript'ы с некопеечными балансами обычно заканчиваются командой OP_CHECKMULTISIG (как в примере), простым копированием scriptSig'а оттуда монеты не снять.

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

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 16, 2014, 07:22:20 AM
 #15

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

В общем, у меня пока нашлось поиском по блокчейну 7 таких неизрасходованных выходов суммой аж цельных BTC0.03  Grin
На тестнете прекрасно все выводится на свой адрес, на мейннете проблемы с нестандартными транзакциями - обычные клиенты их не пересылают, так что для добавления транзакции в блок после "патченья" клиента надо еще как утверждает вики соединиться с 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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 16, 2014, 11:56:46 AM
 #16

И даже при этом не выводится. Не могу понять в чем дело. Возможно, 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) считается и сравнивается.

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 16, 2014, 12:37:02 PM
 #17

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

Quote
Тут проблема в том, что для новых транзакций (после 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
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000


View Profile
February 16, 2014, 01:41:39 PM
 #18

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

Activity: 1372
Merit: 1002



View Profile WWW
February 16, 2014, 04:36:40 PM
 #19

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

Erachain Blockchain is fully ready for use Digital Ecosystem based on blockchain technology for business and government with low transaction costs, identification and built-in functions.
+Decentralized exchange of tokens in Erachain
yurm
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 16, 2014, 04:42:43 PM
 #20

Вообще-то вставление "костылей" подобного рода в алгоритм - странный прецендент.
В какой-то момент разработчики предложат считать последовательность
"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
или
Quote
a914f815b036d9bbbce5e9f2a00abd1bf3dc91e9551087
Сама по себе последовательность "OP_HASH160 <data20> OP_EQUAL" изначально, как вы верно заметили, являлась потенциальной уязвимостью, ибо там ничего не подписывалось и любой майнер мог заменить адрес получения на свой. А среди таких потенциально уязвимых последовательностей эта, пожалуй, одна из самых коротких, включающих хэш.
https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их Smiley
Мораль - надо вовремя апгрейдиться Smiley
Это да, последний майнер попытался её включить в блок аж через полгода, в октябре Smiley Насколько я понял тот скрипт, по новым правилам там нужно перед redeemScript'ом добавить подпись приватным ключом, соответствующим публичному "029c7187ecea7f09146820075c3a8de5d33ffbc293b63228ea1667c8d3796aff3f" (соответственно, адресу "1GgPeoTkagdppaZ1TbeCSPcihFhr4HRue2").

BTC donation:1DPUVJWeN2CNgJvRx5MtbsYWnFsKHxXWrc
Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!