1 2012-07-12 00:00:34 <doublec> knotwork: unfortunately it's hard t otell what bitcoin version that was based on
  2 2012-07-12 00:00:40 <doublec> knotwork: since it doesn't have the bitcoin commit history
  3 2012-07-12 00:01:50 <knotwork> "version" : 32400,
  4 2012-07-12 00:06:08 <doublec> that doesn't tell you what commit though which is useful for merging, knowing what's included, etc.
  5 2012-07-12 00:09:18 <knotwork> hmm yeah likely wherever git wrote that is probably lost by now as likely I pulled bitcoin again since then
  6 2012-07-12 00:11:05 <knotwork> even the non-old devcoin repo I did based on newer bitcoin is out of date by now, I am not sure if I can somehow auto-update it from bitcoin main repo or not
  7 2012-07-12 00:11:51 <knotwork> maybe doesnt matter since its not yet actually a devcoin at all, it might even just be unmodified bitcoin so far that I merely intended to turn into devcoin but never did
  8 2012-07-12 04:05:33 <t3a> Do most miners not accept transactions that go to incorrect addresses?
  9 2012-07-12 04:05:55 <t3a> (incorrect meaning that the checksum is wrong)
 10 2012-07-12 04:19:13 <dooglus> t3a: transactions don't go to bitcoin addresses, they go to 160 bit hashes which don't have checksums
 11 2012-07-12 04:22:15 <t3a> dooglus, Don't you know what I mean?
 12 2012-07-12 05:50:21 <coblee> can anyone help with building bitcoin from source on windows?
 13 2012-07-12 05:52:41 <sipa> t3a: the checksum is part of the base85 encoding, not past of the 160-bit destination key hash
 14 2012-07-12 05:53:00 <sipa> coblee: sorry...
 15 2012-07-12 09:52:16 <gribble> New news from bitcoinrss: Diapolo opened pull request 1587 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1587>
 16 2012-07-12 09:53:43 <jrmithdobbs> this is going to sound retardedly stupid, but please tell me someone knows of a faster bf (specifically bf-ofb) impl than openssl's
 17 2012-07-12 09:54:15 <sipa> bf?
 18 2012-07-12 09:54:26 <jrmithdobbs> preferably one that can parallelize the actual individual blocks since ofb itself can't be. (i want to kill the idiot who used bf-ofb for this in 2007 instead of aes-ctr
 19 2012-07-12 09:54:29 <jrmithdobbs> blowfish
 20 2012-07-12 09:54:58 <jrmithdobbs> i mean even cuda/opencl crap would work as i could throw that hardware at it
 21 2012-07-12 09:55:41 <jrmithdobbs> it's legit use, have the keys, the shit will not stream faster than 70MB/s off meadia capable of ~120MB/s due to cpu bottleneck ... on current gen e5 cores!
 22 2012-07-12 09:57:49 <jrmithdobbs> if i could find something that'd split the bf op across 4 cores or that speeds it up (maybe using carryless mult, etc) so that multiple portions are computed at once :(
 23 2012-07-12 11:08:53 <gribble> New news from bitcoinrss: Diapolo opened issue 1588 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1588>
 24 2012-07-12 11:44:28 <gribble> New news from bitcoinrss: Diapolo opened pull request 1589 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1589>
 25 2012-07-12 12:04:23 <t7> jrmithdobbs: what for?
 26 2012-07-12 12:51:13 <Joric> where may i download that utterly cool-looking electrum client listed here http://bitcoin.org/clients.html ecdsa.org links to an ugly old one
 27 2012-07-12 12:55:18 <MC1984> or mybe copyright really doesnt make much sense in what is effectivel a post-scarcity environment
 28 2012-07-12 12:55:48 <MC1984> oh that was yesterday lol
 29 2012-07-12 12:57:23 <jgarzik> interesting.  znort987 runs numbers on pirate's bitcoin addresses, https://bitcointalk.org/index.php?topic=91653.0
 30 2012-07-12 12:59:39 <sipa> jgarzik: i read you're coming to the london conference?
 31 2012-07-12 13:00:32 <jgarzik> sipa: yes
 32 2012-07-12 13:00:39 <sipa> nice!
 33 2012-07-12 13:01:00 <jgarzik> it's !@#!@# expensive to fly to Europe :)
 34 2012-07-12 13:01:30 <jgarzik> sipa: looking forward to meeting you in person for the first time :)  and TD too hopefully, and many others
 35 2012-07-12 13:02:08 <sipa> he is on the list on bitcoin2012.com
 36 2012-07-12 13:04:35 <sipa> jgarzik: we can do a small gpg key-signing there
 37 2012-07-12 13:05:38 <sipa> jgarzik: yeah, if it wasn't that expensive I would've been at the NY conference too
 38 2012-07-12 13:05:43 <jgarzik> sure, though I'm still dubious on whether or not in-person keysigning has more than theoretical value ;)
 39 2012-07-12 13:06:18 <sipa> well, in this case probably not, as we've learned to trust eachother based on the code contributions by our virtual identities
 40 2012-07-12 13:06:38 <sipa> whether they are linked to real-world identities is not that important
 41 2012-07-12 13:07:10 <sipa> i've met TD, slush, jim, justmoon, ... already, but none of the US developers
 42 2012-07-12 13:07:24 <t7> you guys allways fix bugs before i get a chance to patch them
 43 2012-07-12 13:07:32 <t7> how can i commit code :(
 44 2012-07-12 13:08:05 <sipa> you don't have to contribute bug fixes (though they are certainly appreciated)
 45 2012-07-12 13:08:21 <jgarzik> exactly :)  Linus Torvalds made a similar point, after kernel.org was hacked, and inside-WoT GPG identities were required for major kernel developers.  You might or might not know the "in person" identity... you primarily know people by their virtual identities, by the code they produce.  A photo id check is insufficient.  You must sit down with someone and watch them email and code for a while... rather tedious.
 46 2012-07-12 13:10:24 <jgarzik> t7: pull requests on github.com are the method by which changes are submitted to bitcoin
 47 2012-07-12 13:10:52 <t7> jgarzik: what makes you think i dont know that?
 48 2012-07-12 13:11:11 <jgarzik> t7: you said "how can i commit code" which seemed a basic question.
 49 2012-07-12 13:11:16 <OneEyed> t7: if he read your lines in isolation, it is a perfect response to your last one :)
 50 2012-07-12 13:11:17 <jgarzik> apologies
 51 2012-07-12 13:11:33 <t7> ah haha
 52 2012-07-12 13:13:12 <sipa> jgarzik: remarkably enough, there is a GPG path of trust between me and gmaxwell
 53 2012-07-12 13:15:06 <OneEyed> Wasn't there an online tool to check for connections between OpenPGP keys once?
 54 2012-07-12 13:15:19 <sipa> http://pgp.cs.uu.nl/mk_path.cgi
 55 2012-07-12 13:15:25 <OneEyed> Thx
 56 2012-07-12 13:18:09 <OneEyed> Is gmaxwell key B0413BFA?
 57 2012-07-12 13:18:22 <sipa> yes
 58 2012-07-12 13:18:46 <OneEyed> 2 intermediate people to reach him by path of trust
 59 2012-07-12 13:18:53 <OneEyed> (although I don't know him at all)
 60 2012-07-12 13:19:29 <OneEyed> I suspect this is quite common. What's your distance with my 1B80ADE6?
 61 2012-07-12 13:20:42 <sipa> i'm 1DAAC974
 62 2012-07-12 13:21:14 <OneEyed> Ok, 2 people in the middle as well, with multiple possibilities
 63 2012-07-12 13:21:55 <sipa> http://webware.lysator.liu.se/jc/wotsap/wots/latest/keystatistics/0x1DAAC974.txt
 64 2012-07-12 13:22:12 <sipa> ther's 2651 keys that have distance 2 to mine
 65 2012-07-12 13:24:57 <OneEyed> We both have 13 people we signed our keys without us signing theirs. Strange, I'll have to check with those people, some of them being very close friends :/
 66 2012-07-12 13:25:02 <OneEyed> ^we^who
 67 2012-07-12 13:41:16 <[\\]> is there a document that lists the fee structure now?
 68 2012-07-12 13:41:49 <[\\]> I've got a tx sending 50+ btc containing 4 inputs ranging from 5-35 btc and its being dropped for lack of fees.  I'd hardly say it qualifies as spam.
 69 2012-07-12 13:43:59 <gavinandresen> https://gist.github.com/2961409  has a review of the current default rules, but some miners have their own policies
 70 2012-07-12 13:45:23 <BlueMatt> anyone happen to know off-hand the current number of unspent outputs?
 71 2012-07-12 13:45:27 <BlueMatt> or something close to it
 72 2012-07-12 13:45:53 <[\\]> thanks
 73 2012-07-12 13:53:51 <sipa> BlueMatt: 1.5M
 74 2012-07-12 14:15:41 <luke-jr> gavinandresen: ping; what GCC version has trouble compiling checknewblock? (I do my development on 32-bit&)
 75 2012-07-12 14:48:00 <topi`> t7: just read an interesting and long thread about a custom DIY fpga project. what is your opinion about FPGA vs ASIC? I think ASIC production is just hideously expensive
 76 2012-07-12 14:48:20 <topi`> well, maybe this is not the right # for this :)
 77 2012-07-12 14:48:45 <t7> im an ASIC kinda guy
 78 2012-07-12 14:49:00 <t7> if you cant afford it, get out the damn kitchen
 79 2012-07-12 14:49:12 <topi`> hehe
 80 2012-07-12 14:49:41 <t7> seriously though, i think you mean someone else :)
 81 2012-07-12 14:49:43 <topi`> well. more hashing power is of course welcome for bitcoin as a whole.
 82 2012-07-12 14:50:00 <topi`> t7: sorry, I perhaps misinterpreted your nick.
 83 2012-07-12 14:51:37 <topi`> just occurred to me, did gmaxwell's proposal for generating a "master key" get incorporated to current bitcoind?
 84 2012-07-12 14:51:38 <Diablo-D3> well
 85 2012-07-12 14:51:53 <topi`> instead of pre-generating 100 pubkeys
 86 2012-07-12 14:52:05 <Diablo-D3> theres always DI.BFLSC insurance.
 87 2012-07-12 15:02:24 <jrmithdobbs> t7: what do you mean what for? for restoring a bunch of data i have on media that is encrypted with that mode of operation?
 88 2012-07-12 15:03:26 <t7> ah ok
 89 2012-07-12 15:11:52 <luke-jr> topi`: no, HD wallets aren't done yet
 90 2012-07-12 15:11:59 <luke-jr> probably won't be until 0.8 at the earliest
 91 2012-07-12 15:13:36 <sipa> topi`: see BIP32 for more information about the planned implementation
 92 2012-07-12 15:13:52 <sipa> but i'm working on other things first
 93 2012-07-12 15:23:03 <imsaguy2> Kinda stupid.. my transaction with 4 larger btc inputs to 1 output wouldn't get relayed, but 4 smaller transactions with 1 input, 1 output did. The fee planning needs more TLC
 94 2012-07-12 15:26:33 <D34TH> well
 95 2012-07-12 15:26:43 <D34TH> my wallet just disappered forever
 96 2012-07-12 15:26:51 <D34TH> bbl
 97 2012-07-12 16:35:31 <gribble> New news from bitcoinrss: gavinandresen opened pull request 1590 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1590>
 98 2012-07-12 16:51:25 <yellowhat> for anyone interested in joining the hackathon in berlin remotely, i will be setting up a google hangout for anyone joining remotely. see also https://plus.google.com/events/ce24slldsj4auqc0jpkjn4to7b0/114922074876942161680
 99 2012-07-12 17:02:54 <BlueMatt> if only a 2-way ticket wasnt 200eur...
100 2012-07-12 17:11:29 <yellowhat> BlueMatt, you will hopefully be able to join remotely via google hangout.
101 2012-07-12 17:16:55 <BlueMatt> yea, Ill be on
102 2012-07-12 17:37:20 <jrmithdobbs> gmaxwell: hey, you have a source for that hash bruteforcing method you mentioned re: statistical analysis of keystrokes that leads to breaking seemingly-random passphrases?
103 2012-07-12 17:38:44 <jrmithdobbs> gmaxwell: or similar papers, I'm trying to find some good papers to cite re: current research in this area especially as it relates to those types of methods and linguistic-based approaches for long passphrases based off of (for instance) published text
104 2012-07-12 17:40:26 <jrmithdobbs> the best I'm being able to find is: http://xkcd.com/936/
105 2012-07-12 17:40:29 <jrmithdobbs> everything i find re: key deriv that is semi-appropriate seems to skip that part because knowing you need to generate the phrase based on a strong prng is an assumption of the rest of the paper!
106 2012-07-12 18:04:52 <OneEyed> 35 minutes without a block. Who pulled the bitcoin plug?
107 2012-07-12 18:06:36 <sipa> ;;bc,tblb 35m
108 2012-07-12 18:06:38 <gribble> 5 hours, 44 minutes, and 8 seconds
109 2012-07-12 18:06:50 <sipa> happens several times a day :)
110 2012-07-12 18:07:06 <OneEyed> Nice, didn't know that command
111 2012-07-12 18:07:15 <OneEyed> ;;bc,tblb 38m
112 2012-07-12 18:07:16 <gribble> 7 hours, 46 minutes, and 41 seconds
113 2012-07-12 18:10:01 <OneEyed> New block contains only 8 transactions and weights 3k? Wow, 40,786.36 BTC though
114 2012-07-12 18:25:42 <[Tycho]> ;;bc,tblb 60m
115 2012-07-12 18:25:43 <gribble> 3 days, 0 hours, 36 minutes, and 31 seconds
116 2012-07-12 18:25:50 <[Tycho]> ;;bc,tblb 120m
117 2012-07-12 18:25:52 <gribble> 3 years, 34 weeks, 5 days, 5 hours, 7 minutes, and 8 seconds
118 2012-07-12 18:27:32 <TimothyA> is there a way to reduce fragmenting caused by bitcoin and other derivative clientS?
119 2012-07-12 18:31:10 <sipa> fragmenting of what?
120 2012-07-12 18:31:17 <TimothyA> sipa: blockchain files
121 2012-07-12 18:31:38 <sipa> diapolo has been working on a fix for that,
122 2012-07-12 18:31:41 <TimothyA> trying to run it on any VPS setup, SAN or no SAN, will run the fragmentation in up to embarrasing numbers
123 2012-07-12 18:31:52 <TimothyA> ~80-200K
124 2012-07-12 18:32:00 <sipa> what OS?
125 2012-07-12 18:32:10 <TimothyA> Linux/Ubuntu, ext3
126 2012-07-12 18:32:35 <[Tycho]> Try pre-allocating those files, they will go up to ~2000 Mb each.
127 2012-07-12 18:32:36 <TimothyA> so I actually have to copy over the file, which is fragmented like ****, to get the amount of fragmantation down. but it will immediately fragment again anyway
128 2012-07-12 18:32:53 <TimothyA> [Tycho]: pre-allocating does not help
129 2012-07-12 18:33:33 <sipa> the problem is mostly that BDB is extremely IO-intensive, and doesn't seem to try minizing its number of IO operations
130 2012-07-12 18:33:33 <TimothyA> when booting up the client, it will immediately go from a low number to something in the thousands
131 2012-07-12 18:33:47 <sipa> you're talking about blkindex.dat, then?
132 2012-07-12 18:33:53 <TimothyA> all blk* files
133 2012-07-12 18:34:06 <sipa> those shouldn't get fragmented
134 2012-07-12 18:34:08 <TimothyA> and I'm rather confused why bitcoind needs to disktrash when I'm doing a getinfo()
135 2012-07-12 18:34:18 <TimothyA> sipa: well, they do get fragmented. severely.
136 2012-07-12 18:34:37 <sipa> the blk000?.dat files are only appended to
137 2012-07-12 18:34:40 <TimothyA> I've tried to run bitcoind on at least 7 different VPS's with Linux/Ubuntu, ext3 fs
138 2012-07-12 18:34:50 <TimothyA> from different providers. they all fragment severely
139 2012-07-12 18:35:26 <sipa> fragmentation as such is not that much of a problem (the files are only accessed randomly anyway)
140 2012-07-12 18:35:39 <sipa> but VPS'es typically have slow IO operations
141 2012-07-12 18:36:07 <sipa> and using BDB certainly doesn't help
142 2012-07-12 18:37:03 <TimothyA> why is BDB even harddisk bound to begin with
143 2012-07-12 18:37:34 <sipa> what else would it be? it's a database, if it's not IO bound, there is a problem
144 2012-07-12 18:38:05 <sipa> the problem is really that we're not using BDB for what it is designed for
145 2012-07-12 18:38:19 <TimothyA> sipa: the last thing I want my database to do is being limited by the harddisk performance, especially if it's a horribly inefficient database
146 2012-07-12 18:38:49 <sipa> i don't see what else it should be limited by
147 2012-07-12 18:39:07 <sipa> the problem is that the application shouldn't be limited by the database
148 2012-07-12 18:39:32 <TimothyA> sipa: yet, the application demands to know the blockchain on every single RPC request I make to it
149 2012-07-12 18:39:55 <TimothyA> at these speeds, sqlite is even faster
150 2012-07-12 18:40:14 <sipa> i really doubt sqlite would be faster when used with the same data
151 2012-07-12 18:40:49 <sipa> and no, the application does not demand access to the database at every RPC request
152 2012-07-12 18:41:16 <sipa> getinfo does, as it tries constructing a block, to be able to report difficulty and some other statistics (that should be changed, really)
153 2012-07-12 18:41:20 <TimothyA> then I would like to know what happens when I do "bitcoind getinfo", and I have to wait 50 seconds on a reply while it trashes the harddisk
154 2012-07-12 18:41:34 <TimothyA> validateaddress() produces the same
155 2012-07-12 18:41:42 <TimothyA> even "help"
156 2012-07-12 18:41:49 <sipa> help shouldn't touch your disk at all
157 2012-07-12 18:41:59 <sipa> it takes a global lock
158 2012-07-12 18:42:12 <sipa> and if a block is being processed, it cannot get that lock until it's done
159 2012-07-12 18:42:24 <sipa> and with a VPS, processing a block will take ages because of slow IO operations
160 2012-07-12 18:42:38 <TimothyA> right. but fragmentation does not help, either
161 2012-07-12 18:42:46 <sipa> that said, we plan to move to another database engine
162 2012-07-12 18:42:50 <TimothyA> so VPS's get the double-whammy here
163 2012-07-12 18:42:53 <sipa> (leveldb)
164 2012-07-12 18:43:42 <sipa> and i've been working myself on the validation system to reduce the amount of data needed for validation
165 2012-07-12 18:43:50 <TimothyA> anyway... anyone got a PHP-implementation for validating addresses? the one found on the wiki does not replicate validateaddress() properly
166 2012-07-12 18:44:13 <TimothyA> lots of false negatives
167 2012-07-12 18:44:16 <sipa> i believe i've seen PHP implementations for that on the forum
168 2012-07-12 18:44:25 <sipa> but they may be old
169 2012-07-12 18:44:40 <TimothyA> sipa: yeah, ~20% false negatives
170 2012-07-12 18:46:33 <[Tycho]> There is some PHP lib for processing bitcoin addresses, mostly correct. But I can't remember where I got it.
171 2012-07-12 18:46:53 <TimothyA> https://bitcointalk.org/index.php?topic=1026.msg22121#msg22121 this one?
172 2012-07-12 18:47:00 <TimothyA> it fails a *LOT*
173 2012-07-12 18:48:12 <[Tycho]> I don't see any validating funcs, so it may be not this one.
174 2012-07-12 18:48:29 <TimothyA> [Tycho]: it's for validating, though
175 2012-07-12 18:48:36 <TimothyA> if it can't encode/decode it, it's "invalid"
176 2012-07-12 18:48:41 <[Tycho]> Nope, I think it's another one.
177 2012-07-12 18:49:16 <TimothyA> http://pastebin.com/vmRQC7ha this?
178 2012-07-12 18:49:52 <[Tycho]> Quite possibly.
179 2012-07-12 18:50:28 <[Tycho]> I think I'm using some version of this one.
180 2012-07-12 18:50:42 <[Tycho]> Why it fails for you ?
181 2012-07-12 18:51:21 <TimothyA> this one is BCMath based, I will try running it with a bitcoinaddress that will produce a false negative..
182 2012-07-12 18:53:52 <TimothyA> k, that one does validate more properly
183 2012-07-12 18:55:13 <[Tycho]> Just "more" ?
184 2012-07-12 18:55:30 <TimothyA> yes
185 2012-07-12 18:55:48 <TimothyA> it's under 5% at least, not the whopping 20%
186 2012-07-12 18:55:51 <[Tycho]> But still produces false negatives ?
187 2012-07-12 18:56:53 <TimothyA> yep
188 2012-07-12 18:57:34 <Diapolo> sipa: How does bitcoind know it is fully synced?
189 2012-07-12 18:58:38 <[Tycho]> TimothyA: give me an example
190 2012-07-12 18:59:31 <sipa> Diapolo: it doesn't
191 2012-07-12 19:00:07 <sipa> Diapolo: it guesses based on the tikestamp of the latest block
192 2012-07-12 19:00:15 <TimothyA> evil clipboard... *thwacks it on the head*
193 2012-07-12 19:00:38 <Diapolo> sipa: I'm asking because of that testnet3 GUI thing I'm looking into ... so how can Bitcoin-Qt know this either?
194 2012-07-12 19:01:46 <Diapolo> It currently uses std::max(cPeerBlockCounts.median(), Checkpoints::GetTotalBlocksEstimate()) as number of estimated blocks, which is a crazy number with all those old testnet nodes.
195 2012-07-12 19:03:07 <sipa> only real solution is headers first mode
196 2012-07-12 19:03:26 <sipa> so you can verify PoW of blocks before downloading them
197 2012-07-12 19:04:20 <Diapolo> You are right, the problem is a deeper onw as PoW fails for the obsolete blocks ... hm.
198 2012-07-12 19:05:52 <Diapolo> Seems like a nice scenario (at least for Bitcoin-Qt) that Gavin created there ^^. Old nodes which claim to have the right chain, which is much much longer than the chain after the testnet reset.
199 2012-07-12 19:07:00 <Diapolo> What is bitcoind doing with the old invalid blocks? Is is generatong PoW failed errors, too?
200 2012-07-12 19:07:06 <Diapolo> -o +i
201 2012-07-12 19:14:01 <sipa> which old invalif blocks?
202 2012-07-12 19:14:18 <sipa> the testnet2 blocks downloaded by a testnet3 node?
203 2012-07-12 19:15:19 <Diapolo> sipa: right
204 2012-07-12 19:16:23 <sipa> testnet3 has a checkpoint, so if they can't provide a path to the checkpoint, i suppose they get discarded before storing on disk
205 2012-07-12 19:17:31 <Diapolo> sipa: Right, they don't get stored, but my node is constantly querying for these blocks as their chain is longer than mine, right?
206 2012-07-12 19:17:39 <sipa> indeed
207 2012-07-12 19:18:03 <sipa> i guess we should have switched the magic marker, or default port as well
208 2012-07-12 19:19:03 <Diapolo> Can't we do sth. like don't request a block again which fails PoW or sth. like trust nodes with a higher version more in terms of block-count or such a thing?
209 2012-07-12 19:19:37 <sipa> i'm not sure it actually keeps asking
210 2012-07-12 19:20:16 <[Tycho]> TimothyA: can you give me an example ?
211 2012-07-12 19:22:18 <Diapolo> sipa: my debug log shows a sending getdata: block 00000001a3f1d16f17f6 3 times after it failed PoW each one 2 minutes later
212 2012-07-12 19:25:54 <TimothyA> [Tycho]: copy-paste error :P
213 2012-07-12 19:26:38 <Diapolo> sipa: My node has 8163 verified testnet3 blocks and tries to get more blocks. Those blocks should all be older than block 8163 and fail PoW, right?
214 2012-07-12 19:27:25 <Diapolo> Are blocks stored from oldest to newest on my local node?
215 2012-07-12 19:30:51 <[Tycho]> TimothyA: so you can't show it ?
216 2012-07-12 19:31:05 <TimothyA> ...
217 2012-07-12 19:31:12 <TimothyA> I said; There was a COPY and PASTE error
218 2012-07-12 19:31:17 <TimothyA> hence I was TESTING the WRONG thing
219 2012-07-12 19:31:31 <[Tycho]> Oh, that.
220 2012-07-12 19:31:33 <[Tycho]> Sorry.
221 2012-07-12 19:31:53 <[Tycho]> I thought it was stopping you from showing that address to us :)
222 2012-07-12 19:40:32 <sipa> Diapolo: not sure what you mean
223 2012-07-12 19:43:13 <Diapolo> As long as there are nodes I'm connected to that have a longer chain my client tries downloading blocks from that node, right?
224 2012-07-12 19:44:46 <sipa> yes
225 2012-07-12 19:44:51 <Diapolo> And all of them will fail PoW check.
226 2012-07-12 19:44:51 <sipa> as long as they announce them
227 2012-07-12 19:45:00 <sipa> no
228 2012-07-12 19:45:37 <Diapolo> How can that be, based of the testnet3 situation?
229 2012-07-12 19:46:43 <Diapolo> My node has 8163 blocks, I think that's the current real block-count. Why should it be able to download blocks then, which succeed the PoW check?
230 2012-07-12 19:46:48 <sipa> they will be downloaded, look valid, stored in RAM as orphan, their parents get requested, peer will send invs for first bunch of blocks in the testnet2 chain, those get requested and downloaded, and they will fail the difficulty check (since testnet3 has different difficulty rules)
231 2012-07-12 19:47:10 <sipa> PoW check = block's hash matches the target specified by its own claimed difficulty
232 2012-07-12 19:47:18 <Diapolo> I was thinking way to easy ...
233 2012-07-12 19:48:50 <Diapolo> sipa: But now comes the thing with the block-date and my question about chronological order of local blocks. Number 1 is always oldest, while 8163 is newest?
234 2012-07-12 19:49:55 <sipa> yes
235 2012-07-12 19:50:00 <Diapolo> My node has these blocks, knows they are valid ... now can me reach a block that could make it into my chain, but has an older blockdate, than my newest block?
236 2012-07-12 19:50:15 <sipa> parse error
237 2012-07-12 19:51:33 <Diapolo> I'm seeking a way for Bitcoin-Qt to know it's up to date and stops showing the progessbar ... I guess this can be only done with block-times.
238 2012-07-12 19:52:23 <sipa> and even that is approximate
239 2012-07-12 19:52:44 <Diapolo> The check for if local block count < median of block count of remote nodes WILL fail with testnet2 nodes online, which sucks ^^.
240 2012-07-12 19:53:27 <sipa> i suppose you could use time-stamps
241 2012-07-12 19:54:04 <sipa> show the number of expected remaining blocks based on median, but make the progressbar dependent on the number of days to catch up
242 2012-07-12 19:54:42 <Diapolo> I think this is done for that spinning-animation in the lower right of the GUI.
243 2012-07-12 19:55:09 <sipa> yes, indeed
244 2012-07-12 19:55:39 <Diapolo> I mean the tooltip is great ... last block generated 14 minutes ago and 39000 blocks remaining ... LOL.
245 2012-07-12 20:17:35 <Diapolo> sipa: It's perhaps not THAT elegant, but what about consider the local node up to date, when (clientModel->isTestNet() && nRemainingBlocks >= 100 && nSecsToLastBlock <= 60*60)
246 2012-07-12 20:18:30 <sipa> meh, it's just testnet
247 2012-07-12 20:19:09 <Diapolo> There were complaints ... even Gavin was grumping in the forums.
248 2012-07-12 20:20:24 <sipa> gavin uses the GUI? ;(
249 2012-07-12 20:22:02 <Diapolo> I guess not, but called this behaviour a GUI bug, which in the end I want to fix :). GUI things are my part, rocket-science is yours :-D.
250 2012-07-12 20:23:04 <sipa> no no, rocket-science is etotheipi's business :p
251 2012-07-12 20:24:14 <Diapolo> I know that name, but never met him here.
252 2012-07-12 20:24:24 <Diapolo> Well you know what I mean ^^.
253 2012-07-12 20:24:41 <sipa> he's the author of armory
254 2012-07-12 20:25:02 <sipa> and left IRC when he started to waste too much time here :)
255 2012-07-12 20:28:22 <Diapolo> I'm only in here, when I want to listen, have a coding-problem but mostly not, when working focused on something. Btw. sorry for not having finished that GUI proxy stuff yet.
256 2012-07-12 20:29:09 <sipa> i'll be offline from tomorrow until the end of juli, btw
257 2012-07-12 20:30:15 <Diapolo> holidays? will Gavin start RC phase during your break?
258 2012-07-12 20:32:19 <sipa> no idea
259 2012-07-12 20:33:23 <Diapolo> I guess the world will keep turning either case :). Come back well and healthy! I'm off for now.
260 2012-07-12 20:33:36 <sipa> cya
261 2012-07-12 21:55:00 <bbqgates> Hello, I'm trying to run bitcoin 0.6.3 for the first time on linux x86_64, but it keeps crashing and displaying this message -> EXCEPTION: 11DbException
262 2012-07-12 21:55:10 <bbqgates> Db::put: Cannot allocate memory
263 2012-07-12 21:55:19 <bbqgates> bitcoin in ProcessMessage()
264 2012-07-12 21:55:36 <bbqgates> it does this when it's downloading the block chain, and the error message just repeats
265 2012-07-12 21:57:11 <gavinandresen> Cannot allocate memory?  You out of disk space or memory?
266 2012-07-12 21:58:48 <bbqgates> well I haven't monitored my memory when running it, but I have enough disk space....
267 2012-07-12 21:58:57 <sipa> that BDB error also occurs when BDB runs out of locks
268 2012-07-12 21:59:07 <bbqgates> how do I tell bitcoin to save to a database?  maybe it's trying to store it in memory
269 2012-07-12 21:59:16 <sipa> no it's not
270 2012-07-12 21:59:46 <sipa> Loading package GLFW-b-0.1.0.2 ... linking ... ghc: /home/pw/.cabal/lib/GLFW-b-0.1.0.2/ghc-7.0.3/HSGLFW-b-0.1.0.2.o: unknown symbol `atexit'
271 2012-07-12 21:59:51 <sipa> ow, wrong window
272 2012-07-12 22:00:32 <gavinandresen> sipa: is there still a running-out-of-locks problem? I thought we fixed that in 0.6.something
273 2012-07-12 22:00:38 <gavinandresen> (we meaning you)
274 2012-07-12 22:01:13 <sipa> bbqgates: how much RAM do you have?
275 2012-07-12 22:01:19 <bbqgates> what's a BDB error: bad Database?
276 2012-07-12 22:01:25 <bbqgates> sipa: 4 GB
277 2012-07-12 22:01:32 <sipa> should certainly be enough
278 2012-07-12 22:01:41 <sipa> that sounds like a corrupted file...
279 2012-07-12 22:02:00 <bbqgates> well I just downloaded it... untared it and ran it
280 2012-07-12 22:02:27 <sipa> is it always at the same block that it complains?
281 2012-07-12 22:02:43 <sipa> can you paste a few pages of debug.log (at the end) somewhere?
282 2012-07-12 22:02:45 <bbqgates> yeah it seems to always be around ~145000 block
283 2012-07-12 22:03:00 <bbqgates> where's the debug.log stored at ??? /var?
284 2012-07-12 22:03:09 <sipa> ~/.bitcoin/debug.log
285 2012-07-12 22:03:18 <bbqgates> hmm ok let me look
286 2012-07-12 22:04:27 <bbqgates> wow long log
287 2012-07-12 22:07:06 <gavinandresen> tail -500 ~/.bitcoin/debug.log is your friend
288 2012-07-12 22:08:22 <bbqgates> lol ok thanks for the tip gavinandersen
289 2012-07-12 22:08:44 <luke-jr> I like 'less'
290 2012-07-12 22:08:58 <sipa> thankfully, less is more than more
291 2012-07-12 22:09:02 <luke-jr> and 'wgetpaste'
292 2012-07-12 22:09:06 <bbqgates> http://pastebin.com/mPEGJMcg
293 2012-07-12 22:09:14 <bbqgates> ok there is where it started spitting out the error
294 2012-07-12 22:11:59 <sipa> it complains at connecting block 43789
295 2012-07-12 22:12:13 <sipa> a 43 KiB block...
296 2012-07-12 22:13:32 <bbqgates> is a 43KiB block ... corrupt?
297 2012-07-12 22:13:46 <bbqgates> abnormal size?
298 2012-07-12 22:13:50 <sipa> if it was corrupt there would be different errors
299 2012-07-12 22:13:53 <sipa> and no, it is small
300 2012-07-12 22:14:12 <sipa> not sure what's causing this
301 2012-07-12 22:15:12 <bbqgates> I was getting this error the other day and I reinstalled my os and i'm getting the same error :P
302 2012-07-12 22:15:22 <gavinandresen> luke-jr: where in pull 1240 are you sorting by fee-per-kb ?
303 2012-07-12 22:16:09 <gavinandresen> luke-jr: oh, never mind, I see, you changed the priority algorithm
304 2012-07-12 22:16:14 <bbqgates> I'm on debian squeeze if that helps
305 2012-07-12 22:18:02 <bbqgates> would dropping down to bitcoin 0.6.2 help?
306 2012-07-12 22:18:10 <sipa> doubtful
307 2012-07-12 22:39:04 <bbqgates> ok well thanks for helping sipa and gavinandresen
308 2012-07-12 22:39:27 <sipa> i find it remarkable that the problem persists
309 2012-07-12 22:39:36 <bbqgates> what would you recommend as an alternative wallet?
310 2012-07-12 22:39:52 <bbqgates> yeah it has... I totally wiped the drive and reinstalled... and here it is again
311 2012-07-12 22:42:22 <bbqgates> it saves the blocks in .bitcoin/database right?
312 2012-07-12 22:42:58 <bbqgates> in that directory I have 3 10MB files named log.xxxxxxxxxx#....
313 2012-07-12 22:43:55 <sipa> no, in blk0001.dat
314 2012-07-12 22:44:15 <sipa> the dir database only contains the db transaction log
315 2012-07-12 22:44:27 <bbqgates> hmm ok blk0001.dat is only 10.3 MB
316 2012-07-12 22:46:51 <bbqgates> now if I try rerunning it it gives me the following error -> Error: To use bitcoind, you must set a rpcpassword in the configuration file:
317 2012-07-12 22:47:09 <sipa> did you?
318 2012-07-12 22:47:39 <bbqgates> no let me try that
319 2012-07-12 22:50:23 <bbqgates> ok I did that and now instead of a Db::put error.... I'm getting a Db::get error
320 2012-07-12 22:50:55 <bbqgates> Db::get: Cannot allocate memory
321 2012-07-12 22:52:13 <bbqgates> here's a link with people having the same identical problem -> https://bitcointalk.org/index.php?topic=9325.0
322 2012-07-12 22:58:51 <D34TH> whats your openfile limit?
323 2012-07-12 23:08:22 <bbqgates> D34TH, how do I check that?
324 2012-07-12 23:08:33 <D34TH> ulimit -n
325 2012-07-12 23:08:46 <bbqgates> 1024
326 2012-07-12 23:08:56 <D34TH> soomes ok
327 2012-07-12 23:09:17 <D34TH> **seems
328 2012-07-12 23:09:49 <D34TH> what about lsof | wc -l
329 2012-07-12 23:11:41 <sipa> is the total number of file descriotors on the system relevant?
330 2012-07-12 23:12:01 <D34TH> out of file descriptors?
331 2012-07-12 23:12:09 <D34TH> wouldnt allow more open files
332 2012-07-12 23:12:19 <D34TH> idk just an idea
333 2012-07-12 23:14:47 <bbqgates> lsof | wc -l .... -> 3566
334 2012-07-12 23:14:55 <bbqgates> thanks for the help D34TH
335 2012-07-12 23:15:26 <D34TH> i tried
336 2012-07-12 23:17:17 <bbqgates> :)
337 2012-07-12 23:20:44 <phantomcircuit> slowest way to download blocks
338 2012-07-12 23:20:51 <phantomcircuit> mirrored disks with mirrored mirror log
339 2012-07-12 23:21:05 <phantomcircuit> click click click click click click click click click click click click click click click click click click click click click click click click
340 2012-07-12 23:22:10 <sipa> slowest would be a software raid over several network block devices hosted on different machines, mounted via sshfs over a 2G mobile data connection
341 2012-07-12 23:25:06 <BlueMatt> meh, just do it on a raid across floppy drives
342 2012-07-12 23:25:30 <BlueMatt> (with a blocksize of the size of the drives, what 1.4M?)
343 2012-07-12 23:26:01 <MC1984> you are supposed to be discussing how to make it faster not slower assholes
344 2012-07-12 23:26:14 <BlueMatt> faster: ultraprune
345 2012-07-12 23:26:21 <BlueMatt> or...bitcoinj ultraprune
346 2012-07-12 23:26:26 <MC1984> wut
347 2012-07-12 23:26:36 <D34TH> or... --no-log
348 2012-07-12 23:26:44 <D34TH> and --no-chain
349 2012-07-12 23:26:46 <D34TH> :D
350 2012-07-12 23:26:53 <BlueMatt> --no-security ;)
351 2012-07-12 23:27:00 <D34TH> :)
352 2012-07-12 23:27:20 <MC1984> is that like pruning, now with 20% extra prune
353 2012-07-12 23:27:42 <D34TH> nah see, you have to juice the prune
354 2012-07-12 23:27:47 <D34TH> to get the extract
355 2012-07-12 23:27:52 <D34TH> i.e. prune juice
356 2012-07-12 23:28:23 <BlueMatt> MC1984: sort of, yea
357 2012-07-12 23:30:54 <sipa> --accept-double-spends
358 2012-07-12 23:31:00 <D34TH> no
359 2012-07-12 23:31:07 <D34TH> --accept-triple-spends
360 2012-07-12 23:31:14 <sipa> haha
361 2012-07-12 23:31:32 <sipa> --use-triple-rot13-encrypted-wallet
362 2012-07-12 23:31:40 <D34TH> base64
363 2012-07-12 23:32:01 <BlueMatt> triple rot13, naaa thats no where near as secure as --use-quad-rot13-encrypted-wallet
364 2012-07-12 23:32:12 <sipa> overkill!
365 2012-07-12 23:32:28 <D34TH> you lose performace after 3 rotations
366 2012-07-12 23:32:38 <D34TH> **performance
367 2012-07-12 23:33:08 <BlueMatt> heh
368 2012-07-12 23:33:22 <MC1984> this is why nerds dont have girlfriends
369 2012-07-12 23:33:37 <D34TH> because we used quad rot13?
370 2012-07-12 23:33:39 <D34TH> DAMN
371 2012-07-12 23:34:04 <D34TH> i blame bluematt
372 2012-07-12 23:34:15 <BlueMatt> sipa: got data size down to 110M with 21M (:o) in relational db index id fields...
373 2012-07-12 23:34:57 <D34TH> hmm instead of base58 why not esab85
374 2012-07-12 23:34:59 <D34TH> :D
375 2012-07-12 23:35:12 <BlueMatt> ooo...bigger number, it must be better
376 2012-07-12 23:35:42 <BlueMatt> anyway, Im gonna go sleep, Im not being productive...sipa, enjoy vacation
377 2012-07-12 23:38:42 <sipa> BlueMatt: is that 110M serialized, or on-disk?
378 2012-07-12 23:39:48 <BlueMatt> sipa: serialized
379 2012-07-12 23:40:23 <CluckCreek> Forgive me if this is an overasked question, but if someone had more than half of the network's CPU power, would it be possible for them to make the difficulty easier than it should be, so that they can mine coins faster?
380 2012-07-12 23:41:30 <BlueMatt> if you have >51%, you could ignore all other blocks and just miner your own chain, then you would be able to get all blocks (probabilistically)
381 2012-07-12 23:42:44 <CluckCreek> That's what I thought.
382 2012-07-12 23:43:57 <luke-jr> CluckCreek: btw, there's effectively no CPU power on the network mining these days
383 2012-07-12 23:44:28 <CluckCreek> Wouldn't that be really bad? Would it be possible to go through all the bitcoin-adding blocks very quickly by making the difficultly really easy?
384 2012-07-12 23:44:42 <CluckCreek> Forgive me, "hashing power"
385 2012-07-12 23:48:21 <luke-jr> CluckCreek: yes, that's why Bitcoin tries to make it impossible
386 2012-07-12 23:48:37 <luke-jr> the whole reason for the proof-of-work mining is to make 51% attacks hard
387 2012-07-12 23:50:01 <CluckCreek> okay
388 2012-07-12 23:59:16 <MC1984> dat netsplit