--- Log opened Thu May 23 00:00:16 2013
02:40 < warren> hmm
02:40 < warren> <sipa> [14:56:02] when comparing a new block to the best chain, consider it better if the work is equal but smaller
02:41 < warren> sipa: wouldn't this encourage zero tx blocks?
18:59 < warren> gmaxwell: btw, http://download1.rpmfusion.org/~warren/openssl/  I fixed it for Fedora 18.
19:00 < gmaxwell> warren: What did you need to do?
19:00 < gmaxwell> ah, I see the patch
19:00 < warren> let me know if you want it for Fedora 19
19:01 < gmaxwell> I'm confused as to why you'd need to do that.
19:01 < warren> The FIPS patches assume they didn't have to twiddle things for ecdsa like they do for the other algs since they don't ship ecdsa.
19:02 < gmaxwell> so why not drop out the fips patches instead?
19:02 < warren> other things blew up
19:02 < gmaxwell> Ah.
19:02 < warren> jgarzik tried all this earlier
19:03 < warren> it works to remove *all* the patches, but then I'd have to rebase the security patches, so I instead figured out how to go forward instead of remove
19:03 < gmaxwell> I suppose ideally the fips patch would get finished to work ... and get redhat to maintain it. :P
19:04 < sipa> warren: any progress on isolating a key that secp256k1-litecoin considers invalid?
19:04 < warren> sipa: not yet.  I'm trying to figure out why bitcoind/litecoind gets stuck during shutdown.
19:05 < sipa> hmm
19:05 < warren> sipa: Looping "Flushed 12035 addresses to peers.dat  38ms" messages forever after *coin-qt is told to Exit. kill -9 required.
19:05 < sipa> something is blocking cs_main
19:05 < warren> any suggestions of debug stuff to add?
19:05 < sipa> addrman functions without cs_main, so continues to dump peers to disk
19:05 < warren> I can reproduce this pretty easily
19:06 < sipa> attach a gdb and see which thread is doing what?
19:06 < warren> gdb attach and bt at that moment, or do you need all threads?
19:06 < sipa> all threads
19:07 < warren> ok
19:07 < sipa> it's likely another thread holding the cs_main lock
19:09 < warren> Let me rebuild rc2 plus pull/2688 before I do this.
19:14 < warren> sipa: I guess I'll work on isolating the key for secp256k1 now, as gmaxwell alluded to known shutdown hangs in rc2
19:16 < sipa> something like: FILE *file=fopen("/tmp/offending.key", "w"); fwrite(&privkey[0], privkey.size(), 1, file); fclose(file);
19:17 < sipa> i've used that before in walletdb.cpp, near the code that reports the corrupted CPrivkey
19:17 < warren> what format should "/tmp/offending.key" be?
19:17 < sipa> the code above will just do a binary dump of the key
19:17 < sipa> that's more than good enough
19:18 < warren> ahhhh
19:18 < warren> thanks
19:23 < sipa> gmaxwell: something i noticed when disable free relay limiting and dust limiting, and adding mempool requests to all peer connections: my memory usage instantly went up to >800 MiB
19:23 < sipa> gmaxwell: while usually it doesn't go over 500
19:24 < warren> sipa: where in the code is "disable free relay limiting"?  I'd like to test that here.
19:24 < gmaxwell> This sounds bad. In particular, I assume you were only ending up with 6k transactions in pool or so.
19:24 < sipa> gmaxwell: indeed, it means an overhead of 50 KiB per tx or so
19:25 < sipa> though i expect some txn have a huge impact compared to others
19:25 < gmaxwell> sure but the txn can't be >100k unless you disabled that check too.
19:25 < sipa> in-memory size of transactions can be a nice multiple of the serialized size
19:26 < sipa> something like 4x or 5x is not impossible
19:27 < gmaxwell> Right, but that sounds like a lot more than the overhead estimations you came up with before.
19:27 < sipa> i should combine that experiment with the memory-usage-estimation code i wrote before
19:28 < sipa> and see how much of the observed heap size i can account for
19:29 < gmaxwell> at some point we should probably make it possible to spill the mempool to disk... I was kinda hoping to prolong that though.
19:29 < sipa> it may make sense to have a more custom allocation for transactions
19:30 < gmaxwell> sipa: could have code that parses the seralized transaction and returns an exact size for a static allocation for it.
19:58 < warren> wtf.  my old wallet is no longer crashing secp256k1
19:58  * warren rebuilds clean to be sure this isn't openssl
20:16 < warren> gmaxwell: after this openssl fix, jgarzik said he'd switch back to fedora after he figures out his EFI boot problem.  I suggested he should chain load from the ubuntu bootloader. =)
21:18 < warren> hmm... my new secp256k1 builds are missing secp256k1 symbols
21:33 < warren> sipa: how do I ensure my build is using secp256k1?
21:33 < sipa> ?
21:33 < sipa> which symbols are missing?
21:34 < warren> I'm having trouble reproducing the problem at all, and I suspect it's actually using openssl now (after I fixed fedora openssl to have ecdsa)
21:34 < gmaxwell> warren: break the secp256k1 code
21:34 < gmaxwell> e.g. stick an _exit(1); in the signature validation or something and see if you die.
21:35 < warren> hmm, I could just remove openssl-devel
21:49 < warren> oops.  i forgot I can't actually remove openssl.
23:07 < warren> sorry back now
23:17 < warren> AH FUCK
23:17 < warren> sipa: gmaxwell: ccache somehow got it wrong.
23:19 < realazthat> hash collision :P
23:19 < realazthat> jk
23:19 < warren> sipa: I have a dump of the key that secp256k1 didn't like.  how do I decode it to figure out which one it is?
23:20 < sipa> if you don't mind giving it to me, i'd like to have a look
23:20 < warren> I trust you will just delete it when you're done? It might be one of my live keys.
23:20 < warren> sipa: where's your GPG keyid?
23:21 < sipa> bitcoin.org/pieterwuille.asc
23:21 < sipa> 1DAAC974
23:21 < sipa> wait
23:22 < sipa> i don't have my private gpg key here
23:22 < sipa> warren: would you trust scp'ing it to my vps?
23:23 < sipa> (bitcoin.sipa.be)
23:23 < warren> do you have the ssh pubkey that you gave me a few days ago?
23:23 < warren> I can put it in the same place you loggedin earlier
23:23 < sipa> i have that one, yes
23:24 < warren> ok
23:24 < sipa> and yes, i promise to delete it after use
23:25 < warren> It's been years since ccache screwed up on me.
23:29 < sipa> warren: interesting, i didn't know that was permitted!
23:29 < sipa> i see why it fails
23:29 < warren> sipa: see ~/protocol.patch for the difference in address
23:29 < sipa> the private key starts with a 0x00, which is omitted
23:30 < warren> This has nothing to do with this?
23:30 < warren> -        PUBKEY_ADDRESS = 0,
23:30 < warren> +        PUBKEY_ADDRESS = 48, // Litecoin addresses start with L
23:32 < warren> but yeah, the vast majority of keys work just fine with secp256k1.  we've only found offending keys in old wallets.
23:32 < warren> sipa: are you able to tell which address is associated with that key?
23:33 < sipa> warren: i don't need to
23:33 < warren> I'm just curious.
23:33 < sipa> warren: i've just pushed a (potential) fix to secp256k1 repo
23:34 < warren> ok, i'll try it
23:34 < warren> sipa: just for my own education, I'd like to learn how to decode that dump
23:35 < sipa> http://lapo.it/asn1js/ :p
23:38 < warren> thanks
23:51 < gmaxwell> sipa: how could one of our own private keys end up starting with 0x00?!
23:51 < sipa> gmaxwell: ?
23:51 < gmaxwell> did openssl pad it?
23:51 < sipa> i mean in 32-byte notation it starts with a 0x00
23:52 < gmaxwell> oh. I see. the test was too agressive and didn't like it when it had less than 32 significant bytes. So about a 1/256 chance of happening.
23:54 < sipa> well, my ASN.1 deserializer is quite hacky and ad-hoc
23:54 < sipa> i somehow assumed it always dumped a 32-byte octet string
23:54 < sipa> but apparently not
23:54 < sipa> indeed, 1/256 chance to fail
23:55 < gmaxwell> you mean you didn't memorize the 500 whatever pages of ASN.1 specification first?!
23:55 < sipa> i actually read the relevant section when implementing it
23:56 < sipa> but that doesn't prevent making an incorrect assumption about how openssl represents things
23:57 < warren> The offending key was in my reserve keys.
23:57 < warren> so I can just delete it
23:57 < warren> sipa: want to add it to a test case?
23:58 < gmaxwell> should just add a privkey of 2 as a test.
23:59 < sipa> warren: but does it work now?
23:59 < sipa> i didn't test the patch before pushing it :p
23:59 < warren> testing now.  I spent all that time learning how to decode and figure out which key it was.
--- Log closed Fri May 24 00:00:19 2013