Topic: Экономия дискового пространства в Bitcoin (Read 658 times)
Я думаю, что дисковое пространство не является каким-то узким местом биткоина. Современные технологии сделали доступными и дешевыми жесткие диски. Но если уж совсем хочется сэкономить, то используйте онлайн кошельки
Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается.
Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было.
Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия
1. синхронизировать ноду
2. импортировать в ноду приватный ключ или адрес.
Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было.
Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия
1. синхронизировать ноду
2. импортировать в ноду приватный ключ или адрес.
Одного приватного ключа не хватит. Без приватника так то ты не выполнишь функцию signrawtransaction, ну как, получишь совсем другую ошибку. А вот информация с prevtxs как раз таки поможет. это как я уже говорил ScriptPubKey.
Ну на прунед ноде может кстати такого и не будет, хотя вполне возможно, как мне кажется.
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Кстати, вот что может быть еще в pruned ноде, когда пытаешься подписать транзакцию (signrawtransaction) (наткнулся на это - https://github.com/bitcoin/bitcoin/issues/11546). По сути, как и в оффлайн машине в прунед ноде могут отсутствовать входы конкретной транзакции, и поэтому в ней необходимо будет проводить операцию добавляя scriptPubKey .
Так что еще один минус в копилку pruned ноды.
Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается.
Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было.
Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия
1. синхронизировать ноду
2. импортировать в ноду приватный ключ или адрес.
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Кстати, вот что может быть еще в 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) нашел интересный фрагмент:
Quote
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.
Буквально:Quote
Причина, по которой это не реализовано, заключается в воздействии на сеть в целом. Если большое количество узлов начнет отсекать старые данные блока, новым узлам будет сложнее найти исторические данные для проверки.
Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?
Вижу оффтопик был активнеым и плодотворным 
Но вернемся к нашим баранам, то бишь к исходному вопросу топика.
Решение в виде block file pruning, которое появилось в версии 0.11.0 клиента Bitcoin Core и которым блокчейн просто усекался до 288 последних блоков (двое суток) — это совсем не то, что предлагал Сатоши Накамото.
Автор Биткоина предлагал другую схему, а именно отсекать старые транзакции (не имеющие неиспользованных выходов), а подтверждения их существования в прошлом хранить в виде корня хэшей дерева Меркла дабы хэш блока не изменился. Повторю схему:
Это, разумеется, приведет к потере истории транзакций, но при этом текущее состояние владения биткоинами будет всегда актуально. Именно последнее (подтверждение владения биткоинами) имеет важное значение для денежной системы. История движения монет от адреса к адресу до текущего состояния не столь важна. Более того, в целях конфиденциальности и анонимности это даже хорошо! К тому же, каждый пользователь, если хочет, может хранить историю своих транзакций локально на своем компьютере.
Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?
Но вернемся к нашим баранам, то бишь к исходному вопросу топика.
Решение в виде block file pruning, которое появилось в версии 0.11.0 клиента Bitcoin Core и которым блокчейн просто усекался до 288 последних блоков (двое суток) — это совсем не то, что предлагал Сатоши Накамото.
Автор Биткоина предлагал другую схему, а именно отсекать старые транзакции (не имеющие неиспользованных выходов), а подтверждения их существования в прошлом хранить в виде корня хэшей дерева Меркла дабы хэш блока не изменился. Повторю схему:
Это, разумеется, приведет к потере истории транзакций, но при этом текущее состояние владения биткоинами будет всегда актуально. Именно последнее (подтверждение владения биткоинами) имеет важное значение для денежной системы. История движения монет от адреса к адресу до текущего состояния не столь важна. Более того, в целях конфиденциальности и анонимности это даже хорошо! К тому же, каждый пользователь, если хочет, может хранить историю своих транзакций локально на своем компьютере.
Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?
и выступать в качестве и ретранслятора и транслятора одновременно даже при закрытом для входящих 8333.
Я немного влезу между вами (хе хе) и спрошу насчет порта 8333: что, помимо этого порта ноды не ведут обмен между собой? Я думал нода постоянно пробует разные порты в таком случае, а не имеет конкретно один. Буду благодарен за ответ.
C тором сложнее.
Про работу ноды через тор вопросов нет. У меня так и работает, и нода иногда 
видна с https://bitnodes.earn.com/. Если я правильно понял ваш сценарий, то он не возможен, ваша история для обрезанных нод не нужна.
Понятно, что обрезанным нодам мои архивы ни к чему. Я думал, что возможно в моем гипотетическом сценарии (если появится новый участник сети, желающий получить полный блокчейн, а этот блокчейн только у меня) обрезанная открытая нода, к которой я подключился, сможет служить ретранслятором моих данных этому новичку. Как-то же у меня работает торрент-трекер, получает файлы и отдает что-то, хотя порт не проброшен.Ну ясно, я ваше мнение понял, спасибо. Теперь я знаю два противоположных мнения ).
Но если рассматривать такой чисто гипотетический случай, что ваша нода с полным блокнчейном единственная в сети, то тогда да, будете выступать в роли ретранслятора для пустой обрезанной ноды.
Да, для простоты понимания меня пока интересует только такой случай. Кажется, мы по разному понимаем слова транслятор/ретранслятор, - по-моему, я со своей полной нодой буду транслятором, а обрезанная ретранслятором моих данных ).Quote
А открывать или не открывать каждый сам решает. Если желаете помочь сети, то откройте.
Так в чем помощь? Стать десятитысячной легкодоступной полной копией блокчейна? А в случае кризиса, как мы тут выяснили, дотянутся до моей копии и так. Или нет? )) Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты?
250 гигов свободного места есть? Тогда можете. При первоначальном скачивании блоков будет грузиться процессор из-за непрерывной проверки постувающих блоков. Насколько это будет влиять на хешрейт, зависит от процессора, количества видеокарт, алгоритма майнинга и. т. д. и т. п.
Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты?
Поэтому ноды с закрытым для входящих соединений 8333 портом в основном закачивают блоки из сети.
Я так понял, что вы согласны с предыдущим утверждением kzv.То есть, если у меня, скажем, единственная полная нода (остальные в сети все урезанные), то, несмотря на невидимость её из сети, архивные блоки будут ретранслироваться от меня через одного из восьми пиров, к которым я подключился. Если так, то как-будто и смысла нет мне прилагать усилия для открытия порта - в сети на самом деле более, чем достаточно открытых нод с полной копией блокчейна, я могу и в резерве посидеть ).
Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
P.S: Сейчас немного все изменилось. К примеру, getrawtransaction можно выполнить если у транзакции есть хотя бы один непотраченный выход (иначе invalid input), но для создания сырой транзакции и ее отправки все равно нужно будет из внешних источников тащить txid.
По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял)
Code:
importprivkey [key] [label] false
Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.
Будет ли узел полноценно работать в системе после усечения цепочки блоков?
Не совсем. И полного функционала у него тоже не будет.
К примеру, нода будет продолжать "верифицировать блокчейн", но подключений к ней не будет (здесь могу ошибаться, так как нода в теории может передавать блоки из диапазона not pruned, но более ранние блоки она передавать не может очевидно что. Возможно в других нодах заложен функционал не обращаться к таким нодам. Типа зачем, если можно найти "нормальную".)
Во вторых, упадет твой функционал.
Ты не сможешь выполнять команды txid, rescan. А следовательно, не сможешь выполнять getrawtransaction (для которого нужен доступ ко всем txid) или importprivatekey (для которого нужен рескан блокчейна).
И как следствие, намного осложнится например возможность создавать транзакции с оффлайн хранилища, если ты используешь Core ноду для этих целей. (так как нет getrawtransaction и невозможно с ноды получить txid, следовательно нет возможности выполнить scriptPubKey, который необходим для подписи функцией signrawtransaction).
P.S: Сейчас немного все изменилось. К примеру, getrawtransaction можно выполнить если у транзакции есть хотя бы один непотраченный выход (иначе invalid input), но для создания сырой транзакции и ее отправки все равно нужно будет из внешних источников тащить txid.
По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял)
Code:
importprivkey [key] [label] false
Хорошо, спасибо! Надеюсь, если это не так, то кто-нибудь не поленится отметиться здесь ).
Если у вас публичный IP адрес и закрытый порт, тогда никто из сети к вам не может подключиться. Вы будете вне сети до тех пор, пока сами не подключитесь к кому-то. Как только вы к кому-то подключитесь, ваш компьютер сможет отдавать информацию в сеть точно так же как если бы у вас был открытый порт.
Другие p2p сети работают так.
100% не уверен, что также и в Bitcoin Core, но если бы я был в проекте, то сделал бы именно так.
Если у вас публичный IP адрес и закрытый порт, тогда никто из сети к вам не может подключиться. Вы будете вне сети до тех пор, пока сами не подключитесь к кому-то. Как только вы к кому-то подключитесь, ваш компьютер сможет отдавать информацию в сеть точно так же как если бы у вас был открытый порт.
Jump to: