kzv
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
July 30, 2019, 01:10:58 PM |
|
Если у вас публичный IP адрес и закрытый порт, тогда никто из сети к вам не может подключиться. Вы будете вне сети до тех пор, пока сами не подключитесь к кому-то. Как только вы к кому-то подключитесь, ваш компьютер сможет отдавать информацию в сеть точно так же как если бы у вас был открытый порт.
То есть, если та нода, к которой я, будучи за NAT-ом, подключился, открыта для сети, то она будет от меня ретранслировать другим архив блоков, даже если сама "pruned", так? Другие p2p сети работают так. 100% не уверен, что также и в Bitcoin Core, но если бы я был в проекте, то сделал бы именно так.
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 01:12:58 PM |
|
Хорошо, спасибо! Надеюсь, если это не так, то кто-нибудь не поленится отметиться здесь ).
|
|
|
|
johhnyUA
Legendary
Offline
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. По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял) importprivkey [key] [label] false
|
|
|
|
kzv
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
July 30, 2019, 01:54:27 PM |
|
P.S: Сейчас немного все изменилось. К примеру, getrawtransaction можно выполнить если у транзакции есть хотя бы один непотраченный выход (иначе invalid input), но для создания сырой транзакции и ее отправки все равно нужно будет из внешних источников тащить txid. По поводу импорта приватного ключа, то вот вроде бы работающий способ (сам не проверял) importprivkey [key] [label] false Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.
|
|
|
|
johhnyUA
Legendary
Offline
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
|
|
July 30, 2019, 02:52:05 PM |
|
Я проверял. importprivkey работает если false указать. Еще есть importaddress - тоже полезная штука и тоже работает. txid тоже не надо ни откуда тащить. Есть команда listunspent, она выплевывает все что надо.
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность. Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 04:34:27 PM |
|
Поэтому ноды с закрытым для входящих соединений 8333 портом в основном закачивают блоки из сети. Я так понял, что вы согласны с предыдущим утверждением kzv. То есть, если у меня, скажем, единственная полная нода (остальные в сети все урезанные), то, несмотря на невидимость её из сети, архивные блоки будут ретранслироваться от меня через одного из восьми пиров, к которым я подключился. Если так, то как-будто и смысла нет мне прилагать усилия для открытия порта - в сети на самом деле более, чем достаточно открытых нод с полной копией блокчейна, я могу и в резерве посидеть ).
|
|
|
|
madnessteat
Legendary
Offline
Activity: 2380
Merit: 2179
|
|
July 30, 2019, 05:01:04 PM |
|
Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты?
|
| Duelbits | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | TRY OUR UNIQUE GAMES! ◥ DICE ◥ MINES ◥ PLINKO ◥ DUEL POKER ◥ DICE DUELS | | | | █▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ KENONEW ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄█ | | 10,000x MULTIPLIER | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ |
[/tabl
|
|
|
A-Bolt
Legendary
Offline
Activity: 2326
Merit: 2365
|
|
July 30, 2019, 05:19:04 PM |
|
Спасибо всем за разъяснения. Хочу попробовать запустить полную ноду ради интереса и ознакомления с процессом. В данный момент работает зеленый риг. Могу ли я на нем запустить полную ноду? Как я понимаю это не должно сказаться на уменьшении хешрейта добываемой монеты?
250 гигов свободного места есть? Тогда можете. При первоначальном скачивании блоков будет грузиться процессор из-за непрерывной проверки постувающих блоков. Насколько это будет влиять на хешрейт, зависит от процессора, количества видеокарт, алгоритма майнинга и. т. д. и т. п.
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 05:30:05 PM |
|
Но если рассматривать такой чисто гипотетический случай, что ваша нода с полным блокнчейном единственная в сети, то тогда да, будете выступать в роли ретранслятора для пустой обрезанной ноды. Да, для простоты понимания меня пока интересует только такой случай. Кажется, мы по разному понимаем слова транслятор/ретранслятор, - по-моему, я со своей полной нодой буду транслятором, а обрезанная ретранслятором моих данных ). А открывать или не открывать каждый сам решает. Если желаете помочь сети, то откройте. Так в чем помощь? Стать десятитысячной легкодоступной полной копией блокчейна? А в случае кризиса, как мы тут выяснили, дотянутся до моей копии и так. Или нет? ))
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 05:51:23 PM |
|
Если я правильно понял ваш сценарий, то он не возможен, ваша история для обрезанных нод не нужна.
Понятно, что обрезанным нодам мои архивы ни к чему. Я думал, что возможно в моем гипотетическом сценарии (если появится новый участник сети, желающий получить полный блокчейн, а этот блокчейн только у меня) обрезанная открытая нода, к которой я подключился, сможет служить ретранслятором моих данных этому новичку. Как-то же у меня работает торрент-трекер, получает файлы и отдает что-то, хотя порт не проброшен. Ну ясно, я ваше мнение понял, спасибо. Теперь я знаю два противоположных мнения ).
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 06:14:14 PM |
|
C тором сложнее. Про работу ноды через тор вопросов нет. У меня так и работает, и нода иногда видна с https://bitnodes.earn.com/.
|
|
|
|
johhnyUA
Legendary
Offline
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
|
|
July 30, 2019, 07:30:28 PM |
|
и выступать в качестве и ретранслятора и транслятора одновременно даже при закрытом для входящих 8333.
Я немного влезу между вами (хе хе) и спрошу насчет порта 8333: что, помимо этого порта ноды не ведут обмен между собой? Я думал нода постоянно пробует разные порты в таком случае, а не имеет конкретно один. Буду благодарен за ответ.
|
|
|
|
uanix-2 (OP)
Member
Offline
Activity: 83
Merit: 48
Bitcoin Review owner
|
|
July 30, 2019, 07:32:09 PM |
|
Вижу оффтопик был активнеым и плодотворным Но вернемся к нашим баранам, то бишь к исходному вопросу топика. Решение в виде block file pruning, которое появилось в версии 0.11.0 клиента Bitcoin Core и которым блокчейн просто усекался до 288 последних блоков (двое суток) — это совсем не то, что предлагал Сатоши Накамото. Автор Биткоина предлагал другую схему, а именно отсекать старые транзакции (не имеющие неиспользованных выходов), а подтверждения их существования в прошлом хранить в виде корня хэшей дерева Меркла дабы хэш блока не изменился. Повторю схему: Это, разумеется, приведет к потере истории транзакций, но при этом текущее состояние владения биткоинами будет всегда актуально. Именно последнее (подтверждение владения биткоинами) имеет важное значение для денежной системы. История движения монет от адреса к адресу до текущего состояния не столь важна. Более того, в целях конфиденциальности и анонимности это даже хорошо! К тому же, каждый пользователь, если хочет, может хранить историю своих транзакций локально на своем компьютере. Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована? Ваши соображения?
|
|
|
|
igor72
Legendary
Offline
Activity: 1974
Merit: 2064
Crypto Swap Exchange
|
|
July 30, 2019, 08:16:22 PM |
|
Так все же, почему идея усечения транзакций, предложенная Сатоши Накамото не была реализована? Ваши соображения?
Посмотрите, может в этой теме найдете что-то полезное.
|
|
|
|
uanix-2 (OP)
Member
Offline
Activity: 83
Merit: 48
Bitcoin Review owner
|
|
July 31, 2019, 07:32:49 AM Last edit: July 31, 2019, 08:06:13 AM by 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
Legendary
Offline
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
|
|
August 01, 2019, 08:30:19 AM |
|
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Кстати, вот что может быть еще в pruned ноде, когда пытаешься подписать транзакцию (signrawtransaction) (наткнулся на это - https://github.com/bitcoin/bitcoin/issues/11546). По сути, как и в оффлайн машине в прунед ноде могут отсутствовать входы конкретной транзакции, и поэтому в ней необходимо будет проводить операцию добавляя scriptPubKey . Так что еще один минус в копилку pruned ноды.
|
|
|
|
kzv
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
August 01, 2019, 08:52:03 AM |
|
Ну я об этом и написал в цитате, которую ты заквотил. По поводу listunspent, раньше как и getrawtransaction оно не работало, но сейчас вполне вероятно что подогнали такую возможность.
Возможно на подключенной к сети pruned ноде с созданием сырой транзакции проблем и не будет. (опять таки, не уверен. Если мы импортируем некий приватный ключ, то не факт что неизрасходованные выходы для него будут отображаться адекватно. Допустим тот адрес последний раз был в блоке, который давным давно был вырезан pruned нодой)
Кстати, вот что может быть еще в pruned ноде, когда пытаешься подписать транзакцию (signrawtransaction) (наткнулся на это - https://github.com/bitcoin/bitcoin/issues/11546). По сути, как и в оффлайн машине в прунед ноде могут отсутствовать входы конкретной транзакции, и поэтому в ней необходимо будет проводить операцию добавляя scriptPubKey . Так что еще один минус в копилку pruned ноды. Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается. Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было. Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия 1. синхронизировать ноду 2. импортировать в ноду приватный ключ или адрес.
|
|
|
|
johhnyUA
Legendary
Offline
Activity: 2436
Merit: 1849
Crypto for the Crypto Throne!
|
|
August 01, 2019, 09:43:54 AM |
|
Там юзер пытается в оффлайн кошельке подписать транзакцию которую сформировал в онлайн. Оффлайновый кошелек не синхронизирован и потому ничего не знает о новых выходах которые юзер пытается подписать. По моему логично юзеру ошибка выплевывается. Если бы юзер сформировал транзакцию в синхронизированной прунед ноде (или в несинхронизированной оффлайн), а потом попытался ее в той же самой ноде подписать - никакой ошибки бы естественно не было. Чтобы прунед нода или оффлайн нода узнала про нужные выходы, нужно выполнить всего два условия 1. синхронизировать ноду 2. импортировать в ноду приватный ключ или адрес.
Одного приватного ключа не хватит. Без приватника так то ты не выполнишь функцию signrawtransaction, ну как, получишь совсем другую ошибку. А вот информация с prevtxs как раз таки поможет. это как я уже говорил ScriptPubKey. Ну на прунед ноде может кстати такого и не будет, хотя вполне возможно, как мне кажется.
|
|
|
|
~DefaultTrust
Copper Member
Sr. Member
Offline
Activity: 1554
Merit: 489
Stop the war!
|
|
May 04, 2020, 09:56:57 AM |
|
Я думаю, что дисковое пространство не является каким-то узким местом биткоина. Современные технологии сделали доступными и дешевыми жесткие диски. Но если уж совсем хочется сэкономить, то используйте онлайн кошельки
|
Do not trust bitcointalk fascists: leonello; Snork1979; ivan1975
|
|
|
|