Как XT будет хорошо по отношению к раме пакета?

Я читал об этом XT Кроме того, и немудрено: Действительно ли это хорошая идея?

Обычный кадр Ethernet действительно имеет значение MTU в 1526, и с заголовками и другими накладными расходами, полученный кадр будет roughtly 1500 байт большим. Вычитание IP-заголовок из этого, который обычно 20 байт, но позволяет быть резкими и переусердствовать немного, и вычитают 30 байт. Тогда у нас есть 1470 байт осталось.
Теперь давайте добавим 1 МБ сделок: 446 байт.
Кроме того, добавить заголовок блока и блок хэш и подпись, и вы будете соскоблить немного, что тоже.

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

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

Блок никогда не помещается в один пакет. MTU из ETH кадра 1,526 килобайт, а не мегабайт. Она занимает около 700 пакетов / кадров, чтобы отправить блок предполагая, что все кадры до MTU.

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

возгласы. Сделал ошибку вычислений при расчете на это.

Была ли конкретная причина для ограничения 1Мб?

Цитата: Себастьяне от 23 августа 2015 года, 6:12:40 PM

возгласы. Сделал ошибку вычислений при расчете на это.

Была ли конкретная причина для ограничения 1Мб?

Первоначально, не было предела.

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

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

Цитата: DannyHamilton от 23 августа 2015 года, 6:44:22 PM

Первоначально, не было предела.

Я думал, что это 32MB (и позже был уменьшен до 1 Мб) - вы уверены, что нет предела?

Цитата: CIYAM от 23 августа 2015 года, 6:46:39 PM

Цитата: DannyHamilton от 23 августа 2015 года, 6:44:22 PM

Первоначально, не было предела.

Я думал, что это 32MB (и позже был уменьшен до 1 Мб) - вы уверены, что нет предела?

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

Тогда ограничение MAX_BLOCK_SIZE было добавлено в код в июле 2010 года с лимитом 1 МБ.

Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM

Так, в то время, блок был послан как единое сетевое сообщение, был косвенно предел 32 МБ от размера блока, но не было какого-либо конкретного ограничения на размер, специально предназначенные для блоков.

Понял - так блоки не передаются в виде одного сетевого сообщения сейчас (я не поспевает с последними изменениями)?

Следует отметить, что споры о том, когда и как идти об увеличении размера блока не что-то новое. Это обсуждение, которое в значительной степени было непрерывным, так как предел был первым поставить на место. Уже в октябре 2010 года (всего 3 месяца после того, как лимит был впервые добавлен) Satoshi отвечал на вопросы о ней.

Цитата: Satoshi от 04 октября 2010 года, 7:48:40 PM

Это может быть поэтапно, как:

если (blocknumber > 115000)
MaxBlocksize = largerlimit

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

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

Цитата: CIYAM от 23 августа 2015 года, 6:53:37 PM

Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM

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

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

Цитата: DannyHamilton от 23 августа 2015 года, 6:59:12 PM

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

Да я уверен, "заголовки первых" уже реализовано (в 0.10.0) Я просто не был уверен в пределах в отношении размера блока (и не имел в виду, чтобы получить в целом размер блока дебаты вещи).

Цитата: DannyHamilton от 23 августа 2015 года, 6:59:12 PM

Цитата: CIYAM от 23 августа 2015 года, 6:53:37 PM

Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM

Я привел полагать, что заголовки находятся отправлено в первую очередь; Bitcoin-кли getblockchaininfo возвращает количество заголовков примерно равное количеству блоков, в общей сложности, даже во время синхронизации. Я не уверен, но мое предположение было бы, что это на самом деле заголовок первой передачи, а не просто плохая формулировка. (Я также предполагаю, что это не связано с сообщениями INV, пересылаемых через P2P для описания доступных блоков).

Где предел 32MB сети сообщения взялся? 32MiB из-за количество бит в поле длиной? (Также не в связи с ограничением блочного)

Цитата: hexafraction от 23 августа 2015 года, 6:11:07 PM

Блок никогда не помещается в один пакет.

Протокол реле сети соответствует значительную часть всех блоков в единый пакет (около третьего, ... примерно 60% пригонки в двух пакетах), на самом деле.

Цитата: gmaxwell 24 августа 2015 года, 7:53:27 AM

Цитата: hexafraction от 23 августа 2015 года, 6:11:07 PM

Блок никогда не помещается в один пакет.

Это потому, что блоки чрезвычайно малы, блок-заголовки отправляются, или какой-то большой пакет / jumbogram используется?

Несколько решений было предложено, чтобы облегчить обсуждение размера блока, как 8MB блоков, 20Mb блоков и ограничений динамических блоков размера, среди других. Тем не менее, Bitcoin XT набирает обороты в качестве жизнеспособного решения, как было бы создать жесткую вилку в протоколе, постоянно разделяя blockchain на два разных регистрах бухгалтерского учета.

23 августа 2015, 5:55:10 PM	# 1
Себастьян Сообщения: 122 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я читал об этом XT Кроме того, и немудрено: Действительно ли это хорошая идея? Обычный кадр Ethernet действительно имеет значение MTU в 1526, и с заголовками и другими накладными расходами, полученный кадр будет roughtly 1500 байт большим. Вычитание IP-заголовок из этого, который обычно 20 байт, но позволяет быть резкими и переусердствовать немного, и вычитают 30 байт. Тогда у нас есть 1470 байт осталось. Теперь давайте добавим 1 МБ сделок: 446 байт. Кроме того, добавить заголовок блока и блок хэш и подпись, и вы будете соскоблить немного, что тоже. Представьте себе, то прослаивая это в VPN или что-нибудь, и вы понимаете, почему XT не плохая идея, потому что блок больше не будет вписываться в один пакет, а пакет должен быть фрагментирован. Не будет ли это лучше hardfork цепь, чтобы иметь более высокую скорость распространения bliock, позволяет сказать, что вместо 10 минут вы хэширования блок каждой минуты. Тогда вы получите ту же повышенную пропускную способность транзакций, но все-таки каждый блок установки в один пакет. Я не думаю, что есть риск softfork из-за нетсплит, потому что я никогда не слышал о связи, которая занимает более 1 минуты, чтобы распространять пакет.

23 августа 2015, 6:11:07 PM	# 2
hexafraction Сообщения: 378 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Получил 1806 Биткоинов Реальная история. Блок никогда не помещается в один пакет. MTU из ETH кадра 1,526 килобайт, а не мегабайт. Она занимает около 700 пакетов / кадров, чтобы отправить блок предполагая, что все кадры до MTU. Кроме того, некоторые нечетные радиолинии, предназначенные для экстремально низких условий сигнала занять несколько минут для передачи данных.
$hexafraction сейчас офлайн$ $Пожаловаться на hexafraction$	$Мультицитирование сообщения от hexafraction$ $Быстрый ответ на сообщение hexafraction$

23 августа 2015, 6:12:40 PM	# 3
Себастьян Сообщения: 122 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? возгласы. Сделал ошибку вычислений при расчете на это. Была ли конкретная причина для ограничения 1Мб?

23 августа 2015, 6:44:22 PM	# 4
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: Себастьяне от 23 августа 2015 года, 6:12:40 PM возгласы. Сделал ошибку вычислений при расчете на это. Была ли конкретная причина для ограничения 1Мб? Первоначально, не было предела. Затем, после того, как Bitcoin было вокруг некоторого времени, был обсужден вопрос о возможных атаках, если шахтер был создавать чрезмерно большие блоки. 1 MB был выбран произвольно, как то, что было достаточно большим, чтобы продлиться некоторое время, но достаточно мало, чтобы избежать значительных проблем, если многие блоки были созданы, что размер. Было сделано с концепцией, что она всегда может быть увеличена позже, когда это необходимо. Очевидно, что не было достаточно мысль положить в том, как трудно это может быть, чтобы получить согласие на это увеличение.

23 августа 2015, 6:46:39 PM	# 5
CIYAM Сообщения: 1862 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: DannyHamilton от 23 августа 2015 года, 6:44:22 PM Первоначально, не было предела. Я думал, что это 32MB (и позже был уменьшен до 1 Мб) - вы уверены, что нет предела?

23 августа 2015, 6:50:31 PM	# 6
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: CIYAM от 23 августа 2015 года, 6:46:39 PM Цитата: DannyHamilton от 23 августа 2015 года, 6:44:22 PM Первоначально, не было предела. Я думал, что это 32MB (и позже был уменьшен до 1 Мб) - вы уверены, что нет предела? Был предел 32 МБ на максимальный размер сети сообщений. Это относится к чему-либо отправленному в одном сетевом сообщении. Так, в то время, блок был послан как единое сетевое сообщение, был косвенно предел 32 МБ от размера блока, но не было какого-либо конкретного ограничения на размер, специально предназначенные для блоков. Тогда ограничение MAX_BLOCK_SIZE было добавлено в код в июле 2010 года с лимитом 1 МБ.

23 августа 2015, 6:53:37 PM	# 7
CIYAM Сообщения: 1862 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM Так, в то время, блок был послан как единое сетевое сообщение, был косвенно предел 32 МБ от размера блока, но не было какого-либо конкретного ограничения на размер, специально предназначенные для блоков. Понял - так блоки не передаются в виде одного сетевого сообщения сейчас (я не поспевает с последними изменениями)?

23 августа 2015, 6:56:26 PM	# 8
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Следует отметить, что споры о том, когда и как идти об увеличении размера блока не что-то новое. Это обсуждение, которое в значительной степени было непрерывным, так как предел был первым поставить на место. Уже в октябре 2010 года (всего 3 месяца после того, как лимит был впервые добавлен) Satoshi отвечал на вопросы о ней. Цитата: Satoshi от 04 октября 2010 года, 7:48:40 PM Это может быть поэтапно, как: если (blocknumber > 115000) MaxBlocksize = largerlimit Он может начать быть в версиях далеко впереди, так что к тому времени он достигает этого номер блока и вступает в силу, старые версии, которые не имеют его уже устарели. Когда мы рядом с номером среза блока, я могу поставить предупреждение для старых версий, чтобы убедиться, что они знают, что они должны модернизировать.

23 августа 2015, 6:59:12 PM	# 9
DannyHamilton Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: CIYAM от 23 августа 2015 года, 6:53:37 PM Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM Так, в то время, блок был послан как единое сетевое сообщение, был косвенно предел 32 МБ от размера блока, но не было какого-либо конкретного ограничения на размер, специально предназначенные для блоков. Понял - так блоки не передаются в виде одного сетевого сообщения сейчас (я не поспевает с последними изменениями)? Я не следил за последние изменения очень близко, так что я не уверен, что уже было реализовано, но возникла идея, что обсуждается об отправке заголовков блоков первого, отделенный от остальной части блока. Так как большинство узлов будут уже слышали о большинстве операций, которые находятся в блоке, обратно, когда они передавали их в первую очередь, узлы должны только запросить несколько сделок, которые они отсутствовали. Это позволит снизить общую пропускную способность, необходимую для работы полного узла, и приведет к увеличению скорости, с которой новый блок был распространяющейся через сеть. Очевидно, что для того чтобы это произошло, блок больше не будет единая сеть сообщений. Я не уверен, что планы для начальной загрузки на новом узле, но я думал, "заголовки первых" уже реализован там?

23 августа 2015, 7:03:47 PM	# 10
CIYAM Сообщения: 1862 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: DannyHamilton от 23 августа 2015 года, 6:59:12 PM Я не уверен, что планы для начальной загрузки на новом узле, но я думал, "заголовки первых" уже реализован там? Да я уверен, "заголовки первых" уже реализовано (в 0.10.0) Я просто не был уверен в пределах в отношении размера блока (и не имел в виду, чтобы получить в целом размер блока дебаты вещи).

23 августа 2015, 7:04:28 PM	# 11
hexafraction Сообщения: 378 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: DannyHamilton от 23 августа 2015 года, 6:59:12 PM Цитата: CIYAM от 23 августа 2015 года, 6:53:37 PM Цитата: DannyHamilton от 23 августа 2015 года, 6:50:31 PM Так, в то время, блок был послан как единое сетевое сообщение, был косвенно предел 32 МБ от размера блока, но не было какого-либо конкретного ограничения на размер, специально предназначенные для блоков. Понял - так блоки не передаются в виде одного сетевого сообщения сейчас (я не поспевает с последними изменениями)? Я не следил за последние изменения очень близко, так что я не уверен, что уже было реализовано, но возникла идея, что обсуждается об отправке заголовков блоков первого, отделенный от остальной части блока. Так как большинство узлов будут уже слышали о большинстве операций, которые находятся в блоке, обратно, когда они передавали их в первую очередь, узлы должны только запросить несколько сделок, которые они отсутствовали. Это позволит снизить общую пропускную способность, необходимую для работы полного узла, и приведет к увеличению скорости, с которой новый блок был распространяющейся через сеть. Очевидно, что для того чтобы это произошло, блок больше не будет единая сеть сообщений. Я не уверен, что планы для начальной загрузки на новом узле, но я думал, "заголовки первых" уже реализован там? Я привел полагать, что заголовки находятся отправлено в первую очередь; Bitcoin-кли getblockchaininfo возвращает количество заголовков примерно равное количеству блоков, в общей сложности, даже во время синхронизации. Я не уверен, но мое предположение было бы, что это на самом деле заголовок первой передачи, а не просто плохая формулировка. (Я также предполагаю, что это не связано с сообщениями INV, пересылаемых через P2P для описания доступных блоков). Где предел 32MB сети сообщения взялся? 32MiB из-за количество бит в поле длиной? (Также не в связи с ограничением блочного)
$hexafraction сейчас офлайн$ $Пожаловаться на hexafraction$	$Мультицитирование сообщения от hexafraction$ $Быстрый ответ на сообщение hexafraction$

24 августа 2015, 7:53:27 AM	# 12
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: hexafraction от 23 августа 2015 года, 6:11:07 PM Блок никогда не помещается в один пакет. Протокол реле сети соответствует значительную часть всех блоков в единый пакет (около третьего, ... примерно 60% пригонки в двух пакетах), на самом деле.

24 августа 2015, 11:50:36 AM	# 13
hexafraction Сообщения: 378 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Цитата: gmaxwell 24 августа 2015 года, 7:53:27 AM Цитата: hexafraction от 23 августа 2015 года, 6:11:07 PM Блок никогда не помещается в один пакет. Протокол реле сети соответствует значительную часть всех блоков в единый пакет (около третьего, ... примерно 60% пригонки в двух пакетах), на самом деле. Это потому, что блоки чрезвычайно малы, блок-заголовки отправляются, или какой-то большой пакет / jumbogram используется?
$hexafraction сейчас офлайн$ $Пожаловаться на hexafraction$	$Мультицитирование сообщения от hexafraction$ $Быстрый ответ на сообщение hexafraction$

27 августа 2015, 10:38:27 AM	# 14
фитили Сообщений: 28 Цитировать по имени цитировать ответ	Re: Как XT будет хорошо по отношению к раме пакета? Несколько решений было предложено, чтобы облегчить обсуждение размера блока, как 8MB блоков, 20Mb блоков и ограничений динамических блоков размера, среди других. Тем не менее, Bitcoin XT набирает обороты в качестве жизнеспособного решения, как было бы создать жесткую вилку в протоколе, постоянно разделяя blockchain на два разных регистрах бухгалтерского учета.

Заголовок