--- Log opened Mon Mar 13 00:00:11 2023
05:21 < josie> @RubenSomsen, w0xlt: following up on some conversations regarding the truncated hash: since the ECDH module requires a 32 byte tweak, I ran the `ECDHPerformance` benchmark with 100k iterations with the following scenarios 1) SHA256( 8 byte truncated hash ) and 2) convert 8 byte hash into 32 bytes by padding with zeros
05:22 < josie> the idea was to see if using a padded number improves performance. The two numbers I got were 205.7 vs 201.77
05:22 < josie> I re-ran a few times to make sure I consistently came up with a similar delta 
05:26 < josie> based on this, it doesn't seem to make any difference between using a padded 64 bit number vs a 256 bit number. ofc, this doesn't mean we wouldn't see an improvement if libsecp provided methods for ecdh with a 8 byte number, but I'm sure of an easy way to benchmark that 
05:27 < josie> s/I'm sure/I'm not sure/
05:44 < josie> actually, I just realized this is probably not a good way to measure this. The way the current benchmark is written, this is just measuring the speedup in scalar multiplication: sum_seckeys * outpoint_hash, with either hash( 8 bytes ) or 8 bytes padded to 32 bytes, then performing ECDH
05:46 < josie> what we are interested in is what is the difference between (8 byte outpoint_hash) * (Sum_input_pubkeys) vs (32 byte outpoint_hash) * (Sum_input_pubkeys)
06:33 -!- LarryRuane_ [sid473749@id-473749.uxbridge.irccloud.com] has quit [Ping timeout: 250 seconds]
06:33 -!- LarryRuane_ [sid473749@id-473749.uxbridge.irccloud.com] has joined #silentpayments
07:29 < w0xlt> josie: Great point. I agree.
07:29 < w0xlt> However, the `secp256k1` lib does not yet support 8-bit tweak. Changes to this lib will be required before this test.
07:30 < sipa> What function do you use? tweak_mul or ecdh?
07:31 < sipa> tweak_mul is variable time, and IIRC will be faster for smaller multipliers
07:31 < sipa> ecdh is constant time
07:36 < w0xlt> `secp256k1_ec_seckey_tweak_mul` 
07:36 < sipa> Oh that's just scalar arithmetic; you won't notice a difference for 32-bit or 256-bit tweaks there.
07:37 < sipa> IIRC RubenSomsen's concerned about a variant where the 32-bit or 256-bit tweak is applied to a point.
07:39 < w0xlt> In PR, I use only `sum_seckeys * outpoint_hash`, which is a scalar arithmetic.
07:39 < w0xlt> But now I noticed josie is suggesting `(8 byte outpoint_hash) * (Sum_input_pubkeys)` or `(32 byte outpoint_hash) * (Sum_input_pubkeys)`, which is applied to a point.
07:42 < w0xlt> If we do as above, we will have two EC multiplications instead of one (counting ECDH).
07:43 < sipa> w0xlt: Obviously, that's silly; scalar mul + EC mult is always going to be faster than two EC mults, even if one is only 64 bit.
07:43 < sipa> But as I understand it, RubenSomsen is talking about a variant for light clients, which would need to rely on the other variant or so.
07:44 < sipa> I'm not actually up to date on what the scheme is, and I may be completely misinterpreting what you all are talking about.
07:46 < josie> sipa: you're correct, this is only about light clients. For a full node, it doesn't really matter: when scanning, the node would do scal mul of the outpoint hash and secret key first, then do EC mul the the point (sum of input pubkeys). For a light client, they need to get the necessary data from a server, since they wont have access to the full blockchain 
07:47 < sipa> You can assume that a 64-bit EC mult is going to be roughly 3x-4x faster as a 256-bit one, if implemented optimally.
07:47 < w0xlt> josie: I think light clients can do `ECDH(sum_seckeys * outpoint_hash, sum_input_pubkeys)`, can't they ?
07:47 < sipa> The speedup won't be as dramatic right now, even with variable-time pubkey_tweak_mul, because it's optimized for 256-bit scalars.
07:51 < josie> w0xlt: yep, but that means the light client would need to have the outpoint_hash and the sum_input_pubkeys before doing ECDH. this was the motivation for truncating the outpoint hash to 8 bytes - now the light client only needs 8 bytes for the outpoint hash and 32 bytes for the summed pubkeys 
07:51 < josie> alternatively, we could have the server do an EC mult before sending the light client the data: outpoint_hash * sum_input_pubkeys
07:52 < josie> now the light client only needs 32 bytes per tx
07:59 < josie> sipa: thanks for the numbers, that's exactly what I needed. If we assume an optimal implementation, then it seems like the best thing to do would be truncate the outpoint_hash to 8 bytes, have the server do the EC mul of truncated_hash * sum_input_pubkeys and then send the light client the resultant 32 byte public key
08:01 < josie> the alternative is don't truncate the outpoint_hash (so its just sha256(outpoints)) and still have the server do the EC mult before sending the light client data, but now we are asking a selfish server to do 3x-4x more work to send this data to light clients 
08:02 < josie> so in either variant, the light client gets 32 bytes, its just if we go with the truncated hash variant, the server does less work, which seems ideal
08:02 < w0xlt> josie: If I am understanding correctly, you are proposing two operations:
08:02 < w0xlt> For full node: `ECDH(seckey * 8-bit outpoint_hash, sum_input_pubkeys)`
08:03 < w0xlt> For light clinets: `8-bit outpoint_hash * sum_input_pubkeys`
08:05 < josie> w0xlt: yep, the full node would do `ECDH(seckey * 8 byte outpoint_hash, sum_input_pubkeys)` for themselves
08:06 < josie> if they want to serve up data for light clients they would also do `8 byte outpoint_hash * sum_input_pubkeys` and send this to a light client
08:07 < josie> then the light client would do `ECDH(scan_seckey, <data from full node>)`
08:07 < w0xlt> OK. In case of fullnode, `secp256k1_ec_seckey_tweak_mul` is used. And it doesn't support 8-byte tweak.
08:11 < w0xlt> For serving data to lightweight clients, I think `secp256k1_ec_pubkey_tweak_mul` is the appropriate function, but it has the same problem. Requires 32-byte tweak.
08:16 < josie> w0xlt: yeah, although thats not really a problem. If this is what we settle on for the spec, we'd end up implementing something optimized for this use case. The main question is whether or not to include it in the spec to truncate the hash or just leave it a 256-bit number
08:18 < josie> if it is indeed safe to do so and the server can produce the light client data 3x-4x faster (assuming an optimal implementation), then I'm inclined to have truncating the outpoint hash to 8 bytes be included in the spec 
08:19 < josie> w0xlt: just for the purpose of a proof of concept, won't 0-padding the 8 bytes to make it 32 bytes work with `secp256k1_ec_pubkey_tweak_mul`?
09:34 -!- achow101 [~achow101@user/achow101] has quit [Quit: Bye]
09:36 -!- achow101 [~achow101@user/achow101] has joined #silentpayments
09:46 < w0xlt> josie: I think we can either 0-pad the 8 bytes to make it 32 bytes or hash the 8 bytes (which is currently being done in full node).
09:46 < w0xlt> RPC `getsilentpaymentblockdata` can be modified to return `hash(8-byte outpoint_hash) * sum_input_pubkeys` or `0-padded 8-byte outpoint_hash * sum_input_pubkeys` and thus return 32 bytes.
--- Log closed Tue Mar 14 00:00:10 2023