1 2011-09-19 00:25:11 <Matth1a3> luke-jr: is it ok to pm you?
  2 2011-09-19 00:42:35 <luke-jr> Matth1a3: about?
  3 2011-09-19 00:43:44 <Matth1a3> luke-jr: I suppose I can just ask here. What did you mean by somewhere people can freely commit to
  4 2011-09-19 00:45:31 <luke-jr> Matth1a3: a website/service that doesn't have a dubious terms-of-service
  5 2011-09-19 00:47:34 <Matth1a3> luke-jr: GitHub's ToS is unsatisfactory then? I just wasn't sure what was meant by that. I definitely respect your opinion, I'm sure it's shared by other skilled developers
  6 2011-09-19 00:48:10 <luke-jr> Matth1a3: GitHub's ToS uses dubious language regarding paying them legal expenses, and can be revised without notice, etc
  7 2011-09-19 00:48:42 <Matth1a3> luke-jr: I see, that does sound suspect
  8 2011-09-19 00:48:45 <luke-jr> ie, if someone merely threatens them with unfounded legal action and it never goes anywhere, you owe them money
  9 2011-09-19 01:01:17 <shadders> !seen TD
 10 2011-09-19 01:01:19 <spaola> I found 2 matches to your query (sorted): TD[gone] TD. TD[gone] (~mike@ip6.plan99.net) was last seen changing nicks from TD on #bitcoin-dev 4 hours, 57 minutes ago. TD[gone] is still there.
 11 2011-09-19 01:21:10 <shadders> there's no uniqueness guarantee for sha256 hash is there?  i.e. two different inputs could theoretically produce the same hash?
 12 2011-09-19 01:21:32 <cjdelisle> correct
 13 2011-09-19 01:21:33 <gmaxwell> Sure.
 14 2011-09-19 01:21:56 <shadders> thx
 15 2011-09-19 01:22:01 <gmaxwell> Pigeonhole principle says such a guarantee is impossible.
 16 2011-09-19 01:22:09 <cjdelisle> it is not *guaranteed* to be collision proof but it is prised for collision resistance and none has yet been found.
 17 2011-09-19 01:23:21 <copumpkin> everyone loves the pigeonhole principle
 18 2011-09-19 01:23:41 <gmaxwell> Right, it's not that it's just not guaranteed. It it would be impossible to not have them. It's just computationally intractable to find any.
 19 2011-09-19 01:24:05 <cjdelisle> /ond
 20 2011-09-19 01:24:11 <cjdelisle> /nod even
 21 2011-09-19 01:24:42 <copumpkin> shadders: a 256-bit hash function can take arbitrarily large (or to a very large limit) inputs and only outputs 2^256 different answers. There have to be collisions :)
 22 2011-09-19 01:25:27 <shadders> I'm sure the bitcoin network could find one if it set it's mind to it...
 23 2011-09-19 01:26:01 <shadders> eventually ;)
 24 2011-09-19 01:26:10 <copumpkin> a bunch of computers can defeat certain kinds of things, but combinatorics always wins ;)
 25 2011-09-19 01:26:57 <shadders> I will definately try to use the word
 26 2011-09-19 01:27:09 <shadders> 'combinatorics' in casual conversation today
 27 2011-09-19 01:28:39 <copumpkin> well, in theory at least, after doing 10^58 SHA256s, you'd have approximately a 50% chance of having a collision
 28 2011-09-19 01:28:58 <copumpkin> oh whoops
 29 2011-09-19 01:29:03 <copumpkin> 10^38 :)
 30 2011-09-19 01:29:38 <copumpkin> (by brute force)
 31 2011-09-19 01:29:58 <cjdelisle> but 10^38 * 32 = more bytes than you have in ram
 32 2011-09-19 01:30:18 <cjdelisle> so your memory lookups for checking for collisions are going to suuuuck
 33 2011-09-19 01:30:19 <copumpkin> yeah, and he's talking about the entire network
 34 2011-09-19 01:30:35 <copumpkin> so we'd need a distributed lookup system of all hashes ever computed by miners
 35 2011-09-19 01:30:39 <copumpkin> even though most of them are thrown away
 36 2011-09-19 01:30:59 <cjdelisle> some kind of really fast dht
 37 2011-09-19 01:32:13 <copumpkin> shadders: at the current network hash rate
 38 2011-09-19 01:32:31 <copumpkin> that'd be ~10^17 years to get a 50% chance of finding a collision
 39 2011-09-19 01:32:33 <soap> but just a table of hash collisions isn't all that fun.
 40 2011-09-19 01:32:34 <gmaxwell> well, first you need to give all the miners _much_ faster pcie busses, because right now they couldn't even get all the hashes they try off the cards.
 41 2011-09-19 01:32:36 <copumpkin> assuming we keep all the hashes away
 42 2011-09-19 01:32:41 <soap> What you want is to be able to /design/ a collision.
 43 2011-09-19 01:32:43 <copumpkin> anyway
 44 2011-09-19 01:32:46 <copumpkin> soap: yep
 45 2011-09-19 01:32:57 <cjdelisle> it would require 3,200,000,000,000,000,000,000,000,000,000 gigabytes of ram to do lookups on a dataset that big
 46 2011-09-19 01:33:15 <copumpkin> so yeah, combinatorics wins again
 47 2011-09-19 01:33:25 <copumpkin> poor bitcoin network
 48 2011-09-19 01:33:27 <copumpkin> I still love it
 49 2011-09-19 01:33:56 <shadders> ok so just compare this hash to previous hash... it might take a bit longer though...
 50 2011-09-19 01:34:21 <copumpkin> lol
 51 2011-09-19 01:34:25 <cjdelisle> well bitcoin is the other extreme
 52 2011-09-19 01:34:31 <cjdelisle> it only compares to 1 number
 53 2011-09-19 01:34:33 <cjdelisle> 0
 54 2011-09-19 01:35:23 <cjdelisle> if you were looking for collisions, you could do some fancy stuff to look for a bunch of numbers forwhich you have known hash imputs that hash to them
 55 2011-09-19 01:35:54 <gmaxwell> you might even call the data structure& a hash table!
 56 2011-09-19 01:36:03 <cjdelisle> and you wouldn't exhaust all of the memory in the universe that way
 57 2011-09-19 01:36:07 <copumpkin> a distributed one!
 58 2011-09-19 01:37:53 <cjdelisle> it would be funny though to make a chain where the proof of work was derived by creating a partial hash collision for a forged ssl cert
 59 2011-09-19 01:37:58 <cjdelisle> that would make people mad
 60 2011-09-19 01:38:09 <gjs278> ;;bc,stats
 61 2011-09-19 01:38:12 <gribble> Current Blocks: 145968 | Current Difficulty: 1755425.3203287 | Next Difficulty At Block: 147167 | Next Difficulty In: 1199 blocks | Next Difficulty In About: 1 week, 1 day, 10 hours, 9 minutes, and 53 seconds | Next Difficulty Estimate: 1737101.38994040
 62 2011-09-19 01:38:32 <gmaxwell> cjdelisle: it would be harmless, getting a full hit would remain astronomically unlikely
 63 2011-09-19 01:38:52 <cjdelisle> unless it was the verisign md2 cert ;)
 64 2011-09-19 01:39:15 <copumpkin> for a while, I remember there existed a root cert with a 16384-bit RSA key
 65 2011-09-19 01:39:23 <copumpkin> anyone know which one I'm talking about?
 66 2011-09-19 01:40:26 <copumpkin> ah, it belonged to thawte
 67 2011-09-19 01:40:54 <copumpkin> https://www.globaltrustpoint.com/x509/x509cert_about.jsp?certID=8bc28a24affb565de850157b7a6b6f14784c90e3&certType=ca
 68 2011-09-19 01:41:22 <copumpkin> that's my kind of modulus
 69 2011-09-19 01:42:09 <shadders> and I thought I was a geek
 70 2011-09-19 01:42:13 <cjdelisle> 16384 bit modulus
 71 2011-09-19 01:42:16 <cjdelisle> sha1 hash
 72 2011-09-19 01:42:19 <cjdelisle> hmm
 73 2011-09-19 01:44:12 <copumpkin> :)
 74 2011-09-19 02:00:46 <flying> kittens.
 75 2011-09-19 03:31:07 <CIA-101> poolserverj: shadders * 338a47b43595 r113 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (4 files in 3 dirs): - partial implementation of worker cache preloading
 76 2011-09-19 03:31:10 <CIA-101> poolserverj: Shadders * 34a1f1adc140 r115 /.hgignore: clear out untracked files
 77 2011-09-19 03:31:11 <CIA-101> poolserverj: shadders * 30c5a5182b86 r116 / (320 files in 58 dirs):
 78 2011-09-19 05:30:47 <flying> bbl, pizza
 79 2011-09-19 07:46:47 <alexwaters> does anyone know what resource leak fix https://github.com/bitcoin/bitcoin/pull/385 fixes? and how I can reproduce / see the resource leak
 80 2011-09-19 07:51:51 <sipa> alexwaters: it supposedly leaks threads
 81 2011-09-19 07:53:02 <sipa> i.e., threads created that are never cleaned up, even after they exit
 82 2011-09-19 08:21:15 <alexwaters> sipa: I have no idea what would reproduce it though - just adding connections?
 83 2011-09-19 08:26:18 <sipa> there are only a limited number of threads created afaik
 84 2011-09-19 08:47:57 <phantomcircuit> sipa, a resource leak that leaks a constant amount of resources
 85 2011-09-19 08:47:58 <phantomcircuit> meh
 86 2011-09-19 08:51:11 <alexwaters> phantomcircuit: so if I'm looking at my system performance, I should see my thread count continually rise when I add nodes?
 87 2011-09-19 08:51:35 <sipa> alexwaters: no
 88 2011-09-19 08:52:11 <sipa> (i'm not entirely sure, i haven't investigated all call sites of CreateThread in bitcoin)
 89 2011-09-19 08:52:39 <alexwaters> i'm sorry I'm completely ignorant on this - I've been scripting for like 8 years - haven't touched anything outside the browser for a while
 90 2011-09-19 08:53:02 <sipa> if my assumption is true, it's a bit of a stretch to call it a resource leak
 91 2011-09-19 08:53:19 <sipa> it's just a limited number of threads that are never cleaned up
 92 2011-09-19 08:53:20 <alexwaters> sipa: it just looked like an easy pull to test
 93 2011-09-19 08:53:33 <alexwaters> sipa: so i jumped on it to get the number of opens pulls down
 94 2011-09-19 08:53:41 <sipa> the patch seems sound to me, btw
 95 2011-09-19 08:53:50 <alexwaters> sipa: i see, thanks
 96 2011-09-19 08:56:39 <sipa> strange, there are no calls to CreateThread left which set fWantHandle to true
 97 2011-09-19 08:58:43 <alexwaters> so if it's rebased, the leak doesn't exist, and I can close the pull?
 98 2011-09-19 08:59:48 <sipa> hmm?
 99 2011-09-19 09:01:50 <alexwaters> sipa: is pull 385 relevant in the current release candidate? or did it only apply to an older version
100 2011-09-19 09:03:46 <sipa> seems already fixed
101 2011-09-19 09:03:59 <alexwaters> sipa: awesome, I'll close it then - thanks!
102 2011-09-19 09:07:39 <sipa> it was fixed in two other commits
103 2011-09-19 09:07:42 <sipa> but only partially
104 2011-09-19 09:07:49 <sipa> https://github.com/bitcoin/bitcoin/commit/858cebed7dee2e9801e754a9969844b7969254ee
105 2011-09-19 09:13:47 <flying> mmm, sleep
106 2011-09-19 09:16:25 <ThomasV> my ABE database is corrupted. I suppose that I need to delete the most recent block from the pgsql table. does someone know how to do that?
107 2011-09-19 09:17:16 <ThomasV> I get the following error trying to delete the block:
108 2011-09-19 09:17:19 <ThomasV> ERROR:  update or delete on table "block" violates foreign key constraint "chain_chain_last_block_id_fkey" on table "chain"
109 2011-09-19 09:17:21 <alexwaters> sipa: that null gets passed to fWantHandle?
110 2011-09-19 09:18:07 <alexwaters> nvm
111 2011-09-19 09:19:57 <ThomasV> I suppose that I could decrement chain_last_block_id in the "chain" table
112 2011-09-19 09:20:16 <ThomasV> anyone familiar with ABE ?
113 2011-09-19 09:27:31 <alexwaters> anyone know who i could talk to about the test_bitcoin unit test runner? is anyone maintaining that?
114 2011-09-19 09:29:21 <sipa> gavin, probably
115 2011-09-19 10:35:45 <nanotube> alexwaters: about your post on the mailing list - consider investigating the tools sourceforge provides for bugtracking etc. i know a lot of projects use a mix of github and sf.
116 2011-09-19 10:37:12 <alexwaters> nanotube: I was hoping to get down a system for sanity testing pull requests so that we can get them processed faster - unless Gavin would rather me spend time researching project managment solutions first
117 2011-09-19 10:37:51 <nanotube> alexwaters: i'm in no way implying that should be first on the list to do. :) just that /when/ you get around to it, you can take a look. :)
118 2011-09-19 10:38:59 <tcatm> tagging of pull requests might be useful, we have quite a lot and I don't think every dev knows the current state of each
119 2011-09-19 10:39:15 <nanotube> does github support that?
120 2011-09-19 10:39:21 <alexwaters> definitely, and thank you. I'm still trying to get a gauge of the priority needs
121 2011-09-19 10:39:36 <alexwaters> nanotube: we have a label system with basic implementation currently
122 2011-09-19 10:39:45 <tcatm> nanotube: no, but we could add that using their API
123 2011-09-19 10:40:01 <alexwaters> tcatm: oh my bad, I thought you were talking about the labels
124 2011-09-19 10:40:55 <alexwaters> something like this: http://aehlke.github.com/tag-it/ ?
125 2011-09-19 10:41:05 <tcatm> issues have labels. pulls do not
126 2011-09-19 10:42:12 <alexwaters> tcatm: I have been trying to get around that by tagging the resultant issues. AFAIK whenever a pull request is made, it pops up in the issues area. Maybe I should make a pull label so that they are easily identified
127 2011-09-19 10:43:02 <tcatm> maybe something simple as: fetch list of pull requests and their comments, fetch list of collaborators and then check whether all collaborators have written an ACK (or NACK) as a comment and make a nice overview
128 2011-09-19 10:44:38 <tcatm> maybe with a third keyword meaning "this needs some more work" and then add a link to that exact comment in the pull request (if possible). the developer could overwrite that with an ACK once the issue is resolved
129 2011-09-19 10:45:22 <alexwaters> tcatm: I would love to build something like that (and am confident I can in PHP/jQuery). I need to bang out some pulls requests first though imho
130 2011-09-19 10:45:32 <alexwaters> just so we can get the numbers down, it's a little unruly
131 2011-09-19 10:47:24 <tcatm> what about closing all "dead" not-automergeable pull requests with no activity for a few months?
132 2011-09-19 10:47:35 <alexwaters> tcatm: my ultimate plan involves BEPS, GitHub, a voting system, and custom reporting that would allow something similar to what you're talking about
133 2011-09-19 10:48:12 <sipa> the BEPS proposal is about requests for changes to the protocol
134 2011-09-19 10:48:14 <alexwaters> tcatm: I would love to implement a timer, I proposed that in the readme file pull request I made - but heard no response
135 2011-09-19 10:48:19 <sipa> not about the client
136 2011-09-19 10:48:44 <sipa> maybe something similar is useful there, but those are separate things
137 2011-09-19 10:49:47 <tcatm> #125 #169 #174 #180 #182 should be closed IMHO
138 2011-09-19 10:50:29 <alexwaters> sipa: I believe that they both share many similarities, and a templateable system should be put in place
139 2011-09-19 10:50:46 <tcatm> #183 should either be fixed and merged soon or closed
140 2011-09-19 10:51:09 <alexwaters> sipa: as far as contribution control
141 2011-09-19 10:51:25 <sipa> tcatm: i plan on getting #183 in a mergeable state soon
142 2011-09-19 10:51:56 <sipa> 180 is too outdated to be useful, i think
143 2011-09-19 10:52:32 <sipa> 182 needs reworking/discussion i think
144 2011-09-19 10:52:40 <sipa> 174 same
145 2011-09-19 10:52:53 <tcatm> 182 will probably break with QT
146 2011-09-19 10:53:34 <gavinandresen> I agree with sipa, BEP process is separate from keeping track of changes to the "satoshi implementation"
147 2011-09-19 10:54:20 <tcatm> err. 182 will definitely break with QT as it depends on a WX feature
148 2011-09-19 10:55:49 <alexwaters> gavinandresen: do client changes intermingle with protocol changes frequently? one leading to the other?
149 2011-09-19 10:56:44 <alexwaters> sipa & tcatm: I have added them to my little list, but I think we need to implement an official timer in the readme (which I am rewriting as we speak) and wait for ACKs
150 2011-09-19 10:57:27 <gavinandresen> alexwaters: it'll be messy.  Somebody will decide a protocol change is a good idea, and will probably start a BEP and implement it at the same time.
151 2011-09-19 10:57:40 <gavinandresen> (to demonstrate that their proposed change actually works)
152 2011-09-19 10:58:28 <gavinandresen> alexwaters: Or one client will add suppport for... oh, I dunno, bitcoin: URLs.  And then a BEP will be written up to try to get everybody to do them the same way
153 2011-09-19 10:58:56 <alexwaters> gavinandresen: I see, that would not be good and would probably lead to more forking/distraction
154 2011-09-19 10:59:27 <tcatm> btw, I think a separate staging branch would be useful so we could start merging for 0.5 while 0.4 is still RC
155 2011-09-19 10:59:34 <gavinandresen> alexwaters: I expect lots of forking distraction
156 2011-09-19 11:00:08 <gavinandresen> tcatm: I was thinking of just starting to pull into master.  0.4rc2 is already tagged, a 0.4 branch can be easily created