--- Log opened Thu Jun 10 00:00:33 2021
00:17 < real_or_random> see https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation here in the spec
00:18 < real_or_random> This is a defense against rouge-key attacks, very similar to how musig combines pubkeys. 
00:19 < real_or_random> There are two public keys, and each party in the channel knows one of the secret keys, so yes, they can use a tweak
00:27 < real_or_random> Electrum uses this too, I believe for BIP32 derivations https://github.com/spesmilo/electrum/pull/5947/commits/ad408ea832c55458b730945832c826894dfa9386
00:36 < real_or_random> also eclair  https://github.com/ACINQ/secp256k1-kmp/blob/master/jni/c/src/fr_acinq_secp256k1_Secp256k1CFunctions.c#L530
00:51 < real_or_random> and it turns out it can be used for adaptor sigs https://github.com/rust-bitcoin/rust-secp256k1/pull/291#issuecomment-858192349
00:53 < real_or_random> Maybe we should simply add a low-level module with the point addition and multiplication  and let people do their YOLO stuff.
00:55 < real_or_random> We're not going to add a module for every use case anyway. We don't have a BIP32 module or a Taproot module (yet), and also the existing tweak functions are somewhere are rather low-level.
01:02 < gmaxwell> But they could just use the tweak though, so why add anything?
01:11 < real_or_random> gmaxwell: for which use case now?
01:11 < real_or_random> the one in LN?
02:18 -!- belcher_ is now known as belcher
07:53 < michaelfolkson> You can't require a ECDSA signature from within a Taproot tree right? All the script paths only support Schnorr pubkeys and signatures? No support for ECDSA at all for SegWit version 1?
07:55 < michaelfolkson> The use case would be a server that is set up to only create ECDSA signatures and you want to include that within a script path of your Taproot tree
08:21 < andytoshi> correct
08:21 < andytoshi> there is no way to get ECDSA from within taproot
08:22 < michaelfolkson> Was it discussed? Because it is possible right? Just encourages usage that hurt some of Taproot's general benefits
08:24 < michaelfolkson> And the use case is pretty weak too :)
09:23 < roconnor> schnorr signatures are batch verifiable.
10:05 < michaelfolkson> roconnor: Indeed I'm clear on the benefits of Schnorr over ECDSA (I think), just wondering about this (unlikely) use case where someone might want to use ECDSA within a Taproot tree
10:05 < sipa> the only use case i can imagine is "i don't want to bother implementing schnorr signing"
10:06 < sipa> but due to the changes in sighashing, you"d need to change signing logic anyway, even if ecdsa were still supported
11:20 < real_or_random> gmaxwell: for which use case could they just use tweaking ? for the one in LN? 
11:33 < gmaxwell> In the above lightning and electrum. 
11:34 < gmaxwell> the tweak functions are created for that usage.
12:07 < real_or_random> indeed, yes. I still wonder whether exposing some functions will be a good idea
12:07 < sipa> using pubkey tweaking should be more efficient than generating two keys and adding them
12:08 < real_or_random> I prefer people using libsecp over some other library if they have special use cases
12:09 < real_or_random> I guess what happens is that if there's some project with self-made scheme X, the unavailability of support for X in libsecp won't stop them from doing X. they'll just use another library
12:25 < gmaxwell> Thats fine.
12:27 < gmaxwell> Every point of interface is another thing to be maintaned, another thing that can't be easily removed if it becomes a nussance or if there is a better replacement, every point is a potential attractive nussance that might cause users to use the wrong tool even when the right one was available the whole time.
12:29 < gmaxwell> This is I think a fine example of that. I believe that the tweak operations _predated_ combine-- combine existed as a side effect of the pre-musig schnorr work. Yet because come was there a bunch of parties used it when they should have used tweak-- and where tweak would have been decidely faster too.
12:33 < sipa> indeed, the tweak operations existed for bip32
12:37 < gmaxwell> and, yeah-- tweak is a bit generic. But bip32 itself is a bit overly constrained.  There have been times in the past where people have proposed invoicing formats that did stuff like tell you a services' static pubkey plus an arbritarily generated tweak value, so that you could better resist address subsitution.  Stuff where an more flexible tweak is useful.  And the interface is simple enough .. 
12:38 < gmaxwell> pubkey+seckey ... and not an obvious footgun.
13:53 -!- jesseposner [~jesse@2601:647:0:89:790f:8501:a950:6a94] has quit [Ping timeout: 252 seconds]
21:33 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
21:37 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
--- Log closed Fri Jun 11 00:00:34 2021