Following the example of "PoDLE" in Joinmarket - it is very likely that many potential applications will want multiple usages available per (u)txo/pubkey. For this reason it makes sense to do:
J = hash(application-specific-label, counter)
(see #7 for some related concepts)
... where counter is just an incrementing integer (or anything similar). For now, this is already technically possible if both sides are prepared to fold the counter into the label; messy but it works.
An interesting practical point here: if we have to check a given token against multiple counters, does it degrade performance too much? I think the answer is no: this calculation is completely orthogonal to the (expensive) curve tree construction and the (cheap but non-zero) curve tree proof verification. That can be done first, and then we can simply iterate the Ped-DLEQ proof verification with different counters (exactly as is done in Joinmarket), because it's very cheap/quick.
Following the example of "PoDLE" in Joinmarket - it is very likely that many potential applications will want multiple usages available per (u)txo/pubkey. For this reason it makes sense to do:
J= hash(application-specific-label, counter)(see #7 for some related concepts)
... where counter is just an incrementing integer (or anything similar). For now, this is already technically possible if both sides are prepared to fold the
counterinto the label; messy but it works.An interesting practical point here: if we have to check a given token against multiple counters, does it degrade performance too much? I think the answer is no: this calculation is completely orthogonal to the (expensive) curve tree construction and the (cheap but non-zero) curve tree proof verification. That can be done first, and then we can simply iterate the Ped-DLEQ proof verification with different counters (exactly as is done in Joinmarket), because it's very cheap/quick.