Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины?

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

Некоторый фон:

Я рассматривал проблему вилки разрешения, когда один блок явно лучше, чем другой.
Более конкретно, я считаю вилку с п различными цепями, ранжированных от 1 до п (1, ..., к, ..., п). Цепь к будет доминировать цепи J, если к<к.
Узлы соединяются друг с другом в произвольном порядке. Если узел с цепью J подключается к узлу с цепью к, где к
В этой установке, время, необходимая для решения вилки увеличения логарифм числа конкурирующих цепей. Смотрите ниже картинки. Оно происходит от решения ряда итерационных дифференциальных уравнений. Весело.

Следующий шаг будет добавление блоков заездов, которые вызывают цепи 2, ..., к, ..., п перескочить в положение # 1.
Быстрее блок заезды = медленнее консенсус, как всегда, но я думаю, что тай-брейк для цепей одинаковой длины ускоряет вещи.

Есть ли где я могу найти более глубокий анализ по этому вопросу?

Я думал, что это уже похоже на общее время работы на самом деле делается (сумма трудностей блоков, а не только сумму min_difficulty) вместо просто длины цепи?

Цитата: Sukrim от 03 декабря 2013 года, 9:52:40 AM

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

Здравствуй!

Цитата: cunicula 03 декабря 2013, 10:54:51 AM

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

Но что происходит, когда третий блок приходит с большим трудом?

Как это:

Цепь 1: ... + A1 + B1, работа (A1) + работа (B1) = X
Цепь 2: ... + A2 + B2, работа (А2) + работа (В2) = Х

cunicula решает для цепи 2, так как работы (В2) > работа (B1)

Затем блоки С1 ^ С2 прибывают, и работы (А1) + работа (В1) + работа (С1) > работа (А2) + работа (В2) + работа (С2). Что делать, если тогда?

Цитата: readerbtc 03 декабря 2013, 11:11:33 AM

Здравствуй!

Цитата: cunicula 03 декабря 2013, 10:54:51 AM

Но что происходит, когда третий блок приходит с большим трудом?

Как это:

Цепь 1: ... + A1 + B1, работа (A1) + работа (B1) = X
Цепь 2: ... + A2 + B2, работа (А2) + работа (В2) = Х

cunicula решает для цепи 2, так как работы (В2) > работа (B1)

Затем блоки С1 ^ С2 прибывают, и работы (С1) > работать (С2). Что делать, если тогда?

Отредактированный свой пост, чтобы отразить мое предложение более точно.
Затем вы выбираете C1.

Это не попадает в точку, хотя. Если вы двигаетесь к консенсусу в ожидании нового блока, вероятность обнаружения как C1 и C2 и продолжения гонки будет уменьшаться. Вместо этого, шахтеры будут сосредоточены на создании C2. Не обращая внимания на парня, который чеканили В1, шахтер соблюдение этого правила должно быть равновесие Нэша. Добыча C1 будет означать обновление 2 блоков вместо 1. Это приведет к увеличению задержки и риск создания сиротой.

Текущее правило:
1) выбрать цепь с высоким суммированного трудом
2) если две цепи были равны суммируется трудности, выбрать в зависимости от того вы видели первый.

В основном (2) означает отказаться от консенсуса, пока новый блок не найден.

Модификация я предлагаю относится только к 2. Это брейк

Cunicula версия 2), если две цепи были равны суммируется трудности, выбрать в зависимости от того один имеет больше работы в последнее время обнаружены блока.

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

Цитата: cunicula 03 декабря 2013, 12:53:18 PM

Если вы двигаетесь к консенсусу в ожидании нового блока, вероятность обнаружения как C1 и C2 и продолжения гонки будет уменьшаться. Вместо этого, шахтеры будут сосредоточены на создании C2. Не обращая внимания на парня, который чеканили В1, шахтер соблюдение этого правила должно быть равновесие Нэша. Добыча C1 будет означать обновление 2 блоков вместо 1. Это приведет к увеличению задержки и риск создания сиротой.

Текущее правило:
1) выбрать цепь с высоким суммированного трудом
2) если две цепи были равны суммируется трудности, выбрать в зависимости от того вы видели первый.

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

Цитата: cunicula 03 декабря 2013, 12:53:18 PM

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

для текущей системы.

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

Цитата: cunicula 03 декабря 2013, 12:53:18 PM

Кстати, добавление тай-брейке является обратная совместимость изменений.

Так удалить его.

Я имею в виду, шахтер мог решить "Я думаю, что лучше для меня, помоему на вершине B1, даже если все остальные добыча на вершине B2" редактировать исходный код и перекомпилировать. А затем найти С1 длиннее С2, или даже раньше люди приходят с любым C2.

Если много людей делают это, мы можем вернуться к ситуации сегодня: де-факто правило, которое я описал становится новым равновесием Нэша.

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

Некоторые из них предложили транслировать заголовки блоков ниже POW, когда обнаружили, что-то вроде 1/64-я текущей сложности. Если шахтеры перешли на цепь с большинством заголовков POW он должен быстро переместить сеть в одной цепи.

Любая схема, которая позволяет вредоносный шахтер, который удерживает блоки, чтобы определить, если их цепь будет выбрана над другим может игру сети аналогично тому, что описывается этой недавней работа http://arxiv.org/pdf/1311.0243v1.pdf

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

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

Цитата: QuinnHarris от 04 декабря 2013 года, 1:08:00 AM

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

#дать согласие

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

Цитата: cunicula 04 декабря 2013, 11:52:51 AM

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

Грустно читать это. Я действительно пытался помочь. Я провел некоторое время, думая об альтернативных решениях проблемы. Честно говоря, до сих пор я только не думал о еще более сильном аргументе против tiebreaking, но ...

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

Цитата: readerbtc от 04 декабря 2013 года, 12:18:59 PM

Цитата: cunicula 04 декабря 2013, 11:52:51 AM

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

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

Я буду ждать.

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

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

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

Я предложил следующий подход, принимая во внимание нынешние трудности в списке рассылки DEV.

Если предположить,
а = хеш блока А
б = хэш-блока В
Трудность = ток трудность такой, что А < трудности и б < трудность

Код:

uint256 choose_block (uint256 а, б uint256, uint256 сложности)

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

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

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

У меня такой же вопрос.

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

Таким образом, очевидно, любой брейку нужен будет применяться только при наличии два цепей одинаковой длины. С учетом такими же длинами, оба имеют один и тот же совокупный вес как Nbits одинакова для обоего цепей для всех блоков, поэтому сумма PoW будет то же самое. В связи с этим, более длинной цепью будет иметь больший вес, чем цепи более короткую цепь.

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

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

Сеть и узлы являются относительно стабильными, мы не tiebreaking между бесхозной или нападениями цепи десятками блоков длиной. В настоящее время правила, где большинство решает "цепь я услышал о первом это один я доверяю" это хороший способ решить блоки. Это не редкость для шахтеров, чтобы опубликовать блок решения в течение нескольких секунд друг от друга из-за задержки в сеть; сироты происходят все время. "Во-первых, чтобы получить блок опубликован, выигрывает" Таким образом, логически справедливый и создает наименее реорганизацию;.

Цитата: QuinnHarris от 04 декабря 2013 года, 1:08:00 AM

Некоторые из них предложили транслировать заголовки блоков ниже POW, когда обнаружили, что-то вроде 1/64-я текущей сложности. Если шахтеры перешли на цепь с большинством заголовков POW он должен быстро переместить сеть в одной цепи.

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

Для детерминированнога добычи, вы могли бы использовать что-то вроде

weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой

Выберите блок с наибольшим весом.

Это делает его так, что шахтер не может определить, будут ли они выиграть галстук, в преддверии 2-го блока был найден. Это сохраняет стимул для трансляции как можно быстрее.

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

Цитата: TierNolan от 02 мая 2016 года, 5:52:29 PM

Если шахтеры могли вещать промахи, то сеть должна быстро сходиться на одной из 2-х блоков, когда есть связь. Даже если некоторые шахтеры не транслируются, те, которые делают бы дать более быструю сходимость.

Я не успокаивать понимаю. Вы имеете в виду сеть может обрабатывать галстук?

Цитата: TierNolan от 02 мая 2016 года, 5:52:29 PM

Для детерминированнога добычи, вы могли бы использовать что-то вроде

weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой

Выберите блок с наибольшим весом.

Это делает его так, что шахтер не может определить, будут ли они выиграть галстук, в преддверии 2-го блока был найден. Это сохраняет стимул для трансляции как можно быстрее.

Когда две цепи имеют одинаковую длину, с высокой степенью вероятности, что они имеют те же "сумма (все блоки в галстуке)",

Так, по вашей формуле "weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой", Критическая часть, кажется, исходит из хэш-значения главы цепи (т.е. block_n в вашей формуле).

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

Наоборот, если hash_block_n искусителя мал, он, кажется, противник имеет мало стимулов для трансляции. Я не понимаю, как скорость вещать блок может повлиять на результат.

Цитата: Tracy_Hu 15 февраля 2017 года, 6:38:12 AM

Я не успокаивать понимаю. Вы имеете в виду сеть может обрабатывать галстук?

Если два или более блоков, которые связаны, шахтеры могли бы транслировать заголовки для детей блоков, которые практически соответствуют трудностям (например 1/64 части работы, необходимой для реального блока).

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

Мини-блоки не должны быть сохранены и могут быть отброшены после того, как следующий блок будет найден.

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

котировка

Моды функция означает, что он обтекает, сумма (все блоки в галстуке) эффективно повторно рандомизирует порядок, когда новый блок найден.

У вас есть столько же шансы на победу с высоким значением хеша как низкое значение хэша.

3 декабря 2013, 9:44:14 AM	# 1
cunicula Сообщения: 798 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Похоже, что даже массивные вилки могут быть решены быстро, если существует какое-то правило для выбора между цепями одинаковой длины. Почему Bitcoin обрабатывает все эти цепи в качестве эквивалента вместо наложения ничьи правила? Есть ли основания для этого? Некоторый фон: Я рассматривал проблему вилки разрешения, когда один блок явно лучше, чем другой. Более конкретно, я считаю вилку с п различными цепями, ранжированных от 1 до п (1, ..., к, ..., п). Цепь к будет доминировать цепи J, если к<к. Узлы соединяются друг с другом в произвольном порядке. Если узел с цепью J подключается к узлу с цепью к, где к В этой установке, время, необходимая для решения вилки увеличения логарифм числа конкурирующих цепей. Смотрите ниже картинки. Оно происходит от решения ряда итерационных дифференциальных уравнений. Весело. Следующий шаг будет добавление блоков заездов, которые вызывают цепи 2, ..., к, ..., п перескочить в положение # 1. Быстрее блок заезды = медленнее консенсус, как всегда, но я думаю, что тай-брейк для цепей одинаковой длины ускоряет вещи. Есть ли где я могу найти более глубокий анализ по этому вопросу?

3 декабря 2013, 9:52:40 AM	# 2
Sukrim Сообщения: 2212 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Получил 1806 Биткоинов Реальная история. Я думал, что это уже похоже на общее время работы на самом деле делается (сумма трудностей блоков, а не только сумму min_difficulty) вместо просто длины цепи?

3 декабря 2013, 10:54:51 AM	# 3
cunicula Сообщения: 798 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: Sukrim от 03 декабря 2013 года, 9:52:40 AM Я думал, что это уже похоже на общее время работы на самом деле делается (сумма трудностей блоков, а не только сумму min_difficulty) вместо просто длины цепи? Да, но если две цепей имеют равные суммированные трудности, они рассматриваются как равные. Это не имеет смысла для меня. Почему бы не выбрать один из двух цепочек, основанных на некоторой произвольной метрике? Например, вы могли бы использовать работу, представленную на последнем блоке, как на тай-брейке. Тогда вам не придется ждать, пока следующий блок не прибывает, чтобы узнать, какая цепь, скорее всего, победит.

3 декабря 2013, 11:11:33 AM	# 4
readerbtc Сообщений: 54 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Здравствуй! Цитата: cunicula 03 декабря 2013, 10:54:51 AM Например, вы могли бы использовать работу, представленную на последнем блоке, как на тай-брейке. Тогда вам не придется ждать, пока следующий блок не прибывает, чтобы узнать, какая цепь, скорее всего, победит. Но что происходит, когда третий блок приходит с большим трудом? Как это: Цепь 1: ... + A1 + B1, работа (A1) + работа (B1) = X Цепь 2: ... + A2 + B2, работа (А2) + работа (В2) = Х cunicula решает для цепи 2, так как работы (В2) > работа (B1) Затем блоки С1 ^ С2 прибывают, и работы (А1) + работа (В1) + работа (С1) > работа (А2) + работа (В2) + работа (С2). Что делать, если тогда?

3 декабря 2013, 12:53:18 PM	# 5
cunicula Сообщения: 798 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: readerbtc 03 декабря 2013, 11:11:33 AM Здравствуй! Цитата: cunicula 03 декабря 2013, 10:54:51 AM Например, вы могли бы использовать работу, представленную на последнем блоке, как на тай-брейке. Тогда вам не придется ждать, пока следующий блок не прибывает, чтобы узнать, какая цепь, скорее всего, победит. Но что происходит, когда третий блок приходит с большим трудом? Как это: Цепь 1: ... + A1 + B1, работа (A1) + работа (B1) = X Цепь 2: ... + A2 + B2, работа (А2) + работа (В2) = Х cunicula решает для цепи 2, так как работы (В2) > работа (B1) Затем блоки С1 ^ С2 прибывают, и работы (С1) > работать (С2). Что делать, если тогда? Отредактированный свой пост, чтобы отразить мое предложение более точно. Затем вы выбираете C1. Это не попадает в точку, хотя. Если вы двигаетесь к консенсусу в ожидании нового блока, вероятность обнаружения как C1 и C2 и продолжения гонки будет уменьшаться. Вместо этого, шахтеры будут сосредоточены на создании C2. Не обращая внимания на парня, который чеканили В1, шахтер соблюдение этого правила должно быть равновесие Нэша. Добыча C1 будет означать обновление 2 блоков вместо 1. Это приведет к увеличению задержки и риск создания сиротой. Текущее правило: 1) выбрать цепь с высоким суммированного трудом 2) если две цепи были равны суммируется трудности, выбрать в зависимости от того вы видели первый. В основном (2) означает отказаться от консенсуса, пока новый блок не найден. Модификация я предлагаю относится только к 2. Это брейк Cunicula версия 2), если две цепи были равны суммируется трудности, выбрать в зависимости от того один имеет больше работы в последнее время обнаружены блока. Это означает, что всегда будет уникальный консенсус цепи, даже при сравнении двух цепей с одинаковой суммированного трудом. Я понимаю, что это не является большой проблемой для Bitcoin. Я просто хочу знать, если есть основания для нынешней системы. Кстати, добавление тай-брейке является обратная совместимость изменений.

3 декабря 2013, 1:16:56 PM	# 6
readerbtc Сообщений: 54 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: cunicula 03 декабря 2013, 12:53:18 PM Если вы двигаетесь к консенсусу в ожидании нового блока, вероятность обнаружения как C1 и C2 и продолжения гонки будет уменьшаться. Вместо этого, шахтеры будут сосредоточены на создании C2. Не обращая внимания на парня, который чеканили В1, шахтер соблюдение этого правила должно быть равновесие Нэша. Добыча C1 будет означать обновление 2 блоков вместо 1. Это приведет к увеличению задержки и риск создания сиротой. Текущее правило: 1) выбрать цепь с высоким суммированного трудом 2) если две цепи были равны суммируется трудности, выбрать в зависимости от того вы видели первый. Я думаю, что я получил его. Как я вижу, в нынешней системе, де-факто Правило тай-брейк является "шахты на верхней части блока от шахтера, который ставит больше усилий на получение его / ее блоков по сети, любыми средствами, он / она имеет, как и увеличения пропускной способности, хорошие настройки сети для уменьшения времени ожидания, более мелкие блоки и т.д.", Цитата: cunicula 03 декабря 2013, 12:53:18 PM Я понимаю, что это не является большой проблемой для Bitcoin. Я просто хочу знать, если есть обоснование для текущей системы. Может быть, де-факто править я писал в предыдущем абзаце, является намеренным, давайте посмотрим, что говорят другие. Цитата: cunicula 03 декабря 2013, 12:53:18 PM Кстати, добавление тай-брейке является обратная совместимость изменений. Так удалить его. Я имею в виду, шахтер мог решить "Я думаю, что лучше для меня, помоему на вершине B1, даже если все остальные добыча на вершине B2" редактировать исходный код и перекомпилировать. А затем найти С1 длиннее С2, или даже раньше люди приходят с любым C2. Если много людей делают это, мы можем вернуться к ситуации сегодня: де-факто правило, которое я описал становится новым равновесием Нэша.

4 декабря 2013, 1:08:00 AM	# 7
QuinnHarris Сообщений: 16 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Там на самом деле не разумное понятие больше работы на одном блоке. Меньшее доказательство работы хэш-значения не означает, что шахтер работал тяжелее, просто так, чтобы приземлиться на это значение. Все выходные значения имеют одинаковую вероятность, но чем больше сеть, тем меньше сложность хеш-выходы будут приняты. При подавляющем большинстве случаев будет ожидать каждый блок в равных цепи длины, чтобы иметь ту же трудность. Некоторые из них предложили транслировать заголовки блоков ниже POW, когда обнаружили, что-то вроде 1/64-я текущей сложности. Если шахтеры перешли на цепь с большинством заголовков POW он должен быстро переместить сеть в одной цепи. Любая схема, которая позволяет вредоносный шахтер, который удерживает блоки, чтобы определить, если их цепь будет выбрана над другим может игру сети аналогично тому, что описывается этой недавней работа http://arxiv.org/pdf/1311.0243v1.pdf Я думаю, что детерминированный выбор блоков делает этот тип атаки еще более проблематичными, поскольку он устраняет необходимость злонамеренного шахтера распространять свой блок быстрее, чем конкурирующий блок. Но я не совсем уверен в этом. Нужно думать, что это через больше. Это может быть сложно понять, любая схема вы думаете, чтобы исправить одну проблему, кажется, вызывает другую.

4 декабря 2013, 11:09:03 AM	# 8
readerbtc Сообщений: 54 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: QuinnHarris от 04 декабря 2013 года, 1:08:00 AM Я думаю, что детерминированный выбор блоков делает этот тип атаки еще более проблематичными, поскольку он устраняет необходимость злонамеренного шахтера распространять свой блок быстрее, чем конкурирующий блок. #дать согласие

4 декабря 2013, 11:52:51 AM	# 9
cunicula Сообщения: 798 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Грустно видеть дискуссионные вырождаются в более эгоистичный горнорудной нонсенс. Рассмотрим поток закрыт.

4 декабря 2013, 12:18:59 PM	# 10
readerbtc Сообщений: 54 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: cunicula 04 декабря 2013, 11:52:51 AM Грустно видеть дискуссионные вырождаются в более эгоистичный горнорудной нонсенс. Рассмотрим поток закрыт. Грустно читать это. Я действительно пытался помочь. Я провел некоторое время, думая об альтернативных решениях проблемы. Честно говоря, до сих пор я только не думал о еще более сильном аргументе против tiebreaking, но ... Я видел на другой вами нити намерение было решить эту проблему также для корректуры из-пакета монет. Я стараюсь думать о том, что слишком.

4 декабря 2013, 2:45:48 PM	# 11
cunicula Сообщения: 798 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: readerbtc от 04 декабря 2013 года, 12:18:59 PM Цитата: cunicula 04 декабря 2013, 11:52:51 AM Грустно видеть дискуссионные вырождаются в более эгоистичный горнорудной нонсенс. Рассмотрим поток закрыт. Грустно читать это. Я действительно пытался помочь. Я провел некоторое время, думая об альтернативных решениях проблемы. Честно говоря, до сих пор я только не думал о еще более сильном аргументе против tiebreaking, но ... Я видел на другой вами нити намерение было решить эту проблему также для корректуры из-пакета монет. Я стараюсь думать о том, что слишком. Не беспокойтесь об этом. Ничего личного. Я просто долго спорил против эгоистического добычи как практический интерес и не хочу, чтобы вернуться аргументом здесь. Я выложу новую тему, когда я добавил в добыче новых блоков в модели. Я сделал некоторые успехи на этом, но все еще предстоит проделать большую работу.

4 декабря 2013, 3:35:01 PM	# 12
readerbtc Сообщений: 54 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Я буду ждать.

4 декабря 2013, 5:39:52 PM	# 13
QuinnHarris Сообщений: 16 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Предположение о том, что эгоистичны шахтер может распространяться их блок быстрее, чем остальная часть сети немного надуманный. Но, если выбор детерминированного блока используется, что позволяет эгоистичны шахтеру, чтобы определить, если их блок, скорее всего, будет выбраны по неизвестному пока конкурирующему блоку ситуация становится менее надуманной. Тем не менее, я думаю, что эта проблема может быть фиксированным или, по крайней мере смягчается путем выбора алгоритма выбора блока, который не позволяет эгоистичный шахтер предсказать, если их блок победит. Я предложил следующий подход, принимая во внимание нынешние трудности в списке рассылки DEV. Если предположить, а = хеш блока А б = хэш-блока В Трудность = ток трудность такой, что А < трудности и б < трудность Код: uint256 choose_block (uint256 а, б uint256, uint256 сложности) Учитывая любой хэш вы не можете знать, если какое-либо другое хэш-значение б более или менее вероятно, будет выбрано. Есть много других методов, как исключительная или между 1 бит на хэш-значения хэш-функции. Я сильно ожидать, если используется выбор детерминированный блок, такой подход лучше, чем просто выбирая блок с наименьшим значением хэш-POW или цепи с более низкой суммой военнопленного. Тем не менее, я не думаю, что эгоистична проблема шахтер является достаточно большой, чтобы гарантировать серьезную озабоченность, и я не уверен, какие-либо изменения не будут иметь другие проблемы, такие как способность к мощному противнику, чтобы заставить сеть неосторожно отклонить хорошие блоки.

30 апреля 2016, 10:40:36 PM	# 14
jl777 Сообщения: 1162 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? У меня такой же вопрос. Я думаю, что проблема в том, что если есть показатель, который дает постоянный приоритет тому или иному блоку, то это позволит злоумышленнику создать блок замены для любой точки в прошлом вне какого бы то ни контрольно-пропускного пункта. Таким образом, очевидно, любой брейку нужен будет применяться только при наличии два цепей одинаковой длины. С учетом такими же длинами, оба имеют один и тот же совокупный вес как Nbits одинакова для обоего цепей для всех блоков, поэтому сумма PoW будет то же самое. В связи с этим, более длинной цепью будет иметь больший вес, чем цепи более короткую цепь. Кажется, что ничего не меняя в протоколе, если все горняки только что приняли любую детерминированную метрику для решения цепочек одинаковой длины, то это будет иметь эффект расширения цепи с самой высокой метрикой, даже если блок вносит свой вклад в таком же количество к chainweight. Это не будет большой проблемой, с Bitcoin, из-за его высокой сложности, но для более слабых сетей, имеющих способ свести к минимуму вилы бы хорошо, если нет какой-то ужасный вектор атаки это открывает. Однако, поскольку все шахтеры, используя тот же тай-брейке, в пределах текущего протокола, если стандартизацию на тай-брейке создает векторы атаки, что уже существует

2 мая 2016, 3:58:09 PM	# 15
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Сеть и узлы являются относительно стабильными, мы не tiebreaking между бесхозной или нападениями цепи десятками блоков длиной. В настоящее время правила, где большинство решает "цепь я услышал о первом это один я доверяю" это хороший способ решить блоки. Это не редкость для шахтеров, чтобы опубликовать блок решения в течение нескольких секунд друг от друга из-за задержки в сеть; сироты происходят все время. "Во-первых, чтобы получить блок опубликован, выигрывает" Таким образом, логически справедливый и создает наименее реорганизацию;.

2 мая 2016, 5:52:29 PM	# 16
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: QuinnHarris от 04 декабря 2013 года, 1:08:00 AM Некоторые из них предложили транслировать заголовки блоков ниже POW, когда обнаружили, что-то вроде 1/64-я текущей сложности. Если шахтеры перешли на цепь с большинством заголовков POW он должен быстро переместить сеть в одной цепи. Я сделал это предложение несколько раз. Если шахтеры могли вещать промахи, то сеть должна быстро сходиться на одной из 2-х блоков, когда есть связь. Даже если некоторые шахтеры не транслируются, те, которые делают бы дать более быструю сходимость. Для детерминированнога добычи, вы могли бы использовать что-то вроде weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой Выберите блок с наибольшим весом. Это делает его так, что шахтер не может определить, будут ли они выиграть галстук, в преддверии 2-го блока был найден. Это сохраняет стимул для трансляции как можно быстрее. Я не уверен, что это считается эгоистичной горнорудной атакой. Я думал, что предполагается, что злоумышленник имел более сетевое подключение к жертве? Даже медленнее шахтер выиграет перерыв галстука в этом случае.

15 февраля 2017, 6:38:12 AM	# 17
Tracy_Hu Сообщения: 1 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: TierNolan от 02 мая 2016 года, 5:52:29 PM Если шахтеры могли вещать промахи, то сеть должна быстро сходиться на одной из 2-х блоков, когда есть связь. Даже если некоторые шахтеры не транслируются, те, которые делают бы дать более быструю сходимость. Я не успокаивать понимаю. Вы имеете в виду сеть может обрабатывать галстук? Цитата: TierNolan от 02 мая 2016 года, 5:52:29 PM Для детерминированнога добычи, вы могли бы использовать что-то вроде weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой Выберите блок с наибольшим весом. Это делает его так, что шахтер не может определить, будут ли они выиграть галстук, в преддверии 2-го блока был найден. Это сохраняет стимул для трансляции как можно быстрее. Когда две цепи имеют одинаковую длину, с высокой степенью вероятности, что они имеют те же "сумма (все блоки в галстуке)", Так, по вашей формуле "weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой", Критическая часть, кажется, исходит из хэш-значения главы цепи (т.е. block_n в вашей формуле). Хотя противник не может знать значение хэша конкурирующего блока, но он может знать, кого он владеет. Если хэш-значение его блока очень велика вероятность того, что хэш других блоков может превысить это низко. По вашей формуле, противник имеет преимущество, если две цепи конкурируют. Наоборот, если hash_block_n искусителя мал, он, кажется, противник имеет мало стимулов для трансляции. Я не понимаю, как скорость вещать блок может повлиять на результат.

15 февраля 2017, 12:22:50 PM	# 18
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Почему не Bitcoin использовать tiebreaking rulewhen сравнения цепочек одинаковой длины? Цитата: Tracy_Hu 15 февраля 2017 года, 6:38:12 AM Я не успокаивать понимаю. Вы имеете в виду сеть может обрабатывать галстук? Если два или более блоков, которые связаны, шахтеры могли бы транслировать заголовки для детей блоков, которые практически соответствуют трудностям (например 1/64 части работы, необходимой для реального блока). Какой блок имеет наибольшую поддержку добычи получит больше этих мини-блоков, построенных на нем. Шахтеры должны разорвать связи в пользу блока с большинством мини-блоков. Мини-блоки не должны быть сохранены и могут быть отброшены после того, как следующий блок будет найден. Это означает, что к тому времени, следующий блок найден 100% шахтеров будут строить на том же блоке. Какой блок в галстуке получает первый мини-блок имеет хорошие шансы на победу в конечном итоге правила тай-брейке. К тому времени, 6 мини-блоки транслируются, есть очень высокая вероятность того, все шахтеры согласятся на какой блок помоему на. котировка Когда две цепи имеют одинаковую длину, с высокой степенью вероятности, что они имеют те же "сумма (все блоки в галстуке)", Так, по вашей формуле "weight_block_n = [сумма (все блоки в галстуке) + hash_block_n] моды Целевой", Критическая часть, кажется, исходит из хэш-значения главы цепи (т.е. block_n в вашей формуле). Хотя противник не может знать значение хэша конкурирующего блока, но он может знать, кого он владеет. Моды функция означает, что он обтекает, сумма (все блоки в галстуке) эффективно повторно рандомизирует порядок, когда новый блок найден. У вас есть столько же шансы на победу с высоким значением хеша как низкое значение хэша.

Заголовок