1 2017-05-03 14:19:26 <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)?
 2 2017-05-03 14:19:31 <somlo> I've seen the former used as source in some distro packages, wondering how they're different...
 3 2017-05-03 14:19:37 <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...
 4 2017-05-03 14:35:29 <wumpus> somlo: the downlooad from github is the entire git repository, including a lot of developer tooling and things
 5 2017-05-03 14:35:44 <wumpus> somlo: the one from bitcoin.org just contains what is necessary for building
 6 2017-05-03 14:35:59 <wumpus> (packages by "make dist")
 7 2017-05-03 15:17:05 <somlo> wumpus: aaah, thanks, that makes sense!
 8 2017-05-03 15:24:15 <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?
 9 2017-05-03 15:42:33 <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
10 2017-05-03 15:44:21 <arubi> comboy, ... can you give an example?
11 2017-05-03 15:44:46 <comboy> MEMCIJp87BK++jjAIbFiiphh6C9oLDoQ6b9OMGQr8Jwkue2TAh/I5oyUD+JC0f7XgyBPhbdCw6bAxQa1UZJBAJuatkTx
12 2017-05-03 15:45:37 <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
13 2017-05-03 15:45:49 <comboy> it's from bitcoin tx 1ae00f463f0ca9984ced1aaa80f19ad43df1929f1ae9ac9fb0fc3b622842cff2
14 2017-05-03 15:46:17 <arubi> 9A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93 -> 009A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93
15 2017-05-03 15:46:38 <arubi> so 30430221009A7CEC12BEFA38C021B1628A9861E82F682C3A10E9BF4E30642BF09C24B9ED93021FC8E68C940FE242D1FED783204F85B742C3A6C0C506B5519241009B9AB644F1
16 2017-05-03 15:49:44 <comboy> that I tried, but it doesn't seem to help, I think it fails then because R length is >  32?
17 2017-05-03 15:49:57 <arubi> r can be 33 bytes, it's fine
18 2017-05-03 15:50:15 <arubi> well, it has to be 33 bytes if it becomes negative
19 2017-05-03 15:50:16 <comboy> huh, so maybe I'm missing something else then
20 2017-05-03 15:52:18 <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)
21 2017-05-03 15:53:33 <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
22 2017-05-03 15:54:24 <arubi> s is already low here, but I'm not sure if you should include a leading 0x00 for it too
23 2017-05-03 15:54:32 <arubi> worth a try
24 2017-05-03 15:54:43 <arubi> definitely should be there for the r
25 2017-05-03 16:03:07 <comboy> ahh
26 2017-05-03 16:03:18 <comboy> yup that's it, thanks a lot arubi
27 2017-05-03 16:03:32 <arubi> cheers, good to know
28 2017-05-03 21:02:59 <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?