--- Log opened Tue Feb 07 00:00:37 2023
01:59 < josie> w0xlt: sorry, I should have explained what I meant better regarding the index. If the wallet expects to be doing multiple rescans, having the index is definitely faster. But for normal node operation, I wouldn't expect multiple rescans, or even any! so if rescanning once is roughly equivalent to building the index, then building the index for a full node doesn't seem worth the effort
02:31 < josie> regarding the index, nice! based on the numbers I shared before, I think we can also truncate the hash from 32 bytes down to 8 bytes, so the index would store `<sum_pub_key1><8 byte hash1>`, so only 40 bytes per tx. This would also allow the light client to do `(i*sum_pub_key1)||<8 byte hash1>` for the tweak, which is (potentially?) faster than `(i*hash)*sum_pub_key`
02:32 < josie> the main question is how much faster is it for the full node to create the index if the full node doesn't have to do the multiplication and is this speed up enough to justify the extra 8 bytes of data we would need to send to the light client 
02:33 < josie> (recall that if the full node does `<hash>*sum_pub_key`, we now only have to send 32 bytes per tx to the light client)
02:40 < josie> re: ordinals, I don't think we should filter these out? an ordinal is just a script path spend, so in theory nothing prevents you from paying to a silent payment address while using an ordinal? I might be missing something, though
14:15 < w0xlt> --
14:15 < w0xlt> josie: Now I understand your point regarding the index. I agree that technically it is not necessary.
14:16 < w0xlt> But there's the UX too. On my machine, the index takes an average of 2 hours to complete. On a Raspberry, it should take considerably longer. I don't know if the user will wait that long for an RPC response.
14:16 < w0xlt> Regarding truncating the hash to 8 bytes, is it safe? Is there no risk of collision?
14:16 < w0xlt> We can have two versions of the index (one with EC multiplication and one with concatenation) to test them out.
14:17 < w0xlt> It is important that the index has the same scheme as the normal operation of the node (only one scheme). Otherwise, it can add unnecessary complexity to the implementation.
14:18 < w0xlt> Regarding ordinals, I wasn't suggesting any specific filters, but whether there's any way to improve the scriptPubKey filter to identify silent payments, but there doesn't seem to be.
14:24 < w0xlt> The current hash logic is in: https://github.com/w0xlt/bitcoin/blob/1507d58f0b38d5e319a3117154c0e9f5202fbf69/src/silentpayment.cpp#L184-L200
15:05 <@RubenSomsen> josie: OK, I think we're on the same page regarding p2pk, p2ms, using an 8 byte hash, and bip158 being good enough for now. I don't think we should concatenate the 8 byte hash, even if we decide to store it separately. Scalar multiplication is no big deal, and that way we leave room for alternative implementations that do decide to store it as `<hash>*sum_pub_key`.
15:10 <@RubenSomsen> w0xlt: we can assume people won't deliberately try to create collisions, because the far more trivial way to cause address reuse is by just reusing an address instead of trying to cause a collision.
18:10 < w0xlt> If I understand correctly, the scheme would be `(i*<8-bytes-hash-outpoints>)*sum_pub_key` ?
--- Log closed Wed Feb 08 00:00:39 2023