Making XMSS safer by optionally storing additional state to help reduce OTS re-use risk..

[surg0r]

Background
XMSS is a stateful signature scheme. An attacker in possession of two or more signatures from the same one-time signature (ots) position with sufficient resources may be able to forge a signature. The QRL network expressly disallows ots re-use for an address by maintaining accurate state of confirmed transactions from the blockchain and storing a record of which ots are used and unused for each address. Any transaction sent by a user into the network which features an ots position classed as used is dropped, not relayed, and cannot be included into a valid block.

On very rare occasions a transaction featuring a valid signature is dropped from the network as invalid due to failed state checks such as insufficient funds.

Best practice
The only way to be completely sure that ots are not re-used is for the user to note down what they have used after each attempt. As each signature occurs, each ots is accounted for regardless of whether the transaction is confirmed or dropped by the network.

Suggested network improvements
Currently the webwallet synchronises address state for a wallet address from the network via the grpc api. This includes an ots_bitfield and counter which reveals which signature positions are used/unused from the blockchain. The webwallet then chooses a safe position to sign from. This state data does not include information not in the chain and thus transactions dropped previously are unknown.

One possibility is to add an optional configuration file setting extended_ots_state in the node. This optional flag allows the node to supplement address state with optional off_chain_ots_bitfield and off_chain_counter which become existent when a transaction is seen and dropped for a given address and ots position. This could either simply activate in the presence of invalid transactions which do not confirm, and with an additional array could denote the number of times an address has been re-used.

This data could be exported via a modified grpc call pairing GetAddressStateReq/GetAddressStateResp and provide the webwallet with an added layer of protection for users.

[surg0r]

Actually in state probably just a dict extended_ots_data:
{ ots_number : integer of dropped transactions } would suffice..

To minimise spam risk the setting extended_ots_state will be turned off by default.

We can set a rule that addresses with 0 balances are ignored and not recorded also.

Finally, the ability to skip ots safely is what makes XMSS vastly safer than systems utilising simple Winternitz-ots+ such as IOTA and mochimo, though requiring significantly more computation prior to signing to achieve this.

[cyyber]

The idea is good for making the web wallet much secure and will help to stop reusing the OTS index. But they are also vulnerable to spam attack, where someone making bad transaction intentionally, to consume the disk usage.

Although adding threshold balance will only need minimum balance on the address to perform the spam. But at the end it will not be able to stop the spam.

Other issues could be

• In a decentralized network, a transaction may be received by other node which is not recording ots index for dropped txn and it may be dropped by that node due to failure in state validation. Thus node recording the OTS index for dropped txn, will not be able to trace such OTS index.

• Wallet hosted by community, may have a different record of used OTS index due to failed transaction compared to the official web wallet. As both the nodes may have not seen all the dropped transaction.

[surg0r]

Spamming is a risk to be considered but it would take a gigantic and constant number of failed transactions to fill a disk over many, many hours and probably is infeasible.

We could just disable extended_ots_state in that instance temporarily to negate the attack vector.

[cyyber]

If we want to disable extended_ots_state during spam attack, probably doing this in an automated way will be better, so that we don't need a human to monitor if we are spammed and disable it manually.

And a spam test over this feature on testnet will be helpful to determine how critical could be the spam.