Понимание транзакции # 14 на блоке # 141460

Я работаю на некоторый код для разбора Bitcoin blockchain и я столкнулся с проблемой с сделки # 14 в блоке # 141460. Я сделал поиск Google и нашел некоторые комментарии по поводу этой конкретной сделки, которая имеет выход, который только что вставил какой-то нонсенс текста в сценарий. Конкретный текст, который он вставлен в: "ЛУКА-JR педофил! О, и бог не реально, Sucka. Прекратите загрязнять blockchain с вашей нонсенс."

Выход только имеет этот текст и не целевой открытый ключ, который я могу определить.

Вот мой вопрос.

В блоке-исследователе он показывает этот выход транзакцию как имеющие «неизвестный» адрес назначения и отмечен как «странные».

http://blockexplorer.com/tx/9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6

Это кажется разумным мне рассматривает сценарий.

Тем не менее, и это суть моего вопроса, на веб-сайте BlockChain.info он перечисляет выходной скрипт с правильным адресом назначения.

Это не имеет никакого смысла для меня, так как выход его не имеет. Что BlockChain информация делать в этом случае? Как они идут с этим адресом назначения «»? Есть ли они только по умолчанию обратно к исходному выходному адресу coinbase шахтера?

https://blockchain.info/tx/9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6

На blockchain.info это указывает на то, что выход будет по этому адресу: 17Xbx4rf27bTjbRdwUKHrzpmg2unVXo1DB

Но я понятия не имею, как они придумали этот адрес, так как он не содержится в выходном-скрипта.

Благодаря,

Джон

Хм. Глядя на сделку, вывод не просто эта строка; это то, что строка плюс OP_CHECKSIG. Поэтому, даже если это ASCII строка почти наверняка не является публичным ключом, он отдается, как если бы это было.

Я думаю, что, если применить обычный открытый ключ хэш-функции для этой строки, вы получите адрес 17Xbx4rf27bTjbRdwUKHrzpmg2unVXo1DB.

Да, это, вероятно, что-то подобное. Надеюсь, кто-то, кто работал над кодом blockchain.info может объяснить, как они справиться с этой конкретной сделки. Если взять предыдущие 65 байт до OP_CHECKSIG как открытый ключ, он по-прежнему не действует, так как заголовок и контрольная сумма выключены. Я полагаю, я мог выбросить заголовок и контрольную сумму, а не делать это, и просто угадать, мне было бы интересно узнать, какие blockchain информации ребята сделали специально. Во всяком случае, это, как представляется, «unspendable» выход, и я думаю, что это безопасно / правильный способ интерпретировать его сейчас.

Как я сканирование blockchain есть довольно много из этих unspendable выходов (выходов без уважительного открытого ключа, связанного с ними).

Для только один пример, проверить это передам из:

http://blockexplorer.com/tx/6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8

Не то, чтобы «Для решения» есть «Unknown» и типа «Странно». Он содержит инструкции для проверки подписи, нет никакой фактической подписи! Там целая куча, как это. Предположительно, это означает, что все эти выходы «потеряны навсегда». Интересно, сколько это будет добавить до в конце ..

Благодаря,

Джон

Я делаю REINDEX, чтобы помочь вам, если кто-то хочет, чтобы ответить быстрее, вот первая сделка в вопросе:

getrawtransaction 9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6

010000000121eb234bbd61b7c3d31034762126a64ff046b074963bf359eaa0da0ab59203a0010000008b4830450220263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf022100f d8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e1414050201410452eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110ec5f1588cec8b4 ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09ffffffff01a0860100000000006b4c684c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652eac00000000

интерпретация blockexplorer в:

{
  "гашиш":"9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6",
  "вер": 1,
  "vin_sz": 1,
  "vout_sz": 1,
  "lock_time": 0,
  "размер": 306,
  "в": [
   {
   "prev_out": {
   "гашиш":"a00392b50adaa0ea59f33b9674b046f04fa62621763410d3c3b761bd4b23eb21",
   "N": 1
   },
   "scriptSig":"30450220263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf022100f d8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e1414050201 0452eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110ec5f1588cec8b4 ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09"
   }
  ],
  "вне": [
   {
   "стоимость":"0.00100000",
   "scriptPubKey":"4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e OP_CHECKSIG"
   }
  ]
}

--
для справки, нормальный 1 в 1 из 1 сделка по BTC:
{
"гашиш":"c4064f2bebbc049493207f88490fc75f52a2246952f10aed346ff5302d9ec6e8",
"вер": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 0,
"размер": 192,
"в": [
{
"prev_out": {
"гашиш":"cc2dff38e25bb23845cfc3f4c3c6d5e4d292d9bb1dd7b34d2dfad310f6ad5f95",
"N": 0
},
"scriptSig":"304502203b3de7314e11b0fbbc42a185a722497e209f8c83e6c67188a9d77d597a0ad3c20221008 605c83437ffbfba47dd67cbedc9bcaac9b1f36009fabfcb9faea143ba7ddc5701 020a4b9b363a66d5a9999e8362ff07e065bddd65ed07e1631e44394dfb51908263"
}
],
"вне": [
{
"стоимость":"1.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 2bf5301ed1b86a86cd0aa8f4c6e8dd1beed60b44 OP_EQUALVERIFY OP_CHECKSIG"
}
]
}

Вот моя интерпретация сделки:

Версия формата данных транзакций (uint32_t):
01000000

TXIN:
   Количество TX_IN (количество входов транзакций, Satoshi VarInt):
   01
   TXIN ДАННЫЕ:
   Предыдущий хэш txout:
   21eb234bbd61b7c3d31034762126a64ff046b074963bf359eaa0da0ab59203a0
   Предыдущий показатель txout:
   01000000
   Длина сценария:
   8б
   Подпись Длина: (48h = 72 байт)
   48
   ECDSA Подпись (X.690 DER-закодированы):
   ASN.1 Идентификатор тега (20h = построена + 10h = ПОСЛЕДОВАТЕЛЬНОСТЬ и последовательность):
   30
   Длина МЭД октет, определенная короткая форма (45ч = 69 байт) (подпись R + S длина)
   45
   ASN.1 [/ URL] Идентификатор тега (02 = Integer):
   02
   Подпись Длина г (МЭД длина октет):
   20
   Подпись г (без знака двоичного ИНТ, большой обратный порядок байт):
   263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf
   ASN.1 [/ URL] Идентификатор тега (02 = Integer):
   02
   Signature S длина (длина МЭД октет):
   21
   Signature S (первый байт 00 колодки для защиты MSB 1 беззнаковое целое):
   00fd8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e14140502
   Конец Подпись байт (SIGHASH_ALL):
   01

   Длина ключа:
   41
   Public Key Префикс:
   04
   Public Key часть х
   52eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110e
   Public Key часть у
   c5f1588cec8b4ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09
   Последовательность чисел:
   FFFFFFFF

TXOUT:
   номер txout:
   01
   Значение в базовых единицах:
   a086010000000000
   Длина сценария (107 байт):
   6b

   Сценарий (если мы должны были запустить его):
   OP_PUSHDATA1 - Следующий байт содержит число байтов, которые будут в стек:
   4c
   Bytes (68 = 104 байт):
   68
   СТЕК DATA 104 байт:
   4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420
   676f642069736e2774207265616c2c207375636b612e2053746f7020706f6c6c
   7574696e672074686520626c6f636b636861696e207769746820796f7572206e
   6f6e73656e73652e

Блокировка времени (не могут быть включены до этого блока):
00000000

Edit: Что делает скрипт только один опкод: толкать все остальные данные в стек.

Сценарий не Opcodes, хотя, именно это в ASCII:

>>> "4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e",раскодировать("наговор")
"ЛУКА-JR педофил! О, и бог не реально, Sucka. Прекратите загрязнять blockchain с вашей нонсенс."

Чтобы ответить на этот вопрос, то, вероятно, простой парсер, используемый сайт blockchain, который выглядит для hash160 опкодом и использует 160 бит после этого вычислить адрес. Ничто как hash160 не в scriptsig хотя. Он также может сканировать для публичного ключа-ля генерации транзакции. Я ставлю каждую шестигранную комбинацию строк можно из scriptsig через Публичный для решения и не получить этот адрес либо.

К сожалению, это смешно. Я хотел бы видеть писание ЛУКИ младших листов.

Ps вы ребята Fing умный

Ребята, спасибо за подробный ответ. Я сделал большой прогресс на мой парсер, хотя мой большой нерешенной проблемой является то, что он собирается с рельсов где-то после того, как блок # 240000. Я отлаживать, что завтра. В предыдущем файле я попал случай, когда после сканирования блока и ожидают блок-заголовок для следующего блока, вместо этого он нашел большой кусок нулевых байт. Я должен был просто сканировать файл, пока я не попал в заголовок, который был некоторое расстояние дальше в файле. Я не знаю, как / почему Bitcoin-кварта может это сделать, но на моей машине это делает. У меня есть подозрение, что подлое, если я удалил свой blockchain и заставил его полностью перезакачаю его, эта проблема будет уходить. Тем не менее, я не хочу, чтобы сделать это, потому что я хочу, чтобы выяснить источник проблемы, как сейчас на моей машине.

Во всяком случае, я экспериментировал с порождающим некоторыми 3d поверхности графики blockchain формирующегося с течением времени. Это очень ранние вещи, но это было круто видеть в любом случае.

codesuppository.blogspot.com/2013/12/work-in-progress.html

Цитата: jratcliff63367 31 декабря 2013 года, 5:50:31 AM

Очень классные графики! Отличная работа!

Я только что обновил свой длинный пост с большим количеством описаний, я нашел DER документов для декодирования тайны байт в подписи. Они являются частью ASN.1 потока контейнера, который описывает кодирование двух целых чисел.

Я нашел что-то интересное - Bitcoin также тянет тот же адрес из воздуха для этой транзакции; он набирает на два байта в конце как опкод:

Цитата: Bitcoin-Qt консоли

gettxout 9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6 0
{
"bestblock" : "000000000000000099630b3f60c04edf89931160a381ca0a5e3bc35d1195272d",
"подтверждения" : 136428,
"стоимость" : 0.00100000,
"scriptPubKey" : {
"как м" : "4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e OP_CHECKSIG",
"наговор" : "4c684c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f6420697 36e2774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f 636b636861696e207769746820796f7572206e6f6e73656e73652eac",
"reqSigs" : 1,
"тип" : "Публичных",
"адреса" : [
"1Address"
]
},
"версия" : 1,
"coinbase" : ложный
}

Это означает, что если вы хотите узнать, где blockchain.info получает этот адрес, у вас есть исходный код. Там в scriptpubkey, с "checksig" на конце в версии ASM. Я думаю, что Bitcoin должен видеть некоторые данные там, на то, что он нашел, как Публичные х и у, это адрес. Если это также случай, когда он использует то же Публичное и пробует checksig, если кто-то пытается провести его, вам потребуется privkey для этого Публичного.

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

Я просто была интересная идея - может ли "ЛУКА-JR IS" TXOUT тратиться? Я думаю, что это может быть, если сценарий был интерпретирован правильно:

Сделка действительна, если ничего в комбинированном сценарии не вызывает сбой, и верхний элемент стека истинно (не равно нулю).

Я пытался провести его.
ОШИБКА: CTxMemPool :: принять (): нестандартный ввод транзакций

Похоже, не весело сейчас, хотя:
   // Проверка на нестандартную оплату за скрипт-хэш в входах
   если (Params (). NETWORKID () == CChainParams :: ГЛАВНАЯ && ! AreInputsStandard (ТХ, вид))
   возвращать ошибку ("AcceptToMemoryPool:: нестандартные входные транзакции");

Это было бы сделка провести его:
0100000001c6b284e70a1c76240d5e39572c21875e6e7166a30647c0038627f546d6e7409700000 0008c493046022100b35acef5d3f5b42ce2e72b60a2e4a52570ce5d28735a561ee48707b0806101 6902210089b752641772b17db3d7e92cef66949513fec42711fadc32b787228e1cc0b399014104e 0ba531dc5d2ad13e2178196ade1a23989088cfbeddc7886528412087f4bff2ebc19ce739f25a630 56b6026a269987fcf5383131440501b583bab70a7254b09effffffff01905f0100000000001976a 914da6475289c7f49bcd9ede6ab7203b304ffb265f288ac00000000

Я собираюсь выяснить это, рядом остановку, testnet. Это, вероятно, ошибка, если нет hash160 и сделка не выглядит как старый SKOOL платить в Публичных.

Цитата: jratcliff63367 31 декабря 2013 года, 5:50:31 AM

codesuppository.blogspot.com/2013/12/work-in-progress.html

Я очень заинтересован в этом blockchain анализатор. Когда вы закончите, я надеюсь, вы не возражаете, позволяя другим скачать и использовать его.

Цитата: jratcliff63367 от 29 декабря 2013 года, 3:53:44 PM

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

Гах. то, что вы, ребята, о чем? Это просто обычный, заурядный платить Публичный выход ... Есть тысячи из них в blockchain- с ASCII с мусором, закодированным в открытом ключе. Это не может быть проведено. Это не редкость, за исключением того, что Публичный является нежелательным, что не удивительно, потому что правила протокола практически не имеют ограничений на scriptpubkeys в txouts (за их размер). Hash160 показывается на нем в случае корректировкой это hash160, соответствующий нормальный платных к-Публичного-хэш для этого "Публичных",

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

Просто найти соответствующий секретный ключ, и вы золотой.

Таким образом, при разборе blockchain последовательно и вы столкнулись с бесхозным блоком, что правильный способ справиться с этим?

Глядя на поток необработанных данных я полагаю, я мог бы «обнаруживать» это тем, что несколько блоков в точке строки к одной и той же «» предыдущего блока. Всегда ли это безопасно / правда, что последний блок рассматривается на «главной» цепи?

Благодаря,

Джон

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

Я не знаю, почему они оба записаны в blockchain вы смотрите, хотя; блоки в осиротевших вилках должны быть совершенно ненужным для построения полной записи транзакций.

Если блоки в осиротевших цепях в записи вы смотрите, то вы должны быть в состоянии выключить запись транзакции и отслеживать два (или даже больше) blockchains. Если оба из них имеют преемника, вы посмотрите на «внуков», и если оба из них имеют преемника, вы посмотрите и т.д. «правнуки» Рано или поздно, одна ветвь оканчивается в блоке, не имеющего последующего блока, так вы тогда знаете, другая ветвь является допустимым. Оттуда вы вернетесь к точке развилки, начать запись ОЙ снова, и идти вперед, не обращая внимания прекращенную ветвь.

Спасибо, я работаю над моей реализацией в настоящее время. Для моей первой попытки я просто хочу, чтобы пропустить блок-сироту, когда я его обнаружить и взять на себя следующий блок не является orpahan. У меня есть Assert в своем коде, чтобы увидеть, если это, по сути, всегда.

Вот как я полагаю, вы можете получить локальную базу данных Bitcoin-кварты с осиротевшими блоками в нем.

Если вы запустите Bitcoin-кварта с совершенно свежей базой данных, она будет загружать весь blockchain на жесткий диск с нулевыми блоками бесхозных. However..if вы оставите Bitcoin-QT день бега в день, синхронизация по сети, то возможно для того, чтобы написать сиротский блок на локальный жесткий диск (это то, что случилось со мной). Одна вещь, пожалуй, единственный мой блок-цепи синтаксического анализа является то, что она является полностью последовательным. Она считывает в 4-х блоках в любой момент времени, логический предыдущий блок, логический «текущий» блок, логический «ряд», блок, и после этого один. Каждый цикл он читает в «следующий» блок в этой модели и перемешивает некоторые указатели.

Так как я уже читал следующий блок, и один за что, я думаю, что это «Fixup» подход будет работать.

Благодаря,

Джон

Хорошо, это похоже, что я, наконец, это исправлено. Это было только бесхозные блоки, которые бросали меня, и теперь те, принимаются во внимание. Анализатор успешно считывает каждый блок, транзакции, вход и выход в blockchain. Есть несколько выходных скриптов, которые он не может получить правильную открытый ключ подписи для Однако во всех этих случаях, я нашел как blockexplorer и blockchain.info имеет один и тот же вопрос, поэтому я не лечение, что является большой проблемой в настоящее время.

Я планирую написать конкретный пост в блоге с подробным описанием всех этих «подводных камней» вы должны знать о том, чтобы поток / разобрать блок-цепь последовательно (а не пытаться сканировать все блоки в какой-то граф / дерево) фронт , Есть куча маленьких раздражающих вещей, которые не очевидны.

[Edit: Спица слишком рано, я сойти с рельс немного дальше вниз по blockchain, все равно придется отлаживать это еще немного ...]

Джон

Цитата: jratcliff63367 31 декабря 2013 года, 9:05:26 PM

Я нашел, что проще всего наивность совершить blockdats в базу данных, как я анализирую их.

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

Выходные сценарии произойдут только, как правило, соответствуют некоторым общим отпечаткам, которые позволяют извлекать адреса и pubkeys, поэтому просто хранить блобы в базе данных, я уверен, что вы делаете. Если я правильно помню, один из немногих предположений, которые вы можете сделать о blockdat данных является то, что ссылка клиент делает убедиться, что он разбирает в оп-кодов, так по крайней мере, есть что!

Дорога к робастности, безусловно унизительно путешествие. Веселый, даже.

Держать нас в курсе. У меня есть много подводных камней, выгравированные в комментарии вокруг моего кодовую, но "конечно, я буду блог о них когда-нибудь!" Оказывается, только чтобы быть навязчивой ложью, я говорю себе, чтобы чувствовать доброжелательными.

Да, я все это фиксируется и работает. То, что я сделал, что я изменил код для сканирования во всех блок-заголовков из файлов на диске. Я вычислить блок-хэш, основанный на каждом заголовке и положить его в хэш-карте. Затем, когда я попал в последний блок заголовка, я хожу в обратном направлении, используя поле «предыдущего блока», чтобы сделать поиск по хэш-таблицы, пока я не попал в первый блок. Кажется, работает отлично, если я не предполагаю, что «последний» блок был сиротой, но я не то, что беспокоит такой редкий случай.

Я пересмотрел весь источник и сделал некоторые новые графики и разместил его здесь.

http://codesuppository.blogspot.com/2014/01/show-me-money-scatter-graph-of-all.html

Мне нравится ваш код. Это очень четкая, минимальная зависимость, и в соответствии со стандартами языка.

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

То, что я хотел сделать, это просто; список всех открытых ключей в blockchain. Что делает мою «основную» функцию о шесть-вкладыше, я думаю.

Да, я все еще работаю над документацией / очистки. Она была написана с первичным натяжением, что другие программисты строить его и шаг через исходный код в качестве учебного упражнения.

I * будет * добавить некоторые ключи командной строки, где вы можете просто запустить его и получить как свалку ключей, такого рода вещи. Просто еще не дошли до этого еще.

Я сейчас работаю над довольно удивительным инструментом визуализации, что я думаю, что община собирается найти очень интересно. Я пишу 3d графическое приложение, которое может визуально отображать практически каждый блок на blockchain с разумным балансом, а затем * * одушевленные его в режиме реального времени, в течение долгого времени.

Джон

29 декабря 2013, 12:40:07 AM	# 1
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я работаю на некоторый код для разбора Bitcoin blockchain и я столкнулся с проблемой с сделки # 14 в блоке # 141460. Я сделал поиск Google и нашел некоторые комментарии по поводу этой конкретной сделки, которая имеет выход, который только что вставил какой-то нонсенс текста в сценарий. Конкретный текст, который он вставлен в: "ЛУКА-JR педофил! О, и бог не реально, Sucka. Прекратите загрязнять blockchain с вашей нонсенс." Выход только имеет этот текст и не целевой открытый ключ, который я могу определить. Вот мой вопрос. В блоке-исследователе он показывает этот выход транзакцию как имеющие «неизвестный» адрес назначения и отмечен как «странные». http://blockexplorer.com/tx/9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6 Это кажется разумным мне рассматривает сценарий. Тем не менее, и это суть моего вопроса, на веб-сайте BlockChain.info он перечисляет выходной скрипт с правильным адресом назначения. Это не имеет никакого смысла для меня, так как выход его не имеет. Что BlockChain информация делать в этом случае? Как они идут с этим адресом назначения «»? Есть ли они только по умолчанию обратно к исходному выходному адресу coinbase шахтера? https://blockchain.info/tx/9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6 На blockchain.info это указывает на то, что выход будет по этому адресу: 17Xbx4rf27bTjbRdwUKHrzpmg2unVXo1DB Но я понятия не имею, как они придумали этот адрес, так как он не содержится в выходном-скрипта. Благодаря, Джон

29 декабря 2013, 6:23:58 AM	# 2
Qoheleth Сообщения: 930 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Получил 1806 Биткоинов Реальная история. Хм. Глядя на сделку, вывод не просто эта строка; это то, что строка плюс OP_CHECKSIG. Поэтому, даже если это ASCII строка почти наверняка не является публичным ключом, он отдается, как если бы это было. Я думаю, что, если применить обычный открытый ключ хэш-функции для этой строки, вы получите адрес 17Xbx4rf27bTjbRdwUKHrzpmg2unVXo1DB.

29 декабря 2013, 3:53:44 PM	# 3
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Да, это, вероятно, что-то подобное. Надеюсь, кто-то, кто работал над кодом blockchain.info может объяснить, как они справиться с этой конкретной сделки. Если взять предыдущие 65 байт до OP_CHECKSIG как открытый ключ, он по-прежнему не действует, так как заголовок и контрольная сумма выключены. Я полагаю, я мог выбросить заголовок и контрольную сумму, а не делать это, и просто угадать, мне было бы интересно узнать, какие blockchain информации ребята сделали специально. Во всяком случае, это, как представляется, «unspendable» выход, и я думаю, что это безопасно / правильный способ интерпретировать его сейчас. Как я сканирование blockchain есть довольно много из этих unspendable выходов (выходов без уважительного открытого ключа, связанного с ними). Для только один пример, проверить это передам из: http://blockexplorer.com/tx/6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8 Не то, чтобы «Для решения» есть «Unknown» и типа «Странно». Он содержит инструкции для проверки подписи, нет никакой фактической подписи! Там целая куча, как это. Предположительно, это означает, что все эти выходы «потеряны навсегда». Интересно, сколько это будет добавить до в конце .. Благодаря, Джон

30 декабря 2013, 8:21:25 AM	# 4
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Я делаю REINDEX, чтобы помочь вам, если кто-то хочет, чтобы ответить быстрее, вот первая сделка в вопросе: getrawtransaction 9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6 010000000121eb234bbd61b7c3d31034762126a64ff046b074963bf359eaa0da0ab59203a0010000008b4830450220263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf022100f d8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e1414050201410452eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110ec5f1588cec8b4 ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09ffffffff01a0860100000000006b4c684c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652eac00000000 интерпретация blockexplorer в: { "гашиш":"9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6", "вер": 1, "vin_sz": 1, "vout_sz": 1, "lock_time": 0, "размер": 306, "в": [ { "prev_out": { "гашиш":"a00392b50adaa0ea59f33b9674b046f04fa62621763410d3c3b761bd4b23eb21", "N": 1 }, "scriptSig":"30450220263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf022100f d8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e1414050201 0452eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110ec5f1588cec8b4 ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09" } ], "вне": [ { "стоимость":"0.00100000", "scriptPubKey":"4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e OP_CHECKSIG" } ] } -- для справки, нормальный 1 в 1 из 1 сделка по BTC: { "гашиш":"c4064f2bebbc049493207f88490fc75f52a2246952f10aed346ff5302d9ec6e8", "вер": 1, "vin_sz": 1, "vout_sz": 1, "lock_time": 0, "размер": 192, "в": [ { "prev_out": { "гашиш":"cc2dff38e25bb23845cfc3f4c3c6d5e4d292d9bb1dd7b34d2dfad310f6ad5f95", "N": 0 }, "scriptSig":"304502203b3de7314e11b0fbbc42a185a722497e209f8c83e6c67188a9d77d597a0ad3c20221008 605c83437ffbfba47dd67cbedc9bcaac9b1f36009fabfcb9faea143ba7ddc5701 020a4b9b363a66d5a9999e8362ff07e065bddd65ed07e1631e44394dfb51908263" } ], "вне": [ { "стоимость":"1.00000000", "scriptPubKey":"OP_DUP OP_HASH160 2bf5301ed1b86a86cd0aa8f4c6e8dd1beed60b44 OP_EQUALVERIFY OP_CHECKSIG" } ] }

30 декабря 2013, 9:37:32 AM	# 5
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Вот моя интерпретация сделки: Версия формата данных транзакций (uint32_t): 01000000 TXIN: Количество TX_IN (количество входов транзакций, Satoshi VarInt): 01 TXIN ДАННЫЕ: Предыдущий хэш txout: 21eb234bbd61b7c3d31034762126a64ff046b074963bf359eaa0da0ab59203a0 Предыдущий показатель txout: 01000000 Длина сценария: 8б Подпись Длина: (48h = 72 байт) 48 ECDSA Подпись (X.690 DER-закодированы): ASN.1 Идентификатор тега (20h = построена + 10h = ПОСЛЕДОВАТЕЛЬНОСТЬ и последовательность): 30 Длина МЭД октет, определенная короткая форма (45ч = 69 байт) (подпись R + S длина) 45 ASN.1 [/ URL] Идентификатор тега (02 = Integer): 02 Подпись Длина г (МЭД длина октет): 20 Подпись г (без знака двоичного ИНТ, большой обратный порядок байт): 263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf ASN.1 [/ URL] Идентификатор тега (02 = Integer): 02 Signature S длина (длина МЭД октет): 21 Signature S (первый байт 00 колодки для защиты MSB 1 беззнаковое целое): 00fd8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e14140502 Конец Подпись байт (SIGHASH_ALL): 01 Длина ключа: 41 Public Key Префикс: 04 Public Key часть х 52eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110e Public Key часть у c5f1588cec8b4ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09 Последовательность чисел: FFFFFFFF TXOUT: номер txout: 01 Значение в базовых единицах: a086010000000000 Длина сценария (107 байт): 6b Сценарий (если мы должны были запустить его): OP_PUSHDATA1 - Следующий байт содержит число байтов, которые будут в стек: 4c Bytes (68 = 104 байт): 68 СТЕК DATA 104 байт: 4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420 676f642069736e2774207265616c2c207375636b612e2053746f7020706f6c6c 7574696e672074686520626c6f636b636861696e207769746820796f7572206e 6f6e73656e73652e Блокировка времени (не могут быть включены до этого блока): 00000000 Edit: Что делает скрипт только один опкод: толкать все остальные данные в стек. Сценарий не Opcodes, хотя, именно это в ASCII: >>> "4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e",раскодировать("наговор") "ЛУКА-JR педофил! О, и бог не реально, Sucka. Прекратите загрязнять blockchain с вашей нонсенс." Чтобы ответить на этот вопрос, то, вероятно, простой парсер, используемый сайт blockchain, который выглядит для hash160 опкодом и использует 160 бит после этого вычислить адрес. Ничто как hash160 не в scriptsig хотя. Он также может сканировать для публичного ключа-ля генерации транзакции. Я ставлю каждую шестигранную комбинацию строк можно из scriptsig через Публичный для решения и не получить этот адрес либо.

30 декабря 2013, 11:35:25 AM	# 6
битпоп Сообщения: 2184 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 К сожалению, это смешно. Я хотел бы видеть писание ЛУКИ младших листов. Ps вы ребята Fing умный

31 декабря 2013, 5:50:31 AM	# 7
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Ребята, спасибо за подробный ответ. Я сделал большой прогресс на мой парсер, хотя мой большой нерешенной проблемой является то, что он собирается с рельсов где-то после того, как блок # 240000. Я отлаживать, что завтра. В предыдущем файле я попал случай, когда после сканирования блока и ожидают блок-заголовок для следующего блока, вместо этого он нашел большой кусок нулевых байт. Я должен был просто сканировать файл, пока я не попал в заголовок, который был некоторое расстояние дальше в файле. Я не знаю, как / почему Bitcoin-кварта может это сделать, но на моей машине это делает. У меня есть подозрение, что подлое, если я удалил свой blockchain и заставил его полностью перезакачаю его, эта проблема будет уходить. Тем не менее, я не хочу, чтобы сделать это, потому что я хочу, чтобы выяснить источник проблемы, как сейчас на моей машине. Во всяком случае, я экспериментировал с порождающим некоторыми 3d поверхности графики blockchain формирующегося с течением времени. Это очень ранние вещи, но это было круто видеть в любом случае. codesuppository.blogspot.com/2013/12/work-in-progress.html

31 декабря 2013, 7:57:58 AM	# 8
Korporal Сообщения: 224 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Цитата: jratcliff63367 31 декабря 2013 года, 5:50:31 AM Ребята, спасибо за подробный ответ. Я сделал большой прогресс на мой парсер, хотя мой большой нерешенной проблемой является то, что он собирается с рельсов где-то после того, как блок # 240000. Я отлаживать, что завтра. В предыдущем файле я попал случай, когда после сканирования блока и ожидают блок-заголовок для следующего блока, вместо этого он нашел большой кусок нулевых байт. Я должен был просто сканировать файл, пока я не попал в заголовок, который был некоторое расстояние дальше в файле. Я не знаю, как / почему Bitcoin-кварта может это сделать, но на моей машине это делает. У меня есть подозрение, что подлое, если я удалил свой blockchain и заставил его полностью перезакачаю его, эта проблема будет уходить. Тем не менее, я не хочу, чтобы сделать это, потому что я хочу, чтобы выяснить источник проблемы, как сейчас на моей машине. Во всяком случае, я экспериментировал с порождающим некоторыми 3d поверхности графики blockchain формирующегося с течением времени. Это очень ранние вещи, но это было круто видеть в любом случае. codesuppository.blogspot.com/2013/12/work-in-progress.html Очень классные графики! Отличная работа!

31 декабря 2013, 9:40:12 AM	# 9
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Я только что обновил свой длинный пост с большим количеством описаний, я нашел DER документов для декодирования тайны байт в подписи. Они являются частью ASN.1 потока контейнера, который описывает кодирование двух целых чисел. Я нашел что-то интересное - Bitcoin также тянет тот же адрес из воздуха для этой транзакции; он набирает на два байта в конце как опкод: Цитата: Bitcoin-Qt консоли gettxout 9740e7d646f5278603c04706a366716e5e87212c57395e0d24761c0ae784b2c6 0 { "bestblock" : "000000000000000099630b3f60c04edf89931160a381ca0a5e3bc35d1195272d", "подтверждения" : 136428, "стоимость" : 0.00100000, "scriptPubKey" : { "как м" : "4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f642069736e2 774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f636b 636861696e207769746820796f7572206e6f6e73656e73652e OP_CHECKSIG", "наговор" : "4c684c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420676f6420697 36e2774207265616c2c207375636b612e2053746f7020706f6c6c7574696e672074686520626c6f 636b636861696e207769746820796f7572206e6f6e73656e73652eac", "reqSigs" : 1, "тип" : "Публичных", "адреса" : [ "1Address" ] }, "версия" : 1, "coinbase" : ложный } Это означает, что если вы хотите узнать, где blockchain.info получает этот адрес, у вас есть исходный код. Там в scriptpubkey, с "checksig" на конце в версии ASM. Я думаю, что Bitcoin должен видеть некоторые данные там, на то, что он нашел, как Публичные х и у, это адрес. Если это также случай, когда он использует то же Публичное и пробует checksig, если кто-то пытается провести его, вам потребуется privkey для этого Публичного. Сценарий на самом деле не делает ничего другого, кроме хранить целую кучу данных в стек. Последние байты, который выглядит как опкод также появляется толкнул в стек, если я полагаюсь байты правильно на этот раз. Вектор байт является Варлен, он не равен нулю, и, следовательно, стек должен быть оставлен "Правда" с большим числом. Я просто была интересная идея - может ли "ЛУКА-JR IS" TXOUT тратиться? Я думаю, что это может быть, если сценарий был интерпретирован правильно: Сделка действительна, если ничего в комбинированном сценарии не вызывает сбой, и верхний элемент стека истинно (не равно нулю). Я пытался провести его. ОШИБКА: CTxMemPool :: принять (): нестандартный ввод транзакций Похоже, не весело сейчас, хотя: // Проверка на нестандартную оплату за скрипт-хэш в входах если (Params (). NETWORKID () == CChainParams :: ГЛАВНАЯ && ! AreInputsStandard (ТХ, вид)) возвращать ошибку ("AcceptToMemoryPool:: нестандартные входные транзакции"); Это было бы сделка провести его: 0100000001c6b284e70a1c76240d5e39572c21875e6e7166a30647c0038627f546d6e7409700000 0008c493046022100b35acef5d3f5b42ce2e72b60a2e4a52570ce5d28735a561ee48707b0806101 6902210089b752641772b17db3d7e92cef66949513fec42711fadc32b787228e1cc0b399014104e 0ba531dc5d2ad13e2178196ade1a23989088cfbeddc7886528412087f4bff2ebc19ce739f25a630 56b6026a269987fcf5383131440501b583bab70a7254b09effffffff01905f0100000000001976a 914da6475289c7f49bcd9ede6ab7203b304ffb265f288ac00000000 Я собираюсь выяснить это, рядом остановку, testnet. Это, вероятно, ошибка, если нет hash160 и сделка не выглядит как старый SKOOL платить в Публичных.

31 декабря 2013, 12:45:48 PM	# 10
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Цитата: jratcliff63367 31 декабря 2013 года, 5:50:31 AM codesuppository.blogspot.com/2013/12/work-in-progress.html Я очень заинтересован в этом blockchain анализатор. Когда вы закончите, я надеюсь, вы не возражаете, позволяя другим скачать и использовать его.

31 декабря 2013, 12:58:35 PM	# 11
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Цитата: jratcliff63367 от 29 декабря 2013 года, 3:53:44 PM это еще не действует, так как заголовок и контрольная сумма выключены. Я полагаю, я мог выбросить заголовок и контрольную сумму, Гах. то, что вы, ребята, о чем? Это просто обычный, заурядный платить Публичный выход ... Есть тысячи из них в blockchain- с ASCII с мусором, закодированным в открытом ключе. Это не может быть проведено. Это не редкость, за исключением того, что Публичный является нежелательным, что не удивительно, потому что правила протокола практически не имеют ограничений на scriptpubkeys в txouts (за их размер). Hash160 показывается на нем в случае корректировкой это hash160, соответствующий нормальный платных к-Публичного-хэш для этого "Публичных",

31 декабря 2013, 1:35:31 PM	# 12
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Таким образом, это не должно быть труднее провести, чем любую другую сделку, вы не имеете ключа. Просто найти соответствующий секретный ключ, и вы золотой.

31 декабря 2013, 4:23:20 PM	# 13
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Таким образом, при разборе blockchain последовательно и вы столкнулись с бесхозным блоком, что правильный способ справиться с этим? Глядя на поток необработанных данных я полагаю, я мог бы «обнаруживать» это тем, что несколько блоков в точке строки к одной и той же «» предыдущего блока. Всегда ли это безопасно / правда, что последний блок рассматривается на «главной» цепи? Благодаря, Джон

31 декабря 2013, 4:39:39 PM	# 14
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Два блока с одинаковым номером оба должны иметь хэш для того же предыдущего блока, потому что они оба построены на том же предыдущем блоке. Это последующий блок, который будет неоднозначность их. Последующий блок будет построен на (и, следовательно, содержит хэш) только один из экземпляров предыдущего блока. Я не знаю, почему они оба записаны в blockchain вы смотрите, хотя; блоки в осиротевших вилках должны быть совершенно ненужным для построения полной записи транзакций. Если блоки в осиротевших цепях в записи вы смотрите, то вы должны быть в состоянии выключить запись транзакции и отслеживать два (или даже больше) blockchains. Если оба из них имеют преемника, вы посмотрите на «внуков», и если оба из них имеют преемника, вы посмотрите и т.д. «правнуки» Рано или поздно, одна ветвь оканчивается в блоке, не имеющего последующего блока, так вы тогда знаете, другая ветвь является допустимым. Оттуда вы вернетесь к точке развилки, начать запись ОЙ снова, и идти вперед, не обращая внимания прекращенную ветвь.

31 декабря 2013, 5:09:05 PM	# 15
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Спасибо, я работаю над моей реализацией в настоящее время. Для моей первой попытки я просто хочу, чтобы пропустить блок-сироту, когда я его обнаружить и взять на себя следующий блок не является orpahan. У меня есть Assert в своем коде, чтобы увидеть, если это, по сути, всегда. Вот как я полагаю, вы можете получить локальную базу данных Bitcoin-кварты с осиротевшими блоками в нем. Если вы запустите Bitcoin-кварта с совершенно свежей базой данных, она будет загружать весь blockchain на жесткий диск с нулевыми блоками бесхозных. However..if вы оставите Bitcoin-QT день бега в день, синхронизация по сети, то возможно для того, чтобы написать сиротский блок на локальный жесткий диск (это то, что случилось со мной). Одна вещь, пожалуй, единственный мой блок-цепи синтаксического анализа является то, что она является полностью последовательным. Она считывает в 4-х блоках в любой момент времени, логический предыдущий блок, логический «текущий» блок, логический «ряд», блок, и после этого один. Каждый цикл он читает в «следующий» блок в этой модели и перемешивает некоторые указатели. Так как я уже читал следующий блок, и один за что, я думаю, что это «Fixup» подход будет работать. Благодаря, Джон

31 декабря 2013, 9:05:26 PM	# 16
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Хорошо, это похоже, что я, наконец, это исправлено. Это было только бесхозные блоки, которые бросали меня, и теперь те, принимаются во внимание. Анализатор успешно считывает каждый блок, транзакции, вход и выход в blockchain. Есть несколько выходных скриптов, которые он не может получить правильную открытый ключ подписи для Однако во всех этих случаях, я нашел как blockexplorer и blockchain.info имеет один и тот же вопрос, поэтому я не лечение, что является большой проблемой в настоящее время. Я планирую написать конкретный пост в блоге с подробным описанием всех этих «подводных камней» вы должны знать о том, чтобы поток / разобрать блок-цепь последовательно (а не пытаться сканировать все блоки в какой-то граф / дерево) фронт , Есть куча маленьких раздражающих вещей, которые не очевидны. [Edit: Спица слишком рано, я сойти с рельс немного дальше вниз по blockchain, все равно придется отлаживать это еще немного ...] Джон

1 января 2014, 1:10:58 AM	# 17
danneu Сообщений: 32 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Цитата: jratcliff63367 31 декабря 2013 года, 9:05:26 PM Хорошо, это похоже, что я, наконец, это исправлено. Это было только бесхозные блоки, которые бросали меня, и теперь те, принимаются во внимание. Анализатор успешно считывает каждый блок, транзакции, вход и выход в blockchain. Есть несколько выходных скриптов, которые он не может получить правильную открытый ключ подписи для Однако во всех этих случаях, я нашел как blockexplorer и blockchain.info имеет один и тот же вопрос, поэтому я не лечение, что является большой проблемой в настоящее время. Я планирую написать конкретный пост в блоге с подробным описанием всех этих «подводных камней» вы должны знать о том, чтобы поток / разобрать блок-цепь последовательно (а не пытаться сканировать все блоки в какой-то граф / дерево) фронт , Есть куча маленьких раздражающих вещей, которые не очевидны. [Edit: Спица слишком рано, я сойти с рельс немного дальше вниз по blockchain, все равно придется отлаживать это еще немного ...] Джон Я нашел, что проще всего наивность совершить blockdats в базу данных, как я анализирую их. Самый простой способ получить самую длинную ветвь для меня было представить ее в виде функции, примененной к дереву, которая возвращает последовательность блоков сущностей на ветке. Тогда я просто кэшировать, пересекаю ее с блоками, чтобы увидеть, если они находятся на нем, или применить его к любому поддерева (как дерево в 50 подтверждениях), когда я добавляю новые блоки. Выходные сценарии произойдут только, как правило, соответствуют некоторым общим отпечаткам, которые позволяют извлекать адреса и pubkeys, поэтому просто хранить блобы в базе данных, я уверен, что вы делаете. Если я правильно помню, один из немногих предположений, которые вы можете сделать о blockdat данных является то, что ссылка клиент делает убедиться, что он разбирает в оп-кодов, так по крайней мере, есть что! Дорога к робастности, безусловно унизительно путешествие. Веселый, даже. Держать нас в курсе. У меня есть много подводных камней, выгравированные в комментарии вокруг моего кодовую, но "конечно, я буду блог о них когда-нибудь!" Оказывается, только чтобы быть навязчивой ложью, я говорю себе, чтобы чувствовать доброжелательными.

1 января 2014, 7:46:13 PM	# 18
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Да, я все это фиксируется и работает. То, что я сделал, что я изменил код для сканирования во всех блок-заголовков из файлов на диске. Я вычислить блок-хэш, основанный на каждом заголовке и положить его в хэш-карте. Затем, когда я попал в последний блок заголовка, я хожу в обратном направлении, используя поле «предыдущего блока», чтобы сделать поиск по хэш-таблицы, пока я не попал в первый блок. Кажется, работает отлично, если я не предполагаю, что «последний» блок был сиротой, но я не то, что беспокоит такой редкий случай. Я пересмотрел весь источник и сделал некоторые новые графики и разместил его здесь. http://codesuppository.blogspot.com/2014/01/show-me-money-scatter-graph-of-all.html

2 января 2014, 12:25:28 AM	# 19
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Мне нравится ваш код. Это очень четкая, минимальная зависимость, и в соответствии со стандартами языка. Его также можно использовать для моих целей, потому что я могу написать свою собственную главную функцию легко обрабатывать его в качестве библиотеки, но я думаю, что большинство людей на самом деле хотят, чтобы вы, чтобы обеспечить "главный" функция, которая получает аргументы командной строки и может быть приказано сделать определенный набор вещей. То, что я хотел сделать, это просто; список всех открытых ключей в blockchain. Что делает мою «основную» функцию о шесть-вкладыше, я думаю.

2 января 2014, 8:53:10 PM	# 20
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Понимание сделки # 14 на блоке # 141460 Да, я все еще работаю над документацией / очистки. Она была написана с первичным натяжением, что другие программисты строить его и шаг через исходный код в качестве учебного упражнения. I * будет * добавить некоторые ключи командной строки, где вы можете просто запустить его и получить как свалку ключей, такого рода вещи. Просто еще не дошли до этого еще. Я сейчас работаю над довольно удивительным инструментом визуализации, что я думаю, что община собирается найти очень интересно. Я пишу 3d графическое приложение, которое может визуально отображать практически каждый блок на blockchain с разумным балансом, а затем * * одушевленные его в режиме реального времени, в течение долгого времени. Джон

Заголовок