Разумеется, ловить чужие транзакции с нестандартными выходами и посылать свои транзакции с нестандартными входами (дайте мне кривой молоток забивать кривые гвозди) надо именно приконнектившись к Eliguis, а не к своему локалхосту. Во всех остальных местах рыбы нет - ловить нечего. Даже если существуют имплементации, которые пересылают нестандартные транзакции - как их найти среди всех узлов сети? Перебирать все узлы сети и проверять по юзер-агенту? Бесполезно. Лучше как контролер на "конечной остановке" стоять и "проверять билетики". Понятно, что надо успеть раньше, чем это сделает кто-то другой. Ну и если кто-то посылает транзакцию с нестандартным выходом и сразу вслед за ней сам выводит это себе - то тут мой шанс "вклиниться" нулевой.
Пришлось сегодня взяться за серьезную переделку кода - надо более корректно строить основную цепочку блоков (сперва читаю с диска blk***.dat, потом прозрачно для других частей ядра переключаюсь на получение данных по сети с одного или нескольких пиров) с возможностью "отката" на несколько блоков назад если находится более длинное продолжение. В общем, на словах все понятно. Но чувствую себя как собака - всё понимаю, а выразить словами не могу.
Topic: Автоматическая пересылка биткойнов - page 3. (Read 19681 times)
В принципе, как раз возможен ответ на мой вопрос - почему мои raw-транзакции не проходят через веб-форму на eligius.st - они не проходят валидацию, потому что пул их справедливо считает double-spending-ом транзакций из мемори-пула.
Скорее всего да, вроде распространяемые double-spend транзакции в bitcoin-qt отбрасываются, что логично. В общем, кто первый до Eligius добежит, тот и молодец 
Кстати, в этом плане такая архитектура:Софтина прожевывает существующий блокчейн, потом коннектится к пиру (пиром пока выступает запущенный на моей же тачке Bitcoin-Qt в тестовом режиме), и парсит все что от пира приходит.
Если приходит что-то "интересное" - может выполнить какое-то действие, например сразу перевести биткойны "снежным комом" в другое место.
может не дать желаемого эффекта — в момент, когда что-то "интересное" придёт к софтине, оно же в неизменённом виде одновременно придёт и к Eligius'у, а изменённую транзакцию он не пропустит как double-spend. Если приходит что-то "интересное" - может выполнить какое-то действие, например сразу перевести биткойны "снежным комом" в другое место.
половину слов не понимаю, но читать очень интересно
спасибо
спасибо
Кажется, я таки нашел пул Eligius 
По крайней мере нечто очень похожее на него
Запрашиваю у этого хоста командой mempool список его транзакций и получаю в ответ транзакции 1Enjoy & 1Sochi
Делаю вывод, что этот хост принял данные транзакции, хоть они и не должны передаваться по сети (нестандартные из-за большого количества пыли), но до сих пор держит их в памяти. Причем не включает их в блок, потому что опять же - это спам. Ну, это их право засирать себе память и не чистить ее, пока не понадобится. В выходные буду анализировать что в этом мемпуле лежит и можно ли туда что-нибудь добавить свое.
В принципе, как раз возможен ответ на мой вопрос - почему мои raw-транзакции не проходят через веб-форму на eligius.st - они не проходят валидацию, потому что пул их справедливо считает double-spending-ом транзакций из мемори-пула.
По крайней мере нечто очень похожее на него
Запрашиваю у этого хоста командой mempool список его транзакций и получаю в ответ транзакции 1Enjoy & 1Sochi
Делаю вывод, что этот хост принял данные транзакции, хоть они и не должны передаваться по сети (нестандартные из-за большого количества пыли), но до сих пор держит их в памяти. Причем не включает их в блок, потому что опять же - это спам. Ну, это их право засирать себе память и не чистить ее, пока не понадобится. В выходные буду анализировать что в этом мемпуле лежит и можно ли туда что-нибудь добавить свое.
В принципе, как раз возможен ответ на мой вопрос - почему мои raw-транзакции не проходят через веб-форму на eligius.st - они не проходят валидацию, потому что пул их справедливо считает double-spending-ом транзакций из мемори-пула.
Ну вы как хотите, а я двигаюсь потихоньку.
В общем, вот что вырисовывается: у меня получается в некотором роде собственная реализация bitcoin-core.
Работает она так: на вход ей дается
1) существующие на диске blk***-файлы
2) приватные ключи (пока я не морочил голову как их хранить секурно)
3) ну и сообщается куда коннектиться (пока 127.0.0.1:18333)
Софтина прожевывает существующий блокчейн, потом коннектится к пиру (пиром пока выступает запущенный на моей же тачке Bitcoin-Qt в тестовом режиме), и парсит все что от пира приходит.
Если приходит что-то "интересное" - может выполнить какое-то действие, например сразу перевести биткойны "снежным комом" в другое место.
Где эту софтину использовать и как - это я еще не придумал. Может быть оформить именно как ядро и потом уже наворачивать какую-то кастомную функциональность? Пока не знаю. С нестандартными транзакциями полная жопа. Не нашел ip-адреса eligius-пула, да и ен факт, что они тоже возьмутся их обрабатывать.
В общем, вот что вырисовывается: у меня получается в некотором роде собственная реализация bitcoin-core.
Работает она так: на вход ей дается
1) существующие на диске blk***-файлы
2) приватные ключи (пока я не морочил голову как их хранить секурно)
3) ну и сообщается куда коннектиться (пока 127.0.0.1:18333)
Софтина прожевывает существующий блокчейн, потом коннектится к пиру (пиром пока выступает запущенный на моей же тачке Bitcoin-Qt в тестовом режиме), и парсит все что от пира приходит.
Если приходит что-то "интересное" - может выполнить какое-то действие, например сразу перевести биткойны "снежным комом" в другое место.
Где эту софтину использовать и как - это я еще не придумал. Может быть оформить именно как ядро и потом уже наворачивать какую-то кастомную функциональность? Пока не знаю. С нестандартными транзакциями полная жопа. Не нашел ip-адреса eligius-пула, да и ен факт, что они тоже возьмутся их обрабатывать.
как оказалось, мультисиг-выход 16-of-16 - это еще не самый жирный пример
вот тут
https://blockchain.info/tx/c4aaf7fbec7a9a079e670e50f6a672315451c7618814494ab1f89cf3fd97b3bb
выход 20-of-20 Причем его ухитрились потратить. Так что ограничение на размер scriptSig - не протокольное, а реферального клиента
вот тут
https://blockchain.info/tx/c4aaf7fbec7a9a079e670e50f6a672315451c7618814494ab1f89cf3fd97b3bb
выход 20-of-20
Причем его ухитрились потратить. Так что ограничение на размер scriptSig - не протокольное, а реферального клиентаЯ еще не разбирался с мультисиг, по-моему там существует ограничение - стандартными считаются транзакции с не более чем тремя подписями. Так?
Да. Точнее, не транзакции, а адреса — в m-of-n адресах n не может быть больше 3. По крайней мере пока. В самой же транзакции подписей может быть больше за счёт других входов.Чуть-чуть пошукал еще. Нашел во что:
https://blockchain.info/ru/tx-index/112996485
Эта (или подобная) транзакция попала в мемори-пул на blockchain.info и висит в этом пуле аж с 13 февраля - уже неделю как! Майнеры ее не майнят, blockchain.info ее не выбрасывает, а просто ждет когда ее подтвердит кто-нибудь.
Надо попробовать ее "снежным комом" попробовать выколупать.
Не взлетит. Опять же — пока. Текущее ограничение на размер scriptSig (из одного входа) — 500 байт.https://blockchain.info/ru/tx-index/112996485
Эта (или подобная) транзакция попала в мемори-пул на blockchain.info и висит в этом пуле аж с 13 февраля - уже неделю как! Майнеры ее не майнят, blockchain.info ее не выбрасывает, а просто ждет когда ее подтвердит кто-нибудь.
Надо попробовать ее "снежным комом" попробовать выколупать.
main.cpp, функция IsStandardTx:
Code:
BOOST_FOREACH(const CTxIn& txin, tx.vin)
{
// Biggest 'standard' txin is a 3-signature 3-of-3 CHECKMULTISIG
// pay-to-script-hash, which is 3 ~80-byte signatures, 3
// ~65-byte public keys, plus a few script ops.
if (txin.scriptSig.size() > 500) {
reason = "scriptsig-size";
return false;
}
if (!txin.scriptSig.IsPushOnly()) {
reason = "scriptsig-not-pushonly";
return false;
}
}
{
// Biggest 'standard' txin is a 3-signature 3-of-3 CHECKMULTISIG
// pay-to-script-hash, which is 3 ~80-byte signatures, 3
// ~65-byte public keys, plus a few script ops.
if (txin.scriptSig.size() > 500) {
reason = "scriptsig-size";
return false;
}
if (!txin.scriptSig.IsPushOnly()) {
reason = "scriptsig-not-pushonly";
return false;
}
}
P.S. Только сообразил — если мультисиг реализован без redeemScript (не pay-to-script-hash, а просто ключи указаны непосредственно в scriptPubKey), как в приведённом случае, то ограничений на n и m нет, но вот ограничение в 500 байт остаётся.
Вот еще любопытность нашел.
Сперва читаем тут http://thomas.bitwasp.co/?p=22
В двух словах - мультисиг транзакция, которая выводится владельцем ключа "correct horse..."
Автор попытался ее вывести, но... Не вышло. Я еще не разбирался с мультисиг, по-моему там существует ограничение - стандартными считаются транзакции с не более чем тремя подписями. Так?
Чуть-чуть пошукал еще. Нашел во что:
https://blockchain.info/ru/tx-index/112996485
Эта (или подобная) транзакция попала в мемори-пул на blockchain.info и висит в этом пуле аж с 13 февраля - уже неделю как! Майнеры ее не майнят, blockchain.info ее не выбрасывает, а просто ждет когда ее подтвердит кто-нибудь.
Надо попробовать ее "снежным комом" попробовать выколупать.
Сперва читаем тут http://thomas.bitwasp.co/?p=22
В двух словах - мультисиг транзакция, которая выводится владельцем ключа "correct horse..."
Автор попытался ее вывести, но... Не вышло. Я еще не разбирался с мультисиг, по-моему там существует ограничение - стандартными считаются транзакции с не более чем тремя подписями. Так?
Чуть-чуть пошукал еще. Нашел во что:
https://blockchain.info/ru/tx-index/112996485
Эта (или подобная) транзакция попала в мемори-пул на blockchain.info и висит в этом пуле аж с 13 февраля - уже неделю как! Майнеры ее не майнят, blockchain.info ее не выбрасывает, а просто ждет когда ее подтвердит кто-нибудь.
Надо попробовать ее "снежным комом" попробовать выколупать.
Значит входящая транзакция и исходящая транзакция на пришедшую сумму возможны в одном блоке ?
Протокол вроде не запрещает любое количество транзакций наследующихся друг от друга в одном блоке. Вопрос в том - должны ли они в блоке располагаться в "правильном порядке"? Не проверял. Наверно.Можно проверить простым способом - делаете перевод, потом еще перевод (средства для него возьмутся из сдачи первого перевода), потом еще перевод (из сдачи второго перевода)... и так далее - по идее все переводы попадут в один блок.
Значит входящая транзакция и исходящая транзакция на пришедшую сумму возможны в одном блоке ?
Quote
Какие программы ты используешь для обработки данных?
Да всё пока самописное. Открываю по-очереди blk***.dat - там формат очень простойQuote
Значит ктото парсит такие адреса уже на уровне memory pool и сразу вывод средств организует ?
Скорее всего именно так. У меня именно такая же идея. Сейчас я уже понимаю, что смысла в этом немного - тратить 2 месяца писать по вечерам программу которая будет по 3 рубля в месяц ловить (и то если успеет). Но когда я начинал - я об этом совсем не знал.
blockchain.info указывает время транзакции, когда эта транзакция именно на blockchain.info прилетела.
Понаблюдал за одним скомпрометированным адресом и вижу, что исходящаа транзакция прошла через 2 секунды после входящей. И обе оказались в одном блоке.
Значит ктото парсит такие адреса уже на уровне memory pool и сразу вывод средств организует ?
Значит ктото парсит такие адреса уже на уровне memory pool и сразу вывод средств организует ?
Quote from: amaclin
Сперва пришлось просканировать 15 гигабайт блокчейна и разобраться с транзакциями, вернее с их выходами.
Какие программы ты используешь для обработки данных?
а как для винды такое запустить - в инете не нашел - все под убунту
Дальнейшее решение этого вопроса здесь будет оффтопом, поэтому переходим обратно:https://bitcointalksearch.org/topic/m.5189801
а как для винды такое запустить - в инете не нашел - все под убунту
а как удалить транзакцию из wallet.dat ??
I dumped the wallet.dat using
$ db4.8_dump ~/.bitcoin/wallet.dat > dumpfile
The really hard thing was to find the transaction there! I was almost going crazy until i found out that you have to reverse the the transaction-id (=read from right to left)! Then it was simply (carefully) deleting the right two lines from the dump and importing again with db4.8_load.
$ db4.8_dump ~/.bitcoin/wallet.dat > dumpfile
The really hard thing was to find the transaction there! I was almost going crazy until i found out that you have to reverse the the transaction-id (=read from right to left)! Then it was simply (carefully) deleting the right two lines from the dump and importing again with db4.8_load.
Сделать бэкап wallet.dat (два: один, если что-то пойдёт не так, другой для модификации), затем дамп
Code:
$ db4.8_dump wallet.temp.dat > dumpfile
потом найти транзакцию в дампе (имейте в виду — txid там записан в обратном порядке следования байт, т.е. если ваш txid начинается с "01234567", то искать надо "67452301"), удалить найденную и следующую за ней строку, загрузить дамп обратно в wallet.temp.datCode:
$ db4.8_load -f dumpfile wallet.temp.dat
остановить bitcoin-qt (bitcoind), записать wallet.temp.dat на место wallet.dat, перезапустить клиент.Вообще-то вставление "костылей" подобного рода в алгоритм - странный прецендент.
В какой-то момент разработчики предложат считать последовательность
"OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG" тоже "особой" и таким образом "поднимут из небытия" биткойны, которые уплыли в Лету ( см. https://bitcointalksearch.org/topic/a-lot-of-btc-just-destroyed-block-150951-50232 )
Это вряд ли. Одной из целей такого «костыля», насколько я понимаю, было сокращение размера scriptPubKey. В будущем, когда мультисигнатурные адреса будут часто использовать на практике и когда блокчейн разрастётся до неприличных размеров, большинство узлов (в т.ч. условно-полноценных) будут хранить только последние блоки и список непотраченных выходов. И вот тогда будет разница, хранитьВ какой-то момент разработчики предложат считать последовательность
"OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG" тоже "особой" и таким образом "поднимут из небытия" биткойны, которые уплыли в Лету ( см. https://bitcointalksearch.org/topic/a-lot-of-btc-just-destroyed-block-150951-50232 )
https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться
Это да, последний майнер попытался её включить в блок аж через полгода, в октябре Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться
Насколько я понял тот скрипт, по новым правилам там нужно перед redeemScript'ом добавить подпись приватным ключом, соответствующим публичному "029c7187ecea7f09146820075c3a8de5d33ffbc293b63228ea1667c8d3796aff3f" (соответственно, адресу "1GgPeoTkagdppaZ1TbeCSPcihFhr4HRue2").
а как удалить транзакцию из wallet.dat ??
Смотрю внимательно пока что их себя представляет BIP-16
Пока нашел "весёлую транзакцию", которая была валидной по "старым правилам", но перестала быть валидной по "новым правилам".
https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться
Пока нашел "весёлую транзакцию", которая была валидной по "старым правилам", но перестала быть валидной по "новым правилам".
https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2
Почему "весёлая"? Потому что те майнеры, которые не проапгрейдились и работали по "старым" правилам включали её в свои блоки, а 51% сети в том числе и 51% новых майнеров эти блоки считали невалидными и, разумеется, орфанили их
Мораль - надо вовремя апгрейдиться
Quote
«Снежным комом» пробовали? По крайней мере приоритет выше будет. Рекомендую подождать пару дней, если не пройдёт — удалить транзакцию из wallet.dat и повторить с одним крупным инпутом (кстати, вы в курсе, что транзакцию можно подписывать последовательно в разных кошельках и таким образом избежать засвечивания приватных ключей с большим балансом?).
Нет, еще не пробовал. Рисковать на mainnet "живыми" деньгами немного ссыкотно. Да и "большого баланса" как такового у меня нет. Я ж говорю - биткойном заинтересовался только в конце прошлого года. Я даже могу сказать почему до этого это было вне сферы моих интересов - когда я впервые увидел публикации несколько лет назад там были слова что-то типа "...позволяет пересылать на IP-адрес..." - это я счел потенциальной уязвимостью (а это она и есть, так как все идет по открытым каналам и легко перехватывается) и не обратил внимание на технологию в целом.Quote
Тут проблема в том, что для новых транзакций (после 1 апреля 2012) такая последовательность ("OP_HASH160 OP_EQUAL") считается особой и обрабатывается отдельно.
Говорила мне мама: "Учи английский" Вообще-то вставление "костылей" подобного рода в алгоритм - странный прецендент.
В какой-то момент разработчики предложат считать последовательность
"OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG" тоже "особой" и таким образом "поднимут из небытия" биткойны, которые уплыли в Лету ( см. https://bitcointalksearch.org/topic/a-lot-of-btc-just-destroyed-block-150951-50232 ) Большинство пользователей просто скачает новый клиент, тем самым проголосовав "за" изменение в алгоритме.
Jump to: