Реальная история.
Я помню, как читал о BIP, которая в основном предполагают, что blockchain будет увеличиваться или уменьшаться, данные параметры, такие как текущий hashrate, спрос (использование как в сделках на второй или как там оно рассчитано). Мой вопрос, это звучит здорово и все, но я уверен, что есть какие-то серьезные проблемы, не быть ведущим BIP.
Так что те плюсы и минусы по сравнению с другими альтернативами, такими как только повышение размера блока по фиксированной ставке, либо оставить его относительно небольшой + blockstream и так далее?
Основные критические замечания, которые я получил при нажатии на такое предложение было потенциалом для шахтеров игры системы и подтолкнуть его в стороне, что обеспечивает размер блока в пользу них. Я по-прежнему убежден, что это улучшение по сравнению с BIP100, где шахтеры прямо просто выбрать размер блока, который они считают наиболее выгодным, но я все еще пытаюсь думать о том, чтобы свести к минимуму этот риск. Другой один в том, что, если он не имеет "жесткий" Колпачок и основывается главным образом на спрос, размер_блока потенциально может вырасти слишком большим, и поставить под угрозу децентрализации.
Кажется, что трюк найти правильный баланс между тем, что работает для шахтеров, узлов и пользователей, но трудность заключается в том, что ограничения полосы пропускания широко варьируются от одного региона к другому. Что было говорить о до сих пор, кажется, баланс между шахтерами и пользователями, но узлы и их требования являются более сложными фактором в:
Идеальное решение является тот, который не создает слишком большой размер блока для полных узлов, чтобы справиться с, но в то же время, тот, который не заставляет большое количество людей от цепи. Даже в два раза до 2Мб на одном дыхании достаточно высок, когда вы думаете об этом, поэтому мы должны стремиться увеличить (или уменьшить) в небольших приращений чаще,
если нужно. Одним из возможных путей является взять лучшие элементы BIP100 и
BIP106. BIP100 только считает, что выгоды шахтеров, а не пользователей. BIP106 учитывает только то, что приносит пользу пользователей и не шахтеры. Так ни один не особенно сбалансированный по себе. Если мы сможем найти способ, позволяющий половину из "голос" чтобы перейти к шахтерам и половину автоматизированной, алгоритмического голосования на основе объемов трафика, то мы поддерживаем какое-то равновесие, которое должно (в теории, по крайней мере) пользу сети в целом.
Шахтеры голосовать путем кодирования «BV» + BlockSizeRequestValue в coinbase scriptSig к:
поднять BLOCKSIZE предел на 12,5%,
понизить предел BLOCKSIZE на 12,5%,
или остаться на текущем пределе блочного.
Это голосование, однако, считается только половина от общего числа голосов, а другая половина определяется по алгоритму на основе сетевого трафика:
Если более 50% от размера блока, найденного в первом 1008 последнего периода сложности, более 90% MaxBlocksize
Сеть голосов для MaxBlocksize = MaxBlocksize + 12,5%
Иначе, если более 90% от размера блока, найденного в первом 1008 последнего периода сложности, составляет менее 50% MaxBlocksize
Сеть голосов для MaxBlocksize = MaxBlocksize -12,5%
еще
Сеть голосов для поддержания такой же MaxBlocksize
12,5% часть открыта для переговоров, некоторые думают, что 10% является более разумным (т.е. BIP105). Если каждые 1008 блоков слишком быстро, мы могли бы (например) увеличить, что в 2016 году блоков, примерно каждые две недели. Твики неизбежны, но я чувствую, что это то, что может работать, если это не слишком сложный код.
(Выше в значительной степени основывается на предложении BIP106 Упал с корректировкой по juiceayres, а затем мне пакетирования его с оттенком BIP100 стиль голосования)
Я думал, что меньше, увеличивается или уменьшается (не так, как все это "удвоение" говорить от большинства других предложений), здесь и там, в случае необходимости, будет более привлекательным для тех, кто только кажется, обеспокоены возможностью запуска узла, но они по-прежнему не собирается за него. Тем не менее, они, кажется, склонны идти за весь прирост 2-4-8, что потенциально может привести к более крупных блоков, чем мы на самом деле нужно. Я был убежден, что если люди хотят, чтобы оказать давление, чтобы проверить свои теории о рынке платы, гибкий предел будет идеальным. Мы всегда были бы близки к пределу, и в течение коротких периодов времени, может кратко освежить против него, поэтому необходимо включать разумную плату приоритизации обработки будет гораздо более постоянны, чем если бы мы имели средний размер блока 5МБ но имел 8MB кепка. Но даже это не получить стрелковый blockians интересно. Я искренне озадачен этим.