You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
... 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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: