Good Day,

I would like to chip in.

I designed, wrote and work on a blockchain that implements WOTS sigs as standard so have some real-world knowledge of how this plays out in a live environment.

'SHRINCS' uses a ladder of WOTS keys that grows one level every time you use it. I think a tree of keys works better. This way you can have a set amount of slots/keys at a constant sig size.

Using a tree you can sign the root of another tree with a leaf key and have tree-of-tree keys (XMSS). This is what we do. This gives _potentially_ millions of signatures from a single address at the cost of signature size. How big the tree-of-trees is, how deep in trees and how many leaf nodes per tree, does not need to be hard coded and can be user defined. More potential sigs > signature size.

The only thing a verifier needs to be able to do is check a merkle branch and a WOTS sig. This covers all possible tree sizes.

With basic parameters you can create a WOTS-Tree sig in anywhere from 2-4k ( less if you use 128bit hash ) and have > 100,000 signatures. Still much larger than BTC sigs but manageable.

I do like the SPHINCS+ tree path SHRINCS uses to allow either system to be used.

Problems :

First - keeping the state is non-trivial. This is MUCH harder for Users than I expected.  

The idea that you can reset your node JUST from a seed is deeply embedded.. asking Users to keep track of even a single digit - the number of 'slots' used - has proved a stumbling block. Key slot reuse and ergo insecure keys happens.

If the proposed changes assume that any reset of your node would then require you to use SPHINCS+ to sweep remaining coins and send them to a new address this would work.. but that in and of itself is not great.

- You lose your old addresses.
- You may have a lot of coins and the sweep transactions may cost a lot - especially given the size of a SPHINCS sig.
- You need a NEW phrase.. all your cold wallets are no good. All your carefully hidden BIP39 seeds are useless and need to be remade.

If you choose to just use SPHINCS .. this also has issues.

We have implemented a SPHINCS+ scheme that runs in the base txn scripting.. so you can use that instead of the base WOTS scheme.

- Creating SPHINCS sigs is a lot more resource intensive than WOTS.
- RAM usage is 100x more ( not soo bad )
- SPHINCS sigs are BIG. ~20kb. Bigger than a regular WOTS sig and MUCH bigger than regular BTC sigs .
- Real issue is that on a phone the SPHINCS sig can take 20-30 seconds to create. Verification is still fast - just checking some merkle branches and WOTS sigs.

I do think a system like SHRINCS is the way to go but with some lee-way to choose the exact construction of your tree of keys.

What you need is :

- An OP_ for general Merkle branch checking. You need to use a HASH-SUM tree for SPHINCS.. so you can tell which HORS set you are using (technical point).
- An OP_ for WOTS check
..
- An OP_ for SPHINCS checking - which you _could_ actually create in script using the first 2 ops but a single OP_ would be cleaner/faster.

Then you have the freedom to create a SHRINCS style keys with variable parameters that allow signature size to be sacrificed for greater potential key uses. 

Regards,
spartacusrex