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
For an output one-time key of O = S + H(8rV)G, an adversary can send to S, V, and then can sample V', before calculating S' = O - H(8rV')G. While the transaction wasn't sent to this address, it can scan for it (at least, it can rebuild the output key, the view tag would have would have to be grinded) if anyone knew its private keys. It's unknown if any OutProof is for such a derived address or for the actually sent to address.
This doesn't allow faking a payment to a store. This does allow claiming a payment made to someone was made to someone else (a random address no one knows the keys for).
This doesn't immediately work for outputs with amount privacy. The amount decrypted will be gibberish, the randomness different, and the commitment won't line up. I'd have to double-check the exact applicability here (even when using amount privacy) with regards to main/sub addresses and upon collusion with the recipient (as then you do have leeway with coercing the view key as necessary). I'm not fully mapping this out as this is a quirk and a rabbit hole, but there's no known real-world use. I just wanted to ensure it's documented.
The text was updated successfully, but these errors were encountered:
For an output one-time key of
O = S + H(8rV)G
, an adversary can send to S, V, and then can sample V', before calculatingS' = O - H(8rV')G
. While the transaction wasn't sent to this address, it can scan for it (at least, it can rebuild the output key, the view tag would have would have to be grinded) if anyone knew its private keys. It's unknown if any OutProof is for such a derived address or for the actually sent to address.This doesn't allow faking a payment to a store. This does allow claiming a payment made to someone was made to someone else (a random address no one knows the keys for).
This doesn't immediately work for outputs with amount privacy. The amount decrypted will be gibberish, the randomness different, and the commitment won't line up. I'd have to double-check the exact applicability here (even when using amount privacy) with regards to main/sub addresses and upon collusion with the recipient (as then you do have leeway with coercing the view key as necessary). I'm not fully mapping this out as this is a quirk and a rabbit hole, but there's no known real-world use. I just wanted to ensure it's documented.
The text was updated successfully, but these errors were encountered: