Sender Initiated Reference ID Exchange #186
Conversation
dips/dip-183.md
Outdated
|
|
||
| This DIP describes a protocol standard for sender initialized pre-flight exchange using reference ID to form payment transactions. | ||
|
|
||
| Reference ID is used as a unique identifier for a payment transaction between two parties across two VASPs without revealing any information about those parties on-chain. |
There was a problem hiding this comment.
IIUC, each VASP will need to maintain every unique (reference id, sending VASP, receiving VASP) identifier to ensure avoiding duplicate reference ids?
Can VASP A initiate a reference ID R to VASP B
and VASP B also legally initiate a reference ID R to VASP A or is it unique per pair?
There was a problem hiding this comment.
Unique per pair, so between VASP A and B, if a reference ID R was used in a previous transaction, regardless of which one initiated it, R cannot be reused for any future transactions between A and B
There was a problem hiding this comment.
Thanks for the clarification. I think it would be good to add something like your statement into the DIP to make this clear.
We should consider from an implementor perspective how feasible this is to implement. I guess it is expected that the implementor would need to maintain an index of (canonical(VASP1, VASP2), reference ID) and rebuild it from the event history if they lost the index.
This might be simpler if, say, there was just a monotonically increasing reference ID number so one could just look at the last number between canonical(VASP1, VASP, last reference ID number) event on-chain rather than keeping an index?
There was a problem hiding this comment.
I think it depends on how the VASP decides to implement it. They can always enforce uniqueness across all reference IDs instead of pair, which is what I do in my miniwallet diem ID example.
| Reference IDs are unique between a pair of VASPs, `VASP A` and `VASP B`, so if a reference ID `r` was used in a previous transaction between the two VASPs, regardless of which one initiated it, `r` cannot be reused for any future transactions between `VASP A` and `VASP B`. | ||
| However, the same `r` value can be used between a different VASP pair, `VASP A` and `VASP C`. VASPs may choose to keep reference IDs globally unique across all VASPs as well. |
There was a problem hiding this comment.
Also added more details on ref ID uniqueness @aching
There was a problem hiding this comment.
Personally I think the first sentence was good enough, but I'd rather over specify than have confusion :P
| Reference IDs are unique between a pair of VASPs, `VASP A` and `VASP B`, so if a reference ID `r` was used in a previous transaction between the two VASPs, regardless of which one initiated it, `r` cannot be reused for any future transactions between `VASP A` and `VASP B`. | ||
| However, the same `r` value can be used between a different VASP pair, `VASP A` and `VASP C`. VASPs may choose to keep reference IDs globally unique across all VASPs as well. |
There was a problem hiding this comment.
Personally I think the first sentence was good enough, but I'd rather over specify than have confusion :P
Reference ID off-chain exchange DIP. Used by DIP-10 Diem ID protocol.
#183