Topic: Экономия дискового пространства в Bitcoin (Read 661 times)

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

Одного приватного ключа не хватит. Без приватника так то ты не выполнишь функцию signrawtransaction, ну как, получишь совсем другую ошибку. А вот информация с prevtxs как раз таки поможет. это как я уже говорил ScriptPubKey.

Ну на прунед ноде может кстати такого и не будет, хотя вполне возможно, как мне кажется.

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

Кстати, вот что может быть еще в pruned ноде, когда пытаешься подписать транзакцию (signrawtransaction) (наткнулся на это - https://github.com/bitcoin/bitcoin/issues/11546). По сути, как и в оффлайн машине в прунед ноде могут отсутствовать входы конкретной транзакции, и поэтому в ней необходимо будет проводить операцию добавляя scriptPubKey .
Так что еще один минус в копилку pruned ноды.

Спасибо!
Первый аргумент (потеряем историю происхожения монет) выглядит неубедительным. А вот это, пожалуй, и есть настоящая причина:
Спасибо! Интересно...
Там по ссылке (https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment) нашел интересный фрагмент:
Буквально:

Посмотрите, может в этой теме найдете что-то полезное.

Вижу оффтопик был активнеым и плодотворным 
Но вернемся к нашим баранам, то бишь к исходному вопросу топика.

Решение в виде block file pruning, которое появилось в версии 0.11.0 клиента Bitcoin Core и которым блокчейн просто усекался до 288 последних блоков (двое суток) — это совсем не то, что предлагал Сатоши Накамото.

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



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

Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?

Я немного влезу между вами (хе хе) и спрошу насчет порта 8333: что, помимо этого порта ноды не ведут обмен между собой? Я думал нода постоянно пробует разные порты в таком случае, а не имеет конкретно один. Буду благодарен за ответ.

Про работу ноды через тор вопросов нет. У меня так и работает, и нода иногда видна с https://bitnodes.earn.com/.

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

Ну ясно, я ваше мнение понял, спасибо. Теперь я знаю два противоположных мнения ).

Да, для простоты понимания меня пока интересует только такой случай. Кажется, мы по разному понимаем слова транслятор/ретранслятор, - по-моему, я со своей полной нодой буду транслятором, а обрезанная ретранслятором моих данных ).

Так в чем помощь? Стать десятитысячной легкодоступной полной копией блокчейна? А в случае кризиса, как мы тут выяснили, дотянутся до моей копии и так. Или нет? ))

250 гигов свободного места есть? Тогда можете. При первоначальном скачивании блоков будет грузиться процессор из-за непрерывной проверки постувающих блоков. Насколько это будет влиять на хешрейт, зависит от процессора, количества видеокарт, алгоритма майнинга и. т. д. и т. п.

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

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

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

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

Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.

Не совсем. И полного функционала у него тоже не будет.

К примеру, нода будет продолжать "верифицировать блокчейн", но подключений к ней не будет (здесь могу ошибаться, так как нода в теории может передавать блоки из диапазона not pruned, но более ранние блоки она передавать не может очевидно что. Возможно в других нодах заложен функционал не обращаться к таким нодам. Типа зачем, если можно найти "нормальную".)

Во вторых, упадет твой функционал.
Ты не сможешь выполнять команды txid, rescan. А следовательно, не сможешь выполнять getrawtransaction (для которого нужен доступ ко всем txid) или importprivatekey (для которого нужен рескан блокчейна).

И как следствие, намного осложнится например возможность создавать транзакции с оффлайн хранилища, если ты используешь Core ноду для этих целей. (так как нет getrawtransaction и невозможно с ноды получить txid, следовательно нет возможности выполнить scriptPubKey, который необходим для подписи функцией signrawtransaction).

P.S: Сейчас немного все изменилось. К примеру, getrawtransaction можно выполнить если у транзакции есть хотя бы один непотраченный выход (иначе invalid input), но для создания сырой транзакции и ее отправки все равно нужно будет из внешних источников тащить txid.

По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял)

Хорошо, спасибо! Надеюсь, если это не так, то кто-нибудь не поленится отметиться здесь ).

Другие p2p сети работают так.
100% не уверен, что также и в Bitcoin Core, но если бы я был в проекте, то сделал бы именно так.

То есть, если та нода, к которой я, будучи за NAT-ом, подключился, открыта для сети, то она будет от меня ретранслировать другим архив блоков, даже если сама "pruned", так?

Если вы за NAT-ом, то открытие/закрытие порта никак не влияет на сеть в целом.

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

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

kzv, ну а зачем тогда открывать порт?
Смотрите. У меня на старом нетбуке крутится полная нода (для поддержки сети, так сказать, ну и электрум у меня к ней подключен). В связи с тем, что интернет у меня за провайдерским NAT-ом, я настроил ноду через тор. Так вот, исходящий трафик сейчас на порядки больше, чем без тора. Что это за трафик? Что-то отдается, что при закрытом порте не может. Но меня интересует другое (повторяться не буду).

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

Спасибо за разъяснение. Буду изучать работу клиента Bitcoin Core...

Я имел ввиду хранить ТОЛЬКО последние блоки.

Ну, это как говорится, «совсем другая история».

Я хотел узнать, передает ли нода с закрытым 8333 портом информацию о блоках в сеть? Есть ли разница (для сети) в таком случае, полная эта нода или нет?

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

Это стандартная процедура работы поиска в одноранговой п2п сети. Полностью ли следует этой процедуре клиент биткоина - я не знаю.

Ок, я так и думал. А раз зашла речь о помощи сети, такой вопрос. Есть ли разница для сети между нодой с полным блокчейном и кастрированной, если они показывают только 8 соединений (8/0) с сетью? Я думаю, эта ситуация сплошь и рядом, вряд ли многие имеют статический (или полноценный динамический) IP или возятся с настройкой через тор.

Смысл в поддержке сети Биткоина. Чем больше вы у себя храните блоков, тем более децентрализована сеть в целом.
Лично для конкретного пользователя смысла нет. Тут вопрос уходит в философскую область: "а есть ли смысл помогать общему делу, если это лично на мне почти никак не отразится"?

А есть ли смысл в установке параметра -prune больше минимального 550 Mb (что тоже избыточно, имхо)? То, что нода сможет поделиться инфой о большем кол-ве блоков, это понятно. Еще есть плюсы?

Протокол - это язык на котором ноды общаются между собой. То как нода внутри себя хранит данные - это её личное дело.


Вот жеж заебали с этим максимальным размером блока.

kzv имел в виду максимальный размер сериализованного блока, который не может превышать 4МБ. А вы всё цепляетесь за константу в коде MAX_BLOCK_SIZE = 1000000, которую из исходников Биткойна уже давно выпилили.

Походите по блокчейну да посмотрите: сколько реальные блоки места занимают.

За рамками какого протокола?
В статье Сатоши Накомото протокол не описан, там только базовые принципы.
В первых версиях клиента тоже кроме запакованного в рар архив экзешника ничего не было. База блоков изначально хранилась в формате berkeley db, потом ее перевели в формат LevelDB.
Протокол обмена информацией между p2p нодами описан в вики. В этом протоколе вообще никаких баз данных нет.

Так что непонятно, что вы подразумеваете под "протоколом", но так или иначе, а у клиента Bitcoin Core есть две базы данных. Противоречит этот факт чему-то или нет это уже вопрос к разработчикам клиента.



Во-первых, после принятия сегвит, максимальный размер блока стал ограничен 3 Мб, но если вы в этом путаетесь - не расстраивайтесь вы не одиноки ) Сами разработчики клиента чтобы не путаться, кроме размера блока ввели в обиход новую сущность которая называется "вес блока". Сути это не меняет, потому что по факту вес это и есть размер который считается по новым правилам.
Во-вторых, смысл хранить последние блоки есть. Смысл в том, что если появится длинная орфан-цепочка, а у вас нет последних блоков, то для актуализации UTXO вам придется опять синхронизироваться с нуля.

Кстати, задолго до появления прунинга в Bitcoin Core, была реализована схема SPV в так называемых "легких кошельках". В этой схеме клиент хранит только заголовки блоков и только свои собственные транзакции.

Ну, мне, как автору топика, интересны как раз технические моменты.


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

Во-первых, максимальный размер блока пока 1 Mb. Если, конечно, речь не идет о Bitcoin Cash. Но это отдельная история и меня этот форк не интересует.
Во-вторых, смысла хранить только последние блоки нет никакого. Поскольку в новом блоке может появиться транзакция с UTXO из более старых блоков.

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

Это технические моменты. Совершенно не интересные.
Технически есть как минимум две базы данных: в одной хранятся блоки, в другой хранятся непотраченные выходы. В принципе, если есть проверенная база UTXO, то база блоков наверное и не нужна вовсе. Ну или на всякий пожарный, на мой взгляд, вполне достаточно хранить только шесть последних блоков на случай длинного орфана которого в истории пока не случалось.
Однако для каких-то внутренних технических причин, минимальный размер базы блоков ограничен константой в 500 Мб, то есть с учетом что максимальный размер блока 3 Мб, то в обрезанном блокчейне должно быть не менее 166 блоков, что примерно равно среднему количеству блоков которые находятся за сутки.

Стирать целые блоки или удалять информацию о транзакциях с потраченными выходами в блоках?
Ведь Сатоши Накамото предлагает делать именно это — отсекать «старые транзакции», т.е. транзакции у которых нет UTXO (непотраченных выходов).

Смотря что вкладывать в понятие "полноценно". Валидацию блоков делать будет, раздавать архив новым нодам - нет.

В режиме "prune", узел качает последовательно блок за блоком всю цепочку до тех пор, пока блокчейн не начнет занимать на диске места больше, чем прописано в параметре "prune=xxx". Как только блокчейн станет занимать больше места, узел начнет стирать те блоки, информация из которых уже проверена. Это если коротко...

Может кто-то пояснить. Какой в этом смысл, если узел сначала должен будет скачать всю цепочку блоков и проверить ее полностью на соблюдение правил системы биткоина, только после этого будет удалена ненужная информация? (ведь если скачать всю цепочку блоков, то места под нее явно хватает) Будет ли узел полноценно работать в системе после усечения цепочки блоков?

Разобрался сам...

Такая возможность (block file pruning, режим prune — обрезать, усекать) появилась только в июле 2015 года в биткоин-клиенте Bitcoin Core версии 0.11.0. И то, это сделано опционально , на усмотрение пользователя ,— он сам решал, включать эту функцию или нет. Операцию усечения блокчейна называют прунинг (от анг. pruning — обрезка, усечение).

В разделе 7 Reclaiming Disk Space своего знаменитого доклада Bitcoin: A Peer-to-Peer Electronic Cash System Сатоши Накамото излагает идею уменьшения дискового пространства для хранения блокчейна:
В переводе:

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

А теперь вопрос: Почему этот механизм так и не был принят?
Это связано с какими-то технологическими проблемами или просто пока нет необходимости?