{ isHomeIcon ? (
) : (
TPS (capacity)
\ **Premise**: Capacity of blockchain in Transactions per Second, with real simplest-TX size, ignoring TX-fees. - **MMX**: `250M cost limit / 50K cost simplest-TX / blocktime` = `~500`\ Node coded extremely performant in C++ to handle all aspects of blockchain logic on regular home hardware. Real-life stress tests, on regular user nodes, have handled 2000 TX-es (200 TPS) per block without problems. Block parameters at that time limited it to 2000 TX-es. Now set to potentially 5000 TX-es (500 TPS). Locally node will be able to handle it, and can easily scale to 10000 TX-es (1000 TPS) in future.\ Bottleneck is bandwidth of home internet connections, and latency of internet in general. A limitation MMX works the most out of, while still being truly decentralized. We know 200 TPS works, with 500 TPS potential. Future home internet improvements could raise that number (1000 TPS). All on-chain L1, before any L2 scaling. - **Bitcoin**: `1 MB / 140 bytes SegWit-TX / blocktime` = `~12`\ Bitcoin is usually referenced with a maximum TPS around 7. Could increase if community had agreed on several design improvements. As of now, with current SegWit-TX structure. Potentially 12 TPS with only SegWit-TX in block. - **Ethereum**: `30M gas limit / 21K gas simplest-TX / blocktime` = `~119`\ Ethereum is usually listed with anything from 15-50 maximum TPS. Real-life statistics have it working at an average of 15 TPS, with variable complexity of TX-es. The calculation of 119 TPS might not look very realistic. But we are talking capacity potential, ignoring TX-fees. Filling a block with about 1428 simplest-TX, results in a potential TPS of 119. If the blockchain logic and nodes are optimized enough to handle such a scenario, unknown. - **Chia**: `Documented as 20-40 TPS, real-life stress tests at 35` = `~35`\ Not easy to get hard numbers to calculate Chia's maximum TPS potential. It is documented to be in the 20-40 range. A real-life stress test, with simplest-TX-es, have given about 35 TPS. :::note[Note] An 100% apples to apples comparison is not possible without overly complicating it. Each blockchain has unique properties, real-life behavior, and limitations. This is an attempt to estimate a realistic capacity potential. As fair as possible, in a simple table. :::Blocktime/TX (average)
\ **Premise**: Average time it takes to create a new block with TX-es, given frequency of non-TX blocks. - **MMX**: `Blocktime 10 sec, ~2% non-TX blocks, average TX blocktime` = `~10 sec` - **Bitcoin**: `Average blocktime statistics` = `~600 sec` (`~10 min`) - **Ethereum**: `Average blocktime statistics` = `~12 sec` - **Chia**: `Blocktime 18.75 sec, 2/3 non-TX blocks, average TX blocktime` = `~56 sec`================================================ FILE: docs/src/content/docs/articles/plotting/plot-format.md ================================================ --- title: Plot format description: Plot format for MMX (mainnet), introduced with testnet11 prev: false next: false articlePublished: 2024-04-06 articleUpdated: 2025-01-30 authorName: voidxno authorPicture: https://avatars.githubusercontent.com/u/53347890?s=200 authorURL: https://github.com/voidxno --- Plot format, MMX. :::note[Important] My own understanding, reading comments when mainnet plot format was rolled out with testnet11. Still relevant info, as an introduction. Reference official information if unsure. ::: ## TLDR; - Plot format for MMX (mainnet), introduced with testnet11 - **Resistant against compression** - Two types, HDD and SSD-plots (min k29, max k32, [plot size](../../../articles/plotting/plot-size/)): | | `k29` | `k30` | `k31` | `k32` | | :--- | :--- | :--- | :--- | :--- | | `hdd` | 36.4 GiB | 75.2 GiB | 155.3 GiB | 320.4 GiB | | `sdd` | 14.7 GiB | 30.3 GiB | 62.3 GiB | 128.4 GiB | - SSD-plots have missing data, smaller, but require high disk IOPS - Plotting: GPU required, full RAM, partial RAM, disk mode - Plotting: Any old 4GB VRAM (Pascal), `k32` needs 6GB VRAM - Farming: CPU only (plots), GPU not supported (not worth it) - Farming: Still iGPU/GPU recommended for VDF-verify (CPU possible) - Compression: Still supported, practically not worth it (1-4%, C1-C15) - Bonus: Open source mmx-node builds (GPU plotter too) ## Compression ### Previously Plot compression is not really traditional compression. It is information left out of plot file, reducing its size. Reconstructed on-the-fly when farming. Data in plot files are several nested tables that takes a certain amount of time to create (plotting). If passing plot filter, this data is used to create potential proofs. That again could be the winning proof for a block. Previously plot files where cleverly reworked to smaller sizes, with missing information. When farming, that information was reconstructed on-the-fly when needed. Branded as plot compression. ### Today Testnet11 introduced a new plot format that are orders of magnitude more resistant to these kind of compression techniques. Reworked by Max to make it practically worthless. Not possible to be 100% compression resistant. It's math. But reworked algorithms, required proof time, limits it greatly. As a principle, compression is still an option. The higher compression chosen (C1-C15), longer plot times, more CPU compute when farming. Gaining **only 1-4% compression, compared to +200% with other Proof of Space**. HDD-plots have C0-C4 as recommended compression (1%). Still easily processed by CPU when farming. Going further up, too much load/time on CPU. ## SSD-plots SSD-plots are a type of pre-compressed plots, missing hashes. Reconstructed on-the-fly when farming, but requires very high disk IOPS. Storing them on HDD will not work, not enough IOPS on spinning platters. Goal is to balance cost/reward potential between SSD and HDD storage (2.5x SSD advantage, but more expensive media). Basically: Given **identical k-size, SSD-plots has same effective space on network as HDD-plots**. Takes less space to store (**2.5x advantage**), but more expensive media (SSD). Given the high IOPS for SSD-plots, recommended to use C0 for compression (0%). ## Plotting **RAM requirements** for plotter, in [memory GB](https://en.wikipedia.org/wiki/Byte#Multiple-byte_units "Memory GB units, 1024^3") (similar for HDD and SSD-plots): | | full RAM | partial RAM | disk mode | | :--- | :--- | :--- | :--- | | `hdd`/`sdd-k29` | 60 GB | 32 GB | 8 GB | | `hdd`/`sdd-k30` | 110 GB | 64 GB | 8 GB | | `hdd`/`sdd-k31` | 216 GB | 120 GB | 8 GB | | `hdd`/`sdd-k32` | 410 GB | 232 GB | 8 GB | :::note[Note] Disk mode usually less than 8 GB, depends on `-S` streams option.\ If close to 32 GB, 32 GB system RAM not enough. 48/64 GB needed. ::: **Temp disk space** needed when plotting (similar for HDD and SSD-plots): | | full RAM | partial RAM | disk mode | | :--- | :--- | :--- | :--- | | `hdd`/`sdd-k29` | 0.0 GiB | 24 GiB | 51 GiB | | `hdd`/`sdd-k30` | 0.0 GiB | 48 GiB | 101 GiB | | `hdd`/`sdd-k31` | 0.0 GiB | 100 GiB | 202 GiB | | `hdd`/`sdd-k32` | 0.0 GiB | 200 GiB | 404 GiB | **Total disk writes** when plotting, in [TiB](https://en.wikipedia.org/wiki/Byte#Multiple-byte_units "TebiByte units, 1024^4") written: | | full RAM | partial RAM | disk mode | | :--- | :--- | :--- | :--- | | `hdd`/`sdd-k29` | 0.04 / 0.02 TiBW | 0.08 / 0.06 TiBW | 0.33 / 0.28 TiBW | | `hdd`/`sdd-k30` | 0.08 / 0.03 TiBW | 0.16 / 0.12 TiBW | 0.68 / 0.57 TiBW | | `hdd`/`sdd-k31` | 0.16 / 0.06 TiBW | 0.33 / 0.25 TiBW | 1.40 / 1.14 TiBW | | `hdd`/`sdd-k32` | 0.32 / 0.13 TiBW | 0.67 / 0.50 TiBW | 2.88 / 2.27 TiBW | :::note[Note] Testnet11 introduced a new farmer key, 33 bytes ECDSA vs old 48 BLS (`-f`, 66 chars vs old 96). ::: Follow [`#mmx-general`](https://discord.com/channels/852982773963161650/925017012235817042) on Discord. ## Farming **Disk seeks** per plot (independent of k-size or C-compression): | | pass filter | full proof | :--- | :--- | :--- | | `hdd` | ~2 | ~256 | | `ssd` | ~4096 | 0 | Follow [`#mmx-farming`](https://discord.com/channels/852982773963161650/853417165980827657) on Discord. ================================================ FILE: docs/src/content/docs/articles/plotting/plot-size.mdx ================================================ --- title: Plot size description: Plot sizes for MMX prev: false next: false articlePublished: 2026-03-04 articleUpdated: 2026-03-20 authorName: voidxno authorPicture: https://avatars.githubusercontent.com/u/53347890?s=200 authorURL: https://github.com/voidxno --- An attempt to quantify real-life MMX plot size patterns into charts, tables and formulas. Created by plotting lots of different k-sizes and C-levels. Both to find patterns, and make sure of them. Goal is an easy overview of plot size behavior, with solid numbers as a bonus. ## TLDR; - [Compression resistant](../../../articles/plotting/plot-format/) plot format - Given a specific k-size/C-level, following is true: - Plot size is random, within a small bell curved range - Plot size will average out, given enough plots - Varying size equals **less or more proofs, not better compression** - Given specific k-size, following is true: - Delta size between C-levels is identical, linear - Delta size of distribution bell curve is identical for all C-levels - Evaluate yourself [what C-compression](../../../faq/plotting/#what-k-size-and-c-compression-should-i-plot) level is worth it - A few thoughts about [filling a disk](#filling-a-disk) further down - Own section below with data for [SSD-plots](#ssd-plots) ## Charts First chart is an overall overview using formulas created. Followed by two charts using real-life hdd-k29 plotting data to illustrate patterns. Those patterns repeat in other k-sizes. Decimal GiB numbers in overview chart have been rounded up. Less chance of underestimating combined size of plots.
Overview
Distribution (hdd-k29, C0)
Distribution (hdd-k29, C0-C15)
List
| | `hdd-k29` | `hdd-k30` | `hdd-k31` | `hdd-k32` | | :--- | :--- | :--- | :--- | :--- | | `C0` | 36.376 GiB | 75.196 GiB | 155.279 GiB | 320.321 GiB | | `C15` | 34.893 GiB | 72.223 GiB | 149.315 GiB | 308.351 GiB | | `%` | -4.08 % | -3.95 % | -3.84 % | -3.74 % |Full list
| | `hdd-k29` | `hdd-k30` | `hdd-k31` | `hdd-k32` | | :--- | :--- | :--- | :--- | :--- | | `C0` | 36.376 GiB | 75.196 GiB | 155.279 GiB | 320.321 GiB | | `C1` | 36.277 GiB | 74.998 GiB | 154.882 GiB | 319.523 GiB | | `C2` | 36.178 GiB | 74.800 GiB | 154.484 GiB | 318.725 GiB | | `C3` | 36.079 GiB | 74.602 GiB | 154.086 GiB | 317.927 GiB | | `C4` | 35.980 GiB | 74.404 GiB | 153.689 GiB | 317.129 GiB | | `C5` | 35.882 GiB | 74.205 GiB | 153.291 GiB | 316.331 GiB | | `C6` | 35.783 GiB | 74.007 GiB | 152.894 GiB | 315.533 GiB | | `C7` | 35.684 GiB | 73.809 GiB | 152.496 GiB | 314.735 GiB | | `C8` | 35.585 GiB | 73.611 GiB | 152.098 GiB | 313.937 GiB | | `C9` | 35.486 GiB | 73.412 GiB | 151.701 GiB | 313.139 GiB | | `C10` | 35.387 GiB | 73.214 GiB | 151.303 GiB | 312.341 GiB | | `C11` | 35.288 GiB | 73.016 GiB | 150.905 GiB | 311.543 GiB | | `C12` | 35.189 GiB | 72.818 GiB | 150.508 GiB | 310.745 GiB | | `C13` | 35.091 GiB | 72.620 GiB | 150.110 GiB | 309.947 GiB | | `C14` | 34.992 GiB | 72.421 GiB | 149.713 GiB | 309.149 GiB | | `C15` | 34.893 GiB | 72.223 GiB | 149.315 GiB | 308.351 GiB | | `%` | -4.08 % | -3.95 % | -3.84 % | -3.74 % |Formula
- HDD-plot C0 (GiB): `4.98452*k*1.99844^(k-30.99297)+0.00513` - HDD-plot C15 (%): `-(1.0871^(34.1291-k)+2.5423)`List
| | `hdd-k29` | `hdd-k30` | `hdd-k31` | `hdd-k32` | | :--- | :--- | :--- | :--- | :--- | | `99.5%` | ±0.485 GiB | ±0.729 GiB | ±1.082 GiB | ±1.586 GiB | | `C0` (average) | 36.4 GiB | 75.2 GiB | 155.3 GiB | 320.4 GiB | | `C0` (range) | 35.8 - 36.9 | 74.4 - 76.0 | 154.1 - 156.4 | 318.7 - 322.0 |Full list
| | `hdd-k29` | `hdd-k30` | `hdd-k31` | `hdd-k32` | | :--- | :--- | :--- | :--- | :--- | | `25%` | ±0.052 GiB | ±0.078 GiB | ±0.116 GiB | ±0.170 GiB | | `50%` | ±0.113 GiB | ±0.169 GiB | ±0.251 GiB | ±0.369 GiB | | `75%` | ±0.195 GiB | ±0.293 GiB | ±0.435 GiB | ±0.638 GiB | | `99.5%` | ±0.485 GiB | ±0.729 GiB | ±1.082 GiB | ±1.586 GiB | | `C0` | 35.8 - 36.9 | 74.4 - 76.0 | 154.1 - 156.4 | 318.7 - 322.0 | | `C1` | 35.7 - 36.8 | 74.2 - 75.8 | 153.7 - 156.0 | 317.9 - 321.2 | | `C2` | 35.6 - 36.7 | 74.0 - 75.6 | 153.4 - 155.6 | 317.1 - 320.4 | | `C3` | 35.5 - 36.6 | 73.8 - 75.4 | 153.0 - 155.2 | 316.3 - 319.6 | | `C4` | 35.4 - 36.5 | 73.6 - 75.2 | 152.6 - 154.8 | 315.5 - 318.8 | | `C5` | 35.3 - 36.4 | 73.4 - 75.0 | 152.2 - 154.4 | 314.7 - 318.0 | | `C6` | 35.2 - 36.3 | 73.2 - 74.8 | 151.8 - 154.0 | 313.9 - 317.2 | | `C7` | 35.1 - 36.2 | 73.0 - 74.6 | 151.4 - 153.6 | 313.1 - 316.4 | | `C8` | 35.1 - 36.1 | 72.8 - 74.4 | 151.0 - 153.2 | 312.3 - 315.6 | | `C9` | 35.0 - 36.0 | 72.6 - 74.2 | 150.6 - 152.8 | 311.5 - 314.8 | | `C10` | 34.9 - 35.9 | 72.4 - 74.0 | 150.2 - 152.4 | 310.7 - 314.0 | | `C11` | 34.8 - 35.8 | 72.2 - 73.8 | 149.8 - 152.0 | 309.9 - 313.2 | | `C12` | 34.7 - 35.7 | 72.0 - 73.6 | 149.4 - 151.6 | 309.1 - 312.4 | | `C13` | 34.6 - 35.6 | 71.8 - 73.4 | 149.0 - 151.2 | 308.3 - 311.6 | | `C14` | 34.5 - 35.5 | 71.6 - 73.2 | 148.6 - 150.8 | 307.5 - 310.8 | | `C15` | 34.4 - 35.4 | 71.4 - 73.0 | 148.2 - 150.4 | 306.7 - 310.0 |Formula
- HDD-plot k29 (±GiB): `0.153*sinh(0.00872*p)-0.0632*ln(100-p)+0.2911` - HDD-plot k-size (multiplier): `2.386E-18*k^12.05`Average - List
| | `ssd-k29` | `ssd-k30` | `ssd-k31` | `ssd-k32` | | :--- | :--- | :--- | :--- | :--- | | `C0` | 14.633 GiB | 30.205 GiB | 62.285 GiB | 128.307 GiB | | `C15` | 13.139 GiB | 27.218 GiB | 56.312 GiB | 116.365 GiB | | `%` | -10.21 | -9.89 | -9.59 | -9.31 |Average - Full List
| | `ssd-k29` | `ssd-k30` | `ssd-k31` | `ssd-k32` | | :--- | :--- | :--- | :--- | :--- | | `C0` | 14.633 GiB | 30.205 GiB | 62.285 GiB | 128.307 GiB | | `C1` | 14.534 GiB | 30.006 GiB | 61.887 GiB | 127.511 GiB | | `C2` | 14.434 GiB | 29.807 GiB | 61.489 GiB | 126.715 GiB | | `C3` | 14.334 GiB | 29.608 GiB | 61.091 GiB | 125.919 GiB | | `C4` | 14.235 GiB | 29.409 GiB | 60.692 GiB | 125.122 GiB | | `C5` | 14.135 GiB | 29.210 GiB | 60.294 GiB | 124.326 GiB | | `C6` | 14.036 GiB | 29.010 GiB | 59.896 GiB | 123.530 GiB | | `C7` | 13.936 GiB | 28.811 GiB | 59.498 GiB | 122.734 GiB | | `C8` | 13.836 GiB | 28.612 GiB | 59.099 GiB | 121.938 GiB | | `C9` | 13.737 GiB | 28.413 GiB | 58.701 GiB | 121.142 GiB | | `C10` | 13.637 GiB | 28.214 GiB | 58.303 GiB | 120.346 GiB | | `C11` | 13.537 GiB | 28.015 GiB | 57.905 GiB | 119.549 GiB | | `C12` | 13.438 GiB | 27.815 GiB | 57.507 GiB | 118.753 GiB | | `C13` | 13.338 GiB | 27.616 GiB | 57.108 GiB | 117.957 GiB | | `C14` | 13.239 GiB | 27.417 GiB | 56.710 GiB | 117.161 GiB | | `C15` | 13.139 GiB | 27.218 GiB | 56.312 GiB | 116.365 GiB | | `%` | -10.21 | -9.89 | -9.59 | -9.31 |Average - Formula
- SSD-plot C0 (GiB): `1.97585*k*1.99570^(k-30.97589)+0.00479` - SSD-plot C15 (%): `-(1.0649^(55.3836-k)+4.9567)`Distribution - List
| | `ssd-k29` | `ssd-k30` | `ssd-k31` | `ssd-k32` | | :--- | :--- | :--- | :--- | :--- | | `99.5%` | ±0.083 GiB | ±0.124 GiB | ±0.185 GiB | ±0.271 GiB | | `C0` (average) | 14.7 GiB | 30.3 GiB | 62.3 GiB | 128.4 GiB | | `C0` (range) | 14.5 - 14.8 | 30.0 - 30.4 | 62.1 - 62.5 | 128.0 - 128.6 |Distribution - Full List
| | `ssd-k29` | `ssd-k30` | `ssd-k31` | `ssd-k32` | | :--- | :--- | :--- | :--- | :--- | | `25%` | ±0.009 GiB | ±0.014 GiB | ±0.021 GiB | ±0.031 GiB | | `50%` | ±0.020 GiB | ±0.030 GiB | ±0.045 GiB | ±0.065 GiB | | `75%` | ±0.034 GiB | ±0.051 GiB | ±0.076 GiB | ±0.111 GiB | | `99.5%` | ±0.083 GiB | ±0.124 GiB | ±0.185 GiB | ±0.271 GiB | | `C0` | 14.5 - 14.8 | 30.0 - 30.4 | 62.1 - 62.5 | 128.0 - 128.6 | | `C1` | 14.4 - 14.7 | 29.8 - 30.2 | 61.7 - 62.1 | 127.2 - 127.8 | | `C2` | 14.3 - 14.6 | 29.6 - 30.0 | 61.3 - 61.7 | 126.4 - 127.0 | | `C3` | 14.2 - 14.5 | 29.4 - 29.8 | 60.9 - 61.3 | 125.6 - 126.2 | | `C4` | 14.1 - 14.4 | 29.2 - 29.6 | 60.5 - 60.9 | 124.8 - 125.4 | | `C5` | 14.0 - 14.3 | 29.0 - 29.4 | 60.1 - 60.5 | 124.0 - 124.6 | | `C6` | 13.9 - 14.2 | 28.8 - 29.2 | 59.7 - 60.1 | 123.2 - 123.9 | | `C7` | 13.8 - 14.1 | 28.6 - 29.0 | 59.3 - 59.7 | 122.4 - 123.1 | | `C8` | 13.7 - 14.0 | 28.4 - 28.8 | 58.9 - 59.3 | 121.6 - 122.3 | | `C9` | 13.6 - 13.9 | 28.2 - 28.6 | 58.5 - 58.9 | 120.8 - 121.5 | | `C10` | 13.5 - 13.8 | 28.0 - 28.4 | 58.1 - 58.5 | 120.0 - 120.7 | | `C11` | 13.4 - 13.7 | 27.8 - 28.2 | 57.7 - 58.1 | 119.2 - 119.9 | | `C12` | 13.3 - 13.6 | 27.6 - 28.0 | 57.3 - 57.7 | 118.4 - 119.1 | | `C13` | 13.2 - 13.5 | 27.4 - 27.8 | 56.9 - 57.3 | 117.6 - 118.3 | | `C14` | 13.1 - 13.4 | 27.2 - 27.6 | 56.5 - 56.9 | 116.8 - 117.5 | | `C15` | 13.0 - 13.3 | 27.0 - 27.4 | 56.1 - 56.5 | 116.0 - 116.7 |Distribution - Formula
- SSD-plot k29 (±GiB): `0.088*sinh(0.00282*p)-0.0109*ln(100-p)+0.0502` - SSD-plot k-size (multiplier): `2.386E-18*k^12.05`Basic data
If useful to anyone. Link to [plot-size_csv.zip](/resources/data/plot-size/plot-size_csv.zip) with raw CSV data used to create formulas. Would even more data be preferable? Always. But was enough to see patterns, and estimate good values for formulas. :::note[Note] Important that such data is as-is, without any pre-filtering of plots that are larger or smaller. There are a few entries in k26 and k29 that are identical. Not wrong, just higher probability on lower k-sizes. Together with k29-k32, k26 was included. Not valid in mainnet, so not shown in charts and tables above. But formulas work for k26. Some signs in data that ± distribution might have a small difference. Not enough to warrant asymmetrical formulas. For reference. A lot of plots created, recorded, deleted. Hardware was Nvidia RTX A4500, Intel DC P4610 6.4TB SDD, and 128GB RAM. A combination of full RAM, partial RAM, and disk mode. Together with some plots already done on my farm. :::Formula creation
Formulas above are not perfect, but close enough. Transforming real source code logic into perfect formulas would be too complex. Better with a good approximation that matches real-life behavior. Strategy used: - Map all real-life plot data into spreadsheets - Transform numbers in different ways, find patterns - Create points for each k-size on a graph - Find basic curve formula that matches points on graph - Brute force iterate numbers in formula - Find numbers with least difference across all k-sizes Without required plot file metadata, formula looks to be: - HDD-plot C0 (GiB): `5*k*2^(k-31)` (ideal, not real-life) - SSD-plot C0 (GiB): `2*k*2^(k-31)` (ideal, not real-life)**Model:** Intel 11th-gen (Rocket Lake), AMD Zen, or later (a few exceptions).
**GPU/iGPU:** Any compatible (offload verify VDF). **Linux:** `grep -o 'sha_ni' /proc/cpuinfo`, empty if not available.
**Windows:** CPU-Z (Instructions) or HWiNFO64 (Features), look for `SHA`. You can run timelord on a CPU without SHA extensions. Will fallback to AVX2. In reality SHA extensions are needed. SHA256 calculations are ~5-10x faster with SHA vs AVX2. ## Why not GPU/FPGA/ASIC Timelord logic will only use CPU, not GPU. GPU is great for parallel SHA256 calculations, beating CPU in both speed and efficiency. GPU is used for verify VDF operation on a node, if available. For a single SHA256 calculation, CPU's SHA extensions will beat GPU on speed. As timelord SHA256 workload is not parallelizable, CPU wins the serial SHA256 race. Feedback welcome on other contenders. As of now, nothing observed beating a high-GHz CPU with SHA extensions (optimized silicon circuits inside CPU). Too low speed (GHz) on FPGA, work not parallelizable. Prohibitive cost to produce a high-GHz ASIC that beats Intel/AMD optimized silicon. ## Optimize TimeLord Standard Linux compile and Windows binaries gives good performance for a timelord. Still important to tune surrounding environment. Either aiming for fastest timelord rewards, or just the challenge. Information and numbers in this article might be superseded. Sections below are known info at date of publish. To help get started or give ideas. Not the absolute answer. Probably angles not discovered yet, and other ways to go about it. You do not need to complicate it like below. Try to run a timelord. Measure speed. Try out a tip. Measure if faster. Discuss and share in [`#mmx-timelord`](https://discord.com/channels/852982773963161650/1026219599311675493) channel on Discord. No requirement to divulge all your secrets. But a good place to get tips, or kickstart new ideas. :::note[Note] Optimize and **overclock at your own risk**. ::: ### Test Environment **CPU:** Intel Ultra 200S series, 265K (15th-gen, Arrow Lake)
**GPU:** Nvidia RTX 4060 Ti 8GB (AD106)
**OS:** Ubuntu 24.10 (Oracular Oriole)
**OS:** Windows 10 (22H2)
**mmx-node:** v1.1.7 (+ [AVX](#optimize-compiler-options-avx-vs-sse42), + [optimized code](#optimize-source-code-architecture)) Most instructions below are transferable to AMD. ### Measuring Speed Timelord speed is measured in MH/s (million hashes per second). Current blockchain network speed, fastest timelord, is found in NODE / VDF Speed in WebGUI. Your own timelord speed is found under NODE / LOG / TIMELORD tab in WebGUI. To make it easier to measure own improvements, baseline numbers, compare with others. It is recommended to measure MH/s speed per 0.1 GHz (**MH/s/0.1GHz**). Yes, absolute speed is the end goal. But timelord speed, at least observed for now, is linear given CPU GHz. A 2-step process is recommended: 1. Optimize for best possible MH/s/0.1GHz 2. Clock 1x CPU core as high as possible In this case the Intel 15th-gen has had an E-core locked to 3.3 GHz (could be lower/higher, not important). We already know from [TimeLord Predictions](../../../articles/timelord/timelord-predictions/) that E-core is the best option. Not always been so. Previous generations had P-core as best, with hyperthreading and E-cores disabled (more on that [later](#optimize-cpu-speed)). Goal is to make optimization measurements easier and controlled. Intel 15th-gen (v1.1.7, + [AVX](#optimize-compiler-options-avx-vs-sse42), + [optimized code](#optimize-source-code-architecture)): | Environment | Measured | Locked Speed | Measured Per Unit | | :--- | :--- | :--- | :--- | | Ubuntu/gcc14 | 44.60 MH/s | /33 (3.3 GHz) | **1.351** MH/s/0.1GHz | | Ubuntu/Clang19 | 44.28 MH/s | /33 (3.3 GHz) | **1.342** MH/s/0.1GHz | | Windows/VC++ | 41.49 MH/s | /33 (3.3 GHz) | **1.257** MH/s/0.1GHz | These numbers represent absolute speed per 0.1 GHz, given the environment and tuning. Easy to compare against yourself or others. Top speed after that is dependent on how high you can clock 1x CPU core (more on that [later](#optimize-cpu-speed)). In this case, 1x E-core stable at **4.6** GHz, would give a timelord speed of ~**62.2** MH/s. As a sidenote. P-core numbers for 12/13/14th-gen Intel gives exact same performance per 0.1 GHz. Basically, no IPC (instructions per clock) uplift for SHA extensions between them (for this specific use-case). But 14th-gen have potential to clock highest. Testing of AMD Zen4-core (7000-series), and Zen5-core (9000-series) gives **0.755** and **0.715** MH/s/0.1GHz. Yes, a degradation in efficiency. Probably an architectural decision. Intel's 15th-gen E-cores efficiency increase was a surprise (1.352, vs 0.975 before). Making it the best known choice for now. Previous generations had Intel/AMD much closer (for this specific use-case). In the end, an overclocking race. Fastest timelord speeds observed on testnets (as of **Mar2025**): | Continuous | Peak | | :--- | :--- | | ~**74.5** MH/s | ~**75.2** MH/s | ### Linux or Windows Numbers above, in previous releases and CPU generations, have switched between Linux or Windows binary being fastest. With current source code, Linux (gcc14) looks to have the edge. Instructions shown in sections below are done on Linux. But most aspects are applicable to Windows too. Linux distribution and kernel often have an effect on different types of workloads. When it comes to timelord logic, not much observed. Logic for creation of a VDF stream is very small. A few instructions repeated in a CPU core. ### Optimize: Establish defaults Follow [mmx-node](../../../guides/installation/#building-from-source) build from source installation for Linux (in this case Ubuntu, with default compiler gcc14). Get mmx-node up and running. Enable timelord in WebGUI, or set `true` in `config/local/timelord` file. Find and [lock timelord process thread](#optimize-isolate-thread) to an E-core (`taskset`). Let it run for a while. Check average speed in NODE / LOG / TIMELORD tab in WebGUI. With this setup: | Environment | Measured | Locked Speed | Measured Per Unit | | :--- | :--- | :--- | :--- | | Ubuntu/gcc14 | 43.16 MH/s | /33 (3.3 GHz) | **1.308** MH/s/0.1GHz | ### Optimize: Compiler Compiler has an effect on how good source code is translated to binary objects. Default for Ubuntu 24.10 is GCC (GNU Compiler Collection), or gcc14. An alternative is Clang (LLVM), or Clang19. There are others. Has varied if Clang or gcc do a better job. One way to install, enable and compile with Clang19: ```bash frame="none" sudo apt install clang lld libomp-dev ``` ```bash frame="none" export CC=/usr/bin/clang-19 export CPP=/usr/bin/clang-cpp-19 export CXX=/usr/bin/clang++-19 export LD=/usr/bin/ld.lld-19 ``` ```bash frame="none" ./clean_all.sh ./make_devel.sh ``` :::note[Note] You need to perform `export` statements in terminal environment before compile, or gcc14 will be used.\ When you switch compiler, or compiler options. Always do `./clean_all.sh` before new compile.\ You will get a lot of unused `-fmax-errors=1` warnings. Just ignore, or remove from compiler options. ::: Default Clang19 compile (`./make_devel.sh`): | Environment | Measured | Locked Speed | Measured Per Unit | | :--- | :--- | :--- | :--- | | Ubuntu/Clang19 | 42.95 MH/s | /33 (3.3 GHz) | **1.301** MH/s/0.1GHz | Small, but noticeable degrade from gcc14's **1.308** MH/s/0.1GHz. We'll switch back to gcc14 going forward. ### Optimize: Compiler options Compiler options can have a big effect on how source code is transformed to a binary object. Often focus is on speed vs size. Several options have an effect on timelord logic. Much have been tried with both gcc and Clang. For now, gcc14 with default options in `./make_devel.sh` gives best performance. Some elements to experiment with (`./make_devel.sh`): * Switch between `Release` and `RelWithDebInfo` (`-DCMAKE_BUILD_TYPE`) * Remove `-fno-omit-frame-pointer` (`-DCMAKE_CXX_FLAGS`) * Add `-march=native` (`-DCMAKE_CXX_FLAGS`) * Variants of `-O` optimization option (`-DCMAKE_CXX_FLAGS`) There are others. Look up optimization in relevant compiler documentation. :::note[Note] When you switch compiler, or compiler options. Always do `./clean_all.sh` before new compile. ::: ### Optimize: Compiler options (AVX vs SSE4.2) Current default compile combines the usage of SHA extensions and SSE4.2 instructions. Raising the SSE4.2 baseline to AVX instructions gives about ~1% boost on 15th-gen Intel. Has to do with compiler using identical AVX versions of certain SSE4.2 instructions. Though, on 11th-gen Intel this looks to degrade performance (better with SSE4.2). To implement AVX vs SSE4.2 baseline (`./CMakeLists.txt`): Change `-msse4.2` to `-mavx` on two lines (Linux compile part): ```cmake set_source_files_properties(src/sha256_ni.cpp PROPERTIES COMPILE_FLAGS "-mavx -msha") set_source_files_properties(src/sha256_ni_rec.cpp PROPERTIES COMPILE_FLAGS "-mavx -msha") ``` Add two lines (Windows compile part): ```cmake set_source_files_properties(src/sha256_ni.cpp PROPERTIES COMPILE_FLAGS "/arch:AVX") set_source_files_properties(src/sha256_ni_rec.cpp PROPERTIES COMPILE_FLAGS "/arch:AVX") ``` Easier to see location in closed [PR#210](https://github.com/madMAx43v3r/mmx-node/pull/210/files) request. Small, but real jump from gcc14's **1.308** MH/s/0.1GHz: | Environment | Measured | Locked Speed | Measured Per Unit | | :--- | :--- | :--- | :--- | | Ubuntu/gcc14 | 43.58 MH/s | /33 (3.3 GHz) | **1.320** MH/s/0.1GHz | :::note[Note] For now, official releases will keep having SSE4.2 as baseline. ::: ### Optimize: Source code One thing to be aware of is that we want to optimize a tiny part of whole mmx-node. Even a tiny subset of whole timelord logic. The calculation of a VDF stream. Performed through `hash_t TimeLord::compute(...)` (`/src/TimeLord.cpp`) calling `recursive_sha256_ni(...)` (`/src/sha256_ni_rec.cpp`). We do not care about the rest. As long as this part goes as fast as possible. Unless surrounding elements has an effect. Not observed for now. That part of source code is already written to be fast when translated to binary objects by compiler (inline, intrinsics, asm). Several iterations were made for it to [end up like that](https://github.com/voidxno/fast-recursive-sha256/blob/main/OPTIMIZE.md). Still, this is the place to adjust source code if you think there is a way to optimize it even more. To illustrate, the following file [sha256_ni_rec_sample.cpp](/resources/code/timelord/optimize/sample/sha256_ni_rec_sample.cpp) contains 5x optimization samples related to static 32 bytes nature of implementation. Intel 15th-gen E-core architecture edition below implements `SAMPLE02` and `SAMPLE04`. If all 5x had been used, reduced effect. Though, would then be possible to remove data for index `8-15` in `K64` array. Independent of that, possible to remove, rearrange variables and order of lines. While still maintaining algorithm. End result is what counts. However you would like the code to look, and what you think works. You are a slave to compiler optimizing code presented. Unless you really want to dig into source code, use architecture edition below. ### Optimize: Source code (architecture) Although current [sha256_ni_rec.cpp](https://raw.githubusercontent.com/madMAx43v3r/mmx-node/refs/heads/master/src/sha256_ni_rec.cpp) is very fast. Not impossible certain CPU architectures could be faster with code organized other ways. Found that out for Intel 15th-gen E-core. Such specific code will not be implemented directly in mmx-node. Making it public here for others to use. | Architecture | File | | :--- | :--- | | Intel 15th-gen E-core | [sha256_ni_rec.cpp](/resources/code/timelord/architecture/Intel_15th-gen_E-core/sha256_ni_rec.cpp) | Download 15th-gen E-core file, overwrite current in mmx-node installation. Update file timestamp, and compile: ```bash frame="none" touch ./src/sha256_ni_rec.cpp ./make_devel.sh ``` Real jump from standard optimized **1.320** MH/s/0.1GHz: | Environment | Measured | Locked Speed | Measured Per Unit | | :--- | :--- | :--- | :--- | | Ubuntu/gcc14 | 44.60 MH/s | /33 (3.3 GHz) | **1.351** MH/s/0.1GHz | ### Optimize: Isolate thread Timelord logic has 1x process thread. It wants 100% of 1x CPU core to calculate VDF stream. Goal is to create an environment that makes this 1x process thread run with high GHz continuously. One way, and valid strategy, is to let the OS process scheduler do its job (Linux or Windows). Distribute and use resources as best possible, depending on requirements and state of system. Maybe tune some aspects of OS, together with BIOS adjustments to clock CPU as high as possible. Gives great results. All modern CPUs have logic to boost individual CPU cores in combination with OS scheduler, power management and other logic. Another, more manual way, is to dedicate a specific CPU core to the 1x timelord process thread. Locking OS and other processes away from it. In this case an Intel CPU with 8x P-cores, numbered 0 to 7. With E-cores following after that. Going to dedicate E-core 8 to timelord process thread. One way to achieve it (Linux, Ubuntu): * Force OS process scheduler to not use core 8. Add `isolcpus=8` to `GRUB_CMDLINE_LINUX` (`/etc/default/grub`). Easily observed through `htop` and CPU core utilization. * When timelord is up and running, you should have 1x process thread at 99/100% with command name of 'TimeLord':
`ps -A -T -o tid,comm,pcpu | grep 'TimeLord'`
You'll get two entries. Last one is the 99/100% creating VDF stream. Can also find it with `htop`. Let's say it have pid(tid) 5122. Assign it to the isolated CPU core:
`taskset -cp 8 5122`
Check result through `htop`. Should have core 8 at 100% all the time through creation of VDF stream. Also possible to isolate several E-cores and assign the process to all of them. Let's say we want a whole E-core cluster, 4x E-cores. Syntax becomes `isolcpus=8,9,10,11` and `taskset -cp 8-11 5122`. How OS process scheduler moves, or not, the process around those E-cores. Not sure. Need to experiment yourself. ### Optimize: CPU speed At this stage we know what to expect for each 0.1 GHz, **1.351** MH/s. All testing we have observed have given linear increase, given CPU GHz. Now it is time to clock CPU core as high as possible. :::note[Note] Optimize and **overclock at your own risk**. ::: First a boring observation. Many elements surrounding raw GHz of CPU core have been tested: * RAM type/speed/latency/bandwidth * HyperThreading on/off * Virtualization (VT-d) * Mitigations (Spectre/Meltdown) * CPU cache/ring ratio * CPU L1/L2/L3 cache size * CPU core-to-core latency Nothing looks to affect timelord speed, except CPU core clock (GHz). Remember, timelord logic for creation of VDF stream is very small. Not much outside a few instructions repeated in a CPU core. In previous CPU generations we disabled P-core hyperthreading and the E-cores themselves. Was no penalty observed on timelord speed. Less complications, more overclocking potential. In this case, if motherboard supports it. Manually clock P-cores lower (GHz), and as high as possible for E-core(s). Now it is a game of getting highest possible GHz, while keeping CPU cool and stable. ### Optimize: CPU speed (Intel 15th-gen) Currently it looks like E-cores on Intel's 15th-gen are able to overlock to between 5.3 to 5.5 GHz. Depending on luck of draw of CPU quality. Tough, are **strong indications of rapid silicon degradation** at those speeds. YOU need to decide if worth it. **Overclock at your own risk, CPU can degrade**. ## Fastest TimeLord On-chain timelord rewards was introduced with testnet10, and further refined with mainnet-rc (release candidate). Now part of blockchain logic. Before that, a temporary centralized solution existed. How do you know if you are fastest timelord. Ultimate indicator is very easy. You have a wallet address set up as 'TimeLord Reward Address' in SETTINGS in WebGUI. Timelord rewards will show up as `0.2 MMX` of type `VDF_REWARD`, every 20th block (...00,20,40,60,80). Overtaking as fastest timelord is not instant. Unless current fastest timelord outright stops, crashes, or new one is faster by a good margin. Your timelord starts behind because of network and verify VDF latency. Not easy to quantify given internet itself, other nodes and decentralized logic. Will help having a fast VDF verify (GPU). Is where your timelord starts calculating its VDF stream from. Still early days. We do not know yet how people will evaluate risk, cost and rewards for running fastest timelord. Run fast, crash often and degrade CPU. Or at the edge, still stable, taking over when fastest crash. Will pattern stabilize, or be random. ### Optimize: VDF verify (GPU) This article is mostly about optimizing your local timelord speed, VDF create on CPU. From whitepaper (quote): > _In the best case, the latency to receive a block is around 100 ms. While the fastest VDF verification is currently around 200 ms, using 40 series NVIDIA GPUs with high clocks. That means a timelord trying to gain the lead would have to be around 3% faster._ As told, many variables in play. Network latency, node reputation, so on. **Another aspect you can optimize locally** is **latency of VDF verify**. Get it as low as possible. For a reference, my RTX 4060 Ti, with fastest timelord at ~72.5 MH/s. Have ~0.257 sec VDF verify. ## Feedback Please contradict findings above, or tell of new ones. Use [`#mmx-timelord`](https://discord.com/channels/852982773963161650/1026219599311675493) channel on Discord. ================================================ FILE: docs/src/content/docs/articles/timelord/timelord-predictions.md ================================================ --- title: TimeLord Predictions description: State and predictions of MMX timelord speeds prev: false next: false articlePublished: 2023-10-05 articleUpdated: 2025-03-17 authorName: voidxno authorPicture: https://avatars.githubusercontent.com/u/53347890?s=200 authorURL: https://github.com/voidxno --- Current state and predictions of MMX TimeLord speeds. Fun reading the future, and [failing](https://discord.com/channels/852982773963161650/1026219599311675493/1307377841070932009) spectacularly. If needed, read [TimeLord Optimizations](../../../articles/timelord/timelord-optimizations/) for technical background and elements of [timelord logic](../../../articles/timelord/timelord-optimizations/#logic). Running a timelord is optional (default is disabled). Not needed to run a fully functional node. Blockchain, as a whole, only need one active timelord to move forward. A few more, spread around, is preferred for redundancy and security. Do not need to be fastest. ## TLDR; Fastest timelord predictions (as of **Mar2025**): - Contenders: Intel/AMD CPUs with SHA extensions - Observed: ~**74.5** MH/s (continuous) - Observed: ~**75.2** MH/s (peak) - Future: ~**71-77** MH/s (2025) ## Contenders Current contenders for fastest timelord are Intel/AMD CPUs with SHA extensions. Why not GPU/FPGA/ASIC, [read here](../../../articles/timelord/timelord-optimizations/#why-not-gpufpgaasic). Always a possibility of something hidden out there, not observed yet. Two elements decide speed of timelord: - CPU core efficiency (MH/s per 0.1 GHz) - CPU core clock speed (running GHz) Leaves us with newest Intel/AMD CPUs that can clock 1x core the highest: - Intel Ultra 200S series (15th-gen, Arrow Lake) - AMD Ryzen 7000/9000 series (Zen 4/5) :::note[Note] [eBACS](https://bench.cr.yp.to) have [SHA256 efficiency benchmarks](https://bench.cr.yp.to/impl-hashblocks/sha256.html) for different CPU architectures with SHA extensions (dolbeau/amd64-sha). ::: ## Today (Mar2025) To illustrate, ignoring overclocking, using max single-core boost from specifications. Intel (E-core): | | MH/s/0.1GHz | Max boost | TimeLord | Release | | :--- | :--- | :--- | :--- | :--- | | 12900KS (E-core) | ~**0.975** | 4.0 GHz | **39.0** MH/s | Nov2021 | | 13900KS (E-core) | ~**0.975** | 4.3 GHz | **41.9** MH/s | Sep2022 | | 14900KS (E-core) | ~**0.975** | 4.5 GHz | **43.9** MH/s | Oct2023 | | 285K (E-core) | ~**1.350** | 4.6 GHz | **62.1** MH/s | Oct2024 | Intel (P-core): | | MH/s/0.1GHz | Max boost | TimeLord | Release | | :--- | :--- | :--- | :--- | :--- | | 12900KS (P-core) | ~**0.705** | 5.5 GHz | **38.8** MH/s | Nov2021 | | 13900KS (P-core) | ~**0.705** | 6.0 GHz | **42.3** MH/s | Sep2022 | | 14900KS (P-core) | ~**0.705** | 6.2 GHz | **43.7** MH/s | Oct2023 | | 285K (P-core) | ~**0.905** | 5.7 GHz | **51.5** MH/s | Oct2024 | AMD (Zen4, Zen5): | | MH/s/0.1GHz | Max boost | TimeLord | Release | | :--- | :--- | :--- | :--- | :--- | | 5950X (Zen4-core) | ~**0.755** | 4.9 GHz | **37.0** MH/s | Nov2020 | | 7950X (Zen4-core) | ~**0.755** | 5.7 GHz | **43.0** MH/s | Sep2022 | | 9950X (Zen5-core) | ~**0.715** | 5.7 GHz | **40.8** MH/s | Aug2024 | In reality, will need to clock 1x core as high as possible (GHz). Keep it there, stable, cool it, 100% load, 24/7. A lot is up to cooling commitment, together with luck of draw on CPU silicon quality. With segmentation and binning done directly by Intel/AMD these days (product SKUs). Top-end SKUs, like Intel KS editions, do not give much headroom. Except if exotic cooling, like LN2 (liquid nitrogen). Observed: ~**74.5** MH/s (continuous) ## Future (2025) Next interesting CPU architecture and node developments: - Intel: Nova Lake (_tbd_, Desktop) - AMD: Zen 6 (_tbd_, Desktop) Both Intel and AMD are cagey about real information on future CPU generations, up-to and including release. Most relevant for timelord: - CPU core efficiency (MH/s per 0.1 GHz) - CPU core clock speed (running GHz) Previous changes in CPU architecture have shown that efficiency for SHA extensions usually change for the better (SHA256 calculations per 0.1 GHz). Intel's 285K E-core (1.350) efficiency increase compared to 14900KS E-core (0.975) was a [surprise](https://discord.com/channels/852982773963161650/1026219599311675493/1307377841070932009). Existing E-core efficiency (0.975) vs P-cores (0.705) was already best in class. Increase is not a given though. Measurements of Zen5-core (0.715) SHA extensions efficiency are lower than Zen4-core (0.755). Probably an architectural decision. Digital circuits have physical limits with trade-offs between CPU cycles needed and max clock frequency. There is a reason why P-cores have higher boost clock (5.7 GHz) than E-cores (4.6 GHz). But at the same time SHA extensions efficiency are lower for P-cores (0.905) vs E-cores (1.350). New desktop CPU architectures are not planned for release by Intel or AMD in 2025. Might get refreshes with somewhat higher clocks, but standstill on IPC and SHA extensions efficiency. Even when we get new desktop CPU architectures in future (Nova Lake, Zen 6). Efficiency will be a question of physical limits depending on architecture and node. After that, what CPU clock speed is possible. With a starting point of ~62 MH/s for Intel 285K (E-core, 4.6 GHz). Possible CPU refreshes and overclock cooling. Up to 20% on top of starting point through 2025. Prediction: ~**71-77** MH/s (continuous) ## Uncertainties (peaks) It is possible we will get short peaks of someone running a timelord with exotic cooling. Trying to make a record timelord speed until CPU crashes, or empty of LN2 (liquid nitrogen). One way to guestimate is to browse [HWBOT](https://hwbot.org/hardware/processors) Geekbench6 [single](https://hwbot.org/benchmark/geekbench6_-_single_core/) and [multi-core](https://hwbot.org/benchmark/geekbench6_-_multi_core/) records. Problem is getting E-core only overclocks for Intel 285K. We have P-core at about 7.0 GHz (single). A few internet mentions looks to have E-core overclock limit/wall around 5.5 GHz. These are usually records done with LN2 cooling. Just enough to run the benchmark. For some reason Intel looks to have left more overclock headroom on E-cores than usual. Observed timelords have probably reached 5.5 GHz. With the benefit of doubt, say someone manages to run **Intel 285K P-cores at 7.0 GHz** or **E-cores at 5.7 GHz**. Results: **63.3** and **77.0** MH/s. More probable with continuous timelord speeds mentioned above. ## Feedback Other angles on topic above. Share on [`#mmx-timelord`](https://discord.com/channels/852982773963161650/1026219599311675493) or [`#mmx-farming`](https://discord.com/channels/852982773963161650/853417165980827657) channels on Discord. ================================================ FILE: docs/src/content/docs/articles/wallets/wallets-mnemonic-passphrase.md ================================================ --- title: Wallets, mnemonic and passphrase description: A look at MMX wallets, mnemonic and passphrase prev: false next: false articlePublished: 2024-07-08 articleUpdated: 2025-01-30 authorName: voidxno authorPicture: https://avatars.githubusercontent.com/u/53347890?s=200 authorURL: https://github.com/voidxno --- A look at MMX wallets, mnemonic and passphrase. :::note[Important] My own understanding, using mmx-node. I take no responsibility for content. When it comes to crypto and wallets, _YOU_ need to educate yourself. As always, _NEVER_ share your mnemonic or passphrase with others. ::: ## TLDR; - **BACKUP** (securely) both **24-words mnemonic** AND **passphrase** (if used) - **NEVER share** your **mnemonic** or **passphrase** with others - Passphrase is not a global lock password for all your wallets - Passphrase is local to, and part of the wallet you created - Passphrase is optional, works like the 25th word of mnemonic - Identical 24-words mnemonic, with/without passphrase, are different wallets - **Take security seriously** (look [Security](#security)) - Public farmer key is not affected by passphrase (look [Farming](#farming)) - Evaluate what farmer reward address is set to (look [Farming](#farming)) - If using other addresses than main one for wallet (look [Addresses](#addresses)) Wallet is [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) based, with [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) functionality. Built with tried and tested elements from Bitcoin wallet. ## Backup As long as you **backup** (securely), in some way, the **24-words mnemonic** and **passphrase** (if used). You will always be able to recreate wallet. Only information needed. Also recommended to **note** the **finger\_print** and main **address** of wallet (Index[0]). Easy indicators to make sure you recreated the correct wallet with backup information. :::caution[Important] Perform the two steps above, and you will always be able to recreate and verify wallet. ::: ## HowTo Look [Find elements](#find-elements) on how to find information above. You can also backup (securely), the `.dat` file, that represents the wallet. Not really needed. The 24-words mnemonic and passphrase (if used), are enough to recreate wallet. Also, if wallet was created with a passphrase. You still need passphrase to access wallet, in addition to `.dat` file. :::tip[Tip] Topics in this article can be tricky to get a grip on. Try asking an LLM chatbot about _"BIP39 wallet standard"_, _"mnemonic"_ and _"passphrase"_. Converse, and you might get answers with angles that works better for you. ::: ## Mnemonic :::note[Note] Ignoring optional passphrase for now (25th word), that is next section. ::: The 24-words mnemonic is a user friendly way to represent the raw binary hexadecimals seed value for wallet ([BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)). Another angle: It is the absolute secret that both creates and gives full access to wallet. When you create a wallet, you have two options: - Specify existing 24-words mnemonic, and recreate an existing wallet. - Don't specify 24-words mnemonic, get a new wallet created, with new random generated 24-words mnemonic. ## Passphrase This element causes some confusion. It is just MMX utilizing the [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) standard in the way it is defined. Nothing more, nothing less. But the simple logic behind BIP39 gives a few use-cases. Depending on your creativity. Technically, not complicated: - Wallet (no passphrase): mnemonic = secret seed (and a unique wallet) - Wallet (with passphrase): mnemonic + passphrase = secret seed (and a unique wallet) Two 100% unique wallets above, even if identical 24-words mnemonic. Seed will be different, finger\_print will be different, main address (Index[0]) will be different. Look at passphrase as the optional 25th word, that you need to type in each time you want to perform actions with wallet. Most important. If you use a passphrase on one of your wallets. You MUST backup that passphrase, in addition to the 24-words mnemonic. Without you will not be able to recreate that wallet. MMX is not storing that passphrase anywhere. Only thing stored in wallet `.dat` file is the 24-words mnemonic. Which is why passphrase is kind of looked at as password for wallet. Two consequences of BIP39 simplicity: - Not possible: Add a passphrase to an existing wallet without passphrase. - Not possible: Change passphrase of an existing wallet with passphrase. - Why: Passphrase (25th word) is a static part of wallet secret. - Solution (both cases): Create a new wallet with existing 24-words mnemonic and new passphrase. This will be a 100% new unique wallet. Then transfer your funds from old to new wallet. Which are two totally independent wallets. Just sharing the same 24-words mnemonic. Some use-cases: - Enhancing security with extra layer on top of 24-words mnemonic. - Have different wallets with same mnemonic, but different passphrases. - Separate funds, hidden wallets, threat scenario, different passphrases. ## Security YOUR responsibility. Too broad of a topic. A few facts: - 24-words mnemonic: Stored in wallet `.dat` file on disk (file itself not encrypted) - Passphrase: Never stored anywhere on disk (only temporary in memory, when used) Full access to a wallet: - Wallet (no passphrase): Only need 24-words mnemonic (i.e., `.dat` file) - Wallet (with passphrase): Need both 24-words mnemonic and passphrase Consider: - Evaluate using passphrase for better security. - Risk of unauthorized access to wallet `.dat` files. - Use of cold wallets, not all wallets have to be active. - Send rewards or other funds to cold wallet addresses. Ultimately. Your responsibility how you store, use, and arrange wallets. ## Farming ### Farmer Public Key You create plots with a `farmer_public_key` (66 chars) from a wallet. This wallet needs to be present on mmx-node to farm those plots. In relation to wallets, `farmer_public_key` can create some confusion. Both statements are true: - Identical 24-words mnemonic, with/without passphrase, gives **identical** `farmer_public_key` - Identical 24-words mnemonic, with/without passphrase, are **different wallets** Logic: - `farmer_public_key` is created from 24-words mnemonic + a fixed passphrase ("`MMX/farmer_keys`"). - Independent of wallet having a passphrase, or not. Done this way on purpose. No compromise on security. Makes it possible for mmx-node to start farming, even if wallet has passphrase. No waiting for user input of passphrase on startup. Pragmatic choice to make farming as seamless as possible. You will never generate identical 24-words mnemonic as another user. Primary purpose of passphrase is extra security, not better randomness. ### Farmer Reward Address Can argue a farming wallet created without passphrase and getting rewards, is an issue. The `.dat` file of that wallet is enough to access reward funds. Still need access to file though. An operational choice, totally avoidable. If wanted. Farmer Reward Address (SETTINGS), can be set to any wallet address. Until set, mmx-node defaults to main address (Index[0]) of first wallet created. Which often is your farming wallet, usually without a passphrase. Make it a non-issue: - Create a new farming wallet, same 24-words mnemonic, now with a passphrase: - This becomes a new unique wallet, with a new main address. - Send rewards to new main address, that you need passphrase to access. - Plots still farming, because of `farmer_public_key` logic above. - Or, set reward address yourself to another cold wallet (best practice). Most important. Double-check that Farmer Reward Address (SETTINGS) is set to what you want and expect. Security and access to wallet controlling that address is up to you. ## Addresses One wallet can have more than one address. When creating a wallet, default is 1 for Number of Addresses. Was 100 in earlier mmx-node releases. You can still set it to 100, or another number. Totally ok, no problem. Rationale: - Easier for most users to operate with one wallet equals one address. - Memo functionality can eliminate need of multiple addresses in most cases. When you recreate a wallet, addresses will be identical to first time you create it. They are unique for your wallet, ordered identically. Independent of how many you choose to be shown. Be aware of ('missing' funds): - No problem sending funds to other index addresses than main one (Index[0]). - If wallet recreated with 1 as number of addresses, will not see those funds. Your wallet is still key to control all those Index[x] addresses. But wallet will only enumerate number of addresses it was specified with. So, if missing funds on a wallet. Make sure it is not issue above, by recreating wallet with at least number of addresses that have seen activity. ## Account Index :::note[Note] Only an explanation that accounts within a wallet technically exists. Not needed in normal usage. ::: The 'Account' word can mislead in this context. Each wallet listed in WebGUI are also 'Accounts'. What we are talking about here is 'Account Index' **within a wallet**. Not to be confused with the `account` index number assigned to a wallet starting at `Wallet #100` (or `#0` if `wallet.dat`). That is just a counter with no significance. Only for mmx-node itself to number the wallets it finds in `Wallet.json`. Account Index here is the `index` property assigned to `0` (default), on each wallet created by mmx-node. Written as `"index": 0,` on each wallet entry in `Wallet.json`. That property has an effect of generating a unique set of addresses for that wallet. Or more specifically, that wallets account index. Unless you have a very specific need of this logic. Ignore it, let it stay at `0` (default). ## .dat files Wallet `.dat` files are stored at following locations: - Linux: `/mmx-node/` `wallet_
Simple calculator to lookup or estimate heights, time and date.
Read this FAQ entry for understanding of height vs. VDF height.
RPC query data from public blockchain explorer.
| Height | |
| VDF Height | |
| Timestamp | |
| Local Time | |
| UTC Time | |
| Discord | |
| Proof Score |
Estimate result for a given height or timestamp.
| Height | |
| VDF Height | |
| Timestamp | |
| Local Time | |
| UTC Time | |
| Discord |
Estimating with data from height
VDF height:
Timestamp:
% non-TX heights, previous 500k
% 10 sec deviation, previous 500k