Wrong assumption that sec-levels above 3 is invalid

[frohal]

I looked at the client-code, and at the getNewAddress-function and discovered a flaw compared to how the protocol has worked earlier.
There has never been any problems using security-levels above 3, they just don't gine any added security, but an address generated with securitylevel 4 or 5 would just need as many tx'es to publish the signature, and all parts of it would then be used to verify the signature.

At least this worked with IRI, and there has not been any mentions about changes in support for sec-levels above 3
samplebundle is KWCSPUKCALYCDPRGDWEVSU9HRIJWUDCXJCDYPCZZJSBDY9SYR9H9X99QWUHPLDDY9UVSBWAKHAZFKSCCC
just sendt and verified by hornet-nodes from an address created with sec-level 5 (using the old java-libs)

[wusyong]

Thanks for notifying. The signing crate is designed in the way that users can sign as documentation suggests. We are going to shift to new transaction layout which might have a slightly different signing scheme on WOTS. Wolfgang will draft another RFC about this in near future. I will address this issue in the RFC and maybe you can also follow it.

[frohal]

Since the 'public' libs for some time already has denied users to create addresses outside 1-3-levels, this is probably not an issie. You are free to choose the restrictions on the libs you create, but I assume that the validity-checking of signatures in the new format will validate signatures that are of any length - since they should also support multisig-transactions, and during validation- there are no difference between a multisg-address created on seclevel 3 by 3 wallets and one seclevel9-address created by my client-lib.
So it's then perfectly OK for your lib to restrict the users of this to only use levels 1-3.