Экономия дискового пространства в Bitcoin

[kzv]

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

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

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

[1714856818]

1714856818

[1714856818]

1714856818

[igor72]

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

[johhnyUA]

Будет ли узел полноценно работать в системе после усечения цепочки блоков?

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

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

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

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

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

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

Code:

importprivkey [key] [label] false

[kzv]

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

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

Code:

importprivkey [key] [label] false

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

[johhnyUA]

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

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

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

[igor72]

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

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

[madnessteat]

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

[A-Bolt]

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

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

[igor72]

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

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

А открывать или не открывать каждый сам решает. Если желаете помочь сети, то откройте.

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

[igor72]

Если я правильно понял ваш сценарий, то он не возможен, ваша история для обрезанных нод не нужна.

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

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

[igor72]

C тором сложнее.

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

[johhnyUA]

и выступать в качестве и  ретранслятора и транслятора  одновременно даже при закрытом для входящих 8333.

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

[uanix-2]

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

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

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



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

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

[igor72]

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

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

[uanix-2]

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

Решение  Сатоши не без проблем.
 

Спасибо!
Первый аргумент (потеряем историю происхожения монет) выглядит неубедительным. А вот это, пожалуй, и есть настоящая причина:

Because of this design, in order to verify the UTXO-required data, you also need to download the entire transaction, including its public keys and signatures which constitute about 1/3 to 2/3 of a transaction.

This makes Nakamoto’s whitepaper-style pruning in Bitcoin right now pretty much impossible. Happily, some smart people have been working on improving the situation.

Т.е. попросту говоря, имеются технические проблемы. Скорее всего, это связано с самим процессом перехода на новый алгоритм с отсечениями транзакций. Ну и решили, что SegWit — лучшее решение проблемы.

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

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

Спасибо! Интересно...
Там по ссылке (https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment) нашел интересный фрагмент:

The reason it's not implemented is because of the effect on the network as a whole. If a large amount of nodes starts pruning old block data away, it will become harder for new nodes starting up to find the historic data to verify.

Буквально:

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

[johhnyUA]

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

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

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

[kzv]

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

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

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

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

[johhnyUA]

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

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

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

[~DefaultTrust]

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