I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.
Yes - so perhaps we should add XOR_A_with_B and XOR_B_with_A to the API (as these will be very easy to implement).
Sounds good, I'll do this right now.
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones,
I think sending two messages could be problematic as it opens up a potential attack vector where others might try to inject a message *between the two*.
That could be avoided by hardcoding an address the messages must be received from. I do agree that it is a less desirable setup, but some may prefer having a higher level of security.