--- Log opened Sat Jan 28 00:00:27 2023
11:55 < w0xlt> sipa: That's great.
11:56 < w0xlt> Originally the PR used https://github.com/bitcoin-core/secp256k1/pull/994.
11:56 < w0xlt> If I remember correctly I changed the approach to use `secp256k1_ecdh` when I changed the PR to use all inputs in ECDH instead of just one.
11:56 < sipa> As long as you don't use the Y coordinate, the two are compatible.
11:57 < w0xlt> The main reason is that there is no function to sum public keys if they are x-only. Therefore, a conversion to compressed public key is needed to be able to use `secp256k1_ec_pubkey_combine` with the other inputs.
11:57 < w0xlt> To achieve this, PR currently treats all public keys as having a byte prefix 2. And negates the secret key when necessary.
11:58 < w0xlt> I even opened a PR about it: https://github.com/bitcoin-core/secp256k1/pull/1143
11:58 < sipa> Oh, then x-only ECDH won't help you.
11:58 < sipa> The point of x-only ECDH is that it can avoid the need to decompress pubkeys. But if you need to add them up, you need to do that anyway.
11:58 < w0xlt> Ideally, it would be better to treat all inputs as x-only, combine them, and apply x-only ECDH.
11:59 < sipa> It doesn't matter. To perform point addition, you need to decompress.
12:00 < sipa> The x-only ecdh PR I opened uses a 32-byte X coordinate as input, not a secp256k1_pubkey.
12:00 < sipa> Because it bypasses that representation
12:01 < w0xlt> Got it. To combine the public keys, it needs to be in the `secp256k1_pubkey` format.
12:02 < sipa> Yeah.
12:02 < sipa> We can compute (q*(X, Y)).X, without computing Y.
12:03 < sipa> But can't do ((X1,Y1) + (X2,Y2)).X without having the Ys.
12:07 < w0xlt> Got it. It makes sense. Thanks for the explanation.
22:15 < w0xlt> josie: Yes, the PR is currently storing outputs as a `rawtr()`. A new descriptor for the outputs might work, but if it could be written in `tr` or `rawtr` I think that would be a better approach.
22:15 < w0xlt> I agree the that using BIP32 derivation for the spend_sec_key and scan_sec_key is more secure.
22:15 < w0xlt> So the the `sp` descriptor would be `sp([m/[BIP-NUMBER]'/0']xpriv, [m/[BIP-NUMBER]'/1']xpriv)` or `sp([m/[BIP-NUMBER]']xpriv)` ?
22:17 < w0xlt> And how can the watch-only descriptor be defined ? Because the scan private key needs to be on the internet-connected node to detect incoming payments and a watch-only wallet in Bitcoin Core (with private key option disabled) does not allow this.
22:17 < w0xlt> So currently, if a descriptor has a private key, it's not considered watch-only, right? This would not be the case with silent payments.
--- Log closed Sun Jan 29 00:00:28 2023