--- Log opened Mon Nov 02 00:00:04 2020
00:52 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
00:57 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 264 seconds]
02:27 -!- stackingcore21 [~stackingc@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
02:28 -!- stackingcore21 [~stackingc@2604:a880:2:d0::1bda:1001] has joined #secp256k1
02:53 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
03:00 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 256 seconds]
03:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
03:51 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
03:59 < nickler> ja: It may take a while until 1.0 is released. I don't think there were ABI changes outside the experimental modules.
03:59 < nickler> libsecp master has the endomorphism optimization turned on by default which is a significant speedup.
03:59 < nickler> Worth noting that the experimental ECDH module wasn't constant time which was fixed in Jan (https://github.com/bitcoin-core/secp256k1/pull/709).
04:56 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
05:01 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 246 seconds]
05:55 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
06:01 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds]
07:57 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
08:02 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 240 seconds]
09:58 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
14:05 < ja> hmm, so if there are not backwards-compatible changes in 1.0, why even bump the version number? the debian package is currently called libsecp256k1-0, what is the advantage of having it be libsecp256k1-1?
14:05 < ja> a bunch of scripts will have to be updated to rely on either package if they don't use schnorr
14:05 -!- jonatack [~jon@213.152.161.101] has quit [Quit: jonatack]
14:06 < ja> *backwards-incompatible
14:08 < ja> there havn't been any releases, but distros have interpreted this as the version being 0
14:09 < ja> so on debian, ecdh was never enabled. if ecdh was enabled on other distros, that would be an argument for incrementing the major version number
14:10 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1
14:13 < sipa> ja: semver allows backward-incompatible changes before 1.0
14:14 < sipa> i don't think there should have been distro packages at all yet... but we also have lingered wait to long before creating a stable api
14:14 < sipa> *way
14:14 < sipa> *too
14:14 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 265 seconds]
14:16 -!- jonatack [~jon@109.202.107.5] has joined #secp256k1
14:29 < ja> sipa: the distro packages are already there. is it really worth it to bump the number to 1.0.0 just because semver says that version defines the public API? the packages already exist, so from a distro perspective that public API has already been defined.
14:30 < ja> where does semver come from? i didn't even know the library was using semver
14:31 < ja> nickler: re "I don't think there were ABI changes outside the experimental modules", since when don't you think there have been changes? your message is a reply to my question about debian packages from 2016/2017 and 2019, right?
14:32 < ja> i have been chatting with gmax, i am quoting with permission: "I am fairly confident that there have been backwards incompatible ABI changes since 2016.  There may not have been any since 2019"
14:34 < sipa> ja: optional modules (and particularly the experimental ones, which until very recently included ecdh) is inherently a problem for packaging... i don't have a good answer
14:35 < sipa> but i don't see any reason not to declare a v1.0 once we're actually ready to commit to a stable API for non-experimental parts
14:38 < sipa> and semver... not formally, but it seems very reasonable to assume that software with a 0.x version (and no releases whatsoever really) has no stable API?
14:44 < ja> bitcoin doesn't follow semver, and this library lives in that ecosystem. there are many examples. there are also many examples of many projects that change ABI in minor versions, like CPython and Linux. libsecp256k1 lives in a C ecosystem where semver is more of an exception than a rule, imho
14:45 < ja> you say that you don't see any reason not to declare a v1.0, but i tried giving you a reason: it will require anybody depending on the package to adjust their scripts, and if they forget, they simply will never get the endomorphism upgrade or schnorr without extra effort
14:45 < ja> or maybe their distro will slap a 0-version on the 1.0 release because it isn't actually incompatible, which will be even more confusing
14:46 < sipa> i don't have a good solution - but it seems keeping a 0 version forever would perpetuate these problems even longer
14:46 < sipa> it's going to be annoying in any case
14:47 < sipa> 0 simply has no guarantees, as it could mean a super early 2013 version when libsecp256k1 was still a C++ library, or the current mostly-stable codebase with various optional modules and whatnot
14:47 < sipa> anything depending on 0 right now has these compatibility problems for every code change we make
14:49 < sipa> 14:45:58 < ja> or maybe their distro will slap a 0-version on the 1.0 release because it isn't actually incompatible, which will be even more confusing   <-  that seems highly unlikely
14:51 < ja> i guess you're right that a version number bump at least gives you a guarantee of a minimum set of features and patches
14:51 < sipa> not getting schnorr with v0 doesn't seem like a problem at all - anything that needs it can upgrade, and things that don't wouldn't know or care
14:52 < sipa> not getting the endomorphism is a bit more unfortunate
14:52 < ja> also , hopefully fedora can get the official libsecp256k1 without the bcash patches, maybe i should talk to wtogami about that. it isn't fair that bcash gets to co-opt the library name
14:52 < sipa> heh, i had no clue all these distro packages even existed
14:53 < ja> gmax  just told me, i use debian/ubuntu
14:53 < ja> but i would like to see more recent secp256k1 packages on fedora
14:53 < ja> that are official
14:54 < ja> so if the version number is bumped, it also gives justification for replacing bcash schnorr with bitcoin schnorr
14:57 < sipa> heh
15:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
15:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
22:17 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 268 seconds]
22:48 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
22:52 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 264 seconds]
23:20 -!- jesseposner [~jesse@98.37.146.62] has joined #secp256k1
23:41 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 240 seconds]
23:56 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 246 seconds]
--- Log closed Tue Nov 03 00:00:05 2020