# LXMF & Discovery Stamps - Upcoming Changes _General · started by Mark on Tue, Nov 10, 2026 12:14 PM_ --- ## Original post **Mark** · Tue, Nov 10, 2026 12:14 PM Since we're doing quite a bit of stamp-related transitioning at this point already, I decided it would be a good point to also get some inconsistencies and old design problems stemming from the very early days of the stamp system ironed out. The initial stamp implementation from LXMF used various difficulty classes of stamps, by constructing hashing workblocks of different sizes. I won't go into the long technical details on everything here; there was a lot of considerations. A large part of those initial design decisions were made in attempts to mitigate the problem of having only integer-based value and cost targets to work with, which made difficulty adjustments quite impractical (a doubling of difficulty for each single point increase). Now that difficulty is adjustable in 0.27% step increments, all the additional complexity of different stamp classes has become something that mostly just causes confusion. Having one unified scale for stamp difficulty is much more intuitive and easy to work with for everyone. Furthermore, I actually made a silly mistake in the initial workblock expansion design, which means that if you're a bit clever, you can bypass the memory-binding property of the workblock generation phase, for some extra compute. As such, we're now in a situation where the whole original purpose of all that extra complexity has been superceded by a much more elegant solution with fractional stamp cost, and some of the desirable properties of the workblock expansion are not even working as intended. This doesn't mean that current, variable workblock stamps are fundamentally broken, of course. The expanded-workblock stamps used in LXMF and interface discovery still work and provide the intended anti-spam functionality. But the system is needlessly complex, for something that could provide the same functionality much more elegantly. It's also more computationally intensive to *verify*, which is also a pretty big argument against it. For those reasons, the stamps used in LXMF and the interface discovery system will be migrated to use the exact same non-expanded workblock format that the network stamps just added to RNS is now using. This will unify everything under the same difficulty class, and make it much easier to understand and configure across applications. It will also have the very beneficial effect of significantly lowering verifier load, something that PN operators on limited systems will probably appreciate quite a lot :) This is mostly just an informative post. Unless you are already using some kind of completely custom stamp setup in your own app, or you're maintaining your own Reticulum implementation, there is nothing you have to do: **All applications using the RNS and LXMF modules will just migrate transparently and automatically, once updated to the relevant versions.** The next releases of RNS and LXMF will add automatic compatibility with both the upcoming and the old stamp versions. Computationally, this is practically free, since the new non-expanded workblock stamps are extremely fast to verify, basically a few microseconds. At some point in the future, once applications and nodes are running a version that supports both the old and new stamp versions, applications will begin generating and stamping messages (and discovery announces) with the new version. Finally, at some later point again, the compatibility shim will be removed, and only the new, non-expanded workblock stamps will be used. That should provide a smooth and transparent transition for everything, without anyone else than me having to actually do anything or make annoying changes to their applications. Furthermore, this approach will give me the opportunity to actually activate a new expanded-workblock generation algorithm (now, actually memory-hard! lol). By then, it won't be used in any actual applications or systems, but it *is* a very useful primitive and tool to have, and it will be ready for future applications then. The only downstream, user-facing effect of this, is that stamp costs will probably have to be adjusted slightly up for LXMF and discovery stamps at some point in the future, once the transition is complete. But I think that's an acceptable consequence of making everything a lot more consistent and efficient. --- ## Reply 1 **Mark** · Tue, Nov 10, 2026 12:32 PM PS: If you want to try and be adversarial and clever against the new workblock expansion design, the initial version of it is in the `_stamp_workblock_future` function of `Stamps.py`. The intention here was designing it to be extremely simple to understand and challenge (it's basically 15 lines of actual code), while also being extremely hard to memory-optimize, without blowing up absurdly in compute cost. As an example challenge, can you find a way to generate a the hash of a 5000 expand-rounds workblock, with meaningfully less memory than just holding the full workblock resident? (note, disk storage counts as "memory" here as well, of course). ---