|
![]() |
# 1 |
Сообщений: 38
цитировать ответ |
![]()
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru У меня есть построить двигатель хранения в качестве основы нового Bitcoin узла в развитии. Идея заключается в том, чтобы отказаться от индекса UTXO и использовать быстрое параллельное Потратьте дерево вместо этого. Результаты являются весьма многообещающими. Более подробную информацию можно здесь: https://bitcrust.org Результаты деятельности: https://bitcrust.org/results Исходный код в Русте доступен на https://github.com/tomasvdw/bitcrust |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 2 |
Сообщения: 1778
цитировать ответ |
![]()
Получил 1806 Биткоинов
Реальная история. Сколько памяти и дискового пространства, это нужно?
Поддерживаете ли вы все это в файлах на диске? Если вы проверить транзакцию (блок), который пытается провести выходные unexisting, вы должны вернуться через все файлы просто чтобы узнать, что она не существует? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 3 |
Сообщений: 38
цитировать ответ |
![]() Текущее использование:
1.3G ../data-cmp/block-index 5.6g ../data-cmp/spend-tree 41М ../data-cmp/headers 25G ../data-cmp/transactions2 196m ../data-cmp/spend-index 3.6G ../data-cmp/tx-index 85G ../data-cmp/transactions1 119g ../data-cmp/ Но это может быть отсечена, так же, как с Core. Что касается памяти, это использует файлы, отображенные на память, что означает много виртуальной памяти, но оставить его в ОС, чтобы поменять. При использовании надлежащей локальности ссылок, данные, которые не используются хранятся из памяти. Проблема потратив ранние выходы решаются Потратьте-индекс, который отстает от кончиков несколько блоков, чтобы поймать их. Это также объясняется под "провести индекс" раздел на сайте. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 4 |
Сообщения: 1778
цитировать ответ |
![]() Проблема потратив ранние выходы решаются Потратьте-индекс, который отстает от кончиков несколько блоков, чтобы поймать их. Это также объясняется под "провести индекс" раздел на сайте. ОК. Но как насчет результатов, которые никогда не существовали в первую очередь. Как вы обнаружите, что они не существуют? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 5 |
Сообщений: 38
цитировать ответ |
![]() ОК. Но как насчет результатов, которые никогда не существовали в первую очередь. Как вы обнаружите, что они не существуют? Израсходует дерево сканируются; если выход будет найден, он является двойным израсходован, если соответствующая сделка проводится это нормально, и если ничего не будет найдено, он тратит несуществующий выход. Аналогичным образом, если расходы индекс "уловы" поиск, два поиска выполняется: наличие сделки и отсутствия выхода. «Обманщик» тратить выход существующей транзакции с индексом выше, то графа вывода перехватывается проверки сценария. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 6 |
Сообщения: 1106
цитировать ответ |
![]() Делает ли это SegWit устаревшим?
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 7 |
Сообщения: 924
цитировать ответ |
![]() Делает ли это SegWit устаревшим? Нет, это только повышает производительность обычных операций при проверке операций и блоков. Что очень полезно, так как это снижает затраты на эксплуатацию полного узла. Другими словами, это увеличивает децентрализацию (нам нравится, что). Я прочитал весь документ, очевидно, что эти люди имеют некоторые навыки! |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 8 |
Сообщения: 1778
цитировать ответ |
![]() Столько, сколько я хотел из коробки подходов к темам, которые меня интересуют, чтобы быть честным, я не думаю, что это один может улучшить общую скорость "общие операции при проверке операций и блоков",
Индекс UTXO есть по причине. Лично я предпочел бы видеть какую-то работу по улучшению индекса и сам UTXO-DB, вместо того, чтобы избавиться от него, я думаю, это не правильный путь. Глядя на "результаты деятельности" следует помнить, что ядро (и раствор LevelDB) используют ограниченное количество системной памяти, в то время как это решение, похоже, использует все это. Кроме того, когда ядро получает проверить транзакцию, которая пытается провести несуществующий вход, он не будет потреблять столько ресурсов. Это потенциальная проблема DoS. К сожалению, я не имею в виду, что средний человек - это только мое холодное профессиональное мнение, что он не будет хорошо работать для вас, для фактического узла реального Bitcoin. Я желаю вам всего наилучшего с вашим проектом, @ tomtomtom7, но я не думаю, что это правильный подход к оптимизации производительности. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 9 |
Сообщений: 38
цитировать ответ |
![]() Спасибо за ваш отзыв.
Индекс UTXO есть по причине. Лично я предпочел бы видеть какую-то работу по улучшению индекса и сам UTXO-DB, вместо того, чтобы избавиться от него, я думаю, это не правильный путь. Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin. Если все транзакции предварительно синхронизировано, то можно выделить валидацию сценария базовой нагрузки (когда ТЕ приходит) и подтверждение заказа при пиковой нагрузке (когда блок приходит), то UTXO-индекс не делает все, что много смысла. Это происходит потому, что для проверки сценария, когда выходные сценарии необходимы различия между израсходованы и неизрасходованной на самом деле не существует, как это может быть потрачено на одной ветви, и не тратится на другом. Использование транзакционно поддерживаются индекс UTXO там только усложнение вещи (с) реорганизацией;. И для подтверждения заказа, выходные скрипты не нужны вообще. Глядя на "результаты деятельности" следует помнить, что ядро (и раствор LevelDB) используют ограниченное количество системной памяти, в то время как это решение, похоже, использует все это. Я не думаю, что это так. Bitcrust использует памяти отображаются страницы, которые отображаются как много виртуальной памяти, но поменялись в ОС по мере необходимости. Если вместо этого вы просто традиционный диск IO, данные кэшируются в ОС по мере необходимости. В любом случае, MRU страницы сохраняются в памяти. Кроме того, когда ядро получает проверить транзакцию, которая пытается провести несуществующий вход, он не будет потреблять столько ресурсов. Это потенциальная проблема DoS. Она никогда не нужно проверять всю цепочку, как после нескольких блоков проводят индекс улавливает искать и выполняет прямой поиск. Там еще могут быть потенциальные проблемы DoS, но не тратить несуществующее выход. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 10 |
Сообщения: 1778
цитировать ответ |
![]() О, хорошо. К сожалению, я не получил идею израсходует-индекс в первом.
Можете ли вы сказать что-то о том, как он на самом деле работает внутри? котировка Это очень компактный битовый индекс с одним битом для каждой транзакции и один для каждого выхода |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 11 |
Сообщения: 2366
цитировать ответ |
![]() Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin. Если все транзакции будут предварительно синхронизированы, Точка факта: сделки проверяемая заранее всегда была верна и полностью ортогонален компактными блоками. Bitcoin также непосредственно эксплуатирует этот факт с помощью кэширования сигнатуры (который отключает ваши тесты, кстати, потому что вы используете недокументированные блоки только режим) с момента применения патча Satoshi на посвящении в мае 2012 года, и далее с кэшем ввода с июля 2012 года. Я видел Peter R сделать тот же самый аргумент несколько раз, и я спросил его, почему он представляет это тот путь, но AFAIR он никогда не ответил на один из этих сообщений. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 12 |
Сообщений: 38
цитировать ответ |
![]() Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin. Если все транзакции будут предварительно синхронизированы, Точка факта: сделки проверяемая заранее всегда была верна и полностью ортогонален компактными блоками. Bitcoin также непосредственно эксплуатирует этот факт с помощью кэширования сигнатуры (который отключает ваши тесты, кстати, потому что вы используете недокументированные блоки только режим) с момента применения патча Satoshi на посвящении в мае 2012 года, и далее с кэшем ввода с июля 2012 года. Я видел Peter R сделать тот же самый аргумент несколько раз, и я спросил его, почему он представляет это тот путь, но AFAIR он никогда не ответил на один из этих сообщений. Я понимаю, ядро предварительно проверяет подпись с нашими без компактных блоков / XThin. Я также понимаю, что скамейки не сравниваю, но сравнивать только полный блок проверки, который я объясняю на этой же странице. Но без компактных блоков / XThin, оптимизируя для сравнения порядка является гораздо менее актуальным из-за высокой стоимости полосы пропускания. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 13 |
Сообщений: 38
цитировать ответ |
![]() О, хорошо. К сожалению, я не получил идею израсходует-индекс в первом. Можете ли вы сказать что-то о том, как он на самом деле работает внутри? Я по существу преобразование операций и выходов к "гашиш" с: Код: хэш (ТХ) = tx.filepos / 16 И использовать "гашиш" в качестве прямого индекса битового индекса. Израсходует индекс представляет отработанное состояние несколько блоков от наконечника; набор бит в месте означает, что транзакции, существует или выход тратится там. Когда израсходует дерево ищется и достигает позицию Потратьте-индекс, положительный поиск для сделки и отрицательный поиск для вывода достаточно. Провел индекс растет с 1 бит на каждые каждые 16 байтов, или 1/128-е место размера blockchain. Так же, как с Потратьте дерева, в основном конец доступа к ним, поэтому запуск может быть сохранен на диске. Код самого Потратьте индекс довольно просто: https://github.com/tomasvdw/bitcrust/blob/master/src/store/spend_index.rs |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 14 |
Сообщения: 1778
цитировать ответ |
![]() Я по существу преобразование операций и выходов к "гашиш" с: Код: хэш (ТХ) = tx.filepos / 16 И использовать "гашиш" в качестве прямого индекса битового индекса. Израсходует индекс представляет отработанное состояние несколько блоков от наконечника; набор бит в месте означает, что транзакции, существует или выход тратится там. Когда израсходует дерево ищется и достигает позицию Потратьте-индекс, положительный поиск для сделки и отрицательный поиск для вывода достаточно. Провел индекс растет с 1 бит на каждые каждые 16 байтов, или 1/128-е место размера blockchain. Так же, как с Потратьте дерева, в основном конец доступа к ним, поэтому запуск может быть сохранен на диске. Код самого Потратьте индекс довольно просто: https://github.com/tomasvdw/bitcrust/blob/master/src/store/spend_index.rs Я честно не могу сказать, что я понимаю половину того, что вы сказали. Но я стараюсь. Допустим, вы получаете новую транзакцию, и вы должны проверить его. Все вы знаете, что он тратит один выход, описанный в TXID-VOUT. Поправьте меня, если я ошибаюсь: сначала пройти через последние X блоков вверх по Потратьте дерева, пытаясь найти TXID там. Но говорят, что TXID не был там - да, то вы должны пойти с тратой индекса, не так ли? Теперь, как вы смотрите на TXID внутри Потратьте индекс? Как вы преобразовать TXID в хэш? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 15 |
Сообщения: 1778
цитировать ответ |
![]() Я думаю, что я понимаю.
Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс", Тогда у вас есть индексный файл (ТХ-индекс), где каждая из различных точек TXID к "числовой индекс" - это на самом деле ваш эквивалент UTXO-индекс, за исключением того, что она включает в себя также проводила операции. И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки. Это верно? |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 16 |
Сообщения: 1778
цитировать ответ |
![]() Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс", Тогда у вас есть индексный файл (ТХ-индекс), где каждая из различных точек TXID к "числовой индекс" - это на самом деле ваш эквивалент UTXO-индекс, за исключением того, что она включает в себя также проводила операции. И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки. Это верно? Я предполагаю, что означает «да». В этом случае я могу дать более точную обратную связь. Прежде всего, вы не избавились от UTXO-индекса. Вы все еще есть. Вы просто расширили его в Ом-индекс означают, что вы индекс не только неизрасходованные сделки, но и затраченные из них. Теперь, как это возможно, что ваш код работает лучше, чем решение LevelDB используемого ядра ..? Она не имеет ничего общего с какой-либо "быстрое одновременное израсходует дерево", В нем есть все, чтобы сделать с самого индексом (U) Ого. Вы используете HashMap в качестве индекса, который намного быстрее, чем индекс, используемый LevelDB двигателя сердечника. Но он также занимает гораздо больше системной памяти. Я знаю, потому что я также использовать индекс UTXO на основе HashMap в моем gocoin s / ш. Таким образом, вы не должны сказать мне, что это намного быстрее. Но это происходит за счет памяти - вы не можете запустить, например, с 2 Гб оперативной памяти. Из моего личного опыта, я бы сказал, что вам нужно, по крайней мере 8 ГБ. И потому, что вы индексировать и; проведенные и неизрасходованные операции, вам нужно еще больше памяти, чем решение UTXO-индекс, который вы пытаетесь бить. Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 17 |
Сообщения: 1778
цитировать ответ |
![]() И потому, что вы индексировать и; проведенные и неизрасходованные операции, вам нужно еще больше памяти, чем решение UTXO-индекс, который вы пытаетесь бить. Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс. Позвольте мне добавить некоторые цифры здесь. На данный момент (блок 461402) типичный показатель UTXO имеет 20438271 записи (транзакция) - что это 20 миллионов. В то же время индекс Тх, используемый вашим решением необходимо более 210 миллионов записей. https://blockchain.info/charts/n-transactions-total |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 18 |
Сообщений: 38
цитировать ответ |
![]() Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс", Тогда у вас есть индексный файл (ТХ-индекс), где каждая из различных точек TXID к "числовой индекс" - это на самом деле ваш эквивалент UTXO-индекс, за исключением того, что она включает в себя также проводила операции. И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки. Это верно? Да. Хотя вы выходите из с тратой дерева. Прежде всего, вы не избавились от UTXO-индекса. Вы все еще есть. Вы просто расширили его в Ом-индекс означают, что вы индекс не только неизрасходованные сделки, но и затраченные из них. Теперь, как это возможно, что ваш код работает лучше, чем решение LevelDB используемого ядра ..? Она не имеет ничего общего с какой-либо "быстрое одновременное израсходует дерево", В нем есть все, чтобы сделать с самого индексом (U) Ого. Вы используете HashMap в качестве индекса, который намного быстрее, чем индекс, используемый LevelDB двигателя сердечника. Но он также занимает гораздо больше системной памяти. Я знаю, потому что я также использовать индекс UTXO на основе HashMap в моем gocoin s / ш. Таким образом, вы не должны сказать мне, что это намного быстрее. Но это происходит за счет памяти - вы не можете запустить, например, с 2 Гб оперативной памяти. Из моего личного опыта, я бы сказал, что вам нужно, по крайней мере 8 ГБ. И потому, что вы индексировать и; проведенные и неизрасходованные операции, вам нужно еще больше памяти, чем решение UTXO-индекс, который вы пытаетесь бить. Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс. Важная часть заключается в разделении проверки базовой транзакции нагрузки (когда транзакция приходит в) с проверкой порядка нагрузки (пик, когда блок приходит в). Для первых, эта конструкция сама по себе не быстрее, так как он действительно использует индекс, который включает в себя отработанные выходы (хотя это может быть отсечена, чтобы быть еще более похожим на UTXO). Это также намного менее актуальна, потому что если нет блока не поступают, ни ядра, ни Bitcrust которые нуждаются много ресурсов. Для последнего, когда блок приходит в выходные сценарии не нужны, поскольку они уже проверены. Единственное, что необходимо, чтобы получить доступ является чтение к индексу операции, которую только отображает хеши в файл коррекций. И читает и пишет на дерево Потратьте и отработавший индекс, которые являются очень компактными и одновременно доступными. Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены. По сути Bitcrust просто гарантирует, что работа и ресурсы, необходимые, когда блок приходит к минимуму. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 19 |
Сообщения: 2366
цитировать ответ |
![]() Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены. Это не то, как работает Bitcoin ядро. Нет доступа к диску обычно вообще не происходит, когда блок проверяется для транзакций, которые еще не видели, чтения или записи, за исключением. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 20 |
Сообщений: 38
цитировать ответ |
![]() Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены. Это не то, как работает Bitcoin ядро. Нет доступа к диску обычно вообще не происходит, когда блок проверяется для транзакций, которые еще не видели, чтения или записи, за исключением.Я не говорю о диске читает и пишет, я говорю об индексе UTXO читает и пишет. |
![]() ![]() |
![]() ![]() ![]() |