BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока

19 февраля 2013, 4:57:15 AM	# 1
Sergio_Demian_Lerner Сообщения: 539 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Здравствуй! Я посылаю эту BIP для сообщества, чтобы обсудить. Я надеюсь получить хорошую обратную связь, поэтому я могу приступить к его реализации, опубликовать его в вики БИП, и сделать это в протокол. BIP: Заглавие: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Автор: Sergio Демьян Лернер Статус: Проект (неполный) Создан 19-Февраль-2013 Абстрактные Когда блок получает сиротой, то это означает, что некоторые из имеющейся мощности сети хеширования были потрачены впустую. Это впустую хэширования власть не выгодно никому в сети Bitcoin. Сирота блоки создаются в основном из-за время распространения сети новых блоков. А 1 Мбайта блок, посланный через соединение 50 Кбайт / с, занимает 20 секунд. Предполагая, что средний диаметр сетевого графика 4 хмеля, это занимает больше, чем 1 минуту для такого блока для распространения по сети. Текущий размер блока в среднем составляет 150 Кбайт, так что это не проблема сегодня. Как мы ожидаем, что сеть Bitcoin расти ДО максимальной мощности, разумно ожидать 13% отходов в сети хеширования власти в ближайшем будущем из-за осиротевших блоков. Один из способов уменьшить блок время распространения является отправка только заголовка блока и транзакции хэш в первой команде полезной нагрузке ("заголовок"), А затем отправить оставшиеся данные (операции), во второй команде полезной нагрузке ("блок"). Поскольку coinbase сделка не может быть отправлена по отношению к аналогам без блока корпуса, то "заголовок" Команда должна также отправить эту специальную операцию. Спецификация "заголовок" Формат команды: - заголовок блока - Операции хеширования список - Coinbase транзакций (максимум 10 Кбайт) В среднем "заголовок" Размер команды (для блока 1 Мбайта, учитывая средний 400 байт ТХ) составляет 80 кбайт, что занимает 1,5 секунд на хмеля. "заголовок" Команда должна быть отправлена только для вновь созданных блоков, а не для исторических. Семантика Сразу после первой команды "заголовок" принимается, узел должен: 1. Убедитесь, что блок родитель известен. Если это не так, то отбросить команду. 2. Убедитесь, что блок является последним блоком цепи (по полю времени) 3. Вычислить POW и проверить, если он похож на родительский блок Pow (~~+/ - возможный ожидаемый вариант~~). Если это не так, то команда игнорируется, и отправитель занесен в черный список (предотвращение DoS). 4. возмущает "заголовок" команда для всех коллег. 5. Проверьте, транзакционные хэши, содержащиеся в "заголовок" Команда уже в бассейне Tx. 6а. Если все хэши в бассейне, восстановить блок, отнесенным "заголовок" и объявить коллега. 6b. Если очень немногие из них не в бассейне, а затем недостающие TXS может быть запрошена от сверстников. 6с. Если почти все они не являются, игнорировать "заголовок" Команда и запросить блок от партнера послав "заголовок" Команда с помощью "getblocks", 7. После того, как весь блок Х реконструируются / получено, действовать в нормальном режиме (объявить блок, "фактура" по отношению к аналогам и вперед по запросу) Шахтеры должны, после выполнения предыдущих шагов 1-6, сделайте следующее: 1. Подождите, пока полный блок не восстанавливаются или получено (при добыче в обычном режиме без перерыва) 2а. Если блок X получен до нашего собственного блока решается начать пытается решить блок, родитель X. 2b. Если блок решается локально до полного блока X восстанавливается, отбросить X и попытаться выиграть гонку блок цепи против X. Это BIP не требует какой-либо мягкой вилки или жесткой вилки и 100% обратная совместимость, так как она включает в себя только изменения в протоколе p2p связи. Сверстники, которые не понимают "заголовок" Команда будет обрабатывать "блок" команды вместо этого. Reference Implementation <еще не реализовано> Кроме того, связанные улучшения С максимальной 10 секунд времени распространения, 2 минуты блок интервал подтверждения должен быть стабильным, так что это может быть возможно в будущем (с согласия общин), чтобы уменьшить интервал блока до 2 минут или меньше с hardfork (сокращение и сборов и размер блока пропорционально, чтобы сохранить те же экономические свойства Bitcoin нетронутыми и сохранить контракт с сообществом). Кто выигрывает от этого BIP? Шахтеры: шахтеры, которые реализуют этот протокол (даже если в частном порядке между ними) получить 10% преимущество над остальными. Пользователи: Они получают 10% дополнительную безопасность практически без дополнительных затрат (накладные расходы должны быть незначительными). Кроме того, если блоки реконструируют с использованием существующей транзакции в бассейне, а не отправлено, использование полосы пропускания сокращается до половины. Это беспроигрышная ситуация. С наилучшими пожеланиями, Серхио.

Как заработать Биткоины?
Без вложений. Не майнинг.

19 февраля 2013, 6:15:09 AM	# 2
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Получил 1806 Биткоинов Реальная история. Я не уверен, где вы получаете 10% с- но осиротением ставки не так высоки, даже экстраполировать на размер блока. Ваш анализ также игнорирует RTT, и изменение размера данных, передаваемый не изменяет вклад задержку от скорости света. P2Pool уже реализует в основном протокол вы описываете. Работает достаточно хорошо. Я не знаю, что это особенно интересно для шахтеров, за исключением, однако. Объективно, это не кажется, что шахтеры все равно, что много, так как они не все перешли на p2pool. котировка 1. Убедитесь, что блок родитель известен. Если это не так, то отбросить команду. Родитель должен быть извлечен или сеть не будет сходиться. котировка 2. Убедитесь, что блок является последним блоком цепи (по полю времени) Время не говорит вам об этом, его не монотонных (и не может быть монотонными без создания незначительных уязвимостей.) котировка 3. Подсчитать PoW и проверить, если он похож на родительском блоке Pow (+/- возможных ожидаемые вариаций). Если это не так, то команда игнорируется, и отправитель занесен в черный список (предотвращение DoS). Объемом работы, назначенной на заголовок является строгой функцией предварительной цепи. Там не допускается изменение _at all_ котировка В среднем "заголовок" Размер команды (для блока 1 Мбайта, учитывая средний 400 байт ТХ) составляет 80 кбайт, что занимает 1,5 секунд на хмеля. Если вы собираетесь сходить с ума сжатия можно реально передавать только половину идентификаторы транзакций (16 байт, а не 32) и половину того, я полагаю.

19 февраля 2013, 6:49:52 AM	# 3
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Sergio_Demian_Lerner от 19 февраля 2013 года, 4:57:15 AM "заголовок" Формат команды: - заголовок блока - Операции хеширования список - Coinbase транзакций (максимум 10 Кбайт) В среднем "заголовок" Размер команды (для блока 1 Мбайта, учитывая средний 400 байт ТХ) составляет 80 кбайт, что занимает 1,5 секунд на хмеля. Вы должны быть осторожны с передачей списка транзакций хэша, а не сами сделок. Хотя это, безусловно, делает распространение быстрее в среднем случае, это также означает, что в худшем случае, блок полностью состоит из операций, которые не были предыдущей трансляции по сети, значительно хуже. С целью снижения только детей-сирот, как это делается P2Pool, как gmaxwell отметил, в худшем случае это не проблема, но не делать предположений, которые имеют отношение к безопасности. В частности, с помощью механизма я указал Вот вы на самом деле создать рынок для крупных hashpower шахтеров, где они могут предложить более низкие сборы, за счет более низкой эффективной конкуренции, при условии, что отправитель обещает не посылать сделку по любой другой шахтера. Я не могу видеть такие рынки развивающихся для 1MiB блоков, но они могли бы развиваться гораздо больших размеров блоков. P2Pool интересен тем, что шахтеры на него есть стимул для любого блока P2Pool будет распространяться на сеть в целом как можно быстрее. Кроме того порочные стимулы распространения для акций в пределах P2Pool, вероятно, менее важная проблема, учитывая, что чем выше хэш сила P2Pool в целом, тем меньше дисперсии для любого отдельного шахтера - шахтеры на P2Pool не играют игру с нулевой суммой , P2Pool шахтеры также имеют очень мало контроля над распространением, так как акции P2Pool все одинаковые.

19 февраля 2013, 7:47:16 AM	# 4
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Retep от 19 февраля 2013 года, 6:49:52 AM Вы должны быть осторожны с передачей списка транзакций хэша, а не сами сделок. Хотя это, безусловно, делает распространение быстрее в среднем случае, это также означает, что в худшем случае, блок полностью состоит из операций, которые не были предыдущей трансляции по сети, значительно хуже. Очевидная вещь, чтобы сделать в этом случае, чтобы отправитель выбрать то, что представление его мнению, будет более эффективным, основываясь на том, что он знает, что от партнера. (Например, сделку он ранее предложил пир, или равный предложил его). В случае p2pool для p2pool акций p2pool шахтеров стимул для предварительного вперед, что сделки, они являются добычей и тем, что их акции наказывали (узлы пытаются построить от своих родителей, а не доли). Хотя я не думаю, что на самом деле полезно относится к сети Bitcoin.

19 февраля 2013, 9:07:13 AM	# 5
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Запись БИП, как это лучше сделать после pullreq пойти с ним. Мэтт уже прототип такой оптимизации некоторое время назад, но не закончил его, там были какие-то детали, которые нуждались адресации для обработки случаев, когда обмен останавливается на полпути через и так далее. Когда кто-то реализовал патч для отправки блоков хэши, и это прошло проверку кода, это время, чтобы написать BIP. Например, вы говорите о команде заголовки, но это уже существует и используется для чего-то другого (ответ на getheaders).

19 февраля 2013, 9:18:04 AM	# 6
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Майк Хирн 19 февраля 2013 года, 9:07:13 AM Запись БИП, как это лучше сделать после pullreq пойти с ним. Даже не должен быть запрос тянуть. Это также может быть альтернативный протокол и маленький шлюз демон. И как доказательство концепции и как инструмент быстрого развертывания. Мы действительно могли бы использовать некоторое разнообразие в P2P транспортов. Как отметил Серхио Демьян Лернер и других есть много гарри DOS случаев атаки угловых ... мы не можем на самом деле никакого разнообразия в вещи Blockchain, но мы абсолютно можем и должны иметь больше в узле к узлу транспорта.

19 февраля 2013, 9:34:35 AM	# 7
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Две выдвижных просьб я хотел бы видеть, те, которые делают прототипирование этого материала легче, будет "getrawblock / sendrawblock" RPC команды, и "notifytransaction" механизм. Последнее позволяет найти новые входящие транзакции, которые были приняты к mempool, так что вы можете вводить их в свой альтернативный механизм распределения, а затем добавляют к клиентскому mempool с sendrawtransaction (флаг, отключающего повторное вещание было бы неплохо) Последний имеет уже Предпринимались попытки; Кажется, я помню, там были какие-то проблемы, связанные с блокировкой, которые необходимо решить, но они выглядели сговорчивым. Первое позволяет делать то же самое для целых блоков. (Submitblock не совсем то, что вы хотите) Например прохладное и потенциально полезная вещь, чтобы сделать будет работать служба, которая mulicasts в blockchain через Simple Service Messaging Amazon. Вы бы зарегистрироваться и получить blockchain корм для вашего EC2 узла без фактического подключения к кому-либо еще. пропускная способность EC2 довольно дорого, поэтому расходы будут значительно меньше, и он может масштабироваться до абсолютно огромное количество клиентов. Конечно, вы доверяете услугу, но для некоторых приложений это не имеет большого значения. Другая интересная вещь, чтобы сделать было бы осуществить многоадресного вещания в blockchain и сделок. Хотя обычно не доступны, многоадресного доступен на нескольких сетей, так что будут какие-то люди, которые могут использовать его. Точно так же вы можете запустить службу сервиса спутниковой нисходящей линии связи или радио. Дело в том, на самом деле реализации этих идей будет гораздо проще с этими двумя выдвижными запросов.

19 февраля 2013, 9:40:00 AM	# 8
Молочный коктейль Сообщений: 98 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Хм, я должен сказать, что я не очень люблю это предложение. Потерянные блоки не совсем впустую - если бесхозные ставки были снижены, то сложность будет выше, потому что больше блоков будут решены, и что на самом деле ничего не меняет.

19 февраля 2013, 10:05:03 AM	# 9
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Это новое требуется что-нибудь, чтобы найти transacations принятого в mempool? Любая сделка принято объявляются через и. Вы можете просто подключиться к локальному узлу запускается самостоятельно, а затем GetData любой ТХ, чем объявлено. Мэтт, вероятно, имеет свой недопитый код где-то. Было бы здорово, чтобы он интегрирован в протокол ядра P2P, хотя я согласен, что есть много других протоколов, которые могут быть полезными способами для перемещения данных вокруг. Один я хотел бы сделать, как наивысшим приоритетом является протокол Bluetooth для телефонов, чтобы поменять сделки друг с другом, так что если один отсутствует другой может транслировать транзакцию для него. Может быть, даже туннелирование реального соединения P2P через BT. Мы прототип очень простой пример того, что в Hackathon Берлина, используя незащищенный Bluetooth (так что нет спаривания над головой UI), он работал, но не был достаточно прочным, чтобы интегрировать.

19 февраля 2013, 10:29:00 AM	# 10
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Milkshake от 19 февраля 2013 года, 9:40:00 AM Хм, я должен сказать, что я не очень люблю это предложение. Потерянные блоки не совсем впустую - если бесхозные ставки были снижены, то сложность будет выше, потому что больше блоков будут решены, и что на самом деле ничего не меняет. Это означает, что общее доказательство работы увеличивается, так что сеть является более безопасным. Преимущество состоит в том, что она уравновешивает узлы, которые имеют более медленные времена распространения. Тем не менее, это все еще означает, что добыча блок, который имеет "скрытый" сделка по-прежнему дает шахтеру преимущество. При нынешней системе, они должны предоставить всю сделку, чтобы получить сеть хэширования питания для переключения. Там должен быть какой-то способ для людей, чтобы подтвердить, что операции известны. Может быть, как правило протокол может быть изменено, чтобы не распространять сообщения, если какие-либо TXS неизвестны. Это создает стимул только мой против хорошо известных операций. Интересно, если это можно было бы объединить с Bloom фильтрации от BIP-37 для уведомления о проведенных выходных транзакций (TXOs). В основном, с фильтрацией цветения, каждый "объект" задает число битов (скажем, 4) на основе хэш-функции. Каждые Ое соответствие входа в блок будет установлен 4 бита на выходе фильтра. Если весь 4 бит, совпадающий с Тм не установлен, то гарантируется, что Тх не в блоке. Тем не менее, ложные срабатывания могут произойти. Если блок имеет 1000 транзакций и каждый в среднем по 3 входа, то это 3000 TXOs, которые признаны недействительными. Это означает, что в среднем 12000 бит будет установлен в отфильтрованной выходе. Длина фильтра может быть определена на основе числа TXOs и бит. Если фильтр был 24000 долго (так удвоить ожидаемое число битов) и использовали 4 бита, то вероятность ложных срабатываний являются (0,5) ^ 4 = 0,0625. 24000 бит составляет около 3KB. Тем не менее, Блум длина фильтра весы непосредственно с номером к TXOs. [Редактировать] Это, вероятно, лучше всего иметь фильтр Блума за ТЕ. То, что, как отдельные TXS могут быть проверены. С 4 байта на фильтр, вы получите около 6,25% вероятность ложных срабатываний. Это позволяет узлам проверять отдельные передатчики.

19 февраля 2013, 12:57:51 PM	# 11
Sergio_Demian_Lerner Сообщения: 539 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: gmaxwell от 19 февраля 2013 года, 6:15:09 AM котировка 3. Подсчитать PoW и проверить, если он похож на родительском блоке Pow (+/- возможных ожидаемые вариаций). Если это не так, то команда игнорируется, и отправитель занесен в черный список (предотвращение DoS). Объемом работы, назначенной на заголовок является строгой функцией предварительной цепи. Там не допускается изменение _at all_ Хорошо, это не ясно. То, что я имел в виду, что родительский блок может быть необходима корректировка трудности, которые должны быть приняты во внимание. Цитата: gmaxwell от 19 февраля 2013 года, 6:15:09 AM котировка 1. Убедитесь, что блок родитель известен. Если это не так, то отбросить команду. Родитель должен быть извлечен или сеть не будет сходиться. Нет, это не правильно. Если родитель известен, то мы продолжаем пропагандируя "заголовок" команда. Если неизвестно, то мы просто ждать полной "блок" команда, чтобы прибыть. Один решение принимается, когда новый блок X рекламируется с "фактура": Если у меня есть предыдущая "заголовок" Описание блока X, то оценить, что лучше, чтобы загрузить блок или загружать сделки отдельно. Если вы решили бывшие, держать в обычном режиме. Если вы решите позже, то это игнорировать "фактура" Команда навсегда, и хранить остаток в таблице памяти, чтобы восстановить блок, когда будут получены все TXS. (Если у меня нет "заголовок" Х, держать в обычном режиме. ) Это упрощает реализацию много. Там нет условия гонки, не нестабильного состояния. Сходимость гарантируется. Цитата: gmaxwell от 19 февраля 2013 года, 6:15:09 AM Если вы собираетесь сходить с ума сжатия можно реально передавать только половину идентификаторы транзакций (16 байт, а не 32) и половину того, я полагаю. Да, я тоже это заметил.

19 февраля 2013, 1:20:58 PM	# 12
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: TierNolan 19 февраля 2013, 10:29:00 AM Там должен быть какой-то способ для людей, чтобы подтвердить, что операции известны. Может быть, как правило протокол может быть изменено, чтобы не распространять сообщения, если какие-либо TXS неизвестны. Это создает стимул только мой против хорошо известных операций. Вы должны быть очень осторожны со всем, что отбивает блоки. Каждый раз, когда данное правило для воспрепятствования блоков принимается меньшинство, а не большинство, большинство хэширования власти, не следует, что конкретное правило имеет стимул сознательно производить блоки, которые будут поощряться меньшинство. То, что вы предлагаете это правило реле, так что вопрос на самом деле то, что% хеширование мощности не получает блок из этого правила, но независимо от того, если только 25% от мощности хеширования игнорирует нарушающий блок, другие 75% должен включает в себя неизвестную TX в каждом блоке они Mine. Они будут иметь 25% меньше конкуренции - очевидное преимущество.

19 февраля 2013, 1:30:48 PM	# 13
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Retep от 19 февраля 2013 года, 1:20:58 PM То, что вы предлагаете это правило реле, так что вопрос на самом деле то, что% хеширование мощности не получает блок из этого правила, но независимо от того, если только 25% от мощности хеширования игнорирует нарушающий блок, другие 75% должен включает в себя неизвестную TX в каждом блоке они Mine. Они будут иметь 25% меньше конкуренции - очевидное преимущество. Это зависит от того, сколько шахтеры используют правило. Если 75% не будет включать в себя определенные передатчики, то добыча этого типа ОГО плохой план. Кроме того, даже если только 25% отказались заминировать Txs, есть еще товар проблема общественной для коалиции большинства. Это может быть в интересах коалиции, чтобы включить по крайней мере, 1 обескураженным ОМУ, но он по-прежнему в интересах каждого отдельного члена, чтобы сделать его приемлемыми для блоков, как много шахтеров, как это возможно. Отказываясь шахты против определенных блоков также не вызовет вилку и правило может быть "мягкий" и применяются только к последнему блоку в цепочке.

19 февраля 2013, 2:22:10 PM	# 14
Sergio_Demian_Lerner Сообщения: 539 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Retep от 19 февраля 2013 года, 6:49:52 AM Вы должны быть осторожны с передачей списка транзакций хэша, а не сами сделок. Хотя это, безусловно, делает распространение быстрее в среднем случае, это также означает, что в худшем случае, блок полностью состоит из операций, которые не были предыдущей трансляции по сети, значительно хуже. Я не думаю, что так. Поскольку только недостающие транзакции передаются, в худшем случае это так же, как это сегодня. Может быть, немного хуже в предельном случае, когда решение просить отдельную Txs вместо полного блока не было хороший (многие просили сделаны вместо одного запроса).

19 февраля 2013, 2:24:19 PM	# 15
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Sergio_Demian_Lerner от 19 февраля 2013 года, 2:22:10 PM Цитата: Retep от 19 февраля 2013 года, 6:49:52 AM Вы должны быть осторожны с передачей списка транзакций хэша, а не сами сделок. Хотя это, безусловно, делает распространение быстрее в среднем случае, это также означает, что в худшем случае, блок полностью состоит из операций, которые не были предыдущей трансляции по сети, значительно хуже. Я не думаю, что так. Поскольку только недостающие транзакции передаются, в худшем случае это так же, как это сегодня. Может быть, немного хуже в предельном случае, когда решение просить отдельную Txs вместо полного блока не было хороший (многие просили сделаны вместо одного запроса). Я не имею в виду хуже, чем сегодня, я имею в виду хуже, чем в среднем случае. Просто реализовать ваши идеи в порядке, и, вероятно, должно быть сделано; вопрос чисто в принятии предположения, в частности, предположения безопасности, о том, как быстро блоки будут распространяться на его основе.

19 февраля 2013, 2:39:58 PM	# 16
Sergio_Demian_Lerner Сообщения: 539 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: Майк Хирн 19 февраля 2013 года, 9:07:13 AM Запись БИП, как это лучше сделать после pullreq пойти с ним. Мэтт уже прототип такой оптимизации некоторое время назад, но не закончил его, там были какие-то детали, которые нуждались адресации для обработки случаев, когда обмен останавливается на полпути через и так далее. Мое предложение почти без гражданства. Там нет неизвестных или промежуточных состояний. Один решение принимается, когда "фактура" прибывает, содержащий блок-хэш. Цитата: Майк Хирн 19 февраля 2013 года, 9:07:13 AM Когда кто-то реализовал патч для отправки блоков хэши, и это прошло проверку кода, это время, чтобы написать BIP. Например, вы говорите о команде заголовки, но это уже существует и используется для чего-то другого (ответ на getheaders). Почему писать код, если вы знаете, что никто не будет использовать его? Я предпочитаю знать заранее. Существующая команда "заголовки" не "заголовок"

19 февраля 2013, 4:18:04 PM	# 17
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Я не помню, что этот вопрос с Matts кодом, так что некоторые детали, которые необходимо решить в коде. Это одна вещь, чтобы сказать, другое дело делать. Но конечно, это было бы хорошее улучшение. Тогда мы можем галочка страницы масштабируемости (он перечислен там как будущее улучшение). Я надеюсь, что вы не представит патч, который добавляет команду только одну букву, отличную от существующей команды?

21 февраля 2013, 2:30:13 PM	# 18
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Кстати, одна возможная разработка этой идеи, чтобы иметь узлы передавать только минимально необходимые префиксы хешей, чтобы неоднозначности транзакций, он знает, что равноправное видел. Для большинства блоков текущего размера вам потребуется только один или два байта, чтобы отличить сделку, которая включена. Это, вероятно, не стоит дополнительная сложность, хотя.

13 апреля 2013, 9:58:52 PM	# 19
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Дальнейшее улучшение в этой системе будет иметь шахтер предварительно отправить свои списки транзакций. Когда шахтер решает, какие операции включить в блок. Он посылает "в ожидании" сообщение. Это список хэшей. хэш (coinbase) хэш (Transaction1) ... ... хэш (последняя сделка) Когда клиент получает отложенное сообщение, он проверяет, что он знает обо всех операциях, перечисленных (кроме coinbase). Затем он будет просить недостающие операции в списке. Когда у него есть все транзакции, он будет пересылать ожидающее сообщение. он не будет пересылать его, если он содержит неизвестные транзакции. Эта таблица будет отображать Merkle корень в списке транзакций. Затем, когда шахтер решает блок, он может отправить только заголовок. Когда другой клиент получает заголовок, он может вытащить список транзакций из таблицы поиска, используя Merkle корня в качестве ключа. Он также попросили все недостающие операции заранее. Это создает стимулы для распространения сделок, прежде чем включать их в блоках. В противном случае ваши отложенные сообщения не будут отправлены. Не знаю, как лучше сделать защиту от спама. Один из способов сделать это будет включать доказательство работы. По сути, доказать, что некоторые хешировании власть была выброшена для получения сообщения.

14 апреля 2013, 9:14:04 AM	# 20
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: BIP: Увеличение сети HASHING питания за счет сокращения времени прохождения блока Цитата: TierNolan 13 апреля 2013 года, 9:58:52 PM Не знаю, как лучше сделать защиту от спама. Один из способов сделать это будет включать доказательство работы. По сути, доказать, что некоторые хешировании власть была выброшена для получения сообщения. Подумав об этом, тот же эффект может быть достигнут путем отправки одного из сообщений в ОП. Если военнопленный является > 1/16 от требуемого военнопленного и сообщения в противном случае действительно, направить его к любому узлу, который вы не отправляли сообщения с тем же корнем Merkle к. Это уменьшает спам, но все же позволяет шахтеры распространять их предварительный просмотр. Порог может быть изменен, но если 1/16 используются, а затем 15 раз из каждых 16 раз шахтер выигрывает блок, шахтер сможет отправить предварительные сделки хэш заранее фактически решения блока. 1 раз в 16, первое решение, которое меньше, чем в 16 раз цель также будет меньше, чем цель. Предварительный просмотр 32 байта за одну транзакцию. Если средние фактические байт за одну транзакцию составляет 350 байт, то это только улучшение 10X. Идея коротких хэш бы улучшить положение вещей. Если есть 100 миллионов транзакций в пуле памяти, то вам нужно только в среднем 26 бит, так что 4 байта. Шахтер может уменьшить размер его отложенным блока с помощью коротких хэшей. Правило может быть не распространять сообщения, если все хэши в хэш сообщения в точности одной транзакции, содержащейся в памяти. Суб-хэш будут увеличиваться с логарифмом числа записей в пуле памяти транзакций.

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW