--- Log opened Mon Oct 11 00:00:32 2021
00:19 -!- Netsplit *.net <-> *.split quits: darosior, real_or_random_
00:30 -!- Netsplit over, joins: darosior, real_or_random_
01:21 -!- real_or_random_ is now known as real_or_random
01:22 < real_or_random> can I ask what this "stego thing" is about? 
06:39 < andytoshi> gmaxwell: awesome! this webpage looks great, hopefully it makes some of the design decisions for you that you weren't sure about 
06:40 < andytoshi> i guess, one decision would be what curve to use for the ecies stuff.. it would be conceptually easier to use a new curve with a safe twist, as you suggested, but maybe practically easier to use the elligator^2 secp256k1 stuff .. especially if the result were significant overlap with bitcoin bip324
15:33 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
15:34 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
18:34 -!- elichai2 [sid212594@hampstead.irccloud.com] has quit [Ping timeout: 260 seconds]
18:34 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 260 seconds]
18:34 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #secp256k1
18:35 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has joined #secp256k1
21:30 < gmaxwell> andytoshi: wrt this application since transactions are only of say 170 bytes, the extra 32 bytes from elegator^2 would be kind of unfortunate.  But you could just use a single fe to represent a subset of pubkeys and do sampling to make the fe's uniform.  It would be slower than elegator^2 encoding but thats fine.
23:34 -!- Netsplit *.net <-> *.split quits: real_or_random, darosior
23:56 -!- Netsplit over, joins: darosior, real_or_random
--- Log closed Tue Oct 12 00:00:33 2021