--- Log opened Fri Sep 17 00:00:10 2021
00:47 -!- belcher_ is now known as belcher
02:45 -!- siv2r093008922 [~siv2r@103.77.37.132] has joined #secp256k1
03:02 -!- siv2r093008922 [~siv2r@103.77.37.132] has quit [Ping timeout: 252 seconds]
03:57 < real_or_random> sipa: are you working on https://github.com/bitcoin-core/secp256k1/pull/507 ?
05:18 < gmaxwell> real_or_random: he's using it for a project right now.
07:31 < sipa> real_or_random: i may try to get it into a state where it's mergeable... though i'm 
07:31 < sipa> not entirely sure that it should
07:34 < nickler> could alternatively just merge it into secp-zkp
08:38 < andytoshi> i'd like to have it in secp-zkp
08:38 < sipa> if it's generally useful, might as well get it in secp itself
08:38 < andytoshi> or anywhere, really. it's rarely useful to grind keys, but when it is, it's nice not to have to re-remember how to do it
08:39 < andytoshi> my uses are usually for QA applications where i want "visibly distinct" keys for testing ... and i guess, you've used it in the past for vanitygenning
08:39 < andytoshi> i would say that that's "generally useful", but i understand the counterargument :)
08:47 < sipa> right
08:47 < nickler> Thought we discussed at some point that libsecp is mostly focusing on code for Bitcoin Core (at least this is what I've been telling people who wanted to add their pet schemes).
08:47 < sipa> i think it's a bit wider - anything we'd expect to be useful for bitcoin applications
08:48 < sipa> due to the integration with bitcoin core, it obviously has to follow anything bitcoin core needs, but i don't think it should be restricted to things needed there
08:49 < gmaxwell> you can just stick it in a module and don't build it by default.
08:49 < gmaxwell> it's had ecdsa for eons and that isn't used in bitcoin.
08:49 < sipa> ecdh you mean
08:49 < gmaxwell> er l
08:49 < gmaxwell> lol
08:49 < gmaxwell> yes, when I say the wrong thing, I mean the right thing instead.
08:50 < sipa> but if someone just has a pet project that's unlikely to become part of a common protocol used in the bitcoin ecosystem, that's a good reason for not including it
08:50 < gmaxwell> There is also a difference between a maintainer's pet project and joe random's pet project, to be fair-- and I don't think there is anything wrong with that.
08:51 < nickler> at least secp-zkp is a good place to put schemes that are unstable to avoid adding "experimental" modules to secp
08:51 < gmaxwell> andytoshi: I think in general people should be discouraged from grinding keys just because it encourages key reuse.
08:51 < gmaxwell> But there will always be silly things where it's useful or fun.
08:52 < gmaxwell> I have a thing I've been working on that grinds keys for a non-silly application. Though I think I'm going to change off of secp256k1 to another curve.
08:54 < andytoshi> my vote is "definitely in -zkp", and i'd prefer it be in libsecp but i wouldn't put any energy into fighting for that
08:54 < gmaxwell> (stego embedding encrypted messages in images, every byte counts, so I was grinding to make shorter keys. But I realized I could make indistinguishable points better by randomly operating over the twist or the curve, and secp256k1's twist properties are ... kinda meh.)
08:54 < andytoshi> oo neat
08:56 < gmaxwell> I want to make a system where you can embed a few hundred byte message (e.g. highly compressed bitcoin txn) in images, encrypted with a known public key,  where it's impossible to detect them in the images.  ... then setup a bot with the private key that trolls all images posted on reddit/r/pics and whatnot, and decrypts any messages it finds and broadcasts the transactions.
08:57 < gmaxwell> I can skip all the SDW stuff, but just having a twist pubkey and a regular pubkey.. and the embedder randomly decides to operate on the curve or the twist.
08:58 < gmaxwell> sorry for the OT. :P
09:00 < sipa> ha, simple solution
09:01 < sipa> that approach was also suggested in a paper for a similar goal that predates elligator
09:27 < gmaxwell> you couldn't easily use it in something like the bitcoin p2p because the two sides need to decide on both curve or both twist.
11:59 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
15:28 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has joined #secp256k1
16:17 < ariard> if key grinding let's you save few bytes, that make sense if you send key material wrapped in a LN onion packet
16:17 < ariard> they're 1366-byte sized
16:18 < sipa> i guess it could be used for that
16:26 < sipa> but you can only realistically shave off one or two bytes
16:27 < sipa> 3 bytes would already take multiple seconds of CPU time
16:53 < ariard> yeah, but with trampoline we have wrapped onions
16:53 < ariard> and we can compress the per-hop payload you might be able to have more trampoline
16:54 < ariard> which might be good for payment privacy and worthy your CPU time
17:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
17:34 -!- belcher [~belcher@user/belcher] has joined #secp256k1
19:03 < gmaxwell> ariard: yeah I dunno how much it would matter for lightning.  In my application I'm compressing transactions by essentially dropping almost all information about the inputs except for a couple bytes, and the output, so the transaction shrinks down under 200 bytes for a 2 in, 1 out. and the detectability of the message is especially sensitive to the space taken by the pubkey, because there isn't a 
19:04 < gmaxwell> shared secret for decoding at that point, so the attacker can be assumed to know exactly which dct coefficients may have been flipped to encode the ecc point. plus I imagine that it's fine if the embedder takes several minutes to encode a transaction. Though I'm not sure yet how the time should be split between gringing down small nonces vs trying multiple nonces to find one with the lowest embedding 
19:04 < gmaxwell> damage in the particular image.
--- Log closed Sat Sep 18 00:00:11 2021