Нужна помощь в понимании сделки

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

Вот пример:

См coinbase транзакции в блоке # 199,975

https://blockchain.info/tx/870f2daaf1e6bf44fd23c98b152f5f5b45beeb7066eb135840809cb528579e87

Вы можете заметить, что выходной адрес, который blockchain.info шоу является:

1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC

Шестнадцатеричный адрес для этого:

0x00, 0x8b, 0x1D, 0x6a, 0x31, 0xb0, 0x19, 0xe2, 0xda, 0x16, 0xDE, 0x77, 0xf6, 0x0c, 0x62, 0x3b, 0x14, 0x42, 0xd5, 0xec, 0x2e, 0x24, 0x3a, 0x00, 0x61

Обычно я нахожу открытый ключ в выходном сценарии, но в данном случае я не могу понять, как / где blockchain.info придумал "1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC" для вывода сценария, содержащего:

ChallengeScriptLength: 35 байт длиной
21 - Push 0x21 байт в стеке
02 14 71 с3 е2 с3 3f 1a 52 55 14 а5 CB f9 дб d3 22 f8 2b 95 78 34 90 е5 AB 99 FF 00 26 30 ЕВА b7 й
переменный ток OP_CHECKSIG

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

Как работает этот поток 33 (02 14 71 с3 е2 с3 3f 1a 52 55 а5 14 CB f9 дб d3 22 f8 2b 95 78 34 е5 90 AB 99 FF 00 26 30 ЕВО b7 й) байты включить в этот открытый ключ '1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC' ?

Благодаря,

Джон

Цитата: jratcliff63367 29 декабря 2014, 10:03:41 PM

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

Вот пример:

См coinbase транзакции в блоке # 199,975

https://blockchain.info/tx/870f2daaf1e6bf44fd23c98b152f5f5b45beeb7066eb135840809cb528579e87

Вы можете заметить, что выходной адрес, который blockchain.info шоу является:

1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC

Шестнадцатеричный адрес для этого:

0x00, 0x8b, 0x1D, 0x6a, 0x31, 0xb0, 0x19, 0xe2, 0xda, 0x16, 0xDE, 0x77, 0xf6, 0x0c, 0x62, 0x3b, 0x14, 0x42, 0xd5, 0xec, 0x2e, 0x24, 0x3a, 0x00, 0x61

Обычно я нахожу открытый ключ в выходном сценарии, но в данном случае я не могу понять, как / где blockchain.info придумал "1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC" для вывода сценария, содержащего:

"021471c3e2c33f1a5255a514cbf9dbd322f82b957834e590ab99ff002630ebb7ee OP_CHECKSIG"

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

Благодаря,

Джон

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

Таким образом, значение, даваемое в сценарии ЯВЛЯЕТСЯ открытый ключ.

Чтобы увидеть этот открытый ключ, представленный в качестве адреса Bitcoin, вам необходимо следовать инструкциям, как описано здесь:
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Так как у вас уже есть открытый ключ, вы в конце "шаг 1",

Шаг 2:
Выполните SHA-256 хеширования на открытом ключе

Код:

A579A1CEDA2894FDDB360E9D2941907835A290C72BFEC0443E1EFF64AAA61EAA

Шаг 3:
Выполните RIPEMD-160 хэширования на результат SHA-256

Код:

8B1D6A31B019E2DA16DE77F60C623B1442D5EC2E

Шаг 4:
Добавить версии байт перед RIPEMD-160 хэша (0x00 для главной сети)

Код:

008B1D6A31B019E2DA16DE77F60C623B1442D5EC2E

Шаг 5:
Выполните SHA-256 хэш на расширенной RIPEMD-160 результата

Код:

F83469929812FE7835C4650BBC6E32DB092B545F0D546B597C8BFBA0C7C26BD8

Шаг 6:
Выполните SHA-256 хэш от результата предыдущего SHA-256 хэш

Код:

243A00619F100F1A1D84D418198875C023F45290574D5BAC64FEA8B7897B1852

Шаг 7:
Возьмите первые 4 байта второй SHA-256 хэш. Это адрес контрольной суммы

Код:

243A0061

Шаг 8:
Добавьте 4 контрольных суммы байт из стадии 7 в конце расширенной RIPEMD-160 хэша со стадии 4. Это 25-байтовый двоичным Биткойн Адрес

Код:

008B1D6A31B019E2DA16DE77F60C623B1442D5EC2E243A0061

Шаг 9:
Преобразование результата из строки байт в строку base58, используя кодирование Base58Check. Это наиболее часто используемый формат Bitcoin адрес

Код:

1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC

Большое спасибо за подробный ответ.

Я посмотрел немного дальше, и выход в формате «сжатого открытого ключа». Мой анализатор уже учитывает несжатый открытый ключ 65 байт, который используется только на некоторое время, в начале срока службы blockchain. Эти сжатые открытые ключи используются редко, а потому что большая часть времени 20 байт ripemd160 хэш открытого ключа, что обычно хранится в выходном скрипте.

http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key

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

Код:

BOOL bitcoinPublicKeyToAddress (Const uint8_t вход [65], // 65 байт длиной ECDSA открытого ключа; первый байт всегда будет 0x4 следуют два байта 32 компонентов
Выход uint8_t [25]) // Bitcoin адрес (в двоичном виде (всегда имеет длину 25 байт.
{
BOOL RET = ложь;

если (вход [0] == 0x04)
{
uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений
SHA256 :: computeSHA256 (вход, 65, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи
Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети)
Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш
SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы)
SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы)
Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного
Выход [22] = hash1 [1];
Выход [23] = hash1 [2];
Выход [24] = hash1 [3];
RET = TRUE;
}
вернуться в отставке;
}

Что мне интересно, как я беру 33 байт «сжатых» форму во внимание?

Цитата: jratcliff63367 29 декабря 2014, 10:28:37 PM

Что мне интересно, как я беру 33 байт «сжатых» форму во внимание?

Обратите внимание, что в tranaction, есть не Bitcoin адрес. Сделка не была "отправлен в Bitcoin адрес", Он был отправлен в сжатом открытый ключ.

Если вы все еще чувствуете, как вы хотите создать Bitcoin адрес представление для этого открытого ключа для какой-либо причины, то вы просто хэш открытого ключа 33 байт, вместо хэширования открытого ключа 65 байт.

Что-то вроде этого:

Код:

BOOL bitcoinCompressedPublicKeyToAddress (Const uint8_t вход [33], // 33-байт длиной ECDSA открытого ключа; первый байт всегда будет либо 0x02 или 0x03 следуют через 32 компонентов байт
Выход uint8_t [25]) // Bitcoin адрес (в двоичной системе всегда имеет длину 25 байт).
{
BOOL RET = ложь;

если ((вход [0] == 0x02) || ((вход [0] == 0x03))
{
uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений
SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи
Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети)
Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш
SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы)
SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы)
Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного
Выход [22] = hash1 [1];
Выход [23] = hash1 [2];
Выход [24] = hash1 [3];
RET = TRUE;
}
вернуться в отставке;
}

Хорошо, я получил его на работу. Я просто должен был сделать «сжатую» версию моей жизни. Вот код:

Код:

BOOL bitcoinCompressedPublicKeyToAddress (Const uint8_t вход [32], // 33 байт длиной сжатого ECDSA открытый ключ; первый байт всегда будет 0x2 или 0x3 с последующим компонентом 32 байта
Выход uint8_t [25]) // Bitcoin адрес (в двоичном виде (всегда имеет длину 25 байт.
{
BOOL RET = ложь;

если (вход [0] == 0x02 || вход [0] == 0x03)
{
uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений
SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи
Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети)
Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш
SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы)
SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы)
Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного
Выход [22] = hash1 [1];
Выход [23] = hash1 [2];
Выход [24] = hash1 [3];
RET = TRUE;
}
вернуться в отставке;
}

Цитата: jratcliff63367 29 декабря 2014, 10:47:07 PM

Хорошо, я получил его на работу. Я просто должен был сделать «сжатую» версию моей жизни. Вот код:

Код:

- чик -

Только для образовательных целей, он мог бы все было сделано в одной процедуре с чем-то вроде следующего:

Код:

BOOL bitcoinPublicKeyToAddress (Const uint8_t вход [65], // Открытый ключ ECDSA; первый байт будет указывать, если открытый ключ сжимается или нет
Выход uint8_t [25]) // Bitcoin адрес (в двоичной системе всегда имеет длину 25 байт).
{
BOOL RET = ложь;
uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений

если (вход [0] == 0x04) // несжатого открытый ключ. Первый байт 0x04 следуют два байта 32 компонентов
{
SHA256 :: computeSHA256 (вход, 65, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи
}
иначе если (вход [0] == 0x02 || вход [0] == 0x03) // Сжатый открытый ключ. Первые байты 0x02 или 0x03 с последующим компонентом 32 байта
{
SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи
}

если (вход [0] == 0x02 || вход [0] == 0x03 || вход [0] == 0x04)
{
Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети)
Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш
SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы)
SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы)
Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного
Выход [22] = hash1 [1];
Выход [23] = hash1 [2];
Выход [24] = hash1 [3];
RET = TRUE;
}
вернуться в отставке;
}

Дэнни, вы были настолько полезным выяснить, что сжатый открытый ключ, может быть, вы можете помочь мне с этим тоже.

Посмотрите на эту сделку:

https://blockchain.info/tx/195c96a25c4e63f641a2ddd920a9d00d2db947752f41c6be6d4cdd21e54f7ae8

Он имеет два выходных сценарии, вторая содержит хэш ripemd160 следующим образом:

OP_HASH160 49206c6f76652077697a6b6964303537203c3300 OP_EQUAL

Когда я бегу: "49206c6f76652077697a6b6964303537203c3300" через мой код для получения ключа ASCII, я получаю:

"17ffAqKkfMLF5QAYwFEDkRtF2mJMzrkmpi" в результате.

Тем не менее, blockchain.info говорит адрес ASCII является: "38Mg6NpCDFedAZrz4LtpB4FBBHb5WqwHaN"

Это выглядит подозреваемого мне, чтобы начать с, потому что она не начинается с «1». Я склонен думать, что мое представление является правильным и blockchain.info есть ошибка. Можешь подтвердить?

* EDIT * и вот еще один:

https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075

Сценарий третий выход имеет длину всего 60 байт, и как только вы удалите оператор толчок данных и OP_CHECKSIG, есть только 58 байт осталось. Я привык получать несжатые открытые ключи 65 байт в длине. Что означает 58 байт длиной открытого ключа означает? Как это должно быть истолковано?

Благодаря,

Джон

Цитата: jratcliff63367 29 декабря 2014, 11:46:44 PM

Bitcoin адреса, которые начинаются с 1 являются "платить Публичный хэш" скрипты. 1 представляет собой номер версии, который говорит бумажник программного обеспечения, которое должно создать / распознать скрипт в формате:
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

Bitcoin адреса, которые начинаются с 3 являются "заплатить скрипт хэш" скрипты. 3 представляет собой номер версии, который говорит бумажник программного обеспечения, которое должно создать / распознать скрипт в формате:
OP_HASH160 (20-байтовое хэш-значение> OP_EQUAL

Представление адреса платы к-скрипт-хэш описан в BIP-0013

Код:

base58-кодирование: [один байт версии] [20-байтовое хэш] [4 байта контрольной суммы]

Для получения более подробной информации о том, как использовать Pay-на-скрипт-хэш вы посмотрите на можете BIP-0016

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

Вот один, где открытый ключ длиной 37 байт:

https://blockchain.info/tx/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1

Данные для ключа:

Код:

4d 65 73 73 61 67 65 20 68 3 74 74 70 3a 2f 2f
69 2e 69 6d 67 75 72 63 2e 6f 6d 2f 73 38 64 5а
30 2e 6а 70 67

Первый байт «0x4D»

Вот один, где открытый ключ длиной 58 байт:

https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075

Данные для ключа:

Код:

4d 65 73 73 61 67 65 20 42 3 69 74 63 69 6f 6e
50 61 72 61 64 2e 65 20 44 69 76 69 64 65 64 6e
65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 20 6f 6d
30 37 30 39 2e 2e 32 30 31 32

Первый байт 0x4D, а также.

Я не привык видеть открытые ключи в выходных сценариях таких нечетных размеров. Почему они появляются, и что надлежащее правило, чтобы преобразовать их в адрес Bitcoin? Есть ли место, что документы все, как эти подписи могут быть закодированы (и преобразованы в формат ripemd160) с чисто шестигранным отвалом точки зрения?

Благодаря,

Джон

Цитата: jratcliff63367 30 декабря 2014, 12:11:40 AM

Код:

4d 65 73 73 61 67 65 20 68 3 74 74 70 3a 2f 2f
69 2e 69 6d 67 75 72 63 2e 6f 6d 2f 73 38 64 5а
30 2e 6а 70 67

Код:

4d 65 73 73 61 67 65 20 42 3 69 74 63 69 6f 6e
50 61 72 61 64 2e 65 20 44 69 76 69 64 65 64 6e
65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 20 6f 6d
30 37 30 39 2e 2e 32 30 31 32

Согласно этому сообщению DeathAndTaxes:

Есть 17112 неизрасходованные выходы, которые постоянно unspendable из-за наличия недопустимого открытого ключа. Я подозреваю, что это два из них.

Если вы хотите создать Bitcoin адрес представление недействительного открытого ключа, который соответствует представлению, что blockchain.info решил использовать, вероятно, можно просто вычислить адрес, хешировании недействительного ключа. Таким образом, ваш bitcoinPublicKeyToAddress сценарий может быть более общим путем подсчитывая количество байтов в открытом ключе, а затем хеширования, независимо от того, есть 33 байт, 65 байт, или некоторое другое значение полностью.

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

Я искал общие закономерности в сценарии, которые обычно 99,999% всех выходных скриптов соответствуют.

В первые дни Bitcoin людей использовали полный 65 байт открытого ключа, а потом перешел на формат 20 байт ripemd160 почти везде.

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

Я думаю, что я ищу заключается в следующем:

Я хочу, чтобы рутина, которая может принимать выходную транзакцию сценария как сырые шестигранные двоичные данные и обеспечить в качестве вывода общественности Bitcoin адреса (* точно *, что будет отображаться в blockchain.info как выходной адрес).

что-то вроде:

Код:

структура BitcoinAddress
{
uint32_t ключа [25]; // 25 Bitcoin публичного адреса ключа
};

uint32_t findOutputAddresses (Const uint8_t * scriptData, // Данные сценария добытого
uint32_t scriptLength, // Длина выходного сценария.
BitcoinAddress * ключи, // Массив ключей для возврата
uint32_t maxOutputKeys); // Максимальное количество выходных ключей разрешено

Если кто-то может осуществить это в C ++ с абсолютно * не * внешних зависимостей на любой другой код любого кода (кроме stdint.h), который был бы идеальным. У меня есть рутина уже, что делает это, однако, что процедура явно не принимает все возможные перестановки во внимание и я заключаю, имеющую магическое знание, чтобы знать, как анализировать выходные сценарии в каждом аромате занимает много времени.

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

Опять же, требования, которые он принимает необработанный блоб выходного сценария и возвращает один или более, Bitcoin адресов, которые при печати в BASE58 ASCII точно соответствует тому, что будет отображаться в blockchain.info. Он должен быть один исходный файл, C ++, и имеют нулевые внешние зависимости ни на что, кроме

Любой на этот вызов?

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

Благодаря,

Джон

Цитата: jratcliff63367 30 декабря 2014, 12:55:23 AM

- чик -
Любой на этот вызов?
- чик -

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

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

Я не понимаю, почему вы хотите, чтобы расшифровать эти фиктивные ключи паба. Они, очевидно, недействительны. Это просто кто-то, кто хотел поместить текстовое сообщение в blockchain. OP_RETURN правильный способ сделать это. Клиент может понизить их из набора UTXO.

4d6573736167653a20687474703a2f2f692e696d6775722e636f6d2f735a3864302e6a7067 в ASCII является "Сообщение: BitcoinPara.de Dividendenzahlung 1 фом 07.09.2012",

PS: разгадка в том, что они начинаются с тех же байтов и 65 «е», 61 «а» в формате ASCII.

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

Может быть, кто-то, кто работает в blcockchain.info может объяснить, как они интерпретируют все эти довольно причудлива сформированные подписи сценария?

Это также напоминает, почему я не то, что в восторге от всего скриптового механизма Bitcoin. Некоторые четкие стандарты по формату и структуре входных и выходных данных будет делать вещи намного чище. Теперь, с 20/20 задним числом, я хочу, чтобы Bitcoin был целиком и полностью жёстко никаких сценарии все, и любая «экспериментальная» программируемая дерьмо не были зарезервированы для боковых цепей.

Затем сделать то, что Дэнни сказал.

Цитата: jratcliff63367 от 30 декабря 2014 года, 6:35:14 AM

По существу, я использую «blockchain.info» для отладки мне свой код, поэтому соответствие их «интерпретации» сигнатур вывода сценария действительно то, что я пытаюсь сделать.

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

котировка

Установка произвольных данных с OP_RETURN - это правильный путь, конечно. Но это была стандартизирована только в 2014 году.
Существовало много других способов, в прошлом.

Кстати, клиенты могут также относиться к p2pk выходов с недействительными открытыми ключами в виде доказуемо unspendable.

Просто следовать, я обнаружил, что большая часть моих вопросов, просто правильно сформированы несколько Sig адрес; который мой парсер не был обновлен, чтобы принять во внимание. Я теперь убедившись, что я могу полностью объяснить несколько сига адреса. Я уверен, что другие люди заметили это, но по чуть более месяц назад был взрыв в использовании нескольких сиг адресов и дерьмо-тонне Bitcoins двигается к ним.

29 декабря 2014, 10:03:41 PM	# 1
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я работаю над моей Bitcoin парсер, и я бегу через несколько случаев, когда я не могу расшифровать открытый ключ в выходном скрипте. Вот пример: См coinbase транзакции в блоке # 199,975 https://blockchain.info/tx/870f2daaf1e6bf44fd23c98b152f5f5b45beeb7066eb135840809cb528579e87 Вы можете заметить, что выходной адрес, который blockchain.info шоу является: 1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC Шестнадцатеричный адрес для этого: 0x00, 0x8b, 0x1D, 0x6a, 0x31, 0xb0, 0x19, 0xe2, 0xda, 0x16, 0xDE, 0x77, 0xf6, 0x0c, 0x62, 0x3b, 0x14, 0x42, 0xd5, 0xec, 0x2e, 0x24, 0x3a, 0x00, 0x61 Обычно я нахожу открытый ключ в выходном сценарии, но в данном случае я не могу понять, как / где blockchain.info придумал "1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC" для вывода сценария, содержащего: ChallengeScriptLength: 35 байт длиной 21 - Push 0x21 байт в стеке 02 14 71 с3 е2 с3 3f 1a 52 55 14 а5 CB f9 дб d3 22 f8 2b 95 78 34 90 е5 AB 99 FF 00 26 30 ЕВА b7 й переменный ток OP_CHECKSIG Любая помощь / советы о том, что я пропускаю, чтобы извлечь открытый ключ из этого вывода сценария будет наиболее высокую оценку. Как работает этот поток 33 (02 14 71 с3 е2 с3 3f 1a 52 55 а5 14 CB f9 дб d3 22 f8 2b 95 78 34 е5 90 AB 99 FF 00 26 30 ЕВО b7 й) байты включить в этот открытый ключ '1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC' ? Благодаря, Джон

29 декабря 2014, 10:22:13 PM	# 2
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Получил 1806 Биткоинов Реальная история. Цитата: jratcliff63367 29 декабря 2014, 10:03:41 PM Я работаю над моей Bitcoin парсер, и я бегу через несколько случаев, когда я не могу расшифровать открытый ключ в выходном скрипте. Вот пример: См coinbase транзакции в блоке # 199,975 https://blockchain.info/tx/870f2daaf1e6bf44fd23c98b152f5f5b45beeb7066eb135840809cb528579e87 Вы можете заметить, что выходной адрес, который blockchain.info шоу является: 1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC Шестнадцатеричный адрес для этого: 0x00, 0x8b, 0x1D, 0x6a, 0x31, 0xb0, 0x19, 0xe2, 0xda, 0x16, 0xDE, 0x77, 0xf6, 0x0c, 0x62, 0x3b, 0x14, 0x42, 0xd5, 0xec, 0x2e, 0x24, 0x3a, 0x00, 0x61 Обычно я нахожу открытый ключ в выходном сценарии, но в данном случае я не могу понять, как / где blockchain.info придумал "1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC" для вывода сценария, содержащего: "021471c3e2c33f1a5255a514cbf9dbd322f82b957834e590ab99ff002630ebb7ee OP_CHECKSIG" Любая помощь / советы о том, что я пропускаю, чтобы извлечь открытый ключ из этого вывода сценария будет наиболее высокую оценку. Благодаря, Джон Эта сделка, как представляется, использовать устаревшие "оплата за Публичный" Сценарий вместо более широко используется "оплата за Публичным-хэш", Таким образом, значение, даваемое в сценарии ЯВЛЯЕТСЯ открытый ключ. Чтобы увидеть этот открытый ключ, представленный в качестве адреса Bitcoin, вам необходимо следовать инструкциям, как описано здесь: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses Так как у вас уже есть открытый ключ, вы в конце "шаг 1", Шаг 2: Выполните SHA-256 хеширования на открытом ключе Код: A579A1CEDA2894FDDB360E9D2941907835A290C72BFEC0443E1EFF64AAA61EAA Шаг 3: Выполните RIPEMD-160 хэширования на результат SHA-256 Код: 8B1D6A31B019E2DA16DE77F60C623B1442D5EC2E Шаг 4: Добавить версии байт перед RIPEMD-160 хэша (0x00 для главной сети) Код: 008B1D6A31B019E2DA16DE77F60C623B1442D5EC2E Шаг 5: Выполните SHA-256 хэш на расширенной RIPEMD-160 результата Код: F83469929812FE7835C4650BBC6E32DB092B545F0D546B597C8BFBA0C7C26BD8 Шаг 6: Выполните SHA-256 хэш от результата предыдущего SHA-256 хэш Код: 243A00619F100F1A1D84D418198875C023F45290574D5BAC64FEA8B7897B1852 Шаг 7: Возьмите первые 4 байта второй SHA-256 хэш. Это адрес контрольной суммы Код: 243A0061 Шаг 8: Добавьте 4 контрольных суммы байт из стадии 7 в конце расширенной RIPEMD-160 хэша со стадии 4. Это 25-байтовый двоичным Биткойн Адрес Код: 008B1D6A31B019E2DA16DE77F60C623B1442D5EC2E243A0061 Шаг 9: Преобразование результата из строки байт в строку base58, используя кодирование Base58Check. Это наиболее часто используемый формат Bitcoin адрес Код: 1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC

29 декабря 2014, 10:28:37 PM	# 3
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Большое спасибо за подробный ответ. Я посмотрел немного дальше, и выход в формате «сжатого открытого ключа». Мой анализатор уже учитывает несжатый открытый ключ 65 байт, который используется только на некоторое время, в начале срока службы blockchain. Эти сжатые открытые ключи используются редко, а потому что большая часть времени 20 байт ripemd160 хэш открытого ключа, что обычно хранится в выходном скрипте. http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key Вот фрагмент кода, если код, который я в настоящее время используют для преобразования 65 байт в несжатом открытый ключ к Bitcoin адрес, который соответствует вашему объяснению. Код: BOOL bitcoinPublicKeyToAddress (Const uint8_t вход [65], // 65 байт длиной ECDSA открытого ключа; первый байт всегда будет 0x4 следуют два байта 32 компонентов Выход uint8_t [25]) // Bitcoin адрес (в двоичном виде (всегда имеет длину 25 байт. { BOOL RET = ложь; если (вход [0] == 0x04) { uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений SHA256 :: computeSHA256 (вход, 65, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети) Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы) SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы) Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного Выход [22] = hash1 [1]; Выход [23] = hash1 [2]; Выход [24] = hash1 [3]; RET = TRUE; } вернуться в отставке; } Что мне интересно, как я беру 33 байт «сжатых» форму во внимание?

29 декабря 2014, 10:43:30 PM	# 4
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Цитата: jratcliff63367 29 декабря 2014, 10:28:37 PM Что мне интересно, как я беру 33 байт «сжатых» форму во внимание? Обратите внимание, что в tranaction, есть не Bitcoin адрес. Сделка не была "отправлен в Bitcoin адрес", Он был отправлен в сжатом открытый ключ. Если вы все еще чувствуете, как вы хотите создать Bitcoin адрес представление для этого открытого ключа для какой-либо причины, то вы просто хэш открытого ключа 33 байт, вместо хэширования открытого ключа 65 байт. Что-то вроде этого: Код: BOOL bitcoinCompressedPublicKeyToAddress (Const uint8_t вход [33], // 33-байт длиной ECDSA открытого ключа; первый байт всегда будет либо 0x02 или 0x03 следуют через 32 компонентов байт Выход uint8_t [25]) // Bitcoin адрес (в двоичной системе всегда имеет длину 25 байт). { BOOL RET = ложь; если ((вход [0] == 0x02) \|\| ((вход [0] == 0x03)) { uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети) Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы) SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы) Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного Выход [22] = hash1 [1]; Выход [23] = hash1 [2]; Выход [24] = hash1 [3]; RET = TRUE; } вернуться в отставке; }

29 декабря 2014, 10:47:07 PM	# 5
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Хорошо, я получил его на работу. Я просто должен был сделать «сжатую» версию моей жизни. Вот код: Код: BOOL bitcoinCompressedPublicKeyToAddress (Const uint8_t вход [32], // 33 байт длиной сжатого ECDSA открытый ключ; первый байт всегда будет 0x2 или 0x3 с последующим компонентом 32 байта Выход uint8_t [25]) // Bitcoin адрес (в двоичном виде (всегда имеет длину 25 байт. { BOOL RET = ложь; если (вход [0] == 0x02 \|\| вход [0] == 0x03) { uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети) Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы) SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы) Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного Выход [22] = hash1 [1]; Выход [23] = hash1 [2]; Выход [24] = hash1 [3]; RET = TRUE; } вернуться в отставке; }

29 декабря 2014, 11:01:34 PM	# 6
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Цитата: jratcliff63367 29 декабря 2014, 10:47:07 PM Хорошо, я получил его на работу. Я просто должен был сделать «сжатую» версию моей жизни. Вот код: Код: - чик - Только для образовательных целей, он мог бы все было сделано в одной процедуре с чем-то вроде следующего: Код: BOOL bitcoinPublicKeyToAddress (Const uint8_t вход [65], // Открытый ключ ECDSA; первый байт будет указывать, если открытый ключ сжимается или нет Выход uint8_t [25]) // Bitcoin адрес (в двоичной системе всегда имеет длину 25 байт). { BOOL RET = ложь; uint8_t hash1 [32]; // держит промежуточный SHA256 хэш вычислений если (вход [0] == 0x04) // несжатого открытый ключ. Первый байт 0x04 следуют два байта 32 компонентов { SHA256 :: computeSHA256 (вход, 65, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи } иначе если (вход [0] == 0x02 \|\| вход [0] == 0x03) // Сжатый открытый ключ. Первые байты 0x02 или 0x03 с последующим компонентом 32 байта { SHA256 :: computeSHA256 (вход, 33, hash1); // Вычислить SHA256 хэш входной общественности ECSDA подписи } если (вход [0] == 0x02 \|\| вход [0] == 0x03 \|\| вход [0] == 0x04) { Выход [0] = 0; // Сохранить сетевые байты 0 (т.е. «» основной сети) Ripemd160 :: computeRIPEMD160 (hash1,32,&Выход [1]); // Вычислить ripemd160 (20 байт) хэш SHA256 хэш SHA256 :: computeSHA256 (выход, 21, hash1); // Вычислить SHA256 хэш хэш RIPEMD16 + заголовок один байт (для контрольной суммы) SHA256 :: computeSHA256 (hash1,32, hash1); // теперь вычислить SHA256 хэш ранее вычисленный хэш SHA256 (для контрольной суммы) Выход [21] = hash1 [0]; // Сохраняет контрольную сумму в последнем 4 байта ключа хэша общественного Выход [22] = hash1 [1]; Выход [23] = hash1 [2]; Выход [24] = hash1 [3]; RET = TRUE; } вернуться в отставке; }

29 декабря 2014, 11:46:44 PM	# 7
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Дэнни, вы были настолько полезным выяснить, что сжатый открытый ключ, может быть, вы можете помочь мне с этим тоже. Посмотрите на эту сделку: https://blockchain.info/tx/195c96a25c4e63f641a2ddd920a9d00d2db947752f41c6be6d4cdd21e54f7ae8 Он имеет два выходных сценарии, вторая содержит хэш ripemd160 следующим образом: OP_HASH160 49206c6f76652077697a6b6964303537203c3300 OP_EQUAL Когда я бегу: "49206c6f76652077697a6b6964303537203c3300" через мой код для получения ключа ASCII, я получаю: "17ffAqKkfMLF5QAYwFEDkRtF2mJMzrkmpi" в результате. Тем не менее, blockchain.info говорит адрес ASCII является: "38Mg6NpCDFedAZrz4LtpB4FBBHb5WqwHaN" Это выглядит подозреваемого мне, чтобы начать с, потому что она не начинается с «1». Я склонен думать, что мое представление является правильным и blockchain.info есть ошибка. Можешь подтвердить? * EDIT * и вот еще один: https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075 Сценарий третий выход имеет длину всего 60 байт, и как только вы удалите оператор толчок данных и OP_CHECKSIG, есть только 58 байт осталось. Я привык получать несжатые открытые ключи 65 байт в длине. Что означает 58 байт длиной открытого ключа означает? Как это должно быть истолковано? Благодаря, Джон

29 декабря 2014, 11:58:24 PM	# 8
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Цитата: jratcliff63367 29 декабря 2014, 11:46:44 PM Дэнни, вы были настолько полезным выяснить, что сжатый открытый ключ, может быть, вы можете помочь мне с этим тоже. Посмотрите на эту сделку: https://blockchain.info/tx/195c96a25c4e63f641a2ddd920a9d00d2db947752f41c6be6d4cdd21e54f7ae8 Он имеет два выходных сценарии, вторая содержит хэш ripemd160 следующим образом: OP_HASH160 49206c6f76652077697a6b6964303537203c3300 OP_EQUAL Когда я бегу: "49206c6f76652077697a6b6964303537203c3300" через мой код для получения ключа ASCII, я получаю: "17ffAqKkfMLF5QAYwFEDkRtF2mJMzrkmpi" в результате. Тем не менее, blockchain.info говорит адрес ASCII является: "38Mg6NpCDFedAZrz4LtpB4FBBHb5WqwHaN" Это выглядит подозреваемого мне, чтобы начать с, потому что она не начинается с «1». Я склонен думать, что мое представление является правильным и blockchain.info есть ошибка. Можешь подтвердить? Благодаря, Джон Bitcoin адреса, которые начинаются с 1 являются "платить Публичный хэш" скрипты. 1 представляет собой номер версии, который говорит бумажник программного обеспечения, которое должно создать / распознать скрипт в формате: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG Bitcoin адреса, которые начинаются с 3 являются "заплатить скрипт хэш" скрипты. 3 представляет собой номер версии, который говорит бумажник программного обеспечения, которое должно создать / распознать скрипт в формате: OP_HASH160 (20-байтовое хэш-значение> OP_EQUAL Представление адреса платы к-скрипт-хэш описан в BIP-0013 Код: base58-кодирование: [один байт версии] [20-байтовое хэш] [4 байта контрольной суммы] Для получения более подробной информации о том, как использовать Pay-на-скрипт-хэш вы посмотрите на можете BIP-0016

30 декабря 2014, 12:11:40 AM	# 9
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Я предполагаю, что у меня есть подобный вопрос. Я сталкиваюсь рядом выходных скриптов, которые имеют нестандартные длины для открытого ключа. Вот один, где открытый ключ длиной 37 байт: https://blockchain.info/tx/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1 Данные для ключа: Код: 4d 65 73 73 61 67 65 20 68 3 74 74 70 3a 2f 2f 69 2e 69 6d 67 75 72 63 2e 6f 6d 2f 73 38 64 5а 30 2e 6а 70 67 Первый байт «0x4D» Вот один, где открытый ключ длиной 58 байт: https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075 Данные для ключа: Код: 4d 65 73 73 61 67 65 20 42 3 69 74 63 69 6f 6e 50 61 72 61 64 2e 65 20 44 69 76 69 64 65 64 6e 65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 20 6f 6d 30 37 30 39 2e 2e 32 30 31 32 Первый байт 0x4D, а также. Я не привык видеть открытые ключи в выходных сценариях таких нечетных размеров. Почему они появляются, и что надлежащее правило, чтобы преобразовать их в адрес Bitcoin? Есть ли место, что документы все, как эти подписи могут быть закодированы (и преобразованы в формат ripemd160) с чисто шестигранным отвалом точки зрения? Благодаря, Джон

30 декабря 2014, 12:35:34 AM	# 10
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Цитата: jratcliff63367 30 декабря 2014, 12:11:40 AM Я предполагаю, что у меня есть подобный вопрос. Я сталкиваюсь рядом выходных скриптов, которые имеют нестандартные длины для открытого ключа. Вот один, где открытый ключ длиной 37 байт: https://blockchain.info/tx/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1 Данные для ключа: Код: 4d 65 73 73 61 67 65 20 68 3 74 74 70 3a 2f 2f 69 2e 69 6d 67 75 72 63 2e 6f 6d 2f 73 38 64 5а 30 2e 6а 70 67 Первый байт «0x4D» Вот один, где открытый ключ длиной 58 байт: https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075 Данные для ключа: Код: 4d 65 73 73 61 67 65 20 42 3 69 74 63 69 6f 6e 50 61 72 61 64 2e 65 20 44 69 76 69 64 65 64 6e 65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 20 6f 6d 30 37 30 39 2e 2e 32 30 31 32 Первый байт 0x4D, а также. Я не привык видеть открытые ключи в выходных сценариях таких нечетных размеров. Почему они появляются, и что надлежащее правило, чтобы преобразовать их в адрес Bitcoin? Есть ли место, что документы все, как эти подписи могут быть закодированы (и преобразованы в формат ripemd160) с чисто шестигранным отвалом точки зрения? Благодаря, Джон Согласно этому сообщению DeathAndTaxes: Есть 17112 неизрасходованные выходы, которые постоянно unspendable из-за наличия недопустимого открытого ключа. Я подозреваю, что это два из них. Если вы хотите создать Bitcoin адрес представление недействительного открытого ключа, который соответствует представлению, что blockchain.info решил использовать, вероятно, можно просто вычислить адрес, хешировании недействительного ключа. Таким образом, ваш bitcoinPublicKeyToAddress сценарий может быть более общим путем подсчитывая количество байтов в открытом ключе, а затем хеширования, независимо от того, есть 33 байт, 65 байт, или некоторое другое значение полностью.

30 декабря 2014, 12:55:23 AM	# 11
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Так что, как я исследовать все выходные сценариев, которые я не могу успешно декодировать адрес Bitcoin для, я понимаю, что, возможно, буду об этом неправильно. Я искал общие закономерности в сценарии, которые обычно 99,999% всех выходных скриптов соответствуют. В первые дни Bitcoin людей использовали полный 65 байт открытого ключа, а потом перешел на формат 20 байт ripemd160 почти везде. Тем не менее, существует ряд других форматов, в том числе таких вещей, как мульти-сиг, скрипт хэш, и других, которые создают много перестановок. Я думаю, что я ищу заключается в следующем: Я хочу, чтобы рутина, которая может принимать выходную транзакцию сценария как сырые шестигранные двоичные данные и обеспечить в качестве вывода общественности Bitcoin адреса (* точно , что будет отображаться в blockchain.info как выходной адрес). что-то вроде: Код: структура BitcoinAddress { uint32_t ключа [25]; // 25 Bitcoin публичного адреса ключа }; uint32_t findOutputAddresses (Const uint8_t scriptData, // Данные сценария добытого uint32_t scriptLength, // Длина выходного сценария. BitcoinAddress * ключи, // Массив ключей для возврата uint32_t maxOutputKeys); // Максимальное количество выходных ключей разрешено Если кто-то может осуществить это в C ++ с абсолютно * не * внешних зависимостей на любой другой код любого кода (кроме stdint.h), который был бы идеальным. У меня есть рутина уже, что делает это, однако, что процедура явно не принимает все возможные перестановки во внимание и я заключаю, имеющую магическое знание, чтобы знать, как анализировать выходные сценарии в каждом аромате занимает много времени. Если кто-то думает, что они могут написать такую процедуру, и есть интерес, я бы с удовольствием заплатил разумную Bitcoin щедроты для фрагмента кода. Она также может быть очень познавательно. Опять же, требования, которые он принимает необработанный блоб выходного сценария и возвращает один или более, Bitcoin адресов, которые при печати в BASE58 ASCII точно соответствует тому, что будет отображаться в blockchain.info. Он должен быть один исходный файл, C ++, и имеют нулевые внешние зависимости ни на что, кроме Любой на этот вызов? До сих пор количество ключей я не смог разобрать не было достаточно статистически незначимым, но это уже не так из-за недавние изменения в том, как люди формируют свои сделки. Я хочу завершить свой «конец года» статистики по blockchain, но, чтобы сделать это, я не могу позволить любым более открытым ключам проскользнуть пропавшим без вести. Благодаря, Джон

30 декабря 2014, 1:44:52 AM	# 12
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Цитата: jratcliff63367 30 декабря 2014, 12:55:23 AM - чик - Любой на этот вызов? - чик - Это интересный проект, звучащий, но у меня нет на это времени на этой неделе. Надеюсь, вы найдете кого-то, чтобы помочь вам. Вы можете создать поток в "базарная площадь" или "Сервисы" запрашивающий программиста. Я в настоящее время пост там предлагают платить PERL программисту писать быстрый небольшой скрипт для меня.

30 декабря 2014, 4:42:39 AM	# 13
hhanh00 Сообщения: 464 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Я не понимаю, почему вы хотите, чтобы расшифровать эти фиктивные ключи паба. Они, очевидно, недействительны. Это просто кто-то, кто хотел поместить текстовое сообщение в blockchain. OP_RETURN правильный способ сделать это. Клиент может понизить их из набора UTXO. 4d6573736167653a20687474703a2f2f692e696d6775722e636f6d2f735a3864302e6a7067 в ASCII является "Сообщение: BitcoinPara.de Dividendenzahlung 1 фом 07.09.2012", PS: разгадка в том, что они начинаются с тех же байтов и 65 «е», 61 «а» в формате ASCII.

30 декабря 2014, 6:35:14 AM	# 14
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Являются ли они «фиктивными» или нет, моя цель состоит в том, чтобы повторить то, что blockchain.info отчетов для них. Для большинства из этих blockchain.info делает доклад некоторые допустимый «адрес» для каждого из этих сценариев. По существу, я использую «blockchain.info» для отладки мне свой код, поэтому соответствие их «интерпретации» сигнатур вывода сценария действительно то, что я пытаюсь сделать. Может быть, кто-то, кто работает в blcockchain.info может объяснить, как они интерпретируют все эти довольно причудлива сформированные подписи сценария? Это также напоминает, почему я не то, что в восторге от всего скриптового механизма Bitcoin. Некоторые четкие стандарты по формату и структуре входных и выходных данных будет делать вещи намного чище. Теперь, с 20/20 задним числом, я хочу, чтобы Bitcoin был целиком и полностью жёстко никаких сценарии все, и любая «экспериментальная» программируемая дерьмо не были зарезервированы для боковых цепей.

30 декабря 2014, 7:32:53 AM	# 15
hhanh00 Сообщения: 464 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Затем сделать то, что Дэнни сказал. Цитата: jratcliff63367 от 30 декабря 2014 года, 6:35:14 AM По существу, я использую «blockchain.info» для отладки мне свой код, поэтому соответствие их «интерпретации» сигнатур вывода сценария действительно то, что я пытаюсь сделать. Я бы не стал использовать реализацию багги в качестве справочного материала для моего собственного кода, но это ваш звонок.

30 декабря 2014, 8:04:10 AM	# 16
amaclin Сообщения: 1260 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки котировка Я не понимаю, почему вы хотите, чтобы расшифровать эти фиктивные ключи паба. Они, очевидно, недействительны. Это просто кто-то, кто хотел поместить текстовое сообщение в blockchain. OP_RETURN правильный способ сделать это. Клиент может понизить их из набора UTXO. Установка произвольных данных с OP_RETURN - это правильный путь, конечно. Но это была стандартизирована только в 2014 году. Существовало много других способов, в прошлом. Кстати, клиенты могут также относиться к p2pk выходов с недействительными открытыми ключами в виде доказуемо unspendable.

30 декабря 2014, 7:57:46 PM	# 17
jratcliff63367 Сообщений: 82 Цитировать по имени цитировать ответ	Re: Нужна помощь в понимании сделки Просто следовать, я обнаружил, что большая часть моих вопросов, просто правильно сформированы несколько Sig адрес; который мой парсер не был обновлен, чтобы принять во внимание. Я теперь убедившись, что я могу полностью объяснить несколько сига адреса. Я уверен, что другие люди заметили это, но по чуть более месяц назад был взрыв в использовании нескольких сиг адресов и дерьмо-тонне Bitcoins двигается к ним.

Заголовок