Максимальный размер блока должен также учитывать размер UTXO набора

Это является устаревшим. Смотрите мое новое предложение ниже:

Мы должны поощрять "хорошие сделки", Которые являются: 1. малы по размеру, 2. с меньшим количеством выходов, 3. с практически расходуемыми выходами

Цели 2, 3 имеют важное значение для поддержания разумного размера UTXO набора.

Действующее ограничение размера блока, однако, учитывает только цель 1. Шахтеров будут принимать загрязняющие операции (с большим количеством практически unspendable выходов) до тех пор, достаточно пошлины. Тем не менее, каждые полные узлы должны поддерживать завышенный набор UTXO.

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

У меня есть общее представление о том:

Обозначим:

S₀, S₁,.....,S_N: Количество Satoshis выходного 0, 1 ..... п.
Размер: размер сделки в кбайт.

Регулировать размер сделки определяется следующим образом:

Размер * (1 / (журнал₂S₀+1) + 1 / (журнал₂S₁+1) + .. + 1 / (журнал₂S_N+1))

Значение 1 / (журнал₂S_N+1) увеличивается экспоненциально по мере выходной размер уменьшается. Значение равно 1: 1, 0,5 Satoshi для 2 Satoshi, 0,13 за 1 uBTC, 0,057 для 1mBTC и 0,036 на 1 BTC.

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

Если реальный размер блока < 1MB, скорректированный размер блока не считают. Если реальный размер блока > 1 Мб, скорректированный размер блока должен быть меньше некоторой константы.

Многие проблемы решаются с помощью системы, как это:

1. Размер блока по-прежнему паника. Если это < 1 Мб, это эквивалентно текущий предел. Если это > 1 Мб, "хорошие сделки" являются приоритетными
2. Шахтеры будут иметь стимул, чтобы исключить выходы пыли, потому что увеличит скорректированный размер блока
3. Шахтеры будут любить операции с меньшим количеством выходов, так что множество UTXO может быть уменьшено.
4. Людям, пытающихся отправить выходы пыли и / или завышать набор UTXO придется платить больше гонорара шахтера, чтобы компенсировать их загрязнение
5. Размер блока, который стоит пропускной способности и дискового пространство, по-прежнему учитываются.

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

Цитата: jl2012 15 марта 2013 года, 3:45:52 PM

Мы должны

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

Цитата: justusranvier 15 марта 2013 года, 3:50:44 PM

Цитата: jl2012 15 марта 2013 года, 3:45:52 PM

Мы должны

Нет, это трудно вилкой.

Цитата: jl2012 15 марта 2013 года, 4:25:17 PM

Нет, это трудно вилкой.

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

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

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

Ну давай сейчас, конечно, очевидно, что другие люди не были вынуждены подчиняться "" правила является doubleplus-ungood?

-MarkM-

Цитата: justusranvier 15 марта 2013 года, 4:29:30 PM

Цитата: jl2012 15 марта 2013 года, 4:25:17 PM

Нет, это трудно вилкой.

Это на самом деле ответ на другой поток:

Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO

Цитата: jl2012 15 марта 2013 года, 4:47:05 PM

Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO

Эта.

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

Кроме того, я не понимаю, почему мы должны были бы иметь одну метрику, чтобы описать использование в двух ограниченных ресурсов, блок пространства и utxo установить пространство. Не было бы проще просто иметь отдельные лимиты для обоих? Они потребляют различные физические ресурсы - пропускную способность и хранение, соответственно - и поэтому эти параметры должны быть несколько ортогональны.

Цитата: d'Aniel 15 марта 2013 года, 8:11:48 PM

Цитата: jl2012 15 марта 2013 года, 4:47:05 PM

Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO

Согласовано.

Мы можем иметь индекс UTXO, который является общее число выходов в блоке минус общее число входов в блоке, и имеют жесткий предел для него

Цитата: jl2012 15 марта 2013 года, 3:45:52 PM

...
Если реальный размер блока < 1MB, скорректированный размер блока не считают. Если реальный размер блока > 1 Мб, скорректированный размер блока должен быть меньше некоторой константы.

Многие проблемы решаются с помощью системы, как это:

1. Размер блока по-прежнему паника. Если это < 1 Мб, это эквивалентно текущий предел. Если это > 1 Мб, "хорошие сделки" являются приоритетными
2. Шахтеры будут иметь стимул, чтобы исключить выходы пыли, потому что увеличит скорректированный размер блока
3. Шахтеры будут любить операции с меньшим количеством выходов, так что множество UTXO может быть уменьшено.
4. Людям, пытающихся отправить выходы пыли и / или завышать набор UTXO придется платить больше гонорара шахтера, чтобы компенсировать их загрязнение
5. Размер блока, который стоит пропускной способности и дискового пространство, по-прежнему учитываются.

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

Извиняюсь за некро-ки в этой теме, но OP кажется особенно уместным к проблемам Гэвина о UTXO наворотов: http://gavinandresen.ninja/utxo-uhoh

и последний пост Грегори:

котировка

Другой связанный пункт, который был подали раньше, но, похоже,
игнорировались в том, что изменения, как вычисляется предельный размер может помочь
лучше согласовать стимулы и тем самым уменьшить риск. Например. одной из основных затрат на
сеть является влиянием UTXO сделок, но так как предел слеп
для UTXO воздействия шахтер получит меньший доход, если существенно факторинга
Влияние UTXO в свои расчеты платы; и без платы пользователей антропогенного воздействия
мало причин, чтобы оптимизировать их поведение UTXO. Это может быть исправлено
путем увеличения "размер" используется для предельных расчетов. Примером может
быть tx_size = MAX (real_size >> 1, real_size + 4 * utxo_created_size -
3 * utxo_consumed_size). Причина MAX так, что блок
который чистил кучу большого UTXO не может разорвать программное обеспечение, будучи
супер большой, utxo_consumed в основном позволяет кредитовать свои сборы на
чистка набор utxo; но так как вы получаете меньше кредитов, чем стоит
Давление должно быть вниз, но не очень так. 1/2, 4, 3 я считаю
в качестве параметров, которые я не очень сильные мнения, по которым может быть
набор на основе наблюдений в сети сегодня (например, регулируют таким образом, что
нормальная сделка чистки может поразить минимальный размер).

http://sourceforge.net/p/bitcoin/mailman/message/34097489/

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

Да, это было в нескольких различных нитей, прежде чем (я даже не уверен, что если бы я знал об этом). Это кажется очевидным и правильным для учета влияния UTXO; хотя точные параметры кажутся менее ясно (хотя почти любой будет работоспособным,., хотя я предпочел бы не пойти реализовать отдельный журнал неподвижную точку для этого)

Он также никуда не делись, хотя эти вещи являются тривиальными для реализации; потому что в основном они более или менее сносно обходиться без них в нынешних пределах (хотя они бы хорошо, utxo все еще растет несколько пугающей скоростью, и пределы пыли любопытное уродливые хаки); и большая часть толчка для более крупных блоков начинаются с того, что существует не главный риск или компромисс стоит адресации, и тем метрической дополнительной сложность не звучит justified-- и в самом деле, почти все, что является более сложным, чем "изменить от 1 до 20",

Мне не нравится кадрирование "Шахтеры будут иметь стимул, чтобы исключить пыль" ... а, сделки имеют стоимость, изменение делает экономические издержки лучше выровнено с истинной стоимостью, а изменение означает операции придется платить пропорционально их costs-- в моем предложении он установлен так, что создание эффективно выводит предоплачивает большая часть стоимости их тратить; но нет никакой дискриминации "пыли"Шахтеры сделать не judgement-- не является экономически и это до пользователей, чтобы оправдать его.

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

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

Я хотел бы переписать следующим образом:

Мы будем формально определить "utxoSize", который

TXID (32 байта) + txoIndex (varInt) + длина scriptPubKey (varInt) + scriptPubKey (? байт) + значение (8 байт) + coinbase (1 байт) + высота coinbase блок (0 или 4 байта)

TXID является TXID из utxo
txoIndex является индекс utxo в ОМ, записывается как varInt
Длина scriptPubKey является длина scriptPubKey в utxo, в varInt
scriptPubKey является scriptPubKey из utxo
является значение utxo в Satoshis
coinbase является индикатором, чтобы показать, является ли utxo это coinbase награды
если это награда coinbase, более 4 байта необходимо записать высоту блока

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

Однако, если utxo содержит какую-либо одну из недействительного OP_CODE, например, OP_RETURN, OP_VERIF, OP_CAT который гарантирует сценарий неудачно, utxoSize устанавливается равным нулю.

Для каждого блока, необходимо рассчитать чистое изменение размера UTXO, который

Код:

utxoDiff = (общая utxoSize новых UTXOs) - (всего utxoSize стреляных UTXOs)

С utxoDiff, мы можем иметь мягкую вилку правило одного из следующих параметров:

1. Поместите жёстко прописанную шапку utxoDiff для каждого блока. Таким образом, мы будем уверены, что множество UTXO не будет расти слишком быстро; или
2. Если блок имеет небольшой (или даже отрицательный) utxoDiff, более высокий MAX_BLOCK_SIZE допускаются

Это будет стимулировать шахтер принимать Txs с небольшим или отрицательным utxoDiff, который будет держать UTXO набора мало.

Цитата: jl2012 09 мая 2015, 12:06:11 PM

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

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

Это экономит хранение информации в оперативной памяти, то есть владелец сделки хранит информацию.

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

База данных будет карта

Hash (key_salt | TXID | п) сопоставляется Hash (value_salt | минуса | высота | ...)

Если каждый хэш был уменьшен до нижних 8 байт, и было 10 миллионов в наборе UTXO, вероятность столкновения еще крошечная (около 1 в 180000).

Для того, чтобы ложно провести UTXO, взломщик нужно будет 2 ^ 63 попыток, но это требует Knowning value_salt целевого узла.

Используя эту систему, весь набор UTXO будет 16 байт на запись для ключа и значения.

Цитата: TierNolan 09 мая 2015 года, 2:29:22 PM

Цитата: jl2012 09 мая 2015, 12:06:11 PM

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

Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО.

Цитата: jl2012 09 мая 2015 года, 3:06:57 PM

Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО.

Я имел в виду, что информация не строго необходимо в базе данных UTXO (в целом). Расширенный формат транзакция может включать в себя scriptPubKey и значение (а также высоту, для coinbase проводит).

Это перемещает стоимость хранения, что данные из памяти в каждом узле тому, кто хочет провести сделку. P2SH выходы уже эффективно делать это (а не значение), но нет никаких оснований, что все сделки не может поддержать его.

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

Цитата: TierNolan 09 мая 2015 года, 3:16:44 PM

Цитата: jl2012 09 мая 2015 года, 3:06:57 PM

Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО.

хорошо, но я не понимаю смысл вашего: Hash (key_salt | TXID | п) сопоставляется Hash (value_salt | минуса | высота | ...)

Почему бы просто не использовать индекс Hash (соль | TXID | п | высота | scriptPubKey | значение)? Сообщение ETX будет предоставлять всю эту информацию (ожидать соль, которая является секретом узла).

Кроме того, сообщение ETX не нужно будет предоставить scriptPubKey если это стандартный один, как ~~P2PK~~, P2PKH или P2SH. Просто используйте байты, чтобы указать тип достаточно.

Цитата: jl2012 09 мая 2015 года, 3:32:57 PM

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

Это падает вещи до 8 байт на выход UTXO для сериализации и немного больше из-за накладные расходы HashSet для оперативной памяти.

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

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

Это означает, что (почти) вся сложность блок проверки (сценарий и крипта) обрабатываются внутри в библиотеке. Единственное, что внешний клиент должен быть это управлять UTXO дайджестов.

Может быть, лучше использовать хэш (соль | хэш (<Информация>)), Так что посол может быть сделан за пределами библиотеки консенсуса. Библиотека консенсуса будет использовать 32 байт дайджестов.

котировка

Кроме того, сообщение ETX не нужно будет предоставить scriptPubKey если это стандартный один, как P2PK, P2PKH или P2SH. Просто используйте байты, чтобы указать тип достаточно.

Он по-прежнему необходимо предоставить информацию для генерации scriptPubKey (адрес или сериализованная scriptPubKey).

Цитата: TierNolan 09 мая 2015 года, 4:16:50 PM

котировка

Он по-прежнему необходимо предоставить информацию для генерации scriptPubKey (адрес или сериализованная scriptPubKey).

Вам не нужен какая-либо дополнительная информация для P2PKH или P2SH, потому что вы можете восстановить scriptPubKey с scriptSig.

(Для P2PK и BIP11 мульти-сиг, однако, ETX должен обеспечить scriptPubKey)

Цитата: jl2012 09 мая 2015 года, 4:38:21 PM

Вам не нужен какая-либо дополнительная информация для P2PKH или P2SH, потому что вы можете восстановить scriptPubKey с scriptSig.

Да, конечно, извините.

Цитата: jl2012 09 мая 2015, 12:06:11 PM

Код:

utxoDiff = (общая utxoSize новых UTXOs) - (всего utxoSize стреляных UTXOs)

С utxoDiff, мы можем иметь мягкую вилку правило одного из следующих параметров:

1. Поместите жёстко прописанную шапку utxoDiff для каждого блока. Таким образом, мы будем уверены, что множество UTXO не будет расти слишком быстро; или
2. Если блок имеет небольшой (или даже отрицательный) utxoDiff, более высокий MAX_BLOCK_SIZE допускаются

Если мы можем сделать размер записи utxo постоянная (как предполагает, по TierNolan) для любого типа utxo, это может быть упрощено

Код:

utxoDiff = (# новых потенциально расходуемого UTXOs) - (# стреляных UTXOs)
где
(# Новых потенциально расходуемого UTXOs) = (# новых UTXOs) - (# новых UTXOs с недопустимой OP_CODE)

Все UTXOs считаются потенциально расходуемого, если не доказано иное

15 марта 2013, 3:45:52 PM	# 1
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Это является устаревшим. Смотрите мое новое предложение ниже: Мы должны поощрять "хорошие сделки", Которые являются: 1. малы по размеру, 2. с меньшим количеством выходов, 3. с практически расходуемыми выходами Цели 2, 3 имеют важное значение для поддержания разумного размера UTXO набора. Действующее ограничение размера блока, однако, учитывает только цель 1. Шахтеров будут принимать загрязняющие операции (с большим количеством практически unspendable выходов) до тех пор, достаточно пошлины. Тем не менее, каждые полные узлы должны поддерживать завышенный набор UTXO. Если предельный размер блока должен быть увеличен, то это может быть определено более факторов, а не только абсолютный размер. У меня есть общее представление о том: Обозначим: S₀, S₁,.....,S_N: Количество Satoshis выходного 0, 1 ..... п. Размер: размер сделки в кбайт. Регулировать размер сделки определяется следующим образом: Размер * (1 / (журнал₂S₀+1) + 1 / (журнал₂S₁+1) + .. + 1 / (журнал₂S_N+1)) Значение 1 / (журнал₂S_N+1) увеличивается экспоненциально по мере выходной размер уменьшается. Значение равно 1: 1, 0,5 Satoshi для 2 Satoshi, 0,13 за 1 uBTC, 0,057 для 1mBTC и 0,036 на 1 BTC. Регулировать размер блока определяется как сумма скорректированного размера сделки. Если реальный размер блока < 1MB, скорректированный размер блока не считают. Если реальный размер блока > 1 Мб, скорректированный размер блока должен быть меньше некоторой константы. Многие проблемы решаются с помощью системы, как это: 1. Размер блока по-прежнему паника. Если это < 1 Мб, это эквивалентно текущий предел. Если это > 1 Мб, "хорошие сделки" являются приоритетными 2. Шахтеры будут иметь стимул, чтобы исключить выходы пыли, потому что увеличит скорректированный размер блока 3. Шахтеры будут любить операции с меньшим количеством выходов, так что множество UTXO может быть уменьшено. 4. Людям, пытающихся отправить выходы пыли и / или завышать набор UTXO придется платить больше гонорара шахтера, чтобы компенсировать их загрязнение 5. Размер блока, который стоит пропускной способности и дискового пространство, по-прежнему учитываются. Так должно быть трудно вилка при подъеме максимального размера блока, добавляя дополнительные правила, как это не сделает изменения более сложным.

15 марта 2013, 3:50:44 PM	# 2
justusranvier Сообщения: 1400 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Получил 1806 Биткоинов Реальная история. Цитата: jl2012 15 марта 2013 года, 3:45:52 PM Мы должны Начало добычи бассейна. Вы можете реализовать любой править вы хотите в отношении которых сделки получить включены и которые этого не делают. Убедить другие шахтер, что ваши правила являются лучшими, и они будут голосовать с их хешированием силой.

15 марта 2013, 4:25:17 PM	# 3
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: justusranvier 15 марта 2013 года, 3:50:44 PM Цитата: jl2012 15 марта 2013 года, 3:45:52 PM Мы должны Начало добычи бассейна. Вы можете реализовать любой править вы хотите в отношении которых сделки получить включены и которые этого не делают. Убедить другие шахтер, что ваши правила являются лучшими, и они будут голосовать с их хешированием силой. Нет, это трудно вилкой.

15 марта 2013, 4:29:30 PM	# 4
justusranvier Сообщения: 1400 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 15 марта 2013 года, 4:25:17 PM Нет, это трудно вилкой. Допустим, что ваш блок по-прежнему должен быть действителен в течение остальной части сети, чтобы принять его. Но ваша цель "поощрение хороших сделок" не требует каких-либо изменений в протокол. Вы можете отказаться от любых без хороших сделок в бассейне и просто попросить другие шахтер, чтобы поддержать вас по добыче в бассейне. Разве это не лучшее решение, чем положить обязательные правила отбора плата в протоколе?

15 марта 2013, 4:33:09 PM	# 5
MarkM Сообщения: 2002 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Ну давай сейчас, конечно, очевидно, что другие люди не были вынуждены подчиняться "" правила является doubleplus-ungood? -MarkM-

15 марта 2013, 4:47:05 PM	# 6
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: justusranvier 15 марта 2013 года, 4:29:30 PM Цитата: jl2012 15 марта 2013 года, 4:25:17 PM Нет, это трудно вилкой. Допустим, что ваш блок по-прежнему должен быть действителен в течение остальной части сети, чтобы принять его. Но ваша цель "поощрение хороших сделок" не требует каких-либо изменений в протокол. Вы можете отказаться от любых без хороших сделок в бассейне и просто попросить другие шахтер, чтобы поддержать вас по добыче в бассейне. Разве это не лучшее решение, чем положить обязательные правила отбора плата в протоколе? Это на самом деле ответ на другой поток: Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO

15 марта 2013, 8:11:48 PM	# 7
d'Aniel Сообщения: 461 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 15 марта 2013 года, 4:47:05 PM Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO Эта. Аргумент, что предельный размер блока необходим для предотвращения чрезмерной централизации в равной степени относится к пределу на каждый блок расширения набора utxo. Так что я думаю, что это оправдывает создание такого предела, если предельный размер блока должен быть сохранен. Кроме того, я не понимаю, почему мы должны были бы иметь одну метрику, чтобы описать использование в двух ограниченных ресурсов, блок пространства и utxo установить пространство. Не было бы проще просто иметь отдельные лимиты для обоих? Они потребляют различные физические ресурсы - пропускную способность и хранение, соответственно - и поэтому эти параметры должны быть несколько ортогональны.

16 марта 2013, 12:56:37 AM	# 8
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: d'Aniel 15 марта 2013 года, 8:11:48 PM Цитата: jl2012 15 марта 2013 года, 4:47:05 PM Используя это предложение, мы можем увеличить максимальный размер блока без вздутия живота набора UTXO Эта. Аргумент, что предельный размер блока необходим для предотвращения чрезмерной централизации в равной степени относится к пределу на каждый блок расширения набора utxo. Так что я думаю, что это оправдывает создание такого предела, если предельный размер блока должен быть сохранен. Кроме того, я не понимаю, почему мы должны были бы иметь одну метрику, чтобы описать использование в двух ограниченных ресурсов, блок пространства и utxo установить пространство. Не было бы проще просто иметь отдельные лимиты для обоих? Они потребляют различные физические ресурсы - пропускную способность и хранение, соответственно - и поэтому эти параметры должны быть несколько ортогональны. Согласовано. Мы можем иметь индекс UTXO, который является общее число выходов в блоке минус общее число входов в блоке, и имеют жесткий предел для него

16 марта 2013, 1:07:41 AM	# 9
Ari Сообщений: 75 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Был нить на Bitcoin-развития об этом тоже ... http://sourceforge.net/mailarchive/forum.php?thread_name=CABOyFfrPTYeq-g5tgte2HWfvBiBcRLw_Bvyk_X2hXMWVoW3dgQ%40mail.gmail.com&FORUM_NAME = Bitcoin-разработка

9 мая 2015, 11:01:03 AM	# 10
Solex Сообщения: 1078 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 15 марта 2013 года, 3:45:52 PM ... Если реальный размер блока < 1MB, скорректированный размер блока не считают. Если реальный размер блока > 1 Мб, скорректированный размер блока должен быть меньше некоторой константы. Многие проблемы решаются с помощью системы, как это: 1. Размер блока по-прежнему паника. Если это < 1 Мб, это эквивалентно текущий предел. Если это > 1 Мб, "хорошие сделки" являются приоритетными 2. Шахтеры будут иметь стимул, чтобы исключить выходы пыли, потому что увеличит скорректированный размер блока 3. Шахтеры будут любить операции с меньшим количеством выходов, так что множество UTXO может быть уменьшено. 4. Людям, пытающихся отправить выходы пыли и / или завышать набор UTXO придется платить больше гонорара шахтера, чтобы компенсировать их загрязнение 5. Размер блока, который стоит пропускной способности и дискового пространство, по-прежнему учитываются. Так должно быть трудно вилка при подъеме максимального размера блока, добавляя дополнительные правила, как это не сделает изменения более сложным. Извиняюсь за некро-ки в этой теме, но OP кажется особенно уместным к проблемам Гэвина о UTXO наворотов: http://gavinandresen.ninja/utxo-uhoh и последний пост Грегори: котировка Другой связанный пункт, который был подали раньше, но, похоже, игнорировались в том, что изменения, как вычисляется предельный размер может помочь лучше согласовать стимулы и тем самым уменьшить риск. Например. одной из основных затрат на сеть является влиянием UTXO сделок, но так как предел слеп для UTXO воздействия шахтер получит меньший доход, если существенно факторинга Влияние UTXO в свои расчеты платы; и без платы пользователей антропогенного воздействия мало причин, чтобы оптимизировать их поведение UTXO. Это может быть исправлено путем увеличения "размер" используется для предельных расчетов. Примером может быть tx_size = MAX (real_size >> 1, real_size + 4 * utxo_created_size - 3 * utxo_consumed_size). Причина MAX так, что блок который чистил кучу большого UTXO не может разорвать программное обеспечение, будучи супер большой, utxo_consumed в основном позволяет кредитовать свои сборы на чистка набор utxo; но так как вы получаете меньше кредитов, чем стоит Давление должно быть вниз, но не очень так. 1/2, 4, 3 я считаю в качестве параметров, которые я не очень сильные мнения, по которым может быть набор на основе наблюдений в сети сегодня (например, регулируют таким образом, что нормальная сделка чистки может поразить минимальный размер). http://sourceforge.net/p/bitcoin/mailman/message/34097489/ Выравнивание спроса на более крупные блоки с давлением, чтобы поддерживать более чистый набор UTXO, может быть более конструктивной, полезной в долгосрочной перспективе, и более приоритетной задачей, чем опасения по поводу дальнейшего давления на рынке сборов.

9 мая 2015, 11:46:58 AM	# 11
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Да, это было в нескольких различных нитей, прежде чем (я даже не уверен, что если бы я знал об этом). Это кажется очевидным и правильным для учета влияния UTXO; хотя точные параметры кажутся менее ясно (хотя почти любой будет работоспособным,., хотя я предпочел бы не пойти реализовать отдельный журнал неподвижную точку для этого) Он также никуда не делись, хотя эти вещи являются тривиальными для реализации; потому что в основном они более или менее сносно обходиться без них в нынешних пределах (хотя они бы хорошо, utxo все еще растет несколько пугающей скоростью, и пределы пыли любопытное уродливые хаки); и большая часть толчка для более крупных блоков начинаются с того, что существует не главный риск или компромисс стоит адресации, и тем метрической дополнительной сложность не звучит justified-- и в самом деле, почти все, что является более сложным, чем "изменить от 1 до 20", Мне не нравится кадрирование "Шахтеры будут иметь стимул, чтобы исключить пыль" ... а, сделки имеют стоимость, изменение делает экономические издержки лучше выровнено с истинной стоимостью, а изменение означает операции придется платить пропорционально их costs-- в моем предложении он установлен так, что создание эффективно выводит предоплачивает большая часть стоимости их тратить; но нет никакой дискриминации "пыли"Шахтеры сделать не judgement-- не является экономически и это до пользователей, чтобы оправдать его. Я не люблю, когда значения txout в терминах, потому что имеет неявный масштабный коэффициент между стоимостью монет и значения байтов, а потому, что значение на самом деле не связаны с затратами на сеть. Моя формула работает с байтами все вокруг, хотя есть некоторые масштабировании, поскольку подпись, как правило, намного больше, чем выходы и ограничения, потому что я пытаюсь избежать некоторых крайних случаев, как шахтеры вздутия живота набора utxo с дёшево расходуемыми выходами для того, чтобы хранить, и -forward их размер блока.

9 мая 2015, 12:06:11 PM	# 12
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Я написал это очень давно, когда я знал, что Bitcoin не очень хорошо. Но я всегда думаю, что это должно быть сделано, если увеличить максимальный размер блока. Я хотел бы переписать следующим образом: Мы будем формально определить "utxoSize", который TXID (32 байта) + txoIndex (varInt) + длина scriptPubKey (varInt) + scriptPubKey (? байт) + значение (8 байт) + coinbase (1 байт) + высота coinbase блок (0 или 4 байта) TXID является TXID из utxo txoIndex является индекс utxo в ОМ, записывается как varInt Длина scriptPubKey является длина scriptPubKey в utxo, в varInt scriptPubKey является scriptPubKey из utxo является значение utxo в Satoshis coinbase является индикатором, чтобы показать, является ли utxo это coinbase награды если это награда coinbase, более 4 байта необходимо записать высоту блока Я думаю, что это минимальное количество данных, необходимых для хранения utxo. множество utxo должен показать, является ли utxo от coinbase в связи с правилом 100-блок. Однако, если utxo содержит какую-либо одну из недействительного OP_CODE, например, OP_RETURN, OP_VERIF, OP_CAT который гарантирует сценарий неудачно, utxoSize устанавливается равным нулю. Для каждого блока, необходимо рассчитать чистое изменение размера UTXO, который Код: utxoDiff = (общая utxoSize новых UTXOs) - (всего utxoSize стреляных UTXOs) С utxoDiff, мы можем иметь мягкую вилку правило одного из следующих параметров: 1. Поместите жёстко прописанную шапку utxoDiff для каждого блока. Таким образом, мы будем уверены, что множество UTXO не будет расти слишком быстро; или 2. Если блок имеет небольшой (или даже отрицательный) utxoDiff, более высокий MAX_BLOCK_SIZE допускаются Это будет стимулировать шахтер принимать Txs с небольшим или отрицательным utxoDiff, который будет держать UTXO набора мало.

9 мая 2015, 2:29:22 PM	# 13
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 09 мая 2015, 12:06:11 PM Я думаю, что это минимальное количество данных, необходимых для хранения utxo. множество utxo должен показать, является ли utxo от coinbase в связи с правилом 100-блок. UTXO только действительно должно содержать хэш выходной точки (и высоту). Транзакция расходов должна включать в себя всю информацию, необходимую, когда расходы. Это экономит хранение информации в оперативной памяти, то есть владелец сделки хранит информацию. Он даже не будет необходимости хранить весь хэш. Узел могут соль хэш и столкновения были бы очень маловероятно. База данных будет карта Hash (key_salt \| TXID \| п) сопоставляется Hash (value_salt \| минуса \| высота \| ...) Если каждый хэш был уменьшен до нижних 8 байт, и было 10 миллионов в наборе UTXO, вероятность столкновения еще крошечная (около 1 в 180000). Для того, чтобы ложно провести UTXO, взломщик нужно будет 2 ^ 63 попыток, но это требует Knowning value_salt целевого узла. Используя эту систему, весь набор UTXO будет 16 байт на запись для ключа и значения.

9 мая 2015, 3:06:57 PM	# 14
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: TierNolan 09 мая 2015 года, 2:29:22 PM Цитата: jl2012 09 мая 2015, 12:06:11 PM Я думаю, что это минимальное количество данных, необходимых для хранения utxo. множество utxo должен показать, является ли utxo от coinbase в связи с правилом 100-блок. UTXO только действительно должно содержать хэш выходной точки (и высоту). Транзакция расходов должна включать в себя всю информацию, необходимую, когда расходы. Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО.

9 мая 2015, 3:16:44 PM	# 15
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 09 мая 2015 года, 3:06:57 PM Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО. Я имел в виду, что информация не строго необходимо в базе данных UTXO (в целом). Расширенный формат транзакция может включать в себя scriptPubKey и значение (а также высоту, для coinbase проводит). Это перемещает стоимость хранения, что данные из памяти в каждом узле тому, кто хочет провести сделку. P2SH выходы уже эффективно делать это (а не значение), но нет никаких оснований, что все сделки не может поддержать его. Во время transitiion, ТЕ сообщения могут быть преобразованы в ETX сообщения полных узлов. В конце концов, ТЕ сообщения могут амортизироваться. Бумажник программного обеспечение будет иметь для управления информацией для любых монет, проведенных в его кошельке.

9 мая 2015, 3:32:57 PM	# 16
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: TierNolan 09 мая 2015 года, 3:16:44 PM Цитата: jl2012 09 мая 2015 года, 3:06:57 PM Как насчет scriptPubKey и стоимости utxo? Они не являются частью расходов ОГО. Я имел в виду, что информация не строго необходимо в базе данных UTXO (в целом). Расширенный формат транзакция может включать в себя scriptPubKey и значение (а также высоту, для coinbase проводит). Это перемещает стоимость хранения, что данные из памяти в каждом узле тому, кто хочет провести сделку. P2SH выходы уже эффективно делать это (а не значение), но нет никаких оснований, что все сделки не может поддержать его. Во время transitiion, ТЕ сообщения могут быть преобразованы в ETX сообщения полных узлов. В конце концов, ТЕ сообщения могут амортизироваться. Бумажник программного обеспечение будет иметь для управления информацией для любых монет, проведенных в его кошельке. хорошо, но я не понимаю смысл вашего: Hash (key_salt \| TXID \| п) сопоставляется Hash (value_salt \| минуса \| высота \| ...) Почему бы просто не использовать индекс Hash (соль \| TXID \| п \| высота \| scriptPubKey \| значение)? Сообщение ETX будет предоставлять всю эту информацию (ожидать соль, которая является секретом узла). Кроме того, сообщение ETX не нужно будет предоставить scriptPubKey если это стандартный один, как ~~P2PK~~, P2PKH или P2SH. Просто используйте байты, чтобы указать тип достаточно.

9 мая 2015, 4:16:50 PM	# 17
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 09 мая 2015 года, 3:32:57 PM хорошо, но я не понимаю смысл вашего: Hash (key_salt \| TXID \| п) сопоставляется Hash (value_salt \| минуса \| высота \| ...) Почему бы просто не использовать индекс Hash (соль \| TXID \| п \| высота \| scriptPubKey \| значение)? Сообщение ETX будет предоставлять всю эту информацию (ожидать соль, которая является секретом узла). Я думал, вы должны быть в состоянии найти его из базы данных, поэтому необходимо (TXID \| п) является ключевым. Тем не менее, вы правы хэш набор достаточно, если ETX имеет всю необходимую дополнительную информацию. Это падает вещи до 8 байт на выход UTXO для сериализации и немного больше из-за накладные расходы HashSet для оперативной памяти. Там может быть eblock тоже. Это позволяет практически полную проверку блока без необходимости какой-либо информации вне eblock. Только проверка, что UTXOs все на самом деле существует. Я думаю, что это поможет с библиотекой консенсуса. Вы передаете это сообщение об eblock и возвращает список UTXOs, который должен существовать для блока, чтобы быть действительными, а также список новых UTXO хэш. Это означает, что (почти) вся сложность блок проверки (сценарий и крипта) обрабатываются внутри в библиотеке. Единственное, что внешний клиент должен быть это управлять UTXO дайджестов. Может быть, лучше использовать хэш (соль \| хэш (<Информация>)), Так что посол может быть сделан за пределами библиотеки консенсуса. Библиотека консенсуса будет использовать 32 байт дайджестов. котировка Кроме того, сообщение ETX не нужно будет предоставить scriptPubKey если это стандартный один, как P2PK, P2PKH или P2SH. Просто используйте байты, чтобы указать тип достаточно. Он по-прежнему необходимо предоставить информацию для генерации scriptPubKey (адрес или сериализованная scriptPubKey).

9 мая 2015, 4:38:21 PM	# 18
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: TierNolan 09 мая 2015 года, 4:16:50 PM котировка Кроме того, сообщение ETX не нужно будет предоставить scriptPubKey если это стандартный один, как P2PK, P2PKH или P2SH. Просто используйте байты, чтобы указать тип достаточно. Он по-прежнему необходимо предоставить информацию для генерации scriptPubKey (адрес или сериализованная scriptPubKey). Вам не нужен какая-либо дополнительная информация для P2PKH или P2SH, потому что вы можете восстановить scriptPubKey с scriptSig. (Для P2PK и BIP11 мульти-сиг, однако, ETX должен обеспечить scriptPubKey)

9 мая 2015, 4:47:07 PM	# 19
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 09 мая 2015 года, 4:38:21 PM Вам не нужен какая-либо дополнительная информация для P2PKH или P2SH, потому что вы можете восстановить scriptPubKey с scriptSig. Да, конечно, извините.

9 мая 2015, 4:48:54 PM	# 20
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Максимальный размер блока должен также учитывать размер UTXO набора Цитата: jl2012 09 мая 2015, 12:06:11 PM Я написал это очень давно, когда я знал, что Bitcoin не очень хорошо. Но я всегда думаю, что это должно быть сделано, если увеличить максимальный размер блока. Я хотел бы переписать следующим образом: Мы будем формально определить "utxoSize", который TXID (32 байта) + txoIndex (varInt) + длина scriptPubKey (varInt) + scriptPubKey (? байт) + значение (8 байт) + coinbase (1 байт) + высота coinbase блок (0 или 4 байта) TXID является TXID из utxo txoIndex является индекс utxo в ОМ, записывается как varInt Длина scriptPubKey является длина scriptPubKey в utxo, в varInt scriptPubKey является scriptPubKey из utxo является значение utxo в Satoshis coinbase является индикатором, чтобы показать, является ли utxo это coinbase награды если это награда coinbase, более 4 байта необходимо записать высоту блока Я думаю, что это минимальное количество данных, необходимых для хранения utxo. множество utxo должен показать, является ли utxo от coinbase в связи с правилом 100-блок. Однако, если utxo содержит какую-либо одну из недействительного OP_CODE, например, OP_RETURN, OP_VERIF, OP_CAT который гарантирует сценарий неудачно, utxoSize устанавливается равным нулю. Для каждого блока, необходимо рассчитать чистое изменение размера UTXO, который Код: utxoDiff = (общая utxoSize новых UTXOs) - (всего utxoSize стреляных UTXOs) С utxoDiff, мы можем иметь мягкую вилку правило одного из следующих параметров: 1. Поместите жёстко прописанную шапку utxoDiff для каждого блока. Таким образом, мы будем уверены, что множество UTXO не будет расти слишком быстро; или 2. Если блок имеет небольшой (или даже отрицательный) utxoDiff, более высокий MAX_BLOCK_SIZE допускаются Это будет стимулировать шахтер принимать Txs с небольшим или отрицательным utxoDiff, который будет держать UTXO набора мало. Если мы можем сделать размер записи utxo постоянная (как предполагает, по TierNolan) для любого типа utxo, это может быть упрощено Код: utxoDiff = (# новых потенциально расходуемого UTXOs) - (# стреляных UTXOs) где (# Новых потенциально расходуемого UTXOs) = (# новых UTXOs) - (# новых UTXOs с недопустимой OP_CODE) Все UTXOs считаются потенциально расходуемого, если не доказано иное

Заголовок