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

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

Теперь по поводу этих ваших долбоёбов. Долбоёбы, которые до запуска SegWit кричали, что блоки больше 1МБ убьют децентрализацию сети, засунули свои языки в жопу и молчат по поводу двухмегабайтных блоков, которые появились в сети Bitcoin после запуска SegWit, что говорит о том, что по факту никто не против состоявшегося увеличения размера блока, кроме совсем уж упоротых, но их предложения никто всерьёз не воспринимает.

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

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

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

А как ещё оценивать качество работы рендеринга, если не на глаз? В Golem и iExec это как-то по другому реализовано?

Владелец Сатанинской Бутылки может её продать только по цене меньшей, чем цена покупки.
Владелец битков не связан таким ограничением.
Это имеет значение.

В последнем квартале 2018 года ушло значительное количество майнеров.
И чо? Сложность упала, для оставшихся профит увеличился. Саморегуляция, однако.

Какой такой текстовый файл? Хеш в консоль выдаётся.

Формат wallet.dat от этого не зависит.

Какой скрипт? Этот? Этот ругается на неизвестную версию, но хеш выдаёт.


Где взять seed-фразу, если Bitcoin Core её не поддерживает?

Размер блока можно увеличивать, вопрос только насколько. Очевидно, что существует некий размер блока, который не позволит держать полную ноду на двухядерном Пентиуме с HDD (не SSD). Разумеется, при условии заполнения блоков транзакциями под завязку.

Характерный пример - Эфир. До 2018 года у меня на HDD со скрипом синхронизировалась полная нода geth. В 2018 году моя нода перестала успевать верифицировать и сохранять на диск поступающие блоки, блоки поступают быстрее, чем происходит их верификация и запись на диск (процессор у меня четырёхядерный, узкое место - именно диск). Это крайний случай, такого в Биткойне допускать нельзя.

Биткойн, на текущий момент, синхронизируется на HDD легко, и это - правильно.

Сейчас блоки, забитые под завязку транзакциями с SegWit-входами, занимают больше 2МБ. Возможно, 2 МБ - это мало, но, очевидно, что ваши 30-мегабайтные блоки, при полном заполнении дающие 1.5ТБ в год - это многовато. И дело не в том, что терабайтные базы сложно хранить. Дело в том, что с терабайтными базами сложно работать. Накладные расходы на операции поиска по базе зависят от её объёма.

Попробуйте добавить в кошелёк приватный ключ. Сколько времени займёт процесс сканирования базы блоков для определения баланса по этому ключу? Долго? А с терабайтными базами, вообще, можно будет вешаться.

Может манипулировать только своими средствами:
1. Отправить на биржу транзакцию со своими BTC
2. Обменять на бирже BTC на бакс
3. Вывести бакс
4. Отменить транзакцию из п.1
В результате у ДЗ останутся и битки, и полученные с биржи баксы.

Имеем такие константы:
MAX_BLOCK_WEIGHT = 4000000
WITNESS_SCALE_FACTOR = 4

Вот это мне понятно:
::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) * WITNESS_SCALE_FACTOR > MAX_BLOCK_WEIGHT
В переводе на русский: Если из сериализованного блока выкинуть witness-данные, то его размер не должен превышать 4000000/4 = 1000000 байт.

Вот это мне непонятно:
block.vtx.size() * WITNESS_SCALE_FACTOR > MAX_BLOCK_WEIGHT
vtx - вроде как имеет тип std::vector, значит метод size() возвращает количество элементов в векторе, а не общий занимаемый размер. Ну, короче, не понимаю смысл этой проверки.

Но это ещё не все проверки размера блока. Дальше видим:
где GetBlockWeight это:

Тут уже всё понятно прописано, как в методичке:


То есть, правило такое: размер_блока_без_witness * 3 + полный_размер_блока < 4000000

Согласен. Действительно 80 байт на блок не выходит. Но это не означает, что Накамото полагал что большинство блоков будут пустыми. Это означает, что он ошибся в оценке количества непотраченных выходов и зависимости этого количества от времени.

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

Ну, вот такое допущение сделал Накамото. В конце концов, он не позиционировал Bitcoin в качестве конкурента Visa по количеству транзакций в секунду. Все делают допущения в условиях недостатка информации. Вы, когда оценивали рост блокчейна в 1.5 ТБ в год, тоже сделали допущение, что все 30-мегабайтные блоки должны быть заполнены под завязку. А как оно на самом деле было бы при таких размерах блока - неизвестно.


Witness-данные записываются внутри транзакций.
Транзакции записываются внутри блока.
Блок представляется в виде байтового потока (сериализуется) и записывается в виде последовательности байт в файл базы данных блоков (blk*.dat). Это легко проверить: внутри любого blk*.dat можно найти при помощи HEX-редактора сериализованный блок и обнаружить в нём транзакции с witness-данными. Если witness-данные оказываются внутри сериализованного блока, то как можно считать, что witness-данные - это не часть блока?

Я самолично сейчас обнаружил двухмегабайтный блок 00000000000000000015700c792c59cda0380d5e3c3e16ba555cc3cfd6d6bb7d внутри файла blk01590.dat. И он таки реально занимает место на диске больше 2МБ.
И разработчики Bitcoin Core с этим размером согласны:

О чём мы спорим? О том что размер блока не может превышать 1 МБ? Ну так, вот вам блок, он на вашем диске тоже занимает 2297675 байт. И все эти 2297675  байт передадутся по сети другому SegWit-совместимому клиенту, когда он будет запрашивать блоки.


Но Холмс, как вы пришли к этому умозаключению?

А чего тут догадываться? Кручу-верчу запутать хочу, как говорили напёрсточники во времена оны.

Есть база данных блоков - bitcoin/blocks, к ней применяется прунинг и размер этой базы подгоняется под параметр prune=2000.
Есть база данных непотраченных выходов (UTXO) - .bitcoin/chainstate, к ней прунинг не применяется, она может расти или уменьшаться в зависимости от текущего количества UTXO в сети.

Вы берёте и сваливаете в одну кучу размер базы, к которой применяется прунинг и размер базы, к которой прунинг не применяется. Получаете результат, который не соответствует вашему prune=2000. Всё логично.


Да. Полноценными блоками обмениваются SegWit-совместимые клиенты, а старым клиентам подсовываются блоки, в которых из транзакций вырезан witness.


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

Что касается хеша блока, я уже говорил:
1. Транзакции в новом формате, включающий в себя witness, хешируются при помощи дерева Меркла, и корневой хеш помещается в один из выходов coinbase-транзакции.
2. Coinbase-транзакция вместе с остальными транзакциями, но уже в старом формате (без witness) хешируются при помощи дерева Меркла и корневой хеш помещается в параметр merkleroot заголовка блока.
3. Ну, а заголовок блока, включающий в себя merkleroot, принимает участие в вычислении хеша блока.
Таким образом, хеш блока зависит, в том числе, и от witness-данных транзакций.


Вах! Мамой клянус, да?
Вы придумали себе какое-то таинственное место, где хранятся witness-данные транзакций, а доказать существование этого места не в состоянии.


Голая тётка - это я понимаю, а где хранятся отдельно от блоков witness-данные транзакций - это я не понимаю.

Прунинг работает так: вы задаёте фиксированный размер хранилища блоков опцией командной строки -prune=<n>. Это фиксированный размер, сколько зададите - столько и будет занимать места на диске база блоков (но не меньше 550МБ). И эта база не будет расти со временем, старые блоки автоматически будут удаляться, чтобы выдерживать целевой размер базы.

Размер этой базы никак не зависит от количества потраченных выходов (вы его сами задаёте). Реально реализованный механизм прунинга не имеет никакого отношения к тому, что писал Накамото в разделе "7. Экономия дискового пространства". Поэтому, ваша фраза "при размере всего блокчейна 200 гиг, в режиме прунига он весит 2 гиг" не имеет никакого смысла.


Старым клиентам новые клиенты дают урезанные неполноценные блоки, влезающие в 1МБ, что никак не доказывает, что новые клиенты хранят witness где-то там отдельно, как вы сказали "Эта часть записывается за пределами блока".

Ваша фраза "Эта часть записывается за пределами блока" не подтверждается ничем, ни сегвитовскими BIP-ами (BIP141, BIP143), ни исходниками SegWit-совместимых клиентов.

Выполните в консоле команду
она вам выдаст сериализованный блок в HEX-формате. Какой у него будет размер в байтах? Вот этот размер и показывают блок-эксплореры.

А нам это неизвестно. Откуда взялась эта цифра - 2ГБ ?


Откуда вы взяли всю эту ересь? Witness - является частью транзакции. Транзакции в новом формате хешируются по алгоритму дерева Меркла и этот хеш помещается в scriptPubKey coinbase-транзакции. В какое место, по-вашему, это всё записывается, если кроме блоков ничего нет. Пальцем покажите.

Вот вам пример записи корня дерева Меркла в блоке:

aa21a9ed5b12dbe0fa44e4d3e1f77de9fe7dce28e1e2c838daa13f1b95269aa2e812c86f - это и есть корень дерева Меркла вычисленный с учётом данных witness.

Банковская система технически децентрализована. Проблемы с банками в Венесуэле французов не колышат. Банкротство одного банка на клиентов других банков никак не влияет. Не берусь судить, что более децентрализовано: биткойн или банки, но если рассматривать вопрос с технической точки зрения, то не всё так однозначно.

Но...  


В 20-м веке государствам, вдруг, пришла в голову мысль, что деньги должны иметь родословную, как какие-то породистые собаки. При этом, искажение этой родословной или сокрытие её было объявлено преступлением, называемым "отмыванием денег". Поэтому, банк может заблокировать деньги на  счету даже без распоряжения от государства, просто по собственному подозрению, без суда и следствия. Ну, и банк ещё может обанкротиться с потерей средств на счетах, что тоже весело.

Это всё проблемы, но не технические, а организационные. Технически у банковской системы проблем нет, поэтому банкам блокчейн не нужен, у них и так всё эффективно работает (привет Амаклину!).

Банковская система - элемент государственной власти. Биткойн выводит платежи из под влияния этой власти. В этом и заключается назначение Биткойна (что б там не думал об этом Накамото).

Биткойн - это прежде всего социальный эксперимент, а не технический (опять же, что б там не думал об этом Накамото). Способна ли существовать сеть Bitcoin длительное время? Насколько она стабильна при воздействии неблагоприятных внешних условий? Захотят ли пользоваться люди Биткойном, если будет проведена атака 51%? А если две атаки? А если пять? Способен ли Биткойн на дальнейшее техническое развитие?

Это всё социальные вопросы. Это всё про людей, которые держат ангары асиков, создают биржи и вносят изменения в исходный код Bitcoin.

Верно, это я перепутал SPV с прунингом.


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

На рисунке видна транзакция Tx3, которую нельзя удалять, а транзакции Tx0, Tx1, Tx2 были удалены, а вместо них добавлены узлы дерева Меркла Hash01 и Hash2, без них невозможно верифицировать корень дерева. То есть, не нужно дожидаться пока все транзакции в блоке будут потрачены.

Я не располагаю статистикой количества потраченных транзакций в блоках, и, поэтому, не имею представления о количестве блоков со всеми потраченными транзакциями и есть ли такие блоки вообще. Но ткнув наугад по старым блокам с красивыми высотами 111111, 222222, 333333, 444444, я обнаружил, что свыше 90% выходов потрачены. Если к этим блокам применить прунинг, то их размер в итоге будет близок к размеру блока совсем без транзакций, с одним лишь только заголовком.

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


Вот это и есть настоящий живой миф, который распространяют люди плохо знакомые с SegWit. Достаточно привести цитату из Segregated Witness Wallet Development Guide, раздел Transaction Serialization, где показано различие между старыми и новыми сериализованными транзакциями:


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


Откуда ж тогда берутся блоки размером больше 2 МБ?

Старых клиентов можно обмануть, подсунув им вместо реальных SegWit-входов валидные пустышки. При этом данные witness старым клиентам не передаются. За счёт вырезанного witness, блоки, передаваемые старым клиентам укладываются в лимит 1 МБ. Но верифицировать SegWit-транзакции старые клиенты не могут, они просто тупо считаются ими валидными. Впрочем, кого волнуют старые клиенты? Кто ими сейчас пользуется?

Поскольку вы в своих рассуждениях ссылаетесь на текущий максимальный размер блока, то всё-таки максимальный размер имеет к данной теме отношение.

Хуже того, мне кажется, вы транслируете пропагандистскую лапшу про SegWit, которой промывали мозги в 2016 году, что спустя полтора года после внедрения SegWit является неприемлемым в разговорах о технической стороне Bitcoin.

Можете пояснить, какие конеретно данные, относящихся к SegWit, не является частью блока?




Повторюсь, его расчёты относятся к SPV-нодам, которые хранят именно заголовки, и эти расчёты верные, а не какие-то там "сфабрикованные".

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


Сейчас, когда размер большинства блоков превышает 1 МБ, слышать об ограничении в 1МБ как-то странно. Особенно от человека, который пишет методички о языке скриптов Bitcoin и пилит форк Bitcoin со своим алгоритмом пересчёта сложности.

Легко? Вы свой уже восстановили?