Transcript for #bitcoin-dev 2017/05/03

14:19 somlo Anybody know what the difference is between the source tarball from bitcoin's GitHub page (at https://github.com/bitcoin/bitcoin/archive/v0.14.1.tar.gz) and the official one (at https://bitcoin.org/bin/bitcoin-core-0.14.1/bitcoin-0.14.1.tar.gz)?
14:19 somlo I've seen the former used as source in some distro packages, wondering how they're different...
14:19 somlo Eyeballing the recursive diff, there's a crapton of autoconf files and some pgp key material, but nothing immediately obvious in terms of actual source code...
14:35 wumpus somlo: the downlooad from github is the entire git repository, including a lot of developer tooling and things
14:35 wumpus somlo: the one from bitcoin.org just contains what is necessary for building
14:35 wumpus (packages by "make dist")
15:17 somlo wumpus: aaah, thanks, that makes sense!
15:24 comboy I'm trying to wrap my small head around libsecp256k1 a bit, but I can't figure out why 2015 version of it verifies non strict sig with negative R, but the current version does not, any hints?
15:42 comboy I tried to manually normalize the signature, in some previous case of negative R I just appended the null byte to fix it, but here R is already 32 bytes long and I'm clueless
15:44 arubi comboy, ... can you give an example?
15:44 comboy MEMCIJp87BK++jjAIbFiiphh6C9oLDoQ6b9OMGQr8Jwkue2TAh/I5oyUD+JC0f7XgyBPhbdCw6bAxQa1UZJBAJuatkTx
15:45 comboy that's the sig, both R and S negative, but I'm guessing S is not the issue, I'm doing modulo order to fix it
15:45 comboy it's from bitcoin tx 1ae00f463f0ca9984ced1aaa80f19ad43df1929f1ae9ac9fb0fc3b622842cff2
15:46 arubi 9A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93 -> 009A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93
15:46 arubi so 30430221009A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93021FC8E68C940FE242D1FED783204F85B742C3A6C0C506B5519241009B9AB644F1
15:49 comboy that I tried, but it doesn't seem to help, I think it fails then because R length is > 32?
15:49 arubi r can be 33 bytes, it's fine
15:50 arubi well, it has to be 33 bytes if it becomes negative
15:50 comboy huh, so maybe I'm missing something else then
15:52 comboy but the version provided by you doesn't seem to verify (but again, it all verifies fine without fixing R with 2015 version of libsecp256k1)
15:53 comboy I'm guessing there's some magic I should call separately before calling verify with the new version? but I only see low S normalization
15:54 arubi s is already low here, but I'm not sure if you should include a leading 0x00 for it too
15:54 arubi worth a try
15:54 arubi definitely should be there for the r
16:03 comboy ahh
16:03 comboy yup that's it, thanks a lot arubi
16:03 arubi cheers, good to know
21:02 mchrosto can anyone point me to where JSONRPC requests are processed or perhaps let me know if they're done in a single threaded manner?