A look at SHRINCS

The challenges of maintaining state within a mobile-first blockchain system are significant, as outlined in a recent discussion. Users frequently encounter difficulties when they need to restart or reset their node, which necessitates the input of a seed-phrase and an accurate count of key uses. The 'KEY USES' value, crucial for the operation of the node, is supposed to be tracked by users after each transaction. However, in practice, many users forget to record this number or lose it entirely when their device is wiped, whether intentionally or accidentally.

Furthermore, complications arise when users operate multiple devices with a single seed phrase without synchronization, leading to overlapping slots and increased complexity in managing separate numerical values for each device. This issue has been partially addressed by proposals to create distinct tree paths for different devices, though this adds another layer of complexity for users to manage.

Non-technical users often misunderstand the purpose of the 'KEY USES' value, confusing it with the frequency of address usage rather than a critical operational parameter. Despite efforts to clarify its importance through comprehensive explanations, there remains a significant gap in user understanding within the ecosystem. Some users even attempt to minimize information sharing during resyncing by underreporting their sync count, inaccurately believing that this will protect their privacy, not realizing the potential security implications.

The current approach to estimating the 'KEY USES' value by asking users how many times they have resynced and multiplying this by 10,000 has proven unreliable. Users often misremember or incorrectly estimate this figure, leading to further inaccuracies. In terms of technical implementation, the SPHINCS algorithm, adopted in-house, provides a basic yet elegant solution without optimization or hardware support. Although functioning adequately, the execution speed on mobile devices using a pure Java version is notably slow, taking 20-30 seconds to generate a key and sign - a potential area for future enhancement to align with more optimized implementations.