--- Log opened Tue Feb 21 00:00:50 2023
16:37 < Murch> FYI: https://twitter.com/sethforprivacy/status/1628107681016709164
18:42 < w0xlt> Interesting. Hopefully the silent payment approach will be compatible with light wallets.
18:48 < w0xlt> One change that would need to be made to the code is to change the hash of the outpoints from 32 bytes to 8 bytes, as discussed here.
18:48 < w0xlt> But I found the answer below which says "No chance to do a secure hash on 64bit.":
18:48 < w0xlt> https://stackoverflow.com/a/13325223
18:49 < w0xlt> And if it is still secure for this specific case, what would be the way to do it? Extract the first 64 elements of `base_blob<256U>::m_data` ?
18:50 < sipa> What property do you need from "secure hash".
18:54 < w0xlt> I think that for this case, the important thing is that hashing different outpoints necessarily generates different results.
18:55 < sipa> Well a 64-bit hash, even a perfect one, will have a probability of 2^-64 for any two outpoints to match.
18:56 < sipa> But I suspect you want more than that.
18:56 < sipa> E.g. an attacker can't raise that probability above 2^-64.
18:56 < sipa> Under some specific scenario.
18:56 < sipa> If 2^-64 is fine, that is probably achievable.
18:57 < sipa> It very much depends on the scenario.
18:58 < sipa> If you need to worry about collision attacks (both inputs under control of an attacker trying to make them hash to the same thing), a 64-bit hash is definitely not enough, but a 128-bit one may be.
19:08 < w0xlt> Thanks for the explanation. If 128 bits is enough, is extracting the first 128 elements of `base_blob<256U>::m_data` a good implementation?
19:21 < sipa> I'd prefer to get a better insight of what you need this for... like what kind of attacks could form a problem.
19:21 < sipa> I can't say what is or isn't a problem without knowing what you're trying to achieve.
19:21 < sipa> If it turns out that a 128-bit hash is acceptable, truncating SHA256 may be a way to achieve it.
20:15 < w0xlt> Got it. Thanks.	
20:17 < w0xlt> If someone receives funds multiple times using the same address and then uses those UTXOs to make silent payments, the recipient will also have the same key for multiple UTXOs as the basic scheme is `X' = hash(i*X)* G + X`, where i is the private key of the input and X the public key of the output (or `X' = hash(x*I)*G + X` on recipient side).
20:17 < w0xlt> So there is a variant in the proposal that suggests using `X' = hash(i*X,txid,index)*G + X` to avoid this.
20:18 < w0xlt> In PR I am using 256 bits, but it has been discussed here whether it would be better to use 64 bits as it is necessary to send this hash to the light wallets.
20:19 < w0xlt> More precisely, the scheme is `X' = hash(x*hash(txid1,index1,txid2,index2,..)*I)*G + X`.
--- Log closed Wed Feb 22 00:00:52 2023