Pages:
Author

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

copper member
Activity: 1554
Merit: 489
Stop the war!
Я думаю, что дисковое пространство не является каким-то узким местом биткоина. Современные технологии сделали доступными и дешевыми жесткие диски. Но если уж совсем хочется сэкономить, то используйте онлайн кошельки
legendary
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается.
Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было.
Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия
1. синхронизировать ноду
2. импортировать в ноду приватный ключ или адрес.

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

Ну на прунед ноде может кстати такого и не будет, хотя вполне возможно, как мне кажется.
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.

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

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

Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается.
Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было.
Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия
1. синхронизировать ноду
2. импортировать в ноду приватный ключ или адрес.
legendary
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.

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

Кстати, вот что может быть еще в pruned ноде, когда пытаешься подписать транзакцию (signrawtransaction) (наткнулся на это - https://github.com/bitcoin/bitcoin/issues/11546). По сути, как и в оффлайн машине в прунед ноде могут отсутствовать входы конкретной транзакции, и поэтому в ней необходимо будет проводить операцию добавляя scriptPubKey .
Так что еще один минус в копилку pruned ноды.
member
Activity: 83
Merit: 48
Bitcoin Review owner
[.....]
 почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?

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

Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?
Посмотрите, может в этой теме найдете что-то полезное.
Спасибо! Интересно...
Там по ссылке (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
Причина, по которой это не реализовано, заключается в воздействии на сеть в целом. Если большое количество узлов начнет отсекать старые данные блока, новым узлам будет сложнее найти исторические данные для проверки.
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange

Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована?
Ваши соображения?
Посмотрите, может в этой теме найдете что-то полезное.
member
Activity: 83
Merit: 48
Bitcoin Review owner
Вижу оффтопик был активнеым и плодотворным  Cheesy
Но вернемся к нашим баранам, то бишь к исходному вопросу топика.

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

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



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

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

legendary
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
и выступать в качестве и  ретранслятора и транслятора  одновременно даже при закрытом для входящих 8333.

Я немного влезу между вами (хе хе) и спрошу насчет порта 8333: что, помимо этого порта ноды не ведут обмен между собой? Я думал нода постоянно пробует разные порты в таком случае, а не имеет конкретно один. Буду благодарен за ответ.
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange
C тором сложнее.
Про работу ноды через тор вопросов нет. У меня так и работает, и нода иногда Smiley видна с https://bitnodes.earn.com/.
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange
Если я правильно понял ваш сценарий, то он не возможен, ваша история для обрезанных нод не нужна.
Понятно, что обрезанным нодам мои архивы ни к чему. Я думал, что возможно в моем гипотетическом сценарии (если появится новый участник сети, желающий получить полный блокчейн, а этот блокчейн только у меня) обрезанная открытая нода, к которой я подключился, сможет служить ретранслятором моих данных этому новичку. Как-то же у меня работает торрент-трекер, получает файлы и отдает что-то, хотя порт не проброшен.

Ну ясно, я ваше мнение понял, спасибо. Теперь я знаю два противоположных мнения ).
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange
Но если рассматривать такой чисто гипотетический случай, что ваша нода с полным блокнчейном единственная в сети,  то тогда да,  будете выступать в роли ретранслятора для пустой обрезанной ноды.
Да, для простоты понимания меня пока интересует только такой случай. Кажется, мы по разному понимаем слова транслятор/ретранслятор, - по-моему, я со своей полной нодой буду транслятором, а обрезанная ретранслятором моих данных ).

Quote
А открывать или не открывать каждый сам решает. Если желаете помочь сети, то откройте.
Так в чем помощь? Стать десятитысячной легкодоступной полной копией блокчейна? А в случае кризиса, как мы тут выяснили, дотянутся до моей копии и так. Или нет? ))
legendary
Activity: 2317
Merit: 2318
Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты? 

250 гигов свободного места есть? Тогда можете. При первоначальном скачивании блоков будет грузиться процессор из-за непрерывной проверки постувающих блоков. Насколько это будет влиять на хешрейт, зависит от процессора, количества видеокарт, алгоритма майнинга и. т. д. и т. п.
legendary
Activity: 2310
Merit: 2073
Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты? 
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange
Поэтому ноды с закрытым для входящих соединений 8333 портом в основном закачивают блоки из сети.
Я так понял, что вы согласны с предыдущим утверждением kzv.
То есть, если у меня, скажем, единственная полная нода (остальные в сети все урезанные), то, несмотря на невидимость её из сети, архивные блоки будут ретранслироваться от меня через одного из восьми пиров, к которым я подключился. Если так, то как-будто и смысла нет мне прилагать усилия для открытия порта - в сети на самом деле более, чем достаточно открытых нод с полной копией блокчейна, я могу и в резерве посидеть ).
legendary
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.

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

Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange


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

По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял)
Code:
importprivkey [key] [label] false

Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.
legendary
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
Будет ли узел полноценно работать в системе после усечения цепочки блоков?

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

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

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

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

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

По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял)
Code:
importprivkey [key] [label] false
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange
Хорошо, спасибо! Надеюсь, если это не так, то кто-нибудь не поленится отметиться здесь ).
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange

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

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

Другие p2p сети работают так.
100% не уверен, что также и в Bitcoin Core, но если бы я был в проекте, то сделал бы именно так.
legendary
Activity: 1848
Merit: 2033
Crypto Swap Exchange

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

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