Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
6 апреля 2017, 4:55:38 PM   # 1
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru

У меня есть построить двигатель хранения в качестве основы нового Bitcoin узла в развитии. Идея заключается в том, чтобы отказаться от индекса UTXO и использовать быстрое параллельное Потратьте дерево вместо этого.

Результаты являются весьма многообещающими. Более подробную информацию можно здесь: https://bitcrust.org

Результаты деятельности: https://bitcrust.org/results

Исходный код в Русте доступен на https://github.com/tomasvdw/bitcrust
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7


Как заработать Биткоины?
Без вложений. Не майнинг.


7 апреля 2017, 12:07:29 AM   # 2
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Получил 1806 Биткоинов
Реальная история.





Сколько памяти и дискового пространства, это нужно?

Поддерживаете ли вы все это в файлах на диске?

Если вы проверить транзакцию (блок), который пытается провести выходные unexisting, вы должны вернуться через все файлы просто чтобы узнать, что она не существует?
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

7 апреля 2017, 1:12:20 AM   # 3
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Текущее использование:

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.

Что касается памяти, это использует файлы, отображенные на память, что означает много виртуальной памяти, но оставить его в ОС, чтобы поменять. При использовании надлежащей локальности ссылок, данные, которые не используются хранятся из памяти.

Проблема потратив ранние выходы решаются Потратьте-индекс, который отстает от кончиков несколько блоков, чтобы поймать их. Это также объясняется под "провести индекс" раздел на сайте.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

7 апреля 2017, 1:27:26 AM   # 4
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Проблема потратив ранние выходы решаются Потратьте-индекс, который отстает от кончиков несколько блоков, чтобы поймать их. Это также объясняется под "провести индекс" раздел на сайте.

ОК. Но как насчет результатов, которые никогда не существовали в первую очередь. Как вы обнаружите, что они не существуют?
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

7 апреля 2017, 5:46:01 AM   # 5
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

ОК. Но как насчет результатов, которые никогда не существовали в первую очередь. Как вы обнаружите, что они не существуют?

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

Аналогичным образом, если расходы индекс "уловы" поиск, два поиска выполняется: наличие сделки и отсутствия выхода.

«Обманщик» тратить выход существующей транзакции с индексом выше, то графа вывода перехватывается проверки сценария.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

7 апреля 2017, 8:50:25 PM   # 6
 
 
Сообщения: 1106
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Делает ли это SegWit устаревшим?
cryptoanarchist сейчас офлайн Пожаловаться на cryptoanarchist   Ответить с цитированием Мультицитирование сообщения от cryptoanarchist Быстрый ответ на сообщение cryptoanarchist

8 апреля 2017, 1:20:53 AM   # 7
 
 
Сообщения: 924
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Делает ли это SegWit устаревшим?

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

Я прочитал весь документ, очевидно, что эти люди имеют некоторые навыки!
misterbigg сейчас офлайн Пожаловаться на misterbigg   Ответить с цитированием Мультицитирование сообщения от misterbigg Быстрый ответ на сообщение misterbigg

8 апреля 2017, 1:33:53 AM   # 8
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

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

Индекс UTXO есть по причине.
Лично я предпочел бы видеть какую-то работу по улучшению индекса и сам UTXO-DB, вместо того, чтобы избавиться от него, я думаю, это не правильный путь.

Глядя на "результаты деятельности" следует помнить, что ядро ​​(и раствор LevelDB) используют ограниченное количество системной памяти, в то время как это решение, похоже, использует все это. Кроме того, когда ядро ​​получает проверить транзакцию, которая пытается провести несуществующий вход, он не будет потреблять столько ресурсов. Это потенциальная проблема DoS.

К сожалению, я не имею в виду, что средний человек - это только мое холодное профессиональное мнение, что он не будет хорошо работать для вас, для фактического узла реального Bitcoin.
Я желаю вам всего наилучшего с вашим проектом, @ tomtomtom7, но я не думаю, что это правильный подход к оптимизации производительности.
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

8 апреля 2017, 6:37:25 PM   # 9
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Спасибо за ваш отзыв.

Индекс UTXO есть по причине.
Лично я предпочел бы видеть какую-то работу по улучшению индекса и сам UTXO-DB, вместо того, чтобы избавиться от него, я думаю, это не правильный путь.

Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin.

Если все транзакции предварительно синхронизировано, то можно выделить валидацию сценария базовой нагрузки (когда ТЕ приходит) и подтверждение заказа при пиковой нагрузке (когда блок приходит), то UTXO-индекс не делает все, что много смысла.

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

И для подтверждения заказа, выходные скрипты не нужны вообще.

Глядя на "результаты деятельности" следует помнить, что ядро ​​(и раствор LevelDB) используют ограниченное количество системной памяти, в то время как это решение, похоже, использует все это.

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

В любом случае, MRU страницы сохраняются в памяти.

Кроме того, когда ядро ​​получает проверить транзакцию, которая пытается провести несуществующий вход, он не будет потреблять столько ресурсов. Это потенциальная проблема DoS.

Она никогда не нужно проверять всю цепочку, как после нескольких блоков проводят индекс улавливает искать и выполняет прямой поиск. Там еще могут быть потенциальные проблемы DoS, но не тратить несуществующее выход.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

9 апреля 2017, 12:37:27 AM   # 10
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

О, хорошо. К сожалению, я не получил идею израсходует-индекс в первом.

Можете ли вы сказать что-то о том, как он на самом деле работает внутри?

котировка
Это очень компактный битовый индекс с одним битом для каждой транзакции и один для каждого выхода
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

9 апреля 2017, 2:40:26 AM   # 11
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin.

Если все транзакции будут предварительно синхронизированы,

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

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

gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

9 апреля 2017, 6:24:01 AM   # 12
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Я вижу UTXO подход на самом деле в виде осталось от архитектуры до компактных блоков / XThin.

Если все транзакции будут предварительно синхронизированы,

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

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



Я понимаю, ядро ​​предварительно проверяет подпись с нашими без компактных блоков / XThin. Я также понимаю, что скамейки не сравниваю, но сравнивать только полный блок проверки, который я объясняю на этой же странице.

Но без компактных блоков / XThin, оптимизируя для сравнения порядка является гораздо менее актуальным из-за высокой стоимости полосы пропускания.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

9 апреля 2017, 6:53:40 AM   # 13
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

О, хорошо. К сожалению, я не получил идею израсходует-индекс в первом.

Можете ли вы сказать что-то о том, как он на самом деле работает внутри?


Я по существу преобразование операций и выходов к "гашиш" с:

Код:
хэш (ТХ) = tx.filepos / 16
хэш (выход) = tx.filepos / 16 + 1 + выход-индекс
(Охраняемая исключительных перетоков на (теперь пустой) карты исключений для вывода, если отсчет +1> TX-размер / 16)

И использовать "гашиш" в качестве прямого индекса битового индекса.

Израсходует индекс представляет отработанное состояние несколько блоков от наконечника; набор бит в месте означает, что транзакции, существует или выход тратится там. Когда израсходует дерево ищется и достигает позицию Потратьте-индекс, положительный поиск для сделки и отрицательный поиск для вывода достаточно.

Провел индекс растет с 1 бит на каждые каждые 16 байтов, или 1/128-е место размера blockchain. Так же, как с Потратьте дерева, в основном конец доступа к ним, поэтому запуск может быть сохранен на диске.

Код самого Потратьте индекс довольно просто: https://github.com/tomasvdw/bitcrust/blob/master/src/store/spend_index.rs
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

9 апреля 2017, 11:31:25 AM   # 14
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Я по существу преобразование операций и выходов к "гашиш" с:

Код:
хэш (ТХ) = tx.filepos / 16
хэш (выход) = tx.filepos / 16 + 1 + выход-индекс
(Охраняемая исключительных перетоков на (теперь пустой) карты исключений для вывода, если отсчет +1> TX-размер / 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 в хэш?
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

9 апреля 2017, 3:33:28 PM   # 15
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Я думаю, что я понимаю.

Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс",

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

И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки.

Это верно?
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

10 апреля 2017, 5:59:43 PM   # 16
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс",

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

И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки.

Это верно?

Я предполагаю, что означает «да».

В этом случае я могу дать более точную обратную связь.

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


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

Она не имеет ничего общего с какой-либо "быстрое одновременное израсходует дерево",
В нем есть все, чтобы сделать с самого индексом (U) Ого.
Вы используете HashMap в качестве индекса, который намного быстрее, чем индекс, используемый LevelDB двигателя сердечника.
Но он также занимает гораздо больше системной памяти.

Я знаю, потому что я также использовать индекс UTXO на основе HashMap в моем gocoin s / ш.
Таким образом, вы не должны сказать мне, что это намного быстрее.
Но это происходит за счет памяти - вы не можете запустить, например, с 2 Гб оперативной памяти.
Из моего личного опыта, я бы сказал, что вам нужно, по крайней мере 8 ГБ.
И потому, что вы индексировать и; проведенные и неизрасходованные операции, вам нужно еще больше памяти, чем решение UTXO-индекс, который вы пытаетесь бить.

Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс.
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

10 апреля 2017, 6:16:18 PM   # 17
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

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

Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс.

Позвольте мне добавить некоторые цифры здесь.

На данный момент (блок 461402) типичный показатель UTXO имеет 20438271 записи (транзакция) - что это 20 миллионов.
В то же время индекс Тх, используемый вашим решением необходимо более 210 миллионов записей.
https://blockchain.info/charts/n-transactions-total
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

11 апреля 2017, 7:51:53 AM   # 18
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Таким образом, вы в основном извлечь все транзакции из блоков и хранить их в отдельных файлах (transactions1 + transactions2), давая каждой транзакции уникальный sequencional "числовой индекс",

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

И тогда у вас есть Потратьте-индекс (адресованный "числовой индекс"), Который в основном говорит вам ли было потрачено конкретный выход конкретной сделки.

Это верно?

Да. Хотя вы выходите из с тратой дерева.


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

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

Она не имеет ничего общего с какой-либо "быстрое одновременное израсходует дерево",
В нем есть все, чтобы сделать с самого индексом (U) Ого.
Вы используете HashMap в качестве индекса, который намного быстрее, чем индекс, используемый LevelDB двигателя сердечника.
Но он также занимает гораздо больше системной памяти.

Я знаю, потому что я также использовать индекс UTXO на основе HashMap в моем gocoin s / ш.
Таким образом, вы не должны сказать мне, что это намного быстрее.
Но это происходит за счет памяти - вы не можете запустить, например, с 2 Гб оперативной памяти.
Из моего личного опыта, я бы сказал, что вам нужно, по крайней мере 8 ГБ.
И потому, что вы индексировать и; проведенные и неизрасходованные операции, вам нужно еще больше памяти, чем решение UTXO-индекс, который вы пытаетесь бить.

Суть не: никоим образом это может работать лучше, чем на основе простого HashMap UTXO-индекс.

Важная часть заключается в разделении проверки базовой транзакции нагрузки (когда транзакция приходит в) с проверкой порядка нагрузки (пик, когда блок приходит в).

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

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

Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены.

По сути Bitcrust просто гарантирует, что работа и ресурсы, необходимые, когда блок приходит к минимуму.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7

11 апреля 2017, 8:29:57 AM   # 19
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены.
Это не то, как работает Bitcoin ядро. Нет доступа к диску обычно вообще не происходит, когда блок проверяется для транзакций, которые еще не видели, чтения или записи, за исключением.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

11 апреля 2017, 9:09:35 AM   # 20
 
 
Сообщений: 38
Цитировать по имени
цитировать ответ
по умолчанию Re: проверка быстрого параллельного блока без UTXO-индекса

Это, в отличие от базовой модели, которая нуждается в операции последовательного чтения и записи в индексе UTXO, даже если все сценарии уже проверены.
Это не то, как работает Bitcoin ядро. Нет доступа к диску обычно вообще не происходит, когда блок проверяется для транзакций, которые еще не видели, чтения или записи, за исключением.

Я не говорю о диске читает и пишет, я говорю об индексе UTXO читает и пишет.
tomtomtom7 сейчас офлайн Пожаловаться на tomtomtom7   Ответить с цитированием Мультицитирование сообщения от tomtomtom7 Быстрый ответ на сообщение tomtomtom7



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW