Максимальный размер блока:
static const unsigned int MAX_BLOCK_SIZE = 1000000;
Средний размер блока на сегодня:
180331000000 / 18033 =
55,45389
То есть, имеем более чем пятидесятикратный запас пропускной способности. Если предположить, что Bitcoin станет основной валютой интернет-расчётов (более 50% мировых объёмов), то можно предвидеть ситуацию, когда мы упрёмся в этот предел, если принять, что сейчас доля Bitcoin меньше 1%. Однако, понятно, что произойдёт это совсем не скоро.
Сразу же вопрос: если в блоке места ещё дохренищща, то почему клиент
уже трясёт с меня бабло за низкоприоритетные транзакции? Готовят меня к страшному?
Ещё раз напомню, что ограничение размера блока и ограничение скорости создания блоков было введено прежде всего
для ограничения скорости увеличения объёма общей истории транзакций. Следующие предложенные здесь варианты увеличения пропускной способности
не решают проблему роста истории:
- создание дополнительных блоков при необходимости (оригинальная идея);
- поднятие ограничения на размер блока (моё предложение);
- уменьшение среднего интервала между блоками ("Bitcoin-2").
Предлагаю разделить проблему "зависших" транзакций и проблему роста истории.
Предлагаемое мною решение направлено на решение первой проблемы. Для решения второй проблемы следует придумать что-то ещё.
Лично мне вообще, не нравится идея хранения истории на диске. Мне кажется, с этим нужно что-то делать.
Теперь рассмотрим некоторые пути решения проблемы компромисса между пропускной способностью и ростом истории.
Ok
Повышение комиссионных сборов приведёт к уменьшению числа транзакций. Пользователи будут переводить биткоины только когда это действительно будет нужно. Замечу, что повышение комиссионных неизбежно. Это заложено в систему. Когда премия за генерацию блока сойдёт на нет, всем придётся платить поборы.
Вы слишком часто напоминаете об этом. Я же не оспариваю данный тезис!
Я лишь говорю, что это - не панацея.
Использование "неполных" узлов сделает проблему роста истории менее острой и позволит увеличить размеры блоков (и пропускную способность сети) при необходимости.
Вот этим и надо заниматься! По возможности, уменьшить историю, хранимую внутри клиента. А в идеале - избавиться от неё вовсе.
Т. е. проблему роста истории нужно уменьшать не за счёт ограничения пропускной способности сети.