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

Вот ваша сумма без модуля:
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, и просят как можно скорее обновиться. Судя по отсутствию описания уязвимости - это что-то серьёзное.

Прошло два года...

https://uablocklist.com/ru/news/derzhspetszviazku-blokuie-kryptobirzhu-kuna

Binance - KUNA - 1:0

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

То есть, грязная крипта - это крипта с историей. И обратный пример: намайненная крипта - это чистая крипта без истории.

Хранится в blocks/xor.dat
Отключается параметром запуска -blocksxor=0

Merged mining. Доге и Лайт майнятся на одном и том же железе одновременно. Сейчас майнеры пашут ради Догов, а Лайт получают, как бесплатный эйрдроп, который не жалко слить по любой цене.