--- Log opened Fri Jan 27 00:00:27 2023
00:21 < josie> w0xlt: thanks! regarding descriptors, I think we will need two descriptors: sp() for the silent payment address, and a second one for storing the silent payment outputs. I think in the PR you are currently just storing outputs as a rawtr(), which is fine. the benefit of adding a second descriptor for silent payment outputs is better standardization. I'm specifically thinking of the scenario
00:21 < josie> where we need to pass data to a signing device which only has the spend private key
00:23 < josie> but the descriptors isn't super urgent right now, because I think those would be defined in their own BIPs, since there is nothing preventing someone from implementing silent payments without using descriptors
00:27 < josie> regarding the SPEND_SEC_KEY and HASH(SPEND_SEC_KEY), I think this works fine, although if the spend_sec_key is ever leaked then the attacker can derive the scan_sec_key and you would lose access to your funds. If we instead use BIP32 derivation for the spend_sec_key and scan_sec_key, you can leak either scan_sec_key or spend_sec_key without losing access to your funds.
14:36 < sipa> This may be interesting here: https://github.com/bitcoin-core/secp256k1/pull/1198
16:17 <@RubenSomsen> sipa: x-only ECDH, nice
--- Log closed Sat Jan 28 00:00:27 2023