Доверие в долг. Криптовалюты как деньги и кредит: механизм, циклы, правила

329

James Howells v Newport City Council [2025] EWHC 22 (Ch), 09.01.2025, https://caselaw.nationalarchives.gov.uk/ewhc/ch/2025/22.

330

James Howells v Newport City Council [2025] EWHC 22 (Ch), 09.01.2025, судья Кизер; основание — Control of Pollution Act 1974: «Bitcoin are not tangible property and cannot be on the Hard Drive or in the Landfill.» Что на диске был ключ, — версия истца; суд её не проверял и решил дело по праву собственности на сам диск. Подробнее о деле — в главе 12.

331

James Howells v Newport City Council [2025] EWHC 22 (Ch), 09.01.2025, https://caselaw.nationalarchives.gov.uk/ewhc/ch/2025/22.

332

Mastering Bitcoin, 3rd ed., 2023, гл. 4.

333

BIP-39 «Mnemonic code for generating deterministic keys», Palatinus M., Rusnak P., Voisine A., Bowe S., created 10.09.2013, https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki; Mastering Bitcoin, 3rd ed., гл. 5.

334

BIP-39 «Mnemonic code for generating deterministic keys», Palatinus M., Rusnak P., Voisine A., Bowe S., created 10.09.2013, https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki; Mastering Bitcoin, 3rd ed., гл. 5.

335

James Howells v Newport City Council [2025] EWHC 22 (Ch), 09.01.2025, https://caselaw.nationalarchives.gov.uk/ewhc/ch/2025/22.

336

Chainalysis, «60% of Bitcoin is Held Long Term as Digital Gold. What About the Rest?», 18.06.2020, https://www.chainalysis.com/blog/bitcoin-market-data-exchanges-trading/; цифры и формулировки — по The Daily Hodl, 22.06.2020, https://dailyhodl.com/2020/06/22/staggering-35000000000-in-bitcoin-btc-is-forever-lost-reports-chainalysis/ и Decrypt.

337

Chainalysis, «60% of Bitcoin is Held Long Term as Digital Gold. What About the Rest?», 18.06.2020, https://www.chainalysis.com/blog/bitcoin-market-data-exchanges-trading/; цифры и формулировки — по The Daily Hodl, 22.06.2020, https://dailyhodl.com/2020/06/22/staggering-35000000000-in-bitcoin-btc-is-forever-lost-reports-chainalysis/ и Decrypt.

338

Lerner S. D. «The Well Deserved Fortune of Satoshi Nakamoto, Bitcoin creator, Visionary and Genius», Bitslog, 17.04.2013, https://bitslog.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/.

339

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

340

Архив форума bitcointalk (Satoshi Nakamoto Institute), тема «overflow bug SERIOUS», 15.08.2010, 19:04 UTC: «seems a block at height 74638 has expoited a bug in the net. It uses an integer overflow to make a negative total transaction.» Орфография оригинала сохранена.

341

Bitcoin Wiki, «Value overflow incident» (CVE-2010-5139), https://en.bitcoin.it/wiki/Value_overflow_incident.

342

Bitcoin Wiki, «Controlled supply», https://en.bitcoin.it/wiki/Controlled_supply.

343

Mastering Bitcoin, 3rd ed., гл. 6.

344

Bitcoin Wiki, «Value overflow incident» (CVE-2010-5139), https://en.bitcoin.it/wiki/Value_overflow_incident.

345

Bitcoin Wiki, «Value overflow incident» (CVE-2010-5139), https://en.bitcoin.it/wiki/Value_overflow_incident.

346

Bitcoin Wiki, «Value overflow incident» (CVE-2010-5139), https://en.bitcoin.it/wiki/Value_overflow_incident; Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

347

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

348

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

349

Там же, 21:06 UTC: «It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.»

350

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

351

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/.

352

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

353

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

354

Сам Накамото 16 августа писал «около 74 689»; разница — в его оценке на глаз. Вики сообщества относит исправление к «мягким» изменениям правил, то есть к ужесточению того, что считается допустимым.

355

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

356

Накамото, bitcointalk, 16.08.2010, 01:00 UTC: «It’s only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear.»

357

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

358

Nakamoto, 2008, раздел 5 «Network», https://bitcoin.org/bitcoin.pdf.

359

Bitcoin Developer Reference, «Block Chain»; исходный код Bitcoin Core, src/kernel/chainparams.cpp (CMainParams): nPowTargetSpacing = 10 * 60; nPowTargetTimespan = 14 * 24 * 60 * 60; nSubsidyHalvingInterval = 210000, https://raw.githubusercontent.com/bitcoin/bitcoin/master/src/kernel/chainparams.cpp; Mastering Bitcoin, 3rd ed., гл. 12; Nakamoto, 2008, раздел 5 «Network», https://bitcoin.org/bitcoin.pdf.

360

U.S. DOJ / IRS-CI, «Two Arrested for Alleged Conspiracy to Launder $4.5 Billion in Stolen Cryptocurrency», 08.02.2022, копия на сайте IRS: https://www.irs.gov/zh-hant/compliance/criminal-investigation/two-arrested-for-alleged-conspiracy-to-launder-4-point-5-billion-in-stolen-cryptocurrency; оригинал: https://www.justice.gov/archives/opa/pr/two-arrested-alleged-conspiracy-launder-45-billion-stolen-cryptocurrency (не открылся); U.S. Department of Justice, Office of Public Affairs, «Department of Justice Seizes $2.3 Million in Cryptocurrency Paid to the Ransomware Extortionists Darkside», 07.06.2021, https://www.justice.gov/opa/pr/department-justice-seizes-23-million-cryptocurrency-paid-ransomware-extortionists-darkside; дубль: https://www.justice.gov/usao-ndca/pr/department-justice-seizes-23-million-cryptocurrency-paid-ransomware-extortionists.

361

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

362

Bitcoin Wiki, «Value overflow incident» (CVE-2010-5139), https://en.bitcoin.it/wiki/Value_overflow_incident; Bitcoin Wiki, «Controlled supply», https://en.bitcoin.it/wiki/Controlled_supply.

363

Satoshi Nakamoto Institute, архив bitcointalk: тема «overflow bug SERIOUS», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/; тема «Version 0.3.10 - block 74638 overflow PATCH!», https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/; Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

364

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

365

Nakamoto, 2008, раздел 4 «Proof-of-Work», https://bitcoin.org/bitcoin.pdf.

366

Bitcoin Wiki, «Value overflow incident», https://en.bitcoin.it/wiki/Value_overflow_incident; Накамото, архив bitcointalk, посты 16.08.2010 01:00:45 и 12:59:38 UTC.

367

L. Lamport, R. Shostak, M. Pease, «The Byzantine Generals Problem», ACM Transactions on Programming Languages and Systems, vol. 4, no. 3, July 1982, pp. 382–401, https://lamport.azurewebsites.net/pubs/byz.pdf.

368

L. Lamport, R. Shostak, M. Pease, «The Byzantine Generals Problem», ACM Transactions on Programming Languages and Systems, vol. 4, no. 3, July 1982, pp. 382–401, https://lamport.azurewebsites.net/pubs/byz.pdf.

369

Lamport L., Shostak R., Pease M. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, vol. 4, no. 3, July 1982, pp. 382–401. Авторы работали в SRI International. «We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger.»

370

L. Lamport, R. Shostak, M. Pease, «The Byzantine Generals Problem», ACM Transactions on Programming Languages and Systems, vol. 4, no. 3, July 1982, pp. 382–401, https://lamport.azurewebsites.net/pubs/byz.pdf.

371

L. Lamport, R. Shostak, M. Pease, «The Byzantine Generals Problem», ACM Transactions on Programming Languages and Systems, vol. 4, no. 3, July 1982, pp. 382–401, https://lamport.azurewebsites.net/pubs/byz.pdf.

372

Lamport, Shostak, Pease, 1982, аннотация и раздел 2 «Impossibility results», https://lamport.azurewebsites.net/pubs/byz.pdf.

373

Там же, аннотация: «It is shown that, using only oral messages, this problem is solvable if and only if more than two-thirds of the generals are loyal; so a single traitor can confound two loyal generals.»

374

Lamport, Shostak, Pease, 1982, аннотация, https://lamport.azurewebsites.net/pubs/byz.pdf.

375

Там же: «With unforgeable written messages, the problem is solvable for any number of generals and possible traitors.»

376

Lamport, Shostak, Pease, 1982, аннотация, https://lamport.azurewebsites.net/pubs/byz.pdf.

377

BTC Nodes (Bitnodes), https://btcnodes.io/; API снимка: https://btcnodes.io/api/v1/snapshots/latest/ (обращение 2026-09-26; старый адрес bitnodes.io перенаправляет туда). Оператор — Rodrigo Martínez.

378

M. Castro, B. Liskov, «Practical Byzantine Fault Tolerance», Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, February 1999; PDF (зеркало курса MIT 6.824): https://css.csail.mit.edu/6.824/2014/papers/castro-practicalbft.pdf.

379

M. Castro, B. Liskov, «Practical Byzantine Fault Tolerance», Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, February 1999; PDF (зеркало курса MIT 6.824): https://css.csail.mit.edu/6.824/2014/papers/castro-practicalbft.pdf.

380

Castro M., Liskov B. Practical Byzantine Fault Tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI ’99), New Orleans, February 1999: «…it works in asynchronous environments like the Internet…» Точная граница: алгоритм выдерживает не более ⌊(n−1)/3⌋ неисправных участников из n, то есть при f злонамеренных участников нужно не меньше 3f+1 участников всего (M. Castro, B. Liskov, «Practical Byzantine Fault Tolerance», Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, February 1999; PDF (зеркало курса MIT 6.824): https://css.csail.mit.edu/6.824/2014/papers/castro-practicalbft.pdf).

381

Castro, Liskov, 1999 (по пересказу: Colyer, The Morning Paper, 2015, https://blog.acolyer.org/2015/05/18/practical-byzantine-fault-tolerance/).

382

Сравнение шло со стандартной нереплицированной NFS, во введении — со стандартным демоном NFS в ядре Digital Unix при нормальной работе, без сбоев (Castro, Liskov, 1999 (по пересказу: Colyer, The Morning Paper, 2015, https://blog.acolyer.org/2015/05/18/practical-byzantine-fault-tolerance/)).

383

M. Castro, B. Liskov, «Practical Byzantine Fault Tolerance», Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, February 1999; PDF (зеркало курса MIT 6.824): https://css.csail.mit.edu/6.824/2014/papers/castro-practicalbft.pdf.

384

Castro, Liskov, 1999, p. 2: «All replicas know the others’ public keys.»

385

M. Castro, B. Liskov, «Practical Byzantine Fault Tolerance», Proceedings of OSDI ’99, 1999, https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance (карточка), http://pmg.csail.mit.edu/papers/osdi99.pdf; содержание сверено по обзору A. Colyer, «Practical Byzantine Fault Tolerance», The Morning Paper, 18.05.2015, https://blog.acolyer.org/2015/05/18/practical-byzantine-fault-tolerance/.

386

Castro, Liskov, 1999 (по пересказу: Colyer, The Morning Paper, 2015, https://blog.acolyer.org/2015/05/18/practical-byzantine-fault-tolerance/).

387

S. Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System», 2008, раздел 4 «Proof-of-Work», https://bitcoin.org/bitcoin.pdf.

388

S. Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System», 2008, раздел 4 «Proof-of-Work», https://bitcoin.org/bitcoin.pdf.

389

Nakamoto S. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008, section 4: «Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.»

390

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

391

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

392

C. Dwork, M. Naor, «Pricing via Processing or Combatting Junk Mail», Advances in Cryptology — CRYPTO ’92, Lecture Notes in Computer Science, vol. 740, Springer, 1993, pp. 139–147, DOI 10.1007/3-540-48071-4_10, https://link.springer.com/chapter/10.1007/3-540-48071-4_10; карточка IACR: https://iacr.org/cryptodb/data/paper.php?pubkey=1268.

393

Dwork C., Naor M. Pricing via Processing or Combatting Junk Mail. Advances in Cryptology — CRYPTO ’92, LNCS 740, Springer, 1993, pp. 139–147. Термина proof-of-work в этой работе нет, его популяризовали позже (C. Dwork, M. Naor, «Pricing via Processing or Combatting Junk Mail», Advances in Cryptology — CRYPTO ’92, Lecture Notes in Computer Science, vol. 740, Springer, 1993, pp. 139–147, DOI 10.1007/3-540-48071-4_10, https://link.springer.com/chapter/10.1007/3-540-48071-4_10; карточка IACR: https://iacr.org/cryptodb/data/paper.php?pubkey=1268).

394

Aaron van Wirdum, «The Genesis Files: Hashcash or How Adam Back Designed Bitcoin’s Motor Block», Bitcoin Magazine, 04.06.2018, https://bitcoinmagazine.com/technical/genesis-files-hashcash-or-how-adam-back-designed-bitcoins-motor-block; статья Бэка: A. Back, «Hashcash — A Denial of Service Counter-Measure», 01.08.2002, http://www.hashcash.org/hashcash.pdf (не открылась — ошибка SSL); Bitcoin Annotated, «Hashcash», https://bitcoinannotated.com/entries/hashcash/; архив рассылки: https://cypherpunks.venona.com/date/1997/03/msg00774.html (при проверке — ошибка 522, не открыт); ср. van Wirdum.

395

Aaron van Wirdum, «The Genesis Files: Hashcash or How Adam Back Designed Bitcoin’s Motor Block», Bitcoin Magazine, 04.06.2018, https://bitcoinmagazine.com/technical/genesis-files-hashcash-or-how-adam-back-designed-bitcoins-motor-block; статья Бэка: A. Back, «Hashcash — A Denial of Service Counter-Measure», 01.08.2002, http://www.hashcash.org/hashcash.pdf (не открылась — ошибка SSL).

396

Слова Бэка в пересказе историка биткоина Арона ван Вирдума: «the idea of using partial hashes is that they can be made arbitrarily expensive to compute, and yet can be verified instantly» (Aaron van Wirdum, «The Genesis Files: Hashcash or How Adam Back Designed Bitcoin’s Motor Block», Bitcoin Magazine, 04.06.2018, https://bitcoinmagazine.com/technical/genesis-files-hashcash-or-how-adam-back-designed-bitcoins-motor-block; статья Бэка: A. Back, «Hashcash — A Denial of Service Counter-Measure», 01.08.2002, http://www.hashcash.org/hashcash.pdf (не открылась — ошибка SSL)). Объявление в рассылке шифропанков два независимых пересказа датируют 28 марта 1997 года, а в статье самого Бэка 2002 года, как её цитируют, сказано «in May 1997» (Bitcoin Annotated, «Hashcash», https://bitcoinannotated.com/entries/hashcash/; архив рассылки: https://cypherpunks.venona.com/date/1997/03/msg00774.html (при проверке — ошибка 522, не открыт); ср. van Wirdum); отсюда «весной 1997 года».

397

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

398

S. Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System», 2008, раздел 4 «Proof-of-Work», https://bitcoin.org/bitcoin.pdf.

399

Nakamoto, 2008, раздел 5 «Network», https://bitcoin.org/bitcoin.pdf.

400

Nakamoto S., Bitcoin: A Peer-to-Peer Electronic Cash System, 2008, section 5, https://bitcoin.org/bitcoin.pdf (стр. 3).

401

Nakamoto, 2008, section 5: «The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.» О переводах с проигравшей страницы у Накамото ничего не сказано; так их обрабатывает программа Bitcoin Core: «Transactions which are mined into blocks that later become stale blocks may be added back into the memory pool» (Bitcoin Developer Guide, P2P Network) (Bitcoin Developer Guide, P2P Network, раздел Memory Pool, https://developer.bitcoin.org/devguide/p2p_network.html).

402

Bitcoin Developer Guide, P2P Network, раздел Memory Pool, https://developer.bitcoin.org/devguide/p2p_network.html.

403

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

404

Satoshi Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System», 2008, https://bitcoin.org/bitcoin.pdf.

405

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

406

Nakamoto, 2008, section 4: «To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.» Шанс отстающего атакующего догнать честную цепочку, по расчёту Накамото, падает экспоненциально с каждым новым блоком (Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf).

407

Nakamoto, 2008, раздел 4, https://bitcoin.org/bitcoin.pdf.

408

Lamport, Shostak, Pease, 1982, аннотация и раздел 2 «Impossibility results», https://lamport.azurewebsites.net/pubs/byz.pdf.

409

Satoshi Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System», 2008, https://bitcoin.org/bitcoin.pdf.

410

Nakamoto, 2008, раздел 5 «Network», https://bitcoin.org/bitcoin.pdf.

411

Mastering Bitcoin, 3rd ed., 2023, гл. 4.

412

Nakamoto, 2008, раздел 5 «Network», https://bitcoin.org/bitcoin.pdf.

413

Nakamoto, 2008, раздел 6 «Incentive», https://bitcoin.org/bitcoin.pdf.

414

Nakamoto, 2008, section 6: «He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.»

415

Bitcoin Gold, «Responding to Attacks», 24.05.2018, http://www.bitcoingold.org/responding-to-attacks/.

416

исходный код Bitcoin Core, src/kernel/chainparams.cpp (CMainParams): nPowTargetSpacing = 10 * 60; nPowTargetTimespan = 14 * 24 * 60 * 60; nSubsidyHalvingInterval = 210000, https://raw.githubusercontent.com/bitcoin/bitcoin/master/src/kernel/chainparams.cpp; Mastering Bitcoin, 3rd ed., гл. 12.

417

Bitcoin Wiki, «Difficulty», https://en.bitcoin.it/wiki/Difficulty; принцип — Nakamoto, 2008, раздел 4 («the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour»).

418

Bitcoin Wiki, «Difficulty», https://en.bitcoin.it/wiki/Difficulty; принцип — Nakamoto, 2008, раздел 4 («the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour»).

419

Bitcoin Wiki, «Difficulty», https://en.bitcoin.it/wiki/Difficulty; принцип — Nakamoto, 2008, раздел 4 («the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour»).

420

mempool.space, API «mining/hashrate/1m» и «mining/pools/1m», запрос 26.09.2026: https://mempool.space/api/v1/mining/hashrate/1m (currentHashrate ≈ 9,34·10²⁰ H/s; дневные средние 24–26.09.2026: 837, 933, 880 ЭХ/с); https://mempool.space/api/v1/mining/pools/1m (оценка за месяц ≈ 1,02·10²¹ H/s).

421

mempool.space, API «mining/hashrate/1m» и «mining/pools/1m», запрос 26.09.2026: https://mempool.space/api/v1/mining/hashrate/1m (currentHashrate ≈ 9,34·10²⁰ H/s; дневные средние 24–26.09.2026: 837, 933, 880 ЭХ/с); https://mempool.space/api/v1/mining/pools/1m (оценка за месяц ≈ 1,02·10²¹ H/s).

422

Оценка mempool.space на 26.09.2026: около 9,34 × 1020 хешей в секунду, дневные средние 24–26 сентября — от 837 до 933 эксахешей в секунду; оценка за месяц — около 1,02 × 1021. Хешрейт не измеряется, а выводится, поэтому дневные значения скачут примерно на ±10%, и разные сервисы дают разные цифры. Последняя корректировка перед этой датой, 19.09.2026 на блоке 967 680, подняла сложность на 4,2% (mempool.space, API «mining/hashrate/1m» и «mining/pools/1m», запрос 26.09.2026: https://mempool.space/api/v1/mining/hashrate/1m (currentHashrate ≈ 9,34·10²⁰ H/s; дневные средние 24–26.09.2026: 837, 933, 880 ЭХ/с); https://mempool.space/api/v1/mining/pools/1m (оценка за месяц ≈ 1,02·10²¹ H/s)). Свежие цифры — в приложении Б.