SegWit + Variable и адаптивные (но весьма консервативны) Blockweight Предложение

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

Статический предел, по моему твердому убеждению, недальновидно. Это не решает проблемы многие до сих пор имеют о на цепочке сделки становятся экономически невыгодными. Многие утверждают, что это просто вопрос заговора "холдинг SegWit назад", Но пока это не без причины, я не полностью убежден, что аргумент и считают, что замок в гарантии о приблизит размером блока активации SegWit.
_{[// EDIT декабрь 2017: Почти пророческий дали первоначальный успех BIP91 (несмотря на то неудачу на втором препятствии), хех. ]}

Я утверждаю, что алгоритмический процесс, основанный на реальное время сетевого трафика намного лучше во всех отношениях, чем установленный "неуклюжий хак" Менталитет собирание произвольное целое число от разреженного воздуха, пинать банку вниз по дороге, ожидая "разрешение" от разработчиков и спуска в ту же дурацкую войну каждый раз, когда вопрос о пропускной способности возникающий в будущем. Кроме того, один раз hardfork гораздо лучше, чем несколько hardforks каждый раз мы начинаем приближается еще один новый и произвольный статический предел. И к сожалению, нет резких колебаний давления платы таким образом. Все гладко, последовательно и, по большей части, предсказуемой, что то, что мы должны все хотим Bitcoin быть.

Давление Манометры Предложение плата в сочетании с движением, чтобы определить, является ли увеличение, уменьшение или отсутствие изменений вообще не требуется. Сильное внимание было уделено ограничением роста (и позволяет уменьшается), чтобы не достичь уровня, при котором узлы будут бороться с использованием полосы пропускания. Состояние платы также помогает предотвратить игровую систему. Эта последняя итерация предложения, в значительной степени основана на BIP106 включает в себя корректировку Уитнессы пространства, чтобы поддерживать соотношение 1: 3 между основанием и свидетелем. SegWit является необходимым условием для этого должно быть активировано:

Код:

Если более 50% от размера блока, найденного в первом 2016 последнего периода сложности, более 90% MaxBlocksize
   И (TotalTxFeeInLastDifficulty > средний (TotalTxFee в последние 8 периодов сложности))
   ТОГДА BaseMaxBlockSize = BaseMaxBlockSize + 0.01MB
   WitnessMaxBlockSize = WitnessMaxBlockSize + 0.03MB

Иначе, если более 90% от размера блока, найденного в первом 2016 последнего периода сложности, составляет менее 50% MaxBlocksize
   ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
   WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB

ELSE
   Держите же BaseMaxBlockSize и WitnessMaxBlockSize

(Кредит Upal Чакраборти для их первоначальной концепции в BIP106)

// EDIT: Приветствия D5000 для предлагаемых их средней корректировки платы

Таким образом, в простом английском языке, крошечные, 0.01MB, Корректировка базовой blockweight может происходить каждый период сложности и пропорциональное 0.03MB свидетельству пространства, чтобы поддерживать соотношение 1: 3, но только если:

SegWit реализуется
Либо имеются достаточно полные блоки, чтобы оправдать увеличение на blockweight, или достаточно пустым, чтобы уменьшить его
Есть больше сборов, сгенерированных в последнем период трудности, чем в среднем за последние 8 периодов, чтобы обеспечить увеличение, но blockweight может быть уменьшен независимо от платы, которая будет сдерживать игровую систему

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), база blockweight бы еще только будет ~ 2.04 MB после 4-х лет.

Является ли это компромисс, большинство из нас может получить позади?

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

Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости.

Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM

Как различать реальный спрос со стороны спроса со спамом?

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

Я просто не понимаю, как гибкие схемы размер_блока не годные для использования.

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM

Ну, я думаю, что гибкость идет в обоих направлениях - блоки могут получить меньше снова, если пространство не используется. Это красота гибких блоков.

Если кто-то хочет использовать blockchain, и платить за него (тратить миллионы), были ли полезны кому-либо сделки, остальное не имеет значения вид. спам одного человека является законным использование другого человека. Но если они платят сборы и шахтеры согласны с этим, я думаю, его хорошо, и мы не должны пытаться сужают размера блока из-за него. Лучше, чтобы получить немного наворотов и сделать спамеры платить за все, что объем, чем постоянно наказывать все остальное с высокими налогами и ограниченной пропускной способностью.

Цитата: jonald_fyookball от 11 мая 2017 года, 12:03:16 AM

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM

" спам одного человека является законным использование другого человека. "

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

Сеть будет расти так много, и узлы будут в конечном итоге кошмар для запуска.

Например загрузив blockchain Эфириума с нуля ад, потому что есть некоторые блоки, заполненные спам из-за нападения. Вы должны обойти эти точки или ее практически невозможно загрузить.

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

Я полностью поддерживаю это предложение и надеюсь, что мы можем двигаться вперед с реальным BIP и фактической реализацией на его основе.

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

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

Вы можете сделать математику: увеличение размера базового блока будет максимум 250 килобайт в год (то есть значительное число относительно квадратичной задачи хеширования), в то время как общий размер блока только может измениться 1 МБ / год.

Что мне нравится в отношении последнего предложения (5% за период) является неэкспоненциальна подходом к блоку размера увеличивается. Таким образом, если размер блока становится больше он по-прежнему столь же трудно "спам на размере блока луны",

если там будет трудно консенсусом, чтобы перейти к адаптивным / динамическим блокам. то не нужно было бы, чтобы быть 1: отношение блока внутри блока 3.

вместо того, чтобы в точке, где все узлы готовы принять адаптивные блоки, проверка segwit может быть частью стандартного консенсуса .. означает, что он может быть только один формат блока, который позволяет
(TX вход) (сиг) (выход TX) - родной / наследие ТХ
а также
(TX вход) (выход TX) (сиг) - segwit
все в том же районе блока

таким образом позволяя ОЧИСТИ один блок Merkle, где люди, которые хотят использовать segwit ТЕ можем .. и те, кто хочет остаться с банкой родного Техаса, а затем, объединяющим сообщество, потому что нет cludge из эшелонов сетей зачистки блоков друга от друга и проблем с совместимостью различные узлы.

также

Код:

ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB

это вызвало бы бесхозные риски, когда узлы пересканировать блок-цепь

если блоки 2016 были X, то в следующий раз 2016 блоки были у (= X-0.01) с правилами, являющихся Y .. все блоки X получили бы сиротами, потому что 2016 блоков, которые X находятся выше текущего правила Y.

Цитата: BillyBobZorton от 11 мая 2017 года, 12:24:59 AM

Цитата: jonald_fyookball от 11 мая 2017 года, 12:03:16 AM

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM

Пользователям выигрывают, получая быстрые подтверждения и низкие сборы, поскольку блоки не полностью.

котировка

Сеть будет расти так много, и узлы будут в конечном итоге кошмар для запуска.

Например загрузив blockchain Эфириума с нуля ад, потому что есть некоторые блоки, заполненные спам из-за нападения. Вы должны обойти эти точки или ее практически невозможно загрузить.

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

У вас есть точка, что blockchain вздутие может быть проблемой. Это была первоначально причина Satoshi положить предел 1МБ место. Однако, когда он сделал так, блоки были около 1 килобайт. Я согласен, что это, возможно, имеет смысл иметь некоторый предел, так что навороты не могут идти баллистическими, но я не понимаю, что случилось с гибкими пределами. Если вы используете что-то подобное, позволяет сказать, 30-дневная скользящая средняя, а затем блоки должны быть засунуты в течение целого месяца. Это стало бы невероятно дорого ... а деньги пойдут прямо в руки шахтеров, которые имеют дело с ним так или иначе ... так они компенсируются за это.

Номера узлы горнодобывающие могут использовать некоторые формы SPV и пропустить раздуваться.

Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM

Я открыт для экономических и технических аргументов для настройки любого аспекта этого компромиссного предложения, но прямое увольнение в связи с опасениями по теории игр будут удалены на месте, если вы также предполагает усовершенствование предложения по преодолению этих проблем. Конструктивная обратная связь, не торпеды.

Статический предел, по моему твердому убеждению, недальновидно. Это не решает проблемы многие до сих пор имеют о на цепочке сделки становятся экономически невыгодными. Многие утверждают, что это просто вопрос заговора "холдинг SegWit назад", Но пока это не без причины, я не полностью убежден, что аргумент и считают, что замок в гарантии о приблизит размером блока активации SegWit. Я утверждаю, что алгоритмический процесс, основанный на реальное время сетевого трафика намного лучше во всех отношениях, чем установленный "неуклюжий хак" Менталитет собирание произвольное целое число от разреженного воздуха, пинать банку вниз по дороге, ожидая "разрешение" от разработчиков и спуска в ту же дурацкую войну каждый раз, когда вопрос о пропускной способности возникающий в будущем. Кроме того, один раз hardfork гораздо лучше, чем несколько hardforks каждый раз мы начинаем приближается еще один новый и произвольный статический предел. И к сожалению, нет резких колебаний давления платы таким образом. Все гладко, последовательно и, по большей части, предсказуемой, что то, что мы должны все хотим Bitcoin быть.

Давление Манометры Предложение плата в сочетании с движением, чтобы определить, является ли увеличение, уменьшение или отсутствие изменений вообще не требуется. Сильное внимание было уделено ограничением роста (и позволяет уменьшается), чтобы не достичь уровня, при котором узлы будут бороться с использованием полосы пропускания. Состояние платы также помогает предотвратить игровую систему. Эта последняя итерация предложения, в значительной степени основана на BIP106 включает в себя корректировку Уитнессы пространства, чтобы поддерживать соотношение 1: 3 между основанием и свидетелем. SegWit является необходимым условием для этого должно быть активировано:

Код:

Если более 50% от размера блока, найденного в первом 2016 последнего периода сложности, более 90% MaxBlocksize
   И (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty)
   ТОГДА BaseMaxBlockSize = BaseMaxBlockSize + 0.01MB
   WitnessMaxBlockSize = WitnessMaxBlockSize + 0.03MB

Иначе, если более 90% от размера блока, найденного в первом 2016 последнего периода сложности, составляет менее 50% MaxBlocksize
   ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
   WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB

ELSE
   Держите же BaseMaxBlockSize и WitnessMaxBlockSize

(Кредит Upal Чакраборти для их первоначальной концепции в BIP106)

Таким образом, в простом английском языке, крошечные, 0.01MB, корректировка базового размера блока может происходить за каждый период сложности и пропорциональное 0.03MB свидетельству пространства, чтобы поддерживать соотношение 1: 3, но только если:

SegWit реализуется
Либо имеются достаточно полные блоки, чтобы оправдать увеличение до размера блока, или достаточно пустым, чтобы уменьшить его
Есть больше сборов, сгенерированных в последнем период трудности, чем предыдущий, чтобы обеспечить рост, но размер_блок может быть уменьшен независимо от платы, которая будет сдерживать игровую систему

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), база размер_блока бы еще только будет ~ 2.04 MB после 4-х лет.

Является ли это компромисс, большинство из нас может получить позади?

Цитата: D5000 от 11 мая 2017 года, 12:32:19 AM

Я тоже полностью поддерживаю это предложение.

Цитата: D5000 от 11 мая 2017 года, 12:32:19 AM

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

Это будет необходимо изучить и изучены глубоко и рассмотреть все эксплуатационные углы, потому что вы забываете есть люди там с буквальным денежных машин.

Злоумышленник, как и сам НБК имеет триллионы долларов на свалку и раздуть сети и держать его на максимуме, так что даже если вы установите лимит, вы бы в конечном итоге с размером блока, что это слишком большой для большинства людей, а затем узлы начнут падать как Soliders в D-Day.

Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года.

Является ли это компромисс, большинство из нас может получить позади?

Для меня, может быть,

Но имейте в виду, говоря, 2,04 MB после 4 лет скрывает тот факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете.

Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM

Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года.

Является ли это компромисс, большинство из нас может получить позади?

если было бы трудно достичь консенсуса в отношении перехода к динамике .. то его гораздо лучше использовать эту oppertunity объединить segwit и родную пару ключей в том же районе.
EG 4mb как для нативного и segwit сидеть в одном блоке Merkle. затем он увеличится на х% за две недели.

люди, работающие тесты скорости знают, что на нынешних современных базовых системах (raspberrypi3) и средней скорости интернета 2017 года вместе со всем efficiences начиная с 2009 годом (libsecp256k1) показало, что 8mb является raspberrypi среднего домашнего пользователя безопасно ..

поэтому, начиная с 4MB одного блока Merkle будет считаться более безопасным.

и запомни
даже с правилом 4Mb НЕ означает, бассейны будут делать 4MB мгновенно ..
так же, как они не делают 1Mb блоков в 2009-2014 даже с 1mb допустимого буфера ..
бассейны сделали свой собственный анализ риска и сделать свои собственные льготные приращений ниже консенсуса.

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

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

Таким образом, это хорошо в ближайщем будущем решение, до того, когда закон Мура перестанет быть возможным применить - когда это произойдет, будет более чем достаточно места в блоках для LN быть реализованы и для большинства пользователей Bitcoin, чтобы использовать его с onchain транзакций для отправки больше Bitcoin и частные каналы которые часто используются в качестве хорошо.

Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM

Как d5000 упоминалось, на его долю приходится только для сделок, которые сделали его в предыдущих блоков, она должна была бы быть спамом с здоровенный плата для подсчета. Кроме того, условия установлены так, что размер_блока может только увеличиться, если общая сумма сборов ТХ, собранные в последний период дифф выше, чем последний дифф период, поэтому им придется платить больше и больше с течением времени, если они хотят сохранить спам , в противном случае он остается на том же уровне и не увеличивается. И даже если они не удалось достичь такого уровня непрерывного спама в течение нескольких последовательных двухнедельных, они получают дополнительный .01MB каждый раз, когда за их усилия и, как только они не могут поддерживать атаку, он будет падать снова. Спам никогда не может быть предотвращено, но может быть в значительной степени disincentivised, что это предложение делает хорошо.

Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM

Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года.

Является ли это компромисс, большинство из нас может получить позади?

В самом деле, но это только если увеличение фактически достигается каждый дифф период. Порог устанавливается достаточно высоким, если по крайней мере, половине из блоков в этот период должна быть по крайней мере 90% от полного, чтобы претендовать на увеличение (но опять же, если люди хотят, чтобы запросить эти цифры, мы можем смотреть на что коллективно и дискуссионные плюсы и минусы). В действительности это может занять гораздо больше времени, чем 4 лет, чтобы достичь такого рода размера. Я уверен, что многие бассейны по-прежнему будет добыча в основном пустые блоки только, чтобы захватить награду, так из-за того, что и другие факторы, там, вероятно, не будет увеличиваться каждый раз. Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате. И, наконец, и, очевидно, даже если максимальные увеличения размера, рудничный не обязательно должен заполнить его. Они все еще довольно радушны освободить <1MB блоки после увеличения, если это их предпочтения.

Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM

Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM

Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM

Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года.

говоря 2,04 MB после 4 лет сокрытия того факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете.

В действительности это может занять гораздо больше времени, чем 4 лет, чтобы достичь такого рода размера. Я уверен, что многие бассейны по-прежнему будет добыча в основном пустые блоки только, чтобы захватить награду, так из-за того, что и другие факторы, там, вероятно, не будет увеличиваться каждый раз.

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

Все рост, BTC обменный курс, темп роста транзакций, размер_блока рост и акт роста hashrate синергически друг с другом, они все агрегат в более широком положительной обратной связи. Я понимаю, что даже это будет иметь незначительное влияние на возможном росте блочных мы в конечном итоге с (скажет 1,04 МБ в год + факторинг в 0,2 МБ макс для < 2 недели в период сложности), но это не означает, что ваши консервативные ожидания были больше правильно, просто, что они не влияют на общий результат слишком много, что приводит меня к следующему пункту ....

Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM

Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате.

Возможно Вы правы. Так зачем это делать? Мы можем быть прямо о том, что 1.04 MB в год не будет раздражать маленькие блокаторы слишком много, но это не будет удовлетворять требованиям больших блокаторов на всех. Или в том, что почему это компромисс? Все одинаково несчастными

Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM

И, наконец, и, очевидно, даже если максимальные увеличения размера, рудничный не обязательно должен заполнить его. Они все еще довольно радушны освободить <1MB блоки после увеличения, если это их предпочтения.

Опять же, мы расстаемся здесь. Если есть разбивка в парадигмах роста технологических факторов, определяющих верхние пределы емкости сети в Bitcoin (т.е. медианы пропускной способность интернет, средние затраты на складских помещений и средние общие вычислительные возможности), то мы вернемся сюда на bitcointalk. орг дежурные около 2027 года, рассуждая о том, где и как размер_блок должен остановиться, вместо того, как она должна расти.

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

Цитата: Carlton банков на 11 мая 2017 года, 6:32:13 PM

Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM

Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате.

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

Цитата: Carlton банков на 11 мая 2017 года, 6:32:13 PM

Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM

Я не знал, что конкретный прецедент был создан. BIP 100, 101 и 106 не указан верхний предел. Хотя это правда, что сообщество не считает их жизнеспособные предложения, они, конечно, не считают их неполными либо. Это звучит как больше личных предпочтений с вашей стороны, а не стандарт сообщества, что представляет собой "полный", Если мы должны смотреть на укупорки его в будущем, то мы можем смотреть на это. Любая попытка упреждения лимита сейчас догадки в лучшем случае, а также открывает двери для будущих hardforks. Укупорки от будет мягкой вилкой. Я не буду увольнять шапку прямо, но мне нужно больше, чем просто один человек говорил мне, что нужно один. В соответствии с ФП, у меня есть довольно сильное отвращение к произвольным статическим пределам, но это только мое личное предпочтение.

Речь не идет о прецедентах. Или о том, как много людей говорят это (серьезно?)

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

Я walways предпочтение динамичного самого размера блока. я поддерживаю это предложение тоже.

Цитата: BillyBobZorton от 11 мая 2017 года, 2:21:40 PM

Злоумышленник, как и сам НБК имеет триллионы долларов на свалку и раздуть сети и держать его на максимуме, так что даже если вы установите лимит, вы бы в конечном итоге с размером блока, что это слишком большой для большинства людей, а затем узлы начнут падать как Soliders в D-Day.

Если эти "деньги сделать машины" хотят уничтожить Bitcoin, они могут сделать это сейчас. 51% атака стоит около 600-700 миллионов долларов в этот момент. PBOC не будет иметь никаких проблем с этим. Так почему пройти нелегкий путь и спам в сеть Bitcoin в течение 10 лет, чтобы достичь ~ 3,5 MB базового размера, если вы можете уничтожить его мгновенно?

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

@DooMAD: У меня есть, однако, небольшое предложение обновления:

+ Изменить

Код:

(TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty)

Код:

(TotalTxFeeInLastDifficulty > средний (TotalTxFee в периоды прошлого X сложности))

с X = 4 или более, я бы предложил X = 8.

Причина заключается в том, что totaltxfee может иметь колебания. Таким образом, злоумышленник / группа, которая хочет, чтобы увеличить размер блока может производить "полный блок спам атаки" в период сложности только после периода с относительно низким TotalTxFee.

Что касается верхней крышки блочной (@Carlton Banks): В предыдущих предложениях мы обсуждали это имело смысл для меня, потому что предлагаемый рост размера блока был экспоненциальным (+-% является последним я помню), и это могло бы привести к неконтролируемой ситуации в будущем. Я думаю, что это предложение является достаточно консервативным, что такая верхней крышка не имеет значения. Я также не полностью против этого.

Цитата: D5000 от 11 мая 2017 г., 10:56:42 PM

@DooMAD: У меня есть, однако, небольшое предложение обновления:

+ Изменить

Код:

(TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty)

Код:

(TotalTxFeeInLastDifficulty > средний (TotalTxFee в периоды прошлого X сложности))

Исключительные рассуждения, я полностью на борту с этим. Я надеялся, что мы могли бы найти улучшения, которые помогут поднять антистимулы на спам, и это абсолютно квалифицируется. OP обновляется. Благодарю.

Цитата: Carlton банков на 11 мая 2017 года, 8:11:45 PM

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

Цитата: franky1 от 11 мая 2017 года, 12:32:50 AM

также

Код:

ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB

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

10 мая 2017, 9:00:29 PM	# 1
DooMAD Сообщения: 1456 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru : Модерация примечание: Я открыт для экономических и технических аргументов для настройки любого аспекта этого компромиссного предложения, но прямое увольнение в связи с опасениями по теории игр будет удалено на месте, если не сказали проблемы сопровождаются предложением улучшить предложение и преодолеть эти проблемы. Конструктивная обратная связь, не торпеды, пожалуйста. Статический предел, по моему твердому убеждению, недальновидно. Это не решает проблемы многие до сих пор имеют о на цепочке сделки становятся экономически невыгодными. Многие утверждают, что это просто вопрос заговора "холдинг SegWit назад", Но пока это не без причины, я не полностью убежден, что аргумент и считают, что замок в гарантии о приблизит размером блока активации SegWit. _{[// EDIT декабрь 2017: Почти пророческий дали первоначальный успех BIP91 (несмотря на то неудачу на втором препятствии), хех. ]} Я утверждаю, что алгоритмический процесс, основанный на реальное время сетевого трафика намного лучше во всех отношениях, чем установленный "неуклюжий хак" Менталитет собирание произвольное целое число от разреженного воздуха, пинать банку вниз по дороге, ожидая "разрешение" от разработчиков и спуска в ту же дурацкую войну каждый раз, когда вопрос о пропускной способности возникающий в будущем. Кроме того, один раз hardfork гораздо лучше, чем несколько hardforks каждый раз мы начинаем приближается еще один новый и произвольный статический предел. И к сожалению, нет резких колебаний давления платы таким образом. Все гладко, последовательно и, по большей части, предсказуемой, что то, что мы должны все хотим Bitcoin быть. Давление Манометры Предложение плата в сочетании с движением, чтобы определить, является ли увеличение, уменьшение или отсутствие изменений вообще не требуется. Сильное внимание было уделено ограничением роста (и позволяет уменьшается), чтобы не достичь уровня, при котором узлы будут бороться с использованием полосы пропускания. Состояние платы также помогает предотвратить игровую систему. Эта последняя итерация предложения, в значительной степени основана на BIP106 включает в себя корректировку Уитнессы пространства, чтобы поддерживать соотношение 1: 3 между основанием и свидетелем. SegWit является необходимым условием для этого должно быть активировано: Код: Если более 50% от размера блока, найденного в первом 2016 последнего периода сложности, более 90% MaxBlocksize И (TotalTxFeeInLastDifficulty > средний (TotalTxFee в последние 8 периодов сложности)) ТОГДА BaseMaxBlockSize = BaseMaxBlockSize + 0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize + 0.03MB Иначе, если более 90% от размера блока, найденного в первом 2016 последнего периода сложности, составляет менее 50% MaxBlocksize ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB ELSE Держите же BaseMaxBlockSize и WitnessMaxBlockSize (Кредит Upal Чакраборти для их первоначальной концепции в BIP106) // EDIT: Приветствия D5000 для предлагаемых их средней корректировки платы Таким образом, в простом английском языке, крошечные, 0.01MB, Корректировка базовой blockweight может происходить каждый период сложности и пропорциональное 0.03MB свидетельству пространства, чтобы поддерживать соотношение 1: 3, но только если: SegWit реализуется Либо имеются достаточно полные блоки, чтобы оправдать увеличение на blockweight, или достаточно пустым, чтобы уменьшить его Есть больше сборов, сгенерированных в последнем период трудности, чем в среднем за последние 8 периодов, чтобы обеспечить увеличение, но blockweight может быть уменьшен независимо от платы, которая будет сдерживать игровую систему Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), база blockweight бы еще только будет ~ 2.04 MB после 4-х лет. Является ли это компромисс, большинство из нас может получить позади?

10 мая 2017, 11:10:27 PM	# 2
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Получил 1806 Биткоинов Реальная история. Мне нравится идея адаптивного размера блока. Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости.

10 мая 2017, 11:34:27 PM	# 3
BillyBobZorton Сообщения: 1036 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM Мне нравится идея адаптивного размера блока. Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости. Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. Я просто не понимаю, как гибкие схемы размер_блока не годные для использования.

11 мая 2017, 12:03:16 AM	# 4
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM Мне нравится идея адаптивного размера блока. Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости. Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. Я просто не понимаю, как гибкие схемы размер_блока не годные для использования. Ну, я думаю, что гибкость идет в обоих направлениях - блоки могут получить меньше снова, если пространство не используется. Это красота гибких блоков. Если кто-то хочет использовать blockchain, и платить за него (тратить миллионы), были ли полезны кому-либо сделки, остальное не имеет значения вид. спам одного человека является законным использование другого человека. Но если они платят сборы и шахтеры согласны с этим, я думаю, его хорошо, и мы не должны пытаться сужают размера блока из-за него. Лучше, чтобы получить немного наворотов и сделать спамеры платить за все, что объем, чем постоянно наказывать все остальное с высокими налогами и ограниченной пропускной способностью.

11 мая 2017, 12:24:59 AM	# 5
BillyBobZorton Сообщения: 1036 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: jonald_fyookball от 11 мая 2017 года, 12:03:16 AM Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM Мне нравится идея адаптивного размера блока. Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости. Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. Я просто не понимаю, как гибкие схемы размер_блока не годные для использования. Ну, я думаю, что гибкость идет в обоих направлениях - блоки могут получить меньше снова, если пространство не используется. Это красота гибких блоков. Если кто-то хочет использовать blockchain, и платить за него (тратить миллионы), были ли полезны кому-либо сделки, остальное не имеет значения вид. спам одного человека является законным использование другого человека. Но если они платят сборы и шахтеры согласны с этим, я думаю, его хорошо, и мы не должны пытаться сужают размера блока из-за него. Лучше, чтобы получить немного наворотов и сделать спамеры платить за все, что объем, чем постоянно наказывать все остальное с высокими налогами и ограниченной пропускной способностью. " спам одного человека является законным использование другого человека. " Но кто получает выгоду, кроме того парня спамить сеть за счет всех остальных получать их узлы раздутый с безумным количеством данных? Сеть будет расти так много, и узлы будут в конечном итоге кошмар для запуска. Например загрузив blockchain Эфириума с нуля ад, потому что есть некоторые блоки, заполненные спам из-за нападения. Вы должны обойти эти точки или ее практически невозможно загрузить. При этом, вы только повреждая сети на долгий срок, потому что люди не будут беспокоить с загрузкой blockchain.

11 мая 2017, 12:32:19 AM	# 6
d5000 Сообщения: 1582 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Я полностью поддерживаю это предложение и надеюсь, что мы можем двигаться вперед с реальным BIP и фактической реализацией на его основе. Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. В этом предложении, он бы лет непрерывного спама для достижения опасного размера блока. Не только mempool спам (как сейчас), сделки должны быть фактически включены в блоки, так что это будет очень дорогостоящей операцией. Вы можете сделать математику: увеличение размера базового блока будет максимум 250 килобайт в год (то есть значительное число относительно квадратичной задачи хеширования), в то время как общий размер блока только может измениться 1 МБ / год. Что мне нравится в отношении последнего предложения (5% за период) является неэкспоненциальна подходом к блоку размера увеличивается. Таким образом, если размер блока становится больше он по-прежнему столь же трудно "спам на размере блока луны",

11 мая 2017, 12:32:50 AM	# 7
franky1 Сообщения: 1890 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение если там будет трудно консенсусом, чтобы перейти к адаптивным / динамическим блокам. то не нужно было бы, чтобы быть 1: отношение блока внутри блока 3. вместо того, чтобы в точке, где все узлы готовы принять адаптивные блоки, проверка segwit может быть частью стандартного консенсуса .. означает, что он может быть только один формат блока, который позволяет (TX вход) (сиг) (выход TX) - родной / наследие ТХ а также (TX вход) (выход TX) (сиг) - segwit все в том же районе блока таким образом позволяя ОЧИСТИ один блок Merkle, где люди, которые хотят использовать segwit ТЕ можем .. и те, кто хочет остаться с банкой родного Техаса, а затем, объединяющим сообщество, потому что нет cludge из эшелонов сетей зачистки блоков друга от друга и проблем с совместимостью различные узлы. также Код: ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB это вызвало бы бесхозные риски, когда узлы пересканировать блок-цепь если блоки 2016 были X, то в следующий раз 2016 блоки были у (= X-0.01) с правилами, являющихся Y .. все блоки X получили бы сиротами, потому что 2016 блоков, которые X находятся выше текущего правила Y.

11 мая 2017, 12:57:06 AM	# 8
jonald_fyookball Сообщения: 1260 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: BillyBobZorton от 11 мая 2017 года, 12:24:59 AM Цитата: jonald_fyookball от 11 мая 2017 года, 12:03:16 AM Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Цитата: jonald_fyookball от 10 мая 2017 г., 11:10:27 PM Мне нравится идея адаптивного размера блока. Я также поддерживаю идею, что способность всегда должна опережать спрос, так что я думаю, что рост должен быть значительно больше, чем это. Я думаю, что астральное делает это в умном способе. Если я прав, то это что-то вроде 20% больше, чем в скользящей средней фактической мощности, используемой. Это обеспечивает блоки держать становится все больше по мере необходимости. Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. Я просто не понимаю, как гибкие схемы размер_блока не годные для использования. Ну, я думаю, что гибкость идет в обоих направлениях - блоки могут получить меньше снова, если пространство не используется. Это красота гибких блоков. Если кто-то хочет использовать blockchain, и платить за него (тратить миллионы), были ли полезны кому-либо сделки, остальное не имеет значения вид. спам одного человека является законным использование другого человека. Но если они платят сборы и шахтеры согласны с этим, я думаю, его хорошо, и мы не должны пытаться сужают размера блока из-за него. Лучше, чтобы получить немного наворотов и сделать спамеры платить за все, что объем, чем постоянно наказывать все остальное с высокими налогами и ограниченной пропускной способностью. " спам одного человека является законным использование другого человека. " Но кто получает выгоду, кроме того парня спамить сеть за счет всех остальных получать их узлы раздутый с безумным количеством данных? Пользователям выигрывают, получая быстрые подтверждения и низкие сборы, поскольку блоки не полностью. котировка Сеть будет расти так много, и узлы будут в конечном итоге кошмар для запуска. Например загрузив blockchain Эфириума с нуля ад, потому что есть некоторые блоки, заполненные спам из-за нападения. Вы должны обойти эти точки или ее практически невозможно загрузить. При этом, вы только повреждая сети на долгий срок, потому что люди не будут беспокоить с загрузкой blockchain. У вас есть точка, что blockchain вздутие может быть проблемой. Это была первоначально причина Satoshi положить предел 1МБ место. Однако, когда он сделал так, блоки были около 1 килобайт. Я согласен, что это, возможно, имеет смысл иметь некоторый предел, так что навороты не могут идти баллистическими, но я не понимаю, что случилось с гибкими пределами. Если вы используете что-то подобное, позволяет сказать, 30-дневная скользящая средняя, а затем блоки должны быть засунуты в течение целого месяца. Это стало бы невероятно дорого ... а деньги пойдут прямо в руки шахтеров, которые имеют дело с ним так или иначе ... так они компенсируются за это. Номера узлы горнодобывающие могут использовать некоторые формы SPV и пропустить раздуваться.

11 мая 2017, 1:36:47 AM	# 9
frodocooper Сообщения: 238 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM Я открыт для экономических и технических аргументов для настройки любого аспекта этого компромиссного предложения, но прямое увольнение в связи с опасениями по теории игр будут удалены на месте, если вы также предполагает усовершенствование предложения по преодолению этих проблем. Конструктивная обратная связь, не торпеды. Статический предел, по моему твердому убеждению, недальновидно. Это не решает проблемы многие до сих пор имеют о на цепочке сделки становятся экономически невыгодными. Многие утверждают, что это просто вопрос заговора "холдинг SegWit назад", Но пока это не без причины, я не полностью убежден, что аргумент и считают, что замок в гарантии о приблизит размером блока активации SegWit. Я утверждаю, что алгоритмический процесс, основанный на реальное время сетевого трафика намного лучше во всех отношениях, чем установленный "неуклюжий хак" Менталитет собирание произвольное целое число от разреженного воздуха, пинать банку вниз по дороге, ожидая "разрешение" от разработчиков и спуска в ту же дурацкую войну каждый раз, когда вопрос о пропускной способности возникающий в будущем. Кроме того, один раз hardfork гораздо лучше, чем несколько hardforks каждый раз мы начинаем приближается еще один новый и произвольный статический предел. И к сожалению, нет резких колебаний давления платы таким образом. Все гладко, последовательно и, по большей части, предсказуемой, что то, что мы должны все хотим Bitcoin быть. Давление Манометры Предложение плата в сочетании с движением, чтобы определить, является ли увеличение, уменьшение или отсутствие изменений вообще не требуется. Сильное внимание было уделено ограничением роста (и позволяет уменьшается), чтобы не достичь уровня, при котором узлы будут бороться с использованием полосы пропускания. Состояние платы также помогает предотвратить игровую систему. Эта последняя итерация предложения, в значительной степени основана на BIP106 включает в себя корректировку Уитнессы пространства, чтобы поддерживать соотношение 1: 3 между основанием и свидетелем. SegWit является необходимым условием для этого должно быть активировано: Код: Если более 50% от размера блока, найденного в первом 2016 последнего периода сложности, более 90% MaxBlocksize И (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) ТОГДА BaseMaxBlockSize = BaseMaxBlockSize + 0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize + 0.03MB Иначе, если более 90% от размера блока, найденного в первом 2016 последнего периода сложности, составляет менее 50% MaxBlocksize ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB ELSE Держите же BaseMaxBlockSize и WitnessMaxBlockSize (Кредит Upal Чакраборти для их первоначальной концепции в BIP106) Таким образом, в простом английском языке, крошечные, 0.01MB, корректировка базового размера блока может происходить за каждый период сложности и пропорциональное 0.03MB свидетельству пространства, чтобы поддерживать соотношение 1: 3, но только если: SegWit реализуется Либо имеются достаточно полные блоки, чтобы оправдать увеличение до размера блока, или достаточно пустым, чтобы уменьшить его Есть больше сборов, сгенерированных в последнем период трудности, чем предыдущий, чтобы обеспечить рост, но размер_блок может быть уменьшен независимо от платы, которая будет сдерживать игровую систему Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), база размер_блока бы еще только будет ~ 2.04 MB после 4-х лет. Является ли это компромисс, большинство из нас может получить позади? Цитата: D5000 от 11 мая 2017 года, 12:32:19 AM Я полностью поддерживаю это предложение и надеюсь, что мы можем двигаться вперед с реальным BIP и фактической реализацией на его основе. Я тоже полностью поддерживаю это предложение.

11 мая 2017, 2:21:40 PM	# 10
BillyBobZorton Сообщения: 1036 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: D5000 от 11 мая 2017 года, 12:32:19 AM Я полностью поддерживаю это предложение и надеюсь, что мы можем двигаться вперед с реальным BIP и фактической реализацией на его основе. Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. В этом предложении, он бы лет непрерывного спама для достижения опасного размера блока. Не только mempool спам (как сейчас), сделки должны быть фактически включены в блоки, так что это будет очень дорогостоящей операцией. Вы можете сделать математику: увеличение размера базового блока будет максимум 250 килобайт в год (то есть значительное число относительно квадратичной задачи хеширования), в то время как общий размер блока только может измениться 1 МБ / год. Что мне нравится в отношении последнего предложения (5% за период) является неэкспоненциальна подходом к блоку размера увеличивается. Таким образом, если размер блока становится больше он по-прежнему столь же трудно "спам на размере блока луны", Это будет необходимо изучить и изучены глубоко и рассмотреть все эксплуатационные углы, потому что вы забываете есть люди там с буквальным денежных машин. Злоумышленник, как и сам НБК имеет триллионы долларов на свалку и раздуть сети и держать его на максимуме, так что даже если вы установите лимит, вы бы в конечном итоге с размером блока, что это слишком большой для большинства людей, а затем узлы начнут падать как Soliders в D-Day.

11 мая 2017, 2:33:52 PM	# 11
Carlton Банки Сообщения: 1848 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года. Является ли это компромисс, большинство из нас может получить позади? Для меня, может быть, Но имейте в виду, говоря, 2,04 MB после 4 лет скрывает тот факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете.

11 мая 2017, 2:46:11 PM	# 12
franky1 Сообщения: 1890 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года. Является ли это компромисс, большинство из нас может получить позади? Для меня, может быть, Но имейте в виду, говоря, 2,04 MB после 4 лет скрывает тот факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете. если было бы трудно достичь консенсуса в отношении перехода к динамике .. то его гораздо лучше использовать эту oppertunity объединить segwit и родную пару ключей в том же районе. EG 4mb как для нативного и segwit сидеть в одном блоке Merkle. затем он увеличится на х% за две недели. люди, работающие тесты скорости знают, что на нынешних современных базовых системах (raspberrypi3) и средней скорости интернета 2017 года вместе со всем efficiences начиная с 2009 годом (libsecp256k1) показало, что 8mb является raspberrypi среднего домашнего пользователя безопасно .. поэтому, начиная с 4MB одного блока Merkle будет считаться более безопасным. и запомни даже с правилом 4Mb НЕ означает, бассейны будут делать 4MB мгновенно .. так же, как они не делают 1Mb блоков в 2009-2014 даже с 1mb допустимого буфера .. бассейны сделали свой собственный анализ риска и сделать свои собственные льготные приращений ниже консенсуса.

11 мая 2017, 2:49:53 PM	# 13
Qartada Сообщения: 574 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Ну один из ключевых аргументов против растущего в том, что размере блока может привести к централизации узлов. Тем не менее, объем данных, что требуется, чтобы запустить узел должен измеряется относительно того, насколько данные люди готовы использовать или сколько данных люди часто имеют на своих устройствах. Предложение с разнообразными размерами блоков, которая ограничена должным образом, как этот, вероятно, не будет на самом деле привести к снижению пользователей узла, просто потому, что скорость, с которой размеры жестких дисков людей обычно возрастает, скорее всего, чтобы соответствовать или превышать скорость, при которой blockchain растет. Таким образом, это хорошо в ближайщем будущем решение, до того, когда закон Мура перестанет быть возможным применить - когда это произойдет, будет более чем достаточно места в блоках для LN быть реализованы и для большинства пользователей Bitcoin, чтобы использовать его с onchain транзакций для отправки больше Bitcoin и частные каналы которые часто используются в качестве хорошо.

11 мая 2017, 5:53:10 PM	# 14
DooMAD Сообщения: 1456 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: BillyBobZorton от 10 мая 2017 г., 11:34:27 PM Как различать реальный спрос со стороны спроса со спамом? Если кто-то, как Веры решают сбросить миллионы долларов от спама-операций, с тем чтобы сделать blockchain огромными, как вы это остановить? так как если он автоматизирован, то blockchain будет просто адаптироваться к этому требованию (даже если его подделка) централизованные узлы в результате. Я просто не понимаю, как гибкие схемы размер_блока не годные для использования. Как d5000 упоминалось, на его долю приходится только для сделок, которые сделали его в предыдущих блоков, она должна была бы быть спамом с здоровенный плата для подсчета. Кроме того, условия установлены так, что размер_блока может только увеличиться, если общая сумма сборов ТХ, собранные в последний период дифф выше, чем последний дифф период, поэтому им придется платить больше и больше с течением времени, если они хотят сохранить спам , в противном случае он остается на том же уровне и не увеличивается. И даже если они не удалось достичь такого уровня непрерывного спама в течение нескольких последовательных двухнедельных, они получают дополнительный .01MB каждый раз, когда за их усилия и, как только они не могут поддерживать атаку, он будет падать снова. Спам никогда не может быть предотвращено, но может быть в значительной степени disincentivised, что это предложение делает хорошо. Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года. Является ли это компромисс, большинство из нас может получить позади? Для меня, может быть, Но имейте в виду, говоря, 2,04 MB после 4 лет скрывает тот факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете. В самом деле, но это только если увеличение фактически достигается каждый дифф период. Порог устанавливается достаточно высоким, если по крайней мере, половине из блоков в этот период должна быть по крайней мере 90% от полного, чтобы претендовать на увеличение (но опять же, если люди хотят, чтобы запросить эти цифры, мы можем смотреть на что коллективно и дискуссионные плюсы и минусы). В действительности это может занять гораздо больше времени, чем 4 лет, чтобы достичь такого рода размера. Я уверен, что многие бассейны по-прежнему будет добыча в основном пустые блоки только, чтобы захватить награду, так из-за того, что и другие факторы, там, вероятно, не будет увеличиваться каждый раз. Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате. И, наконец, и, очевидно, даже если максимальные увеличения размера, рудничный не обязательно должен заполнить его. Они все еще довольно радушны освободить <1MB блоки после увеличения, если это их предпочтения.

11 мая 2017, 6:32:13 PM	# 15
Carlton Банки Сообщения: 1848 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM Цитата: Carlton банков на 11 мая 2017 года, 2:33:52 PM Цитата: DooMAD от 10 мая 2017 года, 9:00:29 PM Математически, предполагая, что среднее время блокирования ~ 10 минут, есть максимум ~ 104 корректировки сложности в течение периода 4 года, так что даже если произошло увеличение +0,01 МБ в каждой трудности вновь целей (шансы которого пренебрежимо малы ), то база размер_блока все равно будет только ~ 2,04 MB через 4 года. говоря 2,04 MB после 4 лет сокрытия того факт, что реальная общая размер_блока будет 8.16MB, когда вы включаете подписи в блоках свидетелей, Segwit является частью этой сделки вы предлагаете. В действительности это может занять гораздо больше времени, чем 4 лет, чтобы достичь такого рода размера. Я уверен, что многие бассейны по-прежнему будет добыча в основном пустые блоки только, чтобы захватить награду, так из-за того, что и другие факторы, там, вероятно, не будет увеличиваться каждый раз. Это не убедительны всех. Помните, что трудности редко падает, и мы могли видеть взрыв в росте добычи, когда реальные корпоративные деньги начнут поступать в горнодобывающей промышленность. Все рост, BTC обменный курс, темп роста транзакций, размер_блока рост и акт роста hashrate синергически друг с другом, они все агрегат в более широком положительной обратной связи. Я понимаю, что даже это будет иметь незначительное влияние на возможном росте блочных мы в конечном итоге с (скажет 1,04 МБ в год + факторинг в 0,2 МБ макс для < 2 недели в период сложности), но это не означает, что ваши консервативные ожидания были больше правильно, просто, что они не влияют на общий результат слишком много, что приводит меня к следующему пункту .... Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате. Возможно Вы правы. Так зачем это делать? Мы можем быть прямо о том, что 1.04 MB в год не будет раздражать маленькие блокаторы слишком много, но это не будет удовлетворять требованиям больших блокаторов на всех. Или в том, что почему это компромисс? Все одинаково несчастными Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM И, наконец, и, очевидно, даже если максимальные увеличения размера, рудничный не обязательно должен заполнить его. Они все еще довольно радушны освободить <1MB блоки после увеличения, если это их предпочтения. Опять же, мы расстаемся здесь. Если есть разбивка в парадигмах роста технологических факторов, определяющих верхние пределы емкости сети в Bitcoin (т.е. медианы пропускной способность интернет, средние затраты на складских помещений и средние общие вычислительные возможности), то мы вернемся сюда на bitcointalk. орг дежурные около 2027 года, рассуждая о том, где и как размер_блок должен остановиться, вместо того, как она должна расти. Бесконечный рост потребности бесконечных ресурсов, и я не заметил, решение бесконечной эмиссии ресурсов в этом предложении. Может быть, время решит, что, но это одна большая, может быть, и не инженерный подход на всех. Желающих вещи далеко плохо инженерии, должен быть квалифицирован верхний предел округлить это предложение от, в противном случае вы не можете ожидать, что она будет рассматриваться как полное предложение.

11 мая 2017, 7:30:15 PM	# 16
DooMAD Сообщения: 1456 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: Carlton банков на 11 мая 2017 года, 6:32:13 PM Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM Я уверен, что достаточно общий размер blockchain не будет испытывать какой-либо значительный рост в результате. Возможно Вы правы. Так зачем это делать? Мы можем быть прямо о том, что 1.04 MB в год не будет раздражать маленькие блокаторы слишком много, но это не будет удовлетворять требованиям больших блокаторов на всех. Или в том, что почему это компромисс? Все одинаково несчастными Довольно много, хе. Моя надежда состоит в том, что все участники по крайней мере, считают, что их голос будет услышан этот путь. С двух полярных лагерями орущих друг на друг, это действительно не кажется, что обе стороны были фактически признать, что другие говорили. Цитата: Carlton банков на 11 мая 2017 года, 6:32:13 PM Цитата: DooMAD от 11 мая 2017 года, 5:53:10 PM И, наконец, и, очевидно, даже если максимальные увеличения размера, рудничный не обязательно должен заполнить его. Они все еще довольно радушны освободить <1MB блоки после увеличения, если это их предпочтения. Опять же, мы расстаемся здесь. Если есть разбивка в парадигмах роста технологических факторов, определяющих верхние пределы емкости сети в Bitcoin (т.е. медианы пропускной способность интернет, средние затраты на складских помещений и средние общие вычислительные возможности), то мы вернемся сюда на bitcointalk. орг дежурные около 2027 года, рассуждая о том, где и как размер_блок должен остановиться, вместо того, как она должна расти. Бесконечный рост потребности бесконечных ресурсов, и я не заметил, решение бесконечной эмиссии ресурсов в этом предложении. Может быть, время решит, что, но это одна большая, может быть, и не инженерный подход на всех. Желающих вещи далеко плохо инженерии, должен быть квалифицирован верхний предел округлить это предложение от, в противном случае вы не можете ожидать, что она будет рассматриваться как полное предложение. Я не знал, что конкретный прецедент был создан. BIP 100, 101 и 106 не указан верхний предел. Хотя это правда, что сообщество не считает их жизнеспособные предложения, они, конечно, не считают их неполными либо. Это звучит как больше личных предпочтений с вашей стороны, а не стандарт сообщества, что представляет собой "полный", Если мы должны смотреть на укупорки его в будущем, то мы можем смотреть на это. Любая попытка упреждения лимита сейчас догадки в лучшем случае, а также открывает двери для будущих hardforks. Укупорки от будет мягкой вилкой. Я не буду увольнять шапку прямо, но мне нужно больше, чем просто один человек говорил мне, что нужно один. В соответствии с ФП, у меня есть довольно сильное отвращение к произвольным статическим пределам, но это только мое личное предпочтение.

11 мая 2017, 8:11:45 PM	# 17
Carlton Банки Сообщения: 1848 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Речь не идет о прецедентах. Или о том, как много людей говорят это (серьезно?) Речь идет о дизайне. Речь идет о логике. Не говорить с нами о том, что все уже думает, или сказал, говорить о том, что имеет смысл. Satoshi не сделал бы Bitcoin, если бы он слушал все предыдущие человек, которые сказали, что децентрализованная криптовалюта была неразрешимая проблемой, вы не решить проблемы проектирования, делая вид проблемы не существует.

11 мая 2017, 8:14:10 PM	# 18
arklan Сообщения: 1526 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Я walways предпочтение динамичного самого размера блока. я поддерживаю это предложение тоже.

11 мая 2017, 10:56:42 PM	# 19
d5000 Сообщения: 1582 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: BillyBobZorton от 11 мая 2017 года, 2:21:40 PM Злоумышленник, как и сам НБК имеет триллионы долларов на свалку и раздуть сети и держать его на максимуме, так что даже если вы установите лимит, вы бы в конечном итоге с размером блока, что это слишком большой для большинства людей, а затем узлы начнут падать как Soliders в D-Day. Если эти "деньги сделать машины" хотят уничтожить Bitcoin, они могут сделать это сейчас. 51% атака стоит около 600-700 миллионов долларов в этот момент. PBOC не будет иметь никаких проблем с этим. Так почему пройти нелегкий путь и спам в сеть Bitcoin в течение 10 лет, чтобы достичь ~ 3,5 MB базового размера, если вы можете уничтожить его мгновенно? Поскольку рост блочного - как уже было сказано - линейно, я думаю, что значение этого вектора атаки можно пренебречь. @DooMAD: У меня есть, однако, небольшое предложение обновления: + Изменить Код: (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) в Код: (TotalTxFeeInLastDifficulty > средний (TotalTxFee в периоды прошлого X сложности)) с X = 4 или более, я бы предложил X = 8. Причина заключается в том, что totaltxfee может иметь колебания. Таким образом, злоумышленник / группа, которая хочет, чтобы увеличить размер блока может производить "полный блок спам атаки" в период сложности только после периода с относительно низким TotalTxFee. Что касается верхней крышки блочной (@Carlton Banks): В предыдущих предложениях мы обсуждали это имело смысл для меня, потому что предлагаемый рост размера блока был экспоненциальным (+-% является последним я помню), и это могло бы привести к неконтролируемой ситуации в будущем. Я думаю, что это предложение является достаточно консервативным, что такая верхней крышка не имеет значения. Я также не полностью против этого.

12 мая 2017, 2:01:46 PM	# 20
DooMAD Сообщения: 1456 Цитировать по имени цитировать ответ	Re: SegWit + Variable и Adaptive (но очень консервативном) Blockweight Предложение Цитата: D5000 от 11 мая 2017 г., 10:56:42 PM @DooMAD: У меня есть, однако, небольшое предложение обновления: + Изменить Код: (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) в Код: (TotalTxFeeInLastDifficulty > средний (TotalTxFee в периоды прошлого X сложности)) с X = 4 или более, я бы предложил X = 8. Причина заключается в том, что totaltxfee может иметь колебания. Таким образом, злоумышленник / группа, которая хочет, чтобы увеличить размер блока может производить "полный блок спам атаки" в период сложности только после периода с относительно низким TotalTxFee. Исключительные рассуждения, я полностью на борту с этим. Я надеялся, что мы могли бы найти улучшения, которые помогут поднять антистимулы на спам, и это абсолютно квалифицируется. OP обновляется. Благодарю. Цитата: Carlton банков на 11 мая 2017 года, 8:11:45 PM Речь не идет о прецедентах. Или о том, как много людей говорят это (серьезно?) Речь идет о дизайне. Речь идет о логике. Не говорить с нами о том, что все уже думает, или сказал, говорить о том, что имеет смысл. Satoshi не сделал бы Bitcoin, если бы он слушал все предыдущие человек, которые сказали, что децентрализованная криптовалюта была неразрешимая проблемой, вы не решить проблемы проектирования, делая вид проблемы не существует. Может быть, это только у меня, но я честно не понимаю, что это логично о принятии удара в темноте теперь никак не точно прогнозировать будущие потребности. Особенно, если это удар в темноте легко может привести к другому спорному дискуссии позже. Если кто-то может убедить меня, почему потенциальная жесткая вилку позже как-то лучше, чем в равной степени потенциальной мягкая вилка позже, я пересмотреть свою позицию. Цитата: franky1 от 11 мая 2017 года, 12:32:50 AM также Код: ТОГДА BaseMaxBlockSize = BaseMaxBlockSize -0.01MB WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB это вызвало бы бесхозные риски, когда узлы пересканировать блок-цепь если блоки 2016 были X, то в следующий раз 2016 блоки были у (= X-0.01) с правилами, являющихся Y .. все блоки X получили бы сиротами, потому что 2016 блоков, которые X находятся выше текущего правила Y. Есть ли какой-то обходной путь или исправления, еще позволит нам уменьшить динамически ограничивая при этом потенциал для детей-сирот? У меня есть сомнения в достаточной квалифицированное может быть достигнуто за предложение, если максимальные размеры может только возрастать. Это должно быть возможно уменьшить, если есть отсутствие спроса.

Заголовок