--- Log opened Tue Feb 28 00:00:57 2023
06:52 -!- Murch [~murch@user/murch] has quit [Ping timeout: 260 seconds]
06:52 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 265 seconds]
07:09 -!- Murch [~murch@user/murch] has joined #silentpayments
07:11 -!- sipa [~sipa@user/sipa] has joined #silentpayments
09:20 <@RubenSomsen> w0xlt: We ultimately have to calculate `privkey*outpoints_hash*I`. In order to do that as a light client you either need to receive outpoints_hash (8 bytes) and I (32 bytes) and first calc `privkey*outpoints_hash` and then multiply that by I, or you could receive `outpoints_hash*I` (32 bytes, so 8 bytes less but requires an ECC mult by the server) and multiply that by `privkey` (another ECC mult).
09:22 <@RubenSomsen> The claim I'm making is that `outpoints_hash*I` is faster if `outpoints_hash` is 8 bytes instead of 32 bytes. But of course this only matters to servers that are willing to serve `outpoints_hash*I` instead of the two separate values (Electrum?).
09:55 < sipa> Can't you compute (privkey * outpoints_hash) first, and then only do a single 32-bit EC multiply?
09:55 < sipa> err, 256-bit
10:05 < w0xlt> Yes, that's what PR does first: `privkey * outpoints_hash`.
10:05 < w0xlt> But doesn't `secp256k1_ec_seckey_tweak_mul` require a 32-byte tweak? That's why I'm converting `outpoints_hash` from 8 bytes to 32.
10:15 < sipa> That's an implementation detail. for production code we can write a silentpayments modulo for secp256k1 that does whatever it needs to.
10:19 < w0xlt> Yes. In this case `privkey * outpoints_hash` is sufficient. There is no need to hash the 8-byte `outpoints_hash`. This is only an issue considering the current version of secp256k1.
10:19 < sipa> I think you're missing my point.
10:21 < sipa> An 8-byte tweak sounds scary to me.
10:22 < sipa> That's not about how the encoding, but about the range of values it can take
10:23 < sipa> My suggestion to hash to get a 256-bit value isn't a workaround for converting an 8-byte value to a 32-byte value due to secp256k1's API.
10:24 < sipa> It's to make sure you don't use a tweak from just a 2^64 range.
10:28 < w0xlt> Yes, I  agree. Originally, PR hashed the outpoints into a 32-byte hash using `CSHA256` and then executed `privkey * outpoints_hash`. There was no 8-byte hash involved.
10:30 < w0xlt> But then it started to be discussed here if it wouldn't be better to use 8 bytes to be able to send less data to the client.
10:38 < w0xlt> https://github.com/w0xlt/bitcoin/blob/ee652ca59a7c3e6f73f871d00d640074a1e7abac/src/silentpayment.cpp#L186-L211
10:40 < w0xlt> Originally, the PR only used `uint256 result_hash`. But then I added `truncated_hash` and `final_hash` to conform with the suggestion to use 8-byte hash.
16:12 <@RubenSomsen> sipa: There is a light client use case where a server provides you with the data that you need to calculate the final address. That server could send you 32 + 8 bytes (this allows the client to do what you described), or it could EC mult first and only send you 32 bytes.
16:16 <@RubenSomsen> sipa: Is the concern about deliberate collisions or something else? We think collisions aren't an issue in this specific case because the only thing a malicious sender could possibly achieve is to cause address reuse, and there are much simpler ways to achieve that (i.e. just reuse an address you were given).
16:20 <@RubenSomsen> To recap the scheme - you basically take a recipient key (X), an input key (I), generate shared secret i*X and send money to hash(i*X)*G + X. This has the issue that address reuse on the sender side could cause address reuse to occur on the recipient side (i.e. if a second payment is made where I is the same).
16:25 <@RubenSomsen> In order to avoid this, we also require the sender to add an outpoint_hash, so we end up with hash(outpoint_hash*i*X)*G + X.
--- Log closed Wed Mar 01 00:00:58 2023