Есть биткоин классик, есть анлимитед.
... Майнеры видят у кого какой клиент и кого больше. ...
... Майнеры видят у кого какой клиент и кого больше. ...
А как майнеры видят, у кого какой клиент?
Topic: Решаем проблему с размером блока - page 4. (Read 5029 times)
А как майнеры видят, у кого какой клиент?
Не вижу предмета для обсуждения.
Есть биткоин классик, есть анлимитед.
Скачивайте, пользуйтесь. Майнеры видят у кого какой клиент и кого больше. Когда корой станет пользоваться меньшинство, все перестанут кору майнить и проблема с размером блока решится.
Есть биткоин классик, есть анлимитед.
Скачивайте, пользуйтесь. Майнеры видят у кого какой клиент и кого больше. Когда корой станет пользоваться меньшинство, все перестанут кору майнить и проблема с размером блока решится.
Вообще то размер блока это далеко не ключевая проблема биткоина. На фоне совокупного комплекса взаимосвязанных проблем(проблема роста бокчейна, проблема пропускной способности сети,.. - централизации) это, можно сказать, даже совсем и не проблема вовсе.
Согласен. Я бы даже сказал, что все эти проблемы связаны, и в совокупности порождают одну комплексную проблему. Я к этому выводу пришел около года назад, но проанализировав свои наработки, понял что протолкнуть решение всех проблем сразу будет нереально. Поэтому, думаю, что лучше попытаться их как-то разделить и действовать поэтапно...Есть у меня некоторые идеи и даже наработки, но с кем их обсуждать? - ещё одна проблема.
Я надеюсь, что эта тема хоть немного поможет решить данную проблему 
Переходим к решению. Дело в том, что мы не можем просто так взять и увеличить лимит. Поскольку он был введен для защиты от спама, то изменять его следует очень осторожно. Существует множество способов это осуществить: можно просто изменить константу в исходном коде; или запрограммировать периодическое увеличение на много лет вперед; еще можно управлять размером блока с помощью голосования майнеров, или других участников системы...
Однако все эти способы имеют один серьезный недостаток - новый размер всегда выбирается не по тем критериям, по которым это следует делать. А правильно следует его увеличивать только тогда, когда в этом появляется реальная необходимость, то есть когда очередь транзакций переполняется и все блоки заполнены под завязку. И наоборот, если размер блоков становится избыточным, и в них начинают попадать нежелательные транзакции с мизерной комиссией, то лимит следует уменьшать. Конечно же не все так просто, и чтобы это реализовать придется решить еще немало проблем. Но я думаю, что этот подход является самым очевидным и наиболее оправданным.
Попробуем продолжить. Выясняется, что нам нужно все время находить такой баланс, чтобы блоки вмещали в себя все полезные транзакции, а слишком мелкие при этом оставались за бортом, и находились в очереди, пока для них не появится свободное место. И вот тут возникает первая проблема. Где находится та самая граница, которая отделяет полезные транзакции, которые нужно пропустить в блокчейн, от нежелательного спама?
Однако все эти способы имеют один серьезный недостаток - новый размер всегда выбирается не по тем критериям, по которым это следует делать. А правильно следует его увеличивать только тогда, когда в этом появляется реальная необходимость, то есть когда очередь транзакций переполняется и все блоки заполнены под завязку. И наоборот, если размер блоков становится избыточным, и в них начинают попадать нежелательные транзакции с мизерной комиссией, то лимит следует уменьшать. Конечно же не все так просто, и чтобы это реализовать придется решить еще немало проблем. Но я думаю, что этот подход является самым очевидным и наиболее оправданным.
Попробуем продолжить. Выясняется, что нам нужно все время находить такой баланс, чтобы блоки вмещали в себя все полезные транзакции, а слишком мелкие при этом оставались за бортом, и находились в очереди, пока для них не появится свободное место. И вот тут возникает первая проблема. Где находится та самая граница, которая отделяет полезные транзакции, которые нужно пропустить в блокчейн, от нежелательного спама?
Начну с постановки проблемы. К сожалению, на данный момент мировое сообщество эту проблему решить не в состоянии. Но рано или поздно размер блока придется увеличивать - это очевидно. Даже в случае активации SegWit 1MB блока может быть недостаточно для создания каналов, а решения вроде XT или Unlimited имеют серьезные изъяны и влекут собой трудно предсказуемые последствия, следовательно необходимо найти лучшее решение.
Предлагаю применить рациональный подход и логическим путем прийти к оптимальному решению. Это очень важный момент, поскольку только с полным и очевидным доказательством его эффективности можно рассчитывать на принятие сообществом. Решение проблемы размера блока должно касаться только этой проблемы и более ничего. То есть недопустимо, чтобы в результате существенно увеличивалась централизация и влияние майнеров, также в рамках этой задачи нам не нужны дополнительные усовершенствования, вроде создания Lightning или чего-либо еще. Нужен фикс одной конкретной проблемы и всё.
Предлагаю применить рациональный подход и логическим путем прийти к оптимальному решению. Это очень важный момент, поскольку только с полным и очевидным доказательством его эффективности можно рассчитывать на принятие сообществом. Решение проблемы размера блока должно касаться только этой проблемы и более ничего. То есть недопустимо, чтобы в результате существенно увеличивалась централизация и влияние майнеров, также в рамках этой задачи нам не нужны дополнительные усовершенствования, вроде создания Lightning или чего-либо еще. Нужен фикс одной конкретной проблемы и всё.
Всем привет!
Имеются ли на форуме русскоязычные девелоперы, желающие принять активное участие в обсуждении решения данной проблемы, а возможно и его реализации?
Для начала предложу простое решение, альтернативное ограничению блока в 1MB. Так как этот лимит был введен в качестве защиты от спама, то можно просто сделать это другим способом. Допустим, мы считаем спамом все транзакции с комиссией ниже некоторой фиксированной величины (скажем, 20 satoshies/byte). В таком случае, проблема решается предельно просто - снимаем ограничение на размер блока и запрещаем майнерам включать в блоки транзакции с комиссией ниже этой величины, а также бесплатно включать собственные транзакции. Вернее, не совсем запрещаем, а все же оставим немного места (пусть будет 5%) для спорных транзакций:
Вариант решения №1
Основная идея в том, что транзакция должна попасть в мемпулы большинства полных нод и пробыть там какое-то время до того, как будет включена в блок. Это необходимо, чтобы майнеры не могли бесплатно включать собственные транзакции - теперь они, наравне со всеми, вынуждены сначала разослать их по сети.
5% спорных транзакций - смягчающее условие, это очень большой запас для того, чтобы ноды всегда приходили к консенсусу. Даже в том случае, если готовый блок каким-то образом будет получен раньше, чем некоторые включенные в него транзакции (что на практике почти невозможно).
* В любом случае, самая длинная цепочка в конечном итоге строится на PoW, и временно отбракованные блоки теоретически могут быть включены в блокчейн, но только если большинство майнеров (>50%) нарушат правила и согласятся их принять. Поэтому, во время оценки PoW для цепочки, ноды и майнеры не должны считать такие блоки, пока за ними не будет построено хотябы 2-3 нормальных блока. По этой же причине имеет смысл ограничить единовременное увеличение блока по сравнению со средним размером нескольких предыдущих, скажем не более чем вдвое.
Тема в англоязычной ветке: https://bitcointalksearch.org/topic/block-size-increase-proposal-consensus-based-on-mempool-1851018
Некоторые выдержки из обсуждений: https://bitcointalksearch.org/topic/m.18465662
Другой возможный способ - это оставить ограничение на размер блока, и увеличивать его тогда, когда в этом появляется реальная необходимость. То есть изменить правила консенсуса, чтобы майнеры могли увеличивать блок, если очередь mempool транзакций (с достаточной комиссией) переполняется. Ниже будут изложены некоторые идеи, как это реализовать...
Имеются ли на форуме русскоязычные девелоперы, желающие принять активное участие в обсуждении решения данной проблемы, а возможно и его реализации?
Для начала предложу простое решение, альтернативное ограничению блока в 1MB. Так как этот лимит был введен в качестве защиты от спама, то можно просто сделать это другим способом. Допустим, мы считаем спамом все транзакции с комиссией ниже некоторой фиксированной величины (скажем, 20 satoshies/byte). В таком случае, проблема решается предельно просто - снимаем ограничение на размер блока и запрещаем майнерам включать в блоки транзакции с комиссией ниже этой величины, а также бесплатно включать собственные транзакции. Вернее, не совсем запрещаем, а все же оставим немного места (пусть будет 5%) для спорных транзакций:
Вариант решения №1
- лимит на размер блока отменяется*
- полные узлы временно отклоняют блоки*, если в них включены транзакции с комиссией ниже 20 сат/байт, или более 5% спорных транзакций (находившиеся в локальной очереди mempool менее 15 секунд)
- майнеры следуют тем же правилам, но кроме этого, они вынуждены передавать транзакции в сеть (в том числе собственные), как минимум за 15-20 секунд до включения их в блок
- minTxRelayFee параметр становится частью консенсуса и не может превышать 20 satoshies/byte, иначе ноды просто не смогут проверить блок на валидность
Основная идея в том, что транзакция должна попасть в мемпулы большинства полных нод и пробыть там какое-то время до того, как будет включена в блок. Это необходимо, чтобы майнеры не могли бесплатно включать собственные транзакции - теперь они, наравне со всеми, вынуждены сначала разослать их по сети.
5% спорных транзакций - смягчающее условие, это очень большой запас для того, чтобы ноды всегда приходили к консенсусу. Даже в том случае, если готовый блок каким-то образом будет получен раньше, чем некоторые включенные в него транзакции (что на практике почти невозможно).
* В любом случае, самая длинная цепочка в конечном итоге строится на PoW, и временно отбракованные блоки теоретически могут быть включены в блокчейн, но только если большинство майнеров (>50%) нарушат правила и согласятся их принять. Поэтому, во время оценки PoW для цепочки, ноды и майнеры не должны считать такие блоки, пока за ними не будет построено хотябы 2-3 нормальных блока. По этой же причине имеет смысл ограничить единовременное увеличение блока по сравнению со средним размером нескольких предыдущих, скажем не более чем вдвое.
Тема в англоязычной ветке: https://bitcointalksearch.org/topic/block-size-increase-proposal-consensus-based-on-mempool-1851018
Некоторые выдержки из обсуждений: https://bitcointalksearch.org/topic/m.18465662
Другой возможный способ - это оставить ограничение на размер блока, и увеличивать его тогда, когда в этом появляется реальная необходимость. То есть изменить правила консенсуса, чтобы майнеры могли увеличивать блок, если очередь mempool транзакций (с достаточной комиссией) переполняется. Ниже будут изложены некоторые идеи, как это реализовать...
Jump to: