Compatibility Problems with high R and high S signatures

[SurfingNerd]

traditionally bitcoin signatures were able to produce high R and S values that are too big to fit into a 32 byte Array.
Later optimizations reduced that possibility and made sure that R and S always fits into 32 bytes. see: bitcoin/bitcoin#13666
This saves a little bit of blockchain data, and also makes development interfaces easier, by working with maximum 32 bytes.

Ethereum seems to have included this limitation already early on.
Solidities ecrevover also expects bytes32: https://docs.soliditylang.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions

OpenZeppelins recover function, does not solve the problem either, because it also relies on R and S being less then 32 bytes:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol

[SurfingNerd]

Potential Solution A: accepting the problem:
This would result into the situation that someone would have to try out different addresses before he can claim.
Therefore the claimer is not able to use the adress that he wishes to use.
That could be a problem for card wallet.

Potential Solution B: working with Nonces:
Since the DMD Signatures are deterministic, we could allow a nonce in the signature, by allowing abritary text in the claim message. like
'claim to 0x50355cABDa098bC8293224C4dF585812BF9c1476 second try'
this would result into another message hash, so we would get another, hopefully better signature with R and S being smaller than 32 bytes.

[cryptonit]

so if i understand correct if he gets a unlucky above 32byte signature (how he dedects that? its more then 32 letters? he just try to sign again a little different message?

then i propose we make message body
targetdmdv4address for first try and hope it fit into 32 byte
targetdmdv4address#2 or #3 #4 #5 if he need more attepts to get below 32 byte

so for check signature u use the wohle message body

and for parse the target address u just ignore # and anything past the #

[SurfingNerd]

yes, that would be essentially "Potential Solution B"
the prefix has to be defined by us and can differ in testnet and realnet.
the address part has the fixed length of a ethereum address (42chars)
the postfix can be whatever.

prefix + address + postfix
'claim to 0x50355cABDa098bC8293224C4dF585812BF9c1476 postfix can be whatever text'