Это мнение автора статьи Cointelegraph, на мой взгляд, высосанное из пальца ради дешёвого хайпа. Однако, в самом заявлении Bitcoin Core никакие ограничительные формулировки типа "minimally permissive" не используются. Смысл этого relay policy сводится к тому, что если майнеры хотят майнить жирные блоки, содержащие нефинансовые данные, то и флаг им в руки, а мы, разработчики, препятствовать этому не намерены.

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

Разработчики Bitcoin Core вдруг подумали: а давайте уберём это дурацкое ограничение, пусть транзакции станут большими на радость майнерам. Предложение было воспринято неоднозначно. Luke Dashjr давно известен, как непримиримый противник использования транзакций Bitcoin для передачи произвольных данных. На пике популярности Ординалов, вызвавших огромные комиссии в сети Bitcoin, Luke Dashjr предложил ввести дополнительные ограничения в политику ретрансляции Bitcoin Core, для противодействия распространению транзакций, содержащих Ординалы. Это предложение было отвергнуто другими разработчиками Bitcoin Core.

Luke Dashjr является разработчиком альтернативной реализации ноды Bitcoin - Bitcoin Knots, и там он реализовал ограничения на ретрансляцию Ординалов, которые предлагались для реализации в Bitcoin Core, но не были приняты. И теперь, когда появилась новая угроза спама в блокчейне, Bitcoin Knots будет этому противодействовать, сохраняя действующее ограничение OP_RETURN. Возможно, такая позиция Luke Dashjr и послужила причиной роста числа нод Bitcoin Knots.

На фоне всей этой ситуации и появилось заявление разработчиков Bitcoin Core о политике ретрансляции, которое в весьма расплывчатой и завуалированной форме оправдывает решение о снятии ограничения на длину выхода OP_RETURN. А автор статьи, опубликованной в Cointelegraph, вывернул всё наизнанку, что дескать разработчики Bitcoin Core выступают за ужесточение политики ретрансляции, а Luke Dashjr - против любой цензуры, хотя, на самом деле, ситуация обратная.

Ретрансляция нестандартных транзакций нодой Bitcoin Core уже и так давным-давно запрещена, поэтому из новости совершенно непонятно, в чём заключается новая позиция разработчиков.

Разработчики Bitcoin Core предлагают снять ограничение на длину выхода OP_RETURN, то есть, наоборот, разрешить ретранслировать ранее запрещённые для ретрансляции транзакции.

Когда фактический баланс достигнет 101.25, эффективный баланс станет 101.
Баланс - 102.25, эффективный баланс - 102 и т. д.

Эффективный баланс изменяется с шагом 1 ETH, но триггером для этого изменения служит пересечение фактическим балансом отметки 0.25. 

Если, например, есть 2 валидатора по 32 ETH, то особого смысла сливать их в один валидатор нет. Но если, вдобавок к этому, ещё имеются 10 ETH, которые лежат мёртвым грузом и не участвуют в валидации, тогда есть смысл создать один валидатор на 74 ETH, в составе которого эти 10 ETH уже будут приносить какую-то копеечку.

Для любого адреса Bitcoin существует 2⁹⁶ приватных ключа. И, разумеется, у адреса 1FuckiRGCTerroristsNoBiTEXXXaAovLX тоже есть 2⁹⁶ приватных ключа, но это не значит, что хоть один ключ из этого множества кому-либо известен.

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

Что именно получается?

Вот ваша сумма без модуля:
a+b = 173688133855974293135356477513031861779256346418612356573907744712277242241495

Эта же сумма в 16-ричном представлении:
a+b = 17FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE18064B5A06ECF0599FBB8DD3385161D7

ice.scalar.multiplication() вместо того, чтобы перед умножением взять это число по модулю n, тупо отбрасывает старший бит, то есть, на вход умножителя на G подаётся число 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE18064B5A06ECF0599FBB8DD3385161D7

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

Неправильно вы складываете.
Правильно: (a + b) mod n

Там просто очередная тупая картинка.

Rеnminbi или по-русски жэньминьби. Китайцы так юань называют.

Например, вот:
lightningd: use P2TR for anchor spends

Смотрите, вот есть Bitcoin - это сеть для передачи и хранения транзакций. Посредством транзакций передаются некие денежные единицы, которые обозначаются как BTC. Правила эмиссии BTC вcтроены в программный код сети Bitcoin. В BTC выплачивается вознаграждение майнерам и взимается комиссия за транзакции с пользователей сети Bitcoin. BTC являются неотъемлемой частью Bitcoin. BTC можно назвать нативными токенами сети Bitcoin.

Посредством транзакций можно передавать не только BTC, но и произвольную информацию, например, строку "Мама мыла раму", заплатив  комиссию всё в тех же BTC. Или вместо "Мама мыла раму" можно записать "Передаю 10 единиц токена BOLT". Получается, теперь на адрес Bitcoin можно отправить не только BTC, но и BOLT. При этом, этот токен BOLT никак не связан с нативным токеном BTC, ни стоимостью, ни алгоритмом эмиссии. Автор токена BOLT может выпустить произвольное количество токенов BOLT и распоряжаться ими по своему усмотрению.

То есть, используя сеть Bitcoin в качестве транспорта, можно передавать и хранить не только нативные токены BTC, но и выпускать, уничтожать и передавать множество токенов со своими собственными объёмами и алгоритмами эмиссии. Комиссию за транзакции, при этом, необходимо платить в нативных токенах BTC.

В сети Ethereum всё то же самое: ETH - нативный токен сети, а USDT - токен популярного стейблкойна. Разница в том, что смарт-контракты Ethereum дают большую гибкость, например, можно организовать обмен одних токенов на другие прямо внутри сети.

Придуманный мной ради примера токен BOLT существует только в сети Bitcoin, поэтому, говоря о конкретном токене полезно обозначить в какой сети он существует. Можно сказать: BOLT - это токен в сети Bitcoin, или проще: BOLT - токен Bitcoin, но повторюсь, BOLT, при этом, никак не связан с BTC. 

Да. И вероятность предложения блока пропорционально больше и вознаграждение за аттестацию тоже пропорционально больше. Даже у валидатора с 33 ETH эти параметры пропорционально больше.

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

Сейчас, до форка вы не сможете объединить валидаторов, потому что не сможете создать валидатора типа 2. А после форка у всех валидаторов будут три варианта:

1. Оставить всё как есть. Валидаторы типа 1 будут продолжать работать без изменений.

2. Консолидировать несколько валидаторов типа 1 в один валидатор типа 2. После форка появится возможность при помощи транзакции на специальный смартконтракт объединить существующих валидаторов в один валидатор нового типа. Это будет возможно, только если все валидаторы имеют один и тот же адрес вывода (withdrawal address).

3. Сделать выход для всех валидаторов типа 1 и создать с нуля валидатор типа 2.

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

Форк Pectra даст новый тип валидатора, более гибкий с экономической точки зрения. Если раньше доход давал баланс ноды с шагом 32 ETH, то есть, 32, 64, 96, 128 и т. д., и, например, баланс 38 ETH давал тот же доход, что и 32 ETH, то теперь доход будет давать баланс с шагом 1 ETH, то есть, 32, 33, 34, 35 и т. д.

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

Я думаю, у разработчиков Биткойна был такой взгляд на ситуацию:

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

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

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

Разрабы Биткойна исправили свой баг на уровне всей сети, а разрабы Эфира устранили последствия чужого бага для одного конкретного пользователя сети, поставив его в привилегированное положение по отношению к другим пользователям. В первом случае никто ничего не заметил (кроме Амаклина) и урон репутации разработчиков нанесён не был, а во втором случае - совсем наоборот.

Отправка 32 ETH на депозитный контракт даёт право на исполнение обязанностей валидатора. Валидатор занимается аттестацией, то есть, верификацией чужих блоков, и предложением своих блоков. За исполнение этих обязанностей валидатор получает вознаграждение, и наоборот, за неисполнение обязанностей валидатор подвергается штрафам, в результате чего его баланс уменьшается.

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

Информация для валидаторов

Разработчики Geth выпустили релиз, закрывающий уязвимость CVE-2025-24883, и просят как можно скорее обновиться. Судя по отсутствию описания уязвимости - это что-то серьёзное.