diff --git a/frontend/README.md b/frontend/README.md index 4bfca4fe8..68fa12e48 100644 --- a/frontend/README.md +++ b/frontend/README.md @@ -132,3 +132,4 @@ https://www.transifex.com/mempool/mempool/dashboard/ * Russian @TonyCrusoe @Bitconan * Romanian @mirceavesa * Macedonian @SkechBoy +* Nepalese @kebinm diff --git a/frontend/src/app/components/block/block.component.html b/frontend/src/app/components/block/block.component.html index 4976205dd..059b9b708 100644 --- a/frontend/src/app/components/block/block.component.html +++ b/frontend/src/app/components/block/block.component.html @@ -53,7 +53,7 @@
For unconfirmed CPFP transactions, Mempool will show the effective feerate (along with descendent & ancestor transaction information) on the transaction page. For confirmed transactions, CPFP relationships are not stored, so this additional information is not shown.
+Block health indicates the extent of potential censorship in a block. This is determined by counting how many expected transactions a block is missing—a block that is not missing any expected transactions will have 100% health, while a block missing 1 or more expected transactions will have sub-100% health.
+How does this work? Let sexpected be the set of all transactions Mempool expected to be in a block and let sactual be the set of all transactions actually in a block. Let n be the number of all transactions in both sexpected and sactual.
+Then let r be the number of removed transactions—all transactions expected to be in sactual but not actually in it (excluding those that have been recently broadcast; see below).
+Block health is calculated as n / ( n + r ).
+Transactions appearing in both sexpected and sactual are used (instead of a block's full transaction count) in order to minimize chances that block health is impacted by missing transactions that don't imply censorship:
+Mempool uses a re-implementation of Bitcoin Core's transaction selection algorithm to determine the transactions it expects to see in the next block.
+