i'm not sure if this is statefully allocating indices (in which case there may be a DoS concern associated with address gap limits) but even if it does such information cannot be recovered from seed, and therefore may link outputs in previously failed transactions (where not all signatures were collected) to the server:
|
pub fn coinjoin_output_address(&self) -> bitcoin::Address { |
|
self.inner.peek_address(KeychainKind::External, 0).address |
|
} |
assuming the server can be trusted to exclude at least one output and subject to a subtle key cancellation concern, this can be more or less guaranteed avoided by deriving these self-spend addresses as silent payments addresses. this requires no participation from the other parties, since the participant presumably knows their own private scanning key (i.e. no privacy preserving (blind DH based) analogue of bip 375 is required to use this)
the edge case is if a pair of adversarial inputs whose public keys sum to the point at infinity are both removed, then even though the input set is different the silent payments tweak may be the same if the lexicographically first outpoint is unchanged. successfully exploiting this requires specially prepared inputs and targetting a user so that this user generates the same self spend address twice. this can be mitigated by rejecting rounds with a duplicate A term (sum of public keys per BIP 352). although this reintroduces statefulness, since the condition this protects against is an adversarial corner case, not a usual occurrence, so in practice this mitigation should suffice and eliminate any possibility of accidental off-chain address reuse in any reasonable attack scenarios.
i'm not sure if this is statefully allocating indices (in which case there may be a DoS concern associated with address gap limits) but even if it does such information cannot be recovered from seed, and therefore may link outputs in previously failed transactions (where not all signatures were collected) to the server:
blindjoin/client/src/wallet.rs
Lines 483 to 485 in 982fc28
assuming the server can be trusted to exclude at least one output and subject to a subtle key cancellation concern, this can be more or less guaranteed avoided by deriving these self-spend addresses as silent payments addresses. this requires no participation from the other parties, since the participant presumably knows their own private scanning key (i.e. no privacy preserving (blind DH based) analogue of bip 375 is required to use this)
the edge case is if a pair of adversarial inputs whose public keys sum to the point at infinity are both removed, then even though the input set is different the silent payments tweak may be the same if the lexicographically first outpoint is unchanged. successfully exploiting this requires specially prepared inputs and targetting a user so that this user generates the same self spend address twice. this can be mitigated by rejecting rounds with a duplicate A term (sum of public keys per BIP 352). although this reintroduces statefulness, since the condition this protects against is an adversarial corner case, not a usual occurrence, so in practice this mitigation should suffice and eliminate any possibility of accidental off-chain address reuse in any reasonable attack scenarios.