If two concurrent send commands both try to initiate sessions for the same URI, different coins may be selected.
To prevent this, we should set the locking_mode pragma to EXLCUSIVE, ensuring that only process gets write access to the database at a time.
Then we should perform these checks:
A duplicate URI (identical) indicates the user is trying to start a session that has already been started.
A duplicate RK indicates the URI has been modified and then tried a second time, or that the receiver is misbehaving.
A duplicate bitcoin address is problematic for privacy especially if the two fallback transactions actually make it on chain. Not sure how I feel about allowing an override.
In the future we can relax the locking mode to allow each session to be locked separately. Introducing unique constraints on RK and bitcoin addresses (with a new column for the latter) would allow relaxing the locking mode to NORMAL, but sqlite's ALTER TABLE can't drop constraints so if we allow overriding either later that would require some kind of hack (copy to a a temporary table + recreate of original). Therefore, EXCLUSIVE locking mode + checking the uniqueness only on the rust side seems like the simplest and most future proof approach for now.
If two concurrent send commands both try to initiate sessions for the same URI, different coins may be selected.
To prevent this, we should set the
locking_modepragma toEXLCUSIVE, ensuring that only process gets write access to the database at a time.Then we should perform these checks:
A duplicate URI (identical) indicates the user is trying to start a session that has already been started.
A duplicate RK indicates the URI has been modified and then tried a second time, or that the receiver is misbehaving.
A duplicate bitcoin address is problematic for privacy especially if the two fallback transactions actually make it on chain. Not sure how I feel about allowing an override.
In the future we can relax the locking mode to allow each session to be locked separately. Introducing unique constraints on RK and bitcoin addresses (with a new column for the latter) would allow relaxing the locking mode to
NORMAL, but sqlite'sALTER TABLEcan't drop constraints so if we allow overriding either later that would require some kind of hack (copy to a a temporary table + recreate of original). Therefore,EXCLUSIVElocking mode + checking the uniqueness only on the rust side seems like the simplest and most future proof approach for now.