Так закодировать до прототипа:
+ Реализовать код, который вычисляет и публикует «блоки баланса» и «баланс блока хэши». Убедить пару человек с дополнительной загрузки полосы пропускания, чтобы запустить его.
+ Изменение одной из реализаций Bitcoin, чтобы загрузить последнюю версию «баланс блока» из какого-то проверенного места при запуске, и использовать его, если транзакции / блоки не могут быть найдены в традиционной базе данных блока.
+ Дополнительный кредит / паранойя: запросить пару надежных мест для баланса блоков хэш, и убедитесь, что он соответствует хэш вы получили.
+ ИЛИ: случайно выборочная проверка блока баланса путем запроса блоков традиционного способа, и убедитесь, что блок баланса не перечисляет никаких результатов, как неизрасходованные, которые фактически потрачены.
Вы не хотите Bitcoin противовесов адреса, нет адреса вниз глубоко внутри. Вы должны знать, какие результаты сделки еще не были израсходованы, и стоимость этих выходов.
Я не в восторге от этого предложения, потому что я думаю, что это решение проблемы, не нужно решать еще и мои приоритеты для Bitcoin по-прежнему безопасности бумажник и стабильность сети, не делает его быстрее новичка соло шахтеров, чтобы получить полный blockchain, чтобы они могли начать проверки сделки / блоков.
Gavin,
Если перечитать мое предложение на другом потоке,
предложение делает позволяют получить весь неизрасходованный-txout-лист на любой адрес, только несколько килобайт из сети (После того, как у вас есть заголовки). Это означает, что вы только скачать пару кбайт из сети для каждого сценария / адреса в вашем бумажнике, и вы можете работать полностью без доверяя кому-либо или что-либо для заголовков, за исключением.
Hash160 адреса используется более чем один раз будет иметь тот же хэш сценария и, таким образом, быть объединены в многоузловой к югу от Merkle дерева. BIP 16 и другие творческие сценарии, используемые когда будут листовые узлы, представленные только одного узла к югу от Merkle дерева (ну это будет просто одно значение, а не дерево).
Это не для шахтеров ... это для легких пользователей. Это означает, что я могу импортировать адрес на мой телефон кошелек и получить полный список неизрасходованных выходов только с заголовками плюс несколько килобайт из сети - вам нужно только ветвь мастер-Merkle (который является O (журнал (N) ), где N есть число уникальных скриптов / адресов в blockchain) и дерева суб-Merkle (который является количество неизрасходованных txouts для этого сценария / адрес). Это
огромный улучшение для Bitcoin в целом, когда даже дрянные смартфоны могут быть 99% в полном объеме, используя только блок заголовков и несколько килобайт от сети. (Я говорю 99% потому, что они не могут сделать 100% проверки, необходимой для добычи полезных ископаемых, но они могут по крайней мере убедиться, что входы нулевого подтверждения-TX являются действительными и неизрасходованные, не полагаясь на другие службы).
Это всегда было предположение, на мой взгляд, что легкие узлы будут гражданами второго сорта в BTC мире. Но если это может быть сделано, чтобы работать, вычислительно, я считаю, даже облегченные узлы могут быть столь же безопасным, как полные узлы. И, конечно же, вы получаете 90% + сжатие. И все это выбрать в - разработчики клиент может просто игнорировать вторую цепь, если они хотят.
Остальные неопределенности являются: (1) Насколько сложна она будет поддерживать отдельную blockchain и все эти вещи, и (2), что является вычислительная сложность / оптимизаций здания & обновление такой blockchain?
Re: Предложение: вторая цепь для Масштабируемости
