O (1) Распространение блока

Уважаемые все

Я прочитал предложение Гэвина на O (1) блок распространения, доступны здесь:

https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

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

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

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

3. Если blockchain теперь только содержит только новый тип блока, каким образом клиент получить историю всех сделок Bitcoin? Будут ли клиенты должны подключаться к пулу памяти других узлов и как будут реконструированы все исторические операции?

4. Как шахтеры будут стимулы раз награда блока падает, как будто уже не столько дефицита в blockchain, плата может быть слишком низкой, чтобы стимулировать шахтер?

Большое спасибо

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

Цитата: jonny1000 от 11 августа 2014 года, 3:11:18 PM

Это предложение ничего о blockchain не изменится. Чтобы ответить на вопрос 1, вид. Так как найти блок на самом деле просто означает найти достаточно низкий хэш, чтобы сделать блок действительно, все данные для хэша, за исключением могут быть известны по всей сети до того, как блок найден.
В настоящее время, когда шахтер находит блок, они должны отправить весь блок (все операции в блоке + заголовке), все остальные, что труднее, чем больше сделок есть в блоке.
Предложение (упрощенно), чтобы убедиться, что каждый шахтер имеет все транзакции, которые будут включены в блоке заранее. Затем, когда шахтер находит блок, они будут иметь только для отправки заголовка и coinbase сделки (рассказывая всем, кто получает награду блока), и другие шахтеры смогут восстановить блок от этого.
Так как они смогут восстановить блок, единственное отличие состоит в том, что весь блок не передается по сети.

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

Пожалуйста, дайте мне знать, если я получил это прямо сейчас:
Когда шахтер находит блок, они распространяются как фактический блок, и этот новый «мини-блок» по сети. Затем, если другой шахтер получает мини-блок, но не может восстановить полный блок во время, они просто ждут, пока они не получат полный блок. Этот способ шахтеры Incentivized разослать оба типа блоков.

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

Цитата: jonny1000 от 11 августа 2014 года, 6:14:46 PM

Когда шахтер находит блок, они распространяются как фактический блок, и этот новый «мини-блок» по сети.

Нет. Это была моя первая мысль тоже, когда я увидел твит Гэвина, но реальность гораздо более удивительно. Новая концепция IBLT блока является абсолютным и общим гением и заслуживает большого конструктивного вклада с этого форума. Это изменение может начать Bitcoin от того, чтобы быть серьезным конкурентом Western Union (сегодня) к серьезному конкуренту VISA (позже в следующем году).

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

Если вы посмотрите на неподтвержденных операций по blockchain.info, вы видите их mempool отображаются вне. Ваша копия Bitcoin Ядра, которая работает на дому, будет иметь очень похожий набор неподтвержденных транзакций, может быть меньше, так как BC.i имеет гораздо больше соединений равный-равному.

В качестве примера, предполагающее обновление IBLT находится в и работает, и шахтер производит блок IBLT, вы получите его и так делаете BC.i (и другие узлы). IBLT содержит все транзакции, чтобы составить блок - но операции не могут быть прочитаны, потому что (в основном) они накладывая друг на друг. Вы, BC.i, другие, возьмите IBLT и вычесть все операции, которые Вы имеете, которые могут находиться в новом блоке и остались с отличиями. Другой различия для каждого! Тогда вычитаются те, и эти дополнительные операции, которые используются для сборки тот же самый новый блок, а затем начинается регулярная проверка.

IBLT блоки одинакового размера, но блок, который идет в blockchain может быть меньше, или значительно больше, в зависимости от количества ОГО, как обычно.

Не пропустите также https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding

Смотрите также PGP SKS сервера ключей, который использует эффективный набор примирения.

котировка

Это изменение может начать Bitcoin от того, чтобы быть серьезным конкурентом Western Union (сегодня) к серьезному конкуренту VISA (позже в следующем году).

Я поклонник фантазии схем для повышения эффективности (ссылка), но это немного сверху.

Воздействие гораздо скромнее, чем вы думаете, особенно по сравнению с типом переадресации, что p2pool и реле сети bluematt уже делать (отправить блоки без повторяющихся операций, что дальний конец уже знает, у вас есть). Сделки по-прежнему должны быть отправлены и проверены. Это делает избежать накладных расходов на полосу пропускания 2x отправки его снова с блоком, и предельную задержку, которая implies- но так делать простые инструменты, например Реле Мэтта для меня имеет hitrate из "В общей сложности, пропускаются 140004 из 142773 (0.9806055766846673%)" после последней перезагрузки.

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

Цитата: gmaxwell от 12 августа 2014 года, 3:20:39 AM

котировка

Я думаю, что вы как-то занижена прикосновенность предложения Гэвина. Несмотря на то, пропускная способность или использование процессора по-прежнему О (п), распространение блока становится O (1). Так как риск блок осиротения положительно коррелируют с временем распространения блока, это предложение позволит снизить затраты, связанные с блокировать сиротой и стимулировать шахтер включать больше операций в блоке

Будет ли переходный период, в котором некоторые пользователи и шахтеры не пытаться реконструировать блоки и полагаться на методе распространения блока старого? В течение этого периода обыкновение это имеет смысл для узлов для распространения нового «мини-блок IBLT» и старый блок стиля? Шахтеры, которые находят блок будет хотеть, чтобы максимизировать свои шансы на признание в качестве первого, следовательно, они не могут быть стимулы, чтобы попытаться распределить как блок IBLT и старый полный блок? Забегая вперед, не всегда будет меньшинство узлов, которые только загрузить новые блоки традиционным способом и не пытаться их восстановить?

Кроме того, что происходит с новыми узлами. Новые узлы не будут иметь данные пула памяти от, скажем 12 месяцев назад, как они будут реконструировать старые блоки. Будет ли загрузка исторической работы blockchain таким же образом, как это делает сейчас?

Цитата: jonny1000 12 августа 2014, 10:28:51 AM

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

Да. Читайте суть Гэвина.

Цитата: jonny1000 12 августа 2014, 10:28:51 AM

Кроме того, что происходит с новыми узлами. Новые узлы не будут иметь данные пула памяти от, скажем 12 месяцев назад, как они будут реконструировать старые блоки. Будет ли загрузка исторической работы blockchain таким же образом, как это делает сейчас?

Старые блоки загружаются как сейчас, вновь добытые блоки распространяются после этого нового механизма. Если в основном все операции в пуле памяти в конечном итоге в блоке, бассейн начинается (почти) порожних каждые 10 минут для всех так "получать до скорости" это не проблема.

Блок повторно Orgs нужно подумать.

Если у меня есть цепь A-B-C, и получить IBLT для альтернативной цепи А-b'-С'-D»...

... то текущий пул памяти не будет работать, чтобы попытаться восстановить B «C» D».

Использование B и C для восстановления B «и C» должны работать очень хорошо. Затем оставшийся пул памяти транзакция может быть использована для восстановления D.

Если какой-либо из реконструкций неудачу, просто падают обратно загрузки всех B «C» D».

Затем снова, повторно Orgs достаточно редки, что всегда падает обратно на выборку полных блоков будет в порядке.

Благодаря Gavin

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

Как именно работает пул памяти? Можно ли сохранить запись о том, что пул памяти был, как, скажем, последние п блоков, например, что если ситуация вы охарактеризовали выше происходит, можно более эффективно восстанавливать блоки?

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

Эти причины включают в себя:
1. Пропускная способность границы, поскольку сделки по-прежнему должны быть переданы и загрузить по крайней мере один раз. Хотя это может стать менее актуальной проблемой сетевой безопасности.
2. Вопросы, связанные с новыми узлами догоняют с сетью
3. Необходимость дефицита в blockchain создать рыночную цену за операционные издержки, что позволит предотвратить спам и в конечном итоге потребуется, чтобы стимулировать шахтер
4. Пределы хранения
5. Быстрого времени распространения в случае реконструкции IBLT блока выходит из строя, из-за преднамеренное нападение или чистую случайность

Какой блочный предел не может быть, если это станет реализовано?

Не уверен, если это поможет кому, но CCN имеет рецензию на IBLTs

https://www.cryptocoinsnews.com/bitcoin-in-bloom-how-iblts-allow-bitcoin-scale/

Кто-то поднял факел

Kalle Розенбаум написал тестовый пакет IBLT в Java, используя bitcoinj.

http://www.reddit.com/r/Bitcoin/comments/2jszdl/encodingdecoding_blocks_in_iblt_experimets_on_o1/

котировка

Я работал на IBLT написано в Java, а также проект для кодирования и декодирования Bitcoin блоков, используя этот IBLT. Главное вдохновение приходит от Gavin Anresens (/ и / Гэвин Андресен) отлично на рецензии O (1) блок распространения, https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2.
Проекты называются ibltj (https://github.com/kallerosenbaum/ibltj) И Bitcoin-iblt (https://github.com/kallerosenbaum/bitcoin-iblt). В Bitcoin-iblt Я запускать несколько экспериментов, чтобы найти хорошего размера стоимости и большое количество хэш-функций для использования. Посмотрите на результаты в https://github.com/kallerosenbaum/bitcoin-iblt/wiki/BlockStatsTest
Я очень заинтересован в обсуждении этого и слушать ваши комментарии. Я также нужна помощь, чтобы задать другие тесты для выполнения. Я думаю, что было бы неплохо иметь какое-то "Учитывая, что не существует не более 100 различающиеся операции, мне нужно 867 ячеек размером 270 B, чтобы иметь <0,1% вероятность того, что декодирование не удается.", Любые мысли по этому поводу?

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

Номер операции в блоке
Количество различий между отправителем и получателем, как дополнительными и отсутствующими сделками.
Количество хэш-функций
KeySize
valueSize
keyHashSize
Количество ячеек

Означает ли это, что метод выбора блока получает запертый в?

Вы скажите принимающие, как были выбраны TXS в блоке. Тем не менее, предполагается, размер приоритета и плата за кбайт.

Блок, который не использует стандартный алгоритм выбора транзакции находится в невыгодном положении.

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

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

Цитата: TierNolan 21 октября 2014, 11:25:55 AM

Означает ли это, что метод выбора блока получает запертый в?

Вы скажите принимающие, как были выбраны TXS в блоке. Тем не менее, предполагается, размер приоритета и плата за кбайт.

Блок, который не использует стандартный алгоритм выбора транзакции находится в невыгодном положении.

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

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

Довольно много заперта в основе консенсуса. И вывод жирного шрифта, имеет важное значение.

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

Тем не менее, блок может быть заминированы, где все это консенсус игнорируется, и новый блок полон сделок, которые шахтер "вытащил из задницы" (В реальном мире бизнеса или нет) с пошлин, уплачиваемых в себя, сценарий, который делает существующий предел 1MB выглядеть как предохранительным одеяло. Помимо обеспечения безопасности POW к старым блокам, новый блок не приносит никакой пользы, и многие из них вместе нападение.

Сделки с консенсусным бассейна находятся в IBLT, но они канонически упорядоченные и XOR'd со смещением таким образом, что небольшой процент не должен быть известен заранее, а остальное делать, потому что это единственный способ, чтобы очистить их выкл. Это выходит далеко за рамки нормального сжатия данных, так как приемники знают большую часть содержимого заранее, следовательно, O (1) распространение блока происходит, или в худшем случае O (_журналп).

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

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

Почему это O (1) для распространения блока?

Если 1% сделок отличались между 2-х блоков, то размер IBLT должен был бы быть в 10 раз больше, чтобы обрабатывать блоки, которые в 10 раз больше.

Цитата: TierNolan 24 октября 2014 года, 5:34:17 PM

Никто другой в пробили в так что это не то, что я думаю: это зависит.

Это зависит от того, как синхронизированные все неподтвержденные ТХ mempools есть. Если все узлы 100% синхронизированы, то да, O (1) Распространение блока может произойти, даже при удалении всего mempool. В действительности, mempools различаются, насколько ?, хорошо было бы неплохо, если бы были метрики на нем.

Разница 1% является рабочим число, основанное на позволяя 6 секунд для новой транзакции, чтобы в полной мере распространяются и 600 секунд между блоками. Таким образом, возможно, TX mempools в основном, не синхронизированы по краям (новый TX входящие, и старые TX отбрасываются без подтверждения), а средний 98% ТХ mempools имеют только разность 0,1%. Может быть, IBLT столкнется разница в 0,01%, всегда выбирая "Лучший" 50% из неподтвержденных транзакций.

Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий.

Цитата: Solex 26 октября 2014, 10:24:18 PM

Никто другой в пробили в так что это не то, что я думаю: это зависит.

Да. Вся система предполагает, что все шахтеры используют аналогичные правила.

котировка

Если все узлы 100% синхронизированы, то да, O (1) Распространение блока может произойти, даже при удалении всего mempool.

С 100% синхронизации, вы можете просто отправить заголовок.

O (1) представляет собой утверждение, что, как блоки становятся больше, различие между 2-х блоками не увеличивается.

котировка

Разница 1% является рабочим число, основанное на позволяя 6 секунд для новой транзакции, чтобы в полной мере распространяются и 600 секунд между блоками. Таким образом, возможно, TX mempools в основном, не синхронизированы по краям (новый TX входящие, и старые TX отбрасываются без подтверждения), а средний 98% ТХ mempools имеют только разность 0,1%. Может быть, IBLT столкнется разница в 0,01%, всегда выбирая "Лучший" 50% из неподтвержденных транзакций.

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

Если блок был только операции, которые, по крайней мере 20 секунд старый, затем 5 секунд задержки не будет иметь значения.

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

котировка

Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий.

Я не понимаю, что вы имеете в виду.

Ярмарка баллов.

Цитата: TierNolan 26 октября 2014, 11:28:27 PM

Цитата: Solex 26 октября 2014, 10:24:18 PM

Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий.

Я не понимаю, что вы имеете в виду.

Что я имею в виду то, что из-за различия увеличивают относительно медленно, на практике O (1) можно провести некоторое время. Фиксированный размер 1Мб IBLT блоков является нормальным в то время как объемы дискового блока увеличится через 5 МБ, 10 МБ, 15 МБ, которая может занять довольно много лет. Таким образом, это приближение, разумное функциональное описание того, что происходит в этот период времени. Конечно, математически, различия не монтировать, пока в какой-то момент необходимы 2MB блоки. Кто знает, возможно, боковые цепи делают тяжелую работу тогда.

Это все еще чертовски много лучше, чем O (п)

11 августа 2014, 3:11:18 PM	# 1
jonny1000 Сообщения: 119 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Уважаемые все Я прочитал предложение Гэвина на O (1) блок распространения, доступны здесь: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 Если есть другой поток на этом я извиняюсь, я не мог найти его. Я думаю, что это предложение интересно и может быть блестящими. Однако существуют различные основные аспекты к нему, которые я не понимаю, может, если это возможно, некоторые из вас пытаются объяснить это: 1. Является ли это предложение только для блока распространения начального, со старыми блоками стиля все еще распространяются с задержкой или будет blockchain содержать только новый меньший стиль блоков? 2. Что является стимул для распространения старого формата блок, со всеми сделками, так как это не будет, вероятно не требуется для добычи полезных ископаемых? Не удалось это сделать проблему отсутствия полных узлов хуже? 3. Если blockchain теперь только содержит только новый тип блока, каким образом клиент получить историю всех сделок Bitcoin? Будут ли клиенты должны подключаться к пулу памяти других узлов и как будут реконструированы все исторические операции? 4. Как шахтеры будут стимулы раз награда блока падает, как будто уже не столько дефицита в blockchain, плата может быть слишком низкой, чтобы стимулировать шахтер? Большое спасибо

11 августа 2014, 3:24:02 PM	# 2
azeteki Сообщений: 96 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Получил 1806 Биткоинов Реальная история. Распространение исходного блока только. В момент сразу после успешного нонс был найден. Сам блок все еще содержит все операции в полном виде. Это просто переносится в более эффективным образом. Там нет "нового меньше стиля блока. Узлы будут по-прежнему передавать полные блоки. Там нет (прямого) финансового стимула для тех, кто работать полный узел и там никогда не были.

11 августа 2014, 3:27:52 PM	# 3
CJYP Сообщения: 112 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: jonny1000 от 11 августа 2014 года, 3:11:18 PM Уважаемые все Я прочитал предложение Гэвина на O (1) блок распространения, доступны здесь: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 Если есть другой поток на этом я извиняюсь, я не мог найти его. Я думаю, что это предложение интересно и может быть блестящими. Однако существуют различные основные аспекты к нему, которые я не понимаю, может, если это возможно, некоторые из вас пытаются объяснить это: 1. Является ли это предложение только для блока распространения начального, со старыми блоками стиля все еще распространяются с задержкой или будет blockchain содержать только новый меньший стиль блоков? 2. Что является стимул для распространения старого формата блок, со всеми сделками, так как это не будет, вероятно не требуется для добычи полезных ископаемых? Не удалось это сделать проблему отсутствия полных узлов хуже? 3. Если blockchain теперь только содержит только новый тип блока, каким образом клиент получить историю всех сделок Bitcoin? Будут ли клиенты должны подключаться к пулу памяти других узлов и как будут реконструированы все исторические операции? 4. Как шахтеры будут стимулы раз награда блока падает, как будто уже не столько дефицита в blockchain, плата может быть слишком низкой, чтобы стимулировать шахтер? Большое спасибо Это предложение ничего о blockchain не изменится. Чтобы ответить на вопрос 1, вид. Так как найти блок на самом деле просто означает найти достаточно низкий хэш, чтобы сделать блок действительно, все данные для хэша, за исключением могут быть известны по всей сети до того, как блок найден. В настоящее время, когда шахтер находит блок, они должны отправить весь блок (все операции в блоке + заголовке), все остальные, что труднее, чем больше сделок есть в блоке. Предложение (упрощенно), чтобы убедиться, что каждый шахтер имеет все транзакции, которые будут включены в блоке заранее. Затем, когда шахтер находит блок, они будут иметь только для отправки заголовка и coinbase сделки (рассказывая всем, кто получает награду блока), и другие шахтеры смогут восстановить блок от этого. Так как они смогут восстановить блок, единственное отличие состоит в том, что весь блок не передается по сети.

11 августа 2014, 6:14:46 PM	# 4
jonny1000 Сообщения: 119 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Спасибо за очистку это для меня, жаль моих заблуждений по поводу этой идеи. Мне еще нужно некоторое время, чтобы думать об этом, но я думаю, что это звучит блестяще и может решить, что я думал, что одна из самых больших проблем Bitcoin в. Пожалуйста, дайте мне знать, если я получил это прямо сейчас: Когда шахтер находит блок, они распространяются как фактический блок, и этот новый «мини-блок» по сети. Затем, если другой шахтер получает мини-блок, но не может восстановить полный блок во время, они просто ждут, пока они не получат полный блок. Этот способ шахтеры Incentivized разослать оба типа блоков. Что произойдет, если шахтеры начинают слишком далеко впереди, например, они реконструировать блок и найти много новых действительных блоков, прежде чем даже один полный блок распространилась, может ли это быть проблема? Там может быть два типа узлов, один типа, который реконструирует блоки и имеет более актуальную версию сети и более медленный традиционный узел, признающие только полные блоки.

11 августа 2014, 9:16:36 PM	# 5
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: jonny1000 от 11 августа 2014 года, 6:14:46 PM Когда шахтер находит блок, они распространяются как фактический блок, и этот новый «мини-блок» по сети. Нет. Это была моя первая мысль тоже, когда я увидел твит Гэвина, но реальность гораздо более удивительно. Новая концепция IBLT блока является абсолютным и общим гением и заслуживает большого конструктивного вклада с этого форума. Это изменение может начать Bitcoin от того, чтобы быть серьезным конкурентом Western Union (сегодня) к серьезному конкуренту VISA (позже в следующем году). Лучший способ думать об этой идее рассматривать IBLT блоки, содержащие инструкции о том, как построить следующий блок самостоятельно, а также различия, куча необходимых операций, которые вы уже не знаете о. Если вы посмотрите на неподтвержденных операций по blockchain.info, вы видите их mempool отображаются вне. Ваша копия Bitcoin Ядра, которая работает на дому, будет иметь очень похожий набор неподтвержденных транзакций, может быть меньше, так как BC.i имеет гораздо больше соединений равный-равному. В качестве примера, предполагающее обновление IBLT находится в и работает, и шахтер производит блок IBLT, вы получите его и так делаете BC.i (и другие узлы). IBLT содержит все транзакции, чтобы составить блок - но операции не могут быть прочитаны, потому что (в основном) они накладывая друг на друг. Вы, BC.i, другие, возьмите IBLT и вычесть все операции, которые Вы имеете, которые могут находиться в новом блоке и остались с отличиями. Другой различия для каждого! Тогда вычитаются те, и эти дополнительные операции, которые используются для сборки тот же самый новый блок, а затем начинается регулярная проверка. IBLT блоки одинакового размера, но блок, который идет в blockchain может быть меньше, или значительно больше, в зависимости от количества ОГО, как обычно.

12 августа 2014, 3:20:39 AM	# 6
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Не пропустите также https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding Смотрите также PGP SKS сервера ключей, который использует эффективный набор примирения. котировка Это изменение может начать Bitcoin от того, чтобы быть серьезным конкурентом Western Union (сегодня) к серьезному конкуренту VISA (позже в следующем году). Я поклонник фантазии схем для повышения эффективности (ссылка), но это немного сверху. Воздействие гораздо скромнее, чем вы думаете, особенно по сравнению с типом переадресации, что p2pool и реле сети bluematt уже делать (отправить блоки без повторяющихся операций, что дальний конец уже знает, у вас есть). Сделки по-прежнему должны быть отправлены и проверены. Это делает избежать накладных расходов на полосу пропускания 2x отправки его снова с блоком, и предельную задержку, которая implies- но так делать простые инструменты, например Реле Мэтта для меня имеет hitrate из "В общей сложности, пропускаются 140004 из 142773 (0.9806055766846673%)" после последней перезагрузки. В отличии от некоторых других технологий, как мошенничество доказательств это не меняет децентрализацию / масштаб компромисса или использование полосы пропускания (Это по-прежнему O (п) с числом сделок, они просто происходят раньше). Это весь удивительный соус и все так и должно быть большое дело иметь, но я люблю этот материал делает это больно все больше, чтобы видеть это преувеличено.

12 августа 2014, 7:27:44 AM	# 7
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: gmaxwell от 12 августа 2014 года, 3:20:39 AM Не пропустите также https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding Смотрите также PGP SKS сервера ключей, который использует эффективный набор примирения. котировка Это изменение может начать Bitcoin от того, чтобы быть серьезным конкурентом Western Union (сегодня) к серьезному конкуренту VISA (позже в следующем году). Я поклонник фантазии схем для повышения эффективности (ссылка), но это немного сверху. Воздействие гораздо скромнее, чем вы думаете, особенно по сравнению с типом переадресации, что p2pool и реле сети bluematt уже делать (отправить блоки без повторяющихся операций, что дальний конец уже знает, у вас есть). Сделки по-прежнему должны быть отправлены и проверены. Это делает избежать накладных расходов на полосу пропускания 2x отправки его снова с блоком, и предельную задержку, которая implies- но так делать простые инструменты, например Реле Мэтта для меня имеет hitrate из "В общей сложности, пропускаются 140004 из 142773 (0.9806055766846673%)" после последней перезагрузки. В отличии от некоторых других технологий, как мошенничество доказательств это не меняет децентрализацию / масштаб компромисса или использование полосы пропускания (Это по-прежнему O (п) с числом сделок, они просто происходят раньше). Это весь удивительный соус и все так и должно быть большое дело иметь, но я люблю этот материал делает это больно все больше, чтобы видеть это преувеличено. Я думаю, что вы как-то занижена прикосновенность предложения Гэвина. Несмотря на то, пропускная способность или использование процессора по-прежнему О (п), распространение блока становится O (1). Так как риск блок осиротения положительно коррелируют с временем распространения блока, это предложение позволит снизить затраты, связанные с блокировать сиротой и стимулировать шахтер включать больше операций в блоке

12 августа 2014, 10:28:51 AM	# 8
jonny1000 Сообщения: 119 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Будет ли переходный период, в котором некоторые пользователи и шахтеры не пытаться реконструировать блоки и полагаться на методе распространения блока старого? В течение этого периода обыкновение это имеет смысл для узлов для распространения нового «мини-блок IBLT» и старый блок стиля? Шахтеры, которые находят блок будет хотеть, чтобы максимизировать свои шансы на признание в качестве первого, следовательно, они не могут быть стимулы, чтобы попытаться распределить как блок IBLT и старый полный блок? Забегая вперед, не всегда будет меньшинство узлов, которые только загрузить новые блоки традиционным способом и не пытаться их восстановить? Кроме того, что происходит с новыми узлами. Новые узлы не будут иметь данные пула памяти от, скажем 12 месяцев назад, как они будут реконструировать старые блоки. Будет ли загрузка исторической работы blockchain таким же образом, как это делает сейчас?

12 августа 2014, 10:38:10 AM	# 9
dserrano5 Сообщения: 1848 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: jonny1000 12 августа 2014, 10:28:51 AM Будет ли переходный период, в котором некоторые пользователи и шахтеры не пытаться реконструировать блоки и полагаться на методе распространения блока старого? Да. Читайте суть Гэвина. Цитата: jonny1000 12 августа 2014, 10:28:51 AM Кроме того, что происходит с новыми узлами. Новые узлы не будут иметь данные пула памяти от, скажем 12 месяцев назад, как они будут реконструировать старые блоки. Будет ли загрузка исторической работы blockchain таким же образом, как это делает сейчас? Старые блоки загружаются как сейчас, вновь добытые блоки распространяются после этого нового механизма. Если в основном все операции в пуле памяти в конечном итоге в блоке, бассейн начинается (почти) порожних каждые 10 минут для всех так "получать до скорости" это не проблема.

12 августа 2014, 2:21:03 PM	# 10
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Блок повторно Orgs нужно подумать. Если у меня есть цепь A-B-C, и получить IBLT для альтернативной цепи А-b'-С'-D»... ... то текущий пул памяти не будет работать, чтобы попытаться восстановить B «C» D». Использование B и C для восстановления B «и C» должны работать очень хорошо. Затем оставшийся пул памяти транзакция может быть использована для восстановления D. Если какой-либо из реконструкций неудачу, просто падают обратно загрузки всех B «C» D». Затем снова, повторно Orgs достаточно редки, что всегда падает обратно на выборку полных блоков будет в порядке.

12 августа 2014, 7:55:11 PM	# 11
jonny1000 Сообщения: 119 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Благодаря Gavin Там поэтому может в некоторых случаях старой расы старинки распространения блока в том случае, если повторное орг происходит и шахтеры не в состоянии восстановить блоки. Я могу видеть, как это может быть не достаточно для стимулирования добычи централизации или создания небольших блоков редко. Как именно работает пул памяти? Можно ли сохранить запись о том, что пул памяти был, как, скажем, последние п блоков, например, что если ситуация вы охарактеризовали выше происходит, можно более эффективно восстанавливать блоки?

21 августа 2014, 9:13:08 AM	# 12
jonny1000 Сообщения: 119 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Как многие уже говорили, конечно, это не решает полностью проблему BLOCKSIZE или функцию, в зависимости от того, как вы смотрите на него. До этого предложения я думал, что времена распространения блок добычи Стимулирование централизацию потенциально один из самых больших проблем безопасности в сети. Поэтому это предложение могло бы существенно помочь в этом. Может быть, это немного склонить чашу весов в пользу умеренного увеличения предела блочного, однако есть еще много причин для предела в целом. Эти причины включают в себя: 1. Пропускная способность границы, поскольку сделки по-прежнему должны быть переданы и загрузить по крайней мере один раз. Хотя это может стать менее актуальной проблемой сетевой безопасности. 2. Вопросы, связанные с новыми узлами догоняют с сетью 3. Необходимость дефицита в blockchain создать рыночную цену за операционные издержки, что позволит предотвратить спам и в конечном итоге потребуется, чтобы стимулировать шахтер 4. Пределы хранения 5. Быстрого времени распространения в случае реконструкции IBLT блока выходит из строя, из-за преднамеренное нападение или чистую случайность Какой блочный предел не может быть, если это станет реализовано?

3 октября 2014, 3:38:45 PM	# 13
Хайек Сообщения: 373 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Не уверен, если это поможет кому, но CCN имеет рецензию на IBLTs https://www.cryptocoinsnews.com/bitcoin-in-bloom-how-iblts-allow-bitcoin-scale/

20 октября 2014, 10:55:08 PM	# 14
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Кто-то поднял факел Kalle Розенбаум написал тестовый пакет IBLT в Java, используя bitcoinj. http://www.reddit.com/r/Bitcoin/comments/2jszdl/encodingdecoding_blocks_in_iblt_experimets_on_o1/ котировка Я работал на IBLT написано в Java, а также проект для кодирования и декодирования Bitcoin блоков, используя этот IBLT. Главное вдохновение приходит от Gavin Anresens (/ и / Гэвин Андресен) отлично на рецензии O (1) блок распространения, https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2. Проекты называются ibltj (https://github.com/kallerosenbaum/ibltj) И Bitcoin-iblt (https://github.com/kallerosenbaum/bitcoin-iblt). В Bitcoin-iblt Я запускать несколько экспериментов, чтобы найти хорошего размера стоимости и большое количество хэш-функций для использования. Посмотрите на результаты в https://github.com/kallerosenbaum/bitcoin-iblt/wiki/BlockStatsTest Я очень заинтересован в обсуждении этого и слушать ваши комментарии. Я также нужна помощь, чтобы задать другие тесты для выполнения. Я думаю, что было бы неплохо иметь какое-то "Учитывая, что не существует не более 100 различающиеся операции, мне нужно 867 ячеек размером 270 B, чтобы иметь <0,1% вероятность того, что декодирование не удается.", Любые мысли по этому поводу? Испытательный стенд довольно способный. Я могу выполнять тесты на сколь угодно больших поддельных блоках, построенных из реальных сделок. Я могу изменить следующие параметры: Номер операции в блоке Количество различий между отправителем и получателем, как дополнительными и отсутствующими сделками. Количество хэш-функций KeySize valueSize keyHashSize Количество ячеек

21 октября 2014, 11:25:55 AM	# 15
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Означает ли это, что метод выбора блока получает запертый в? Вы скажите принимающие, как были выбраны TXS в блоке. Тем не менее, предполагается, размер приоритета и плата за кбайт. Блок, который не использует стандартный алгоритм выбора транзакции находится в невыгодном положении. Это может быть хорошей вещью, так как это означало бы большую согласованность между шахтерами. Я думаю, если размер блока больше, чем спрос на места, то это не имеет большого значения, так как правило по умолчанию "все известные операции",

21 октября 2014, 10:34:45 PM	# 16
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: TierNolan 21 октября 2014, 11:25:55 AM Означает ли это, что метод выбора блока получает запертый в? Вы скажите принимающие, как были выбраны TXS в блоке. Тем не менее, предполагается, размер приоритета и плата за кбайт. Блок, который не использует стандартный алгоритм выбора транзакции находится в невыгодном положении. Это может быть хорошей вещью, так как это будет означать, более согласованность между шахтерами. Я думаю, если размер блока больше, чем спрос на места, то это не имеет большого значения, так как правило по умолчанию "все известные операции", Довольно много заперта в основе консенсуса. И вывод жирного шрифта, имеет важное значение. IBLT делает функцию протокола Bitcoin более близко к тому, как все пользователи ожидают, что это работает. Сейчас есть несколько тысяч пользователей, которые ожидают их сделки (сделок), чтобы получить подтверждение в следующем блоке, и тысячи узлов, которые имеют очень похожий вид этих сделок. Обычно, шахтеры являются хорошими гражданами и включают в себя многие из незавершенных сделок. Тем не менее, блок может быть заминированы, где все это консенсус игнорируется, и новый блок полон сделок, которые шахтер "вытащил из задницы" (В реальном мире бизнеса или нет) с пошлин, уплачиваемых в себя, сценарий, который делает существующий предел 1MB выглядеть как предохранительным одеяло. Помимо обеспечения безопасности POW к старым блокам, новый блок не приносит никакой пользы, и многие из них вместе нападение. Сделки с консенсусным бассейна находятся в IBLT, но они канонически упорядоченные и XOR'd со смещением таким образом, что небольшой процент не должен быть известен заранее, а остальное делать, потому что это единственный способ, чтобы очистить их выкл. Это выходит далеко за рамки нормального сжатия данных, так как приемники знают большую часть содержимого заранее, следовательно, O (1) распространение блока происходит, или в худшем случае O (_журналп). Стоимость распространения блок задержки, включая все транзакции будет низкой, так что стимул улучшает для шахтеров грабель в стольких сборах, насколько это возможно, получить высокий процент сделок, подтвержденных в средних 10 минут. Жулик шахтер игровая IBLT отказывая новую за несколько секунд, и первой трансляции его секрет / спам сделки, может быть сорвана, требуя 20% IBLT сделок быть раньше, чем средний возраст нового блока и предыдущая.

24 октября 2014, 5:34:17 PM	# 17
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Почему это O (1) для распространения блока? Если 1% сделок отличались между 2-х блоков, то размер IBLT должен был бы быть в 10 раз больше, чтобы обрабатывать блоки, которые в 10 раз больше.

26 октября 2014, 10:24:18 PM	# 18
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: TierNolan 24 октября 2014 года, 5:34:17 PM Почему это O (1) для распространения блока? Если 1% сделок отличались между 2-х блоков, то размер IBLT должен был бы быть в 10 раз больше, чтобы обрабатывать блоки, которые в 10 раз больше. Никто другой в пробили в так что это не то, что я думаю: это зависит. Это зависит от того, как синхронизированные все неподтвержденные ТХ mempools есть. Если все узлы 100% синхронизированы, то да, O (1) Распространение блока может произойти, даже при удалении всего mempool. В действительности, mempools различаются, насколько ?, хорошо было бы неплохо, если бы были метрики на нем. Разница 1% является рабочим число, основанное на позволяя 6 секунд для новой транзакции, чтобы в полной мере распространяются и 600 секунд между блоками. Таким образом, возможно, TX mempools в основном, не синхронизированы по краям (новый TX входящие, и старые TX отбрасываются без подтверждения), а средний 98% ТХ mempools имеют только разность 0,1%. Может быть, IBLT столкнется разница в 0,01%, всегда выбирая "Лучший" 50% из неподтвержденных транзакций. Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий.

26 октября 2014, 11:28:27 PM	# 19
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Цитата: Solex 26 октября 2014, 10:24:18 PM Никто другой в пробили в так что это не то, что я думаю: это зависит. Да. Вся система предполагает, что все шахтеры используют аналогичные правила. котировка Если все узлы 100% синхронизированы, то да, O (1) Распространение блока может произойти, даже при удалении всего mempool. С 100% синхронизации, вы можете просто отправить заголовок. O (1) представляет собой утверждение, что, как блоки становятся больше, различие между 2-х блоками не увеличивается. котировка Разница 1% является рабочим число, основанное на позволяя 6 секунд для новой транзакции, чтобы в полной мере распространяются и 600 секунд между блоками. Таким образом, возможно, TX mempools в основном, не синхронизированы по краям (новый TX входящие, и старые TX отбрасываются без подтверждения), а средний 98% ТХ mempools имеют только разность 0,1%. Может быть, IBLT столкнется разница в 0,01%, всегда выбирая "Лучший" 50% из неподтвержденных транзакций. Я думаю, что шахтеры могут включать в себя, когда их блок был создан как часть информации они дают. Если каждый ТХ имеет временную метку, связанную с ним, то это удалить бы латентность сети в качестве проблемы. Если блок был только операции, которые, по крайней мере 20 секунд старый, затем 5 секунд задержки не будет иметь значения. Получение этого к работе означает, что должно быть способом договориться о том, что временные метки для каждой транзакции, хотя. котировка Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий. Я не понимаю, что вы имеете в виду.

27 октября 2014, 4:02:42 AM	# 20
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: O (1) Распространение блока Ярмарка баллов. Цитата: TierNolan 26 октября 2014, 11:28:27 PM Цитата: Solex 26 октября 2014, 10:24:18 PM Кроме того, начальная точка не равна нулю, то 1MB блоки, которые могут вместить 1000 отличий. Я не понимаю, что вы имеете в виду. Что я имею в виду то, что из-за различия увеличивают относительно медленно, на практике O (1) можно провести некоторое время. Фиксированный размер 1Мб IBLT блоков является нормальным в то время как объемы дискового блока увеличится через 5 МБ, 10 МБ, 15 МБ, которая может занять довольно много лет. Таким образом, это приближение, разумное функциональное описание того, что происходит в этот период времени. Конечно, математически, различия не монтировать, пока в какой-то момент необходимы 2MB блоки. Кто знает, возможно, боковые цепи делают тяжелую работу тогда. Это все еще чертовски много лучше, чем O (п)

Заголовок