--- Log opened Fri May 24 00:00:19 2013
00:00 < sipa> (also, you _did_ check that site does the decoding locally before pasting a private key in it, did you?) :p
00:00 < warren> I copied the site to an offline browser
00:01 < warren> but I ended up adding more debug code to just tell me which key it was
00:01 < sipa> hehe
00:01 < warren> the client loaded without any wallet error
00:01 < sipa> \o/
00:01 < warren> that isn't proof of 'working'.  just the error is gone
00:02 < warren> want the entire pubkey and privkey for a test case?  It was a reserve key I can just delete.
00:02 < gmaxwell> sipa: maximum privkey and minimum privkey, would probably be reasonable tests to have.
00:02 < sipa> i always like this blog post (by roconnor!), when i don't really test code before pushing :p
00:02 < sipa> http://r6.ca/blog/20120708T122219Z.html
00:02 < gmaxwell> I wonder if there is any bitcoin assigned to the minimum privkey
00:03 < sipa> you mean 1?
00:04 < warren> ok, I guess not
00:04 < gmaxwell> I wasn't sure if openssl would permit 1.
00:04 < sipa> it should
00:07 < warren> sipa: want me to release the litecoin beta with secp256k1 and see what happens? =)
00:08 < warren> release both openssl and secp256k1.  "Uh... if this faster one blows up, use the other one."
00:09 < sipa> if you don't mind being a guinea pig :)
00:09 < warren> I don't mind.  They're the guinea pigs.  I'm just the guy who likes shiny stuff.
00:10 < sipa> you understand they may come after you with pitchforks? :
00:10 < warren> what's the worse that can happen? =)
00:10 < sipa> you
00:11 < sipa> slowly dying
00:11 < sipa> after being tortured
00:12 < warren> Giant disclaimer: The secp256k1 build is probably faster.  It might do bad things and lose all your money.  We don't know.  Use at your own risk.
00:12 < warren> how else will you find other corner cases?
00:12 < sipa> have it in giant red flashing marquee scroll across the screen, and you're good :p
00:13 < sipa> i'm not really afraid of corner cases hit by regularly usage
00:13 < sipa> i'm afraid of a genius hackr that finds a way to trigger edge cases
00:13 < warren> https://github.com/bitcoin/bitcoin/pull/2688  hmm, why didn't this go into rc2?
00:13 < warren> errr, rc3
00:14 < sipa> it was detected right after rc2 was tagged
00:14 < sipa> there is no rc3 yet
00:15 < warren> ok, I'll rebase onto rc2 and see if I can figure out the looping addrman thing.
00:15 < sipa> addrman has nothing to do with it
00:15 < sipa> it's just the only thing that happens to not be affected :
00:17 < warren> sipa: "genius hackr that finds a way to trigger edge cases" what parts are you worried about?  new keys generated by secp256k1?
00:18 < warren> I would imagine most cases of the client crashing are not really to worry about.
00:28 < gmaxwell> http://blockexplorer.com/address/1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh :-/
00:30 < warren> what's the issue?
00:30 < gmaxwell> thats a privkey of 0
00:33 < gmaxwell> 0.32351356 assigned to 1 but gone now,  0.13 assigned to 1 compressed and gone.  0.0000384 to 2 uncompressed but spent. just recently..
00:38 < midnightmagic> lol is it a race to spend it now?
00:40 < gmaxwell> no 0 can't be spent.
00:40 < midnightmagic> Oh. That sucks. Why not?
00:40 < midnightmagic> Because it can't be multiplied.
00:41 < midnightmagic> Nevermind.
00:41 < warren> should bitcoin have a built-in limit that warns users away from small keys?
00:46 < zooko> We can't detect all guessable keys, but we could detect 0.
00:46 < zooko> "Check for 0" is actually a prophylactic practice that some crypto engineers have long used.
00:47 < zooko> Or more generally, check for invalid...
00:47 < gmaxwell> zooko: We do do that.
00:48 < zooko> Ah. ☺
00:48 < gmaxwell> it's not a valid EC point, it won't be generated. Thats just someone being a clown there.
00:49 < sipa> technicaloty: it is a valid EC point, just not valid as a public key
00:50 < sipa> a technicaloty is a like a technicality, but a lot more pedantic
00:51 < sipa> warren: i'm afraid that some of the field/group code has very unlikely overflows or other edge cases, which won't occur for random keys/messages/nonces, but perhaps do happen for constructable inputs
00:52 < sipa> warren: which would be enough to cause a chain fork in that case
00:52 < sipa> or theft
00:52 < warren> If I understand that correctly, the risk of chain fork is nil if no miners use it?
00:52 < gmaxwell> otoh sipa's code may now be more tested than some of the in production ECC code out there… but as we know, consistency matters more than correctness. :)
00:53 < warren> I could rip out getwork and GBT from the secp256k1 builds =)
01:01 < sipa> warren: if everyone but miners use it, there is just as much a problem
01:41 < sipa> gmaxwell: well, there are 8 config combinations possible...
01:42 < gmaxwell> Hm?
01:42 < sipa> 4 field implementations, 2 scalar implementations
01:44 < gmaxwell> oh of your code, indeed.
03:22 < warren> sipa: http://pastebin.com/tw3RgHGj   thread apply all bt full during the shutdown looping
03:22 < warren> sipa: this is litecoin-0.8.2rc2.  Let me know if you insist on me getting this from bitcoin-0.8.2rc2, and if all the debuginfo would be needed.
03:25 < sipa> hmm nothing suspicious
03:25 < warren> crap
03:26 < warren> gmaxwell: I'm still getting the assertion failure at shutdown with gavin's patch
03:26 < warren> I'm trying a gitian build to see if both bugs are present there.
03:29 < warren> hmm, my issue seems to be a diferrent assertion failure
03:31 < gmaxwell> _what_ assertion?
03:33 < gmaxwell> ah, you put it in the bug.
03:33 < gmaxwell> (should have put it on the patch :P )
03:34 < gmaxwell> warren: trigger it in valgrind, may get a more informative result on _which_ place its failing.
03:35 < warren> haven't used valgrind in years.  you need to run entirely within valgrind, you can't attach like gdb?
03:37 < gmaxwell> right. valgrind ./bitcoind -daemon=0  it's slow.. watch the log. ... and ... uh. you really should be familar with it, it will save your bacon.
03:39 < warren> how do I stop it during the loop to dump the state?
04:33 < warren> gmaxwell: oh, misunderstood you.   I thought you meant valgrid for the shutdown loop forever issue.  I see you mean the assertion.
15:56 < warren> gmaxwell: the shutdown hang seems to be limited to bitcoin-qt, and only my fedora native build, not gitian
15:56 < warren> jgarzik: hey
15:57 < gmaxwell> warren: your bug says the gitian hangs too?
15:57  * jgarzik waves
15:58 < warren> argh
15:58 < warren> gmaxwell: I'm mixing up the bugs again.  just woke up.
15:58 < warren> gmaxwell: the assertion failure is fedora specific.  the hang is both.
15:58  * jgarzik waves at warren.  Thanks for the openssl attention.  Now I need several hours to debug EFI ;p
15:59 < warren> jgarzik: let me know if you want openssl for Fedora 19
15:59 < jgarzik> warren, tempting.  I was hoping to wait for the first beta, and then try a reinstall, hoping that EFI was simply fixed at that point
16:00  * jgarzik is concerned that Fedora is falling behind, not being able to install well on -any- modern laptop.  Two for two in the failure department.  Neither my wife's new laptop, nor mine (different brands, both from Wal-Mart, both EFI) worked with Fedora at all.  CD boots, but failed to create a bootable system.
16:00 < warren> jgarzik: I made that Fedora 18 with epoch++ to prevent yum from upgrading it.  maybe that isn't a good idea.  I dunno
16:02 < warren> jgarzik: is this after mjg59 left RH?
16:02 < jgarzik> warren, heh, he's coming back
16:02 < jgarzik> but yes
16:03 < warren> coming back?  really?
16:04  * gmaxwell waits for warren to ask mjg59 in another window. :P
16:04 < warren> nah
16:05 < warren> jgarzik: I also have a stack for Fedora that allows you to use gitian easily.
--- Log closed Sat May 25 00:00:22 2013