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

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

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

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

Я разветвил версию своего инструмента, выделив 5 транзакций sat/B синим цветом (можно найти здесь , не стесняйтесь исследовать). Поскольку это все еще находится в активной разработке, я добавлю скриншоты некоторых блоков на случай, если ссылки перестанут работать. Я намеренно выбрал набор блоков, из которых, думаю, понятно, что я имею в виду.

Образцы блоков:

Блок 517361Блок № 517361 , добытый ViaBTC (?)

Блок 517363Блок № 517363 , добытый BTC.TOP (?)

Блок 517357Блок № 517357 , добытый BTC.com (?)

а вот и от Slush тоже.

Вопросы:

1) Это известное поведение алгоритма, создающего шаблоны блоков?

2) Какая мотивация стоит за этой функцией. Это ошибка?

3) Существуют ли широко используемые getblocktemplateальтернативы?

Ответы (2)

1) Это известное поведение алгоритма, создающего шаблоны блоков?

Да. Это поведение присутствует в Bitcoin Core.

Bitcoin Core объединяет транзакции в «пакеты» из одной или нескольких транзакций. Каждый пакет состоит из неподтвержденной транзакции и ее дочерних элементов (если они есть), чтобы покрыть случай Child-Pays-For-Parent. Ставка комиссии за транзакцию рассчитывается для всего пакета (общая сумма комиссий, уплачиваемых транзакциями в пакете, делится на размер пакета).

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

Это называется «упорядочивание ставок сборов по предкам».

2) Какая мотивация стоит за этой функцией. Это ошибка?

Это не фича и не баг, это просто особенность работы выбора транзакций.

Смотрите также: https://bitcointalk.org/index.php?topic=2058831.0

Спасибо Андрей, но это не совсем ответ на мой вопрос. Я упомянул транзакции CPFP в своем вопросе с типичной транзакцией с более низкой комиссией, за которой следует транзакция с высокой / более высокой комиссией, которые легко увидеть на визуализации. Но это не то, что я имею в виду. Например, в блоке № 517363 ~ 30 5 спутников/B tx, за которыми следует один 9 sat/B tx, а затем снова несколько 5 sat/B tx (около позиции 1200). Это (я думаю, по крайней мере, я проверю позже) не похоже на CPFP или, по крайней мере, не является правильной позицией в блоке для большого пакета из этих 31 транзакций. (30*5sat/B + 1*9sat/B)/31tx будет позже в блоке.
Я думаю, что вы на самом деле считаете ferate неправильно. Я дважды проверил, и я не получаю таких же комиссионных, как вы, для этих транзакций с заданными блочными индексами. Числа, которые у вас есть, совпадают с sat/byte, а не sat/vbyte. Я думаю, что вы неправильно рассчитываете комиссионные за транзакции, расходующие входы SegWit.
да вы правы. Я обнаружил это примерно 5 минут назад, просматривая транзакции, упомянутые выше. Спасибо!
Кроме того, я написал быстрый скрипт на Python для вычисления того, какие транзакции упакованы вместе в данном блоке: gist.github.com/achow101/dfb1016f78e653656ec40cd019f8116b . Я думаю, это работает.

Как заметил Эндрю Чоу, мои расчеты скорости были неверны. Я использовал totalSize транзакции. Правильным было бы использовать виртуальный размер.

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

Блок 517361Блок № 517361 (сравните выше)

Откуда берется эта закономерность в распределении ставок по блокам?
СпросиСетьПолитика конфиденциальности1y, 0v