1 2013-11-10 00:00:13 <MC1984> that means not dicking with the blocks for a good long while and hoping the world doesnt end up full of fucking ipads
2 2013-11-10 00:00:22 <groglogic> to give just one example, let's say that all the most critical nodes/participants/service were located in the physical US. and one day, the US gov "goes bad" (or rogue super operator inside the NSA, etc.), and blocks/impedes those core services. taht would suck. so better to have key stuff redundant and stuff outside US gov reach, in that scen
3 2013-11-10 00:00:59 <MC1984> jouke actually being a node take hardly shit all reosurces, after the sync is done
4 2013-11-10 00:01:05 <MC1984> until then, its painful
5 2013-11-10 00:02:00 <MC1984> groglogic outside us govt reach means outside the angloshpere at the least, and usually a bit more than that
6 2013-11-10 00:02:19 <groglogic> well in ideal world, everybody has a "smart" device on their person, that can at least act as a Bitcoin client, not necessarily do full mining (no point) but be able to spend/receive/manage Bitoins, just as long as they have (even if only intermittent) IP/USB conn to the greater Internet
7 2013-11-10 00:03:17 <MC1984> thats not a node
8 2013-11-10 00:03:18 <jouke> phantomcircuit: good point. One could ship them with a "trusted" blockchain.
9 2013-11-10 00:03:45 <MC1984> er how about no?
10 2013-11-10 00:04:22 <groglogic> MC1984: I can see it now... Bitcoin Foundation as a future customer of SpaceX, delivering a satellite to orbit, or "thing" onto Moon or Mars, that provides some critical Bitcion service or backup. yes, latency would suck. but it would increase redundancy/backup. (of course, US gov could reach even out there if they wanted). just a thought experiment
11 2013-11-10 00:04:26 <RoboTeddy> variety/redundancy in the channels that broadcasts and txns pass through sound like a good idea. any thoughts on what additional channels could be used?
12 2013-11-10 00:05:00 <MC1984> er the foundation is more likely to concede any us govt demands than launch a moon base to get away from them
13 2013-11-10 00:06:49 <groglogic> RoboTeddy: ad hoc WiFi mesh, so not part of permanent "landline" IP Internet. occasionally connected, mobile, encrypted, etc.... fiber pathways that will immed detect if a splitter is added. point-to-point visual links.... steganophrically-encrypted "porn" images posted with links in IRC/4Chan. all kinds of weird pathways are possible. the more the better
14 2013-11-10 00:08:33 <groglogic> RoboTeddy: putting a lot of Bitcoin bcasts serialized into physical form, put in cargo cantainer, air/water travel, delivered, opened, read/scanned, back into the normal IP network Bitcoin (yes, latency, yes cost, yes efficiency, haha)
15 2013-11-10 00:09:51 <RoboTeddy> groglogic: cool ideas. which do you think are easiest to implement first?
16 2013-11-10 00:09:54 <groglogic> MC1984: agreed. just a thought experiment. but I bet something like that, by somebody with banking interests, could eventually put together enough money, esp as transport options grow and get cheaper
17 2013-11-10 00:10:49 <groglogic> RoboTeddy: good line of thought. i'm not sure offhand. have to think more. i'm currently focused on a different area with respect to Bitcoin
18 2013-11-10 00:10:52 <MC1984> bitcoin could fairly well work out to the moon in fact, as our closest celestial body
19 2013-11-10 00:12:13 <RoboTeddy> http://en.wikipedia.org/wiki/Communication_Moon_Relay
20 2013-11-10 00:16:03 <Luke-Jr> MC1984: I wonder if a more adaptive block time will be necessary if we ever go beyond the moon, or if we'd just create a universal-scope altcoin
21 2013-11-10 00:17:18 <phantomcircuit> MC1984, if he's selling people hardware then they're already trusting him to a pretty high degree anyways
22 2013-11-10 00:17:52 <RoboTeddy> the idea of connecting nodes together in a way that isn't public sounds good -- to successfully DDoS such a network, you'd need to do a ton of recon first
23 2013-11-10 00:18:03 <MC1984> if by beyond the moon you mean the moons of jupiter or something, by then it will be all fee so i couild maybe see consensus on increasing the block time to several hours seeing as mining will probably just be done by governments
24 2013-11-10 00:19:00 <MC1984> but then that would imply a fairly large colony out there to generate the economic activity to justify it
25 2013-11-10 00:19:08 <MC1984> hundreds of years
26 2013-11-10 00:20:02 <MC1984> phantomcircuit any of the asics sold would be noticed pretty quick if they were skimming hashes off the top for a third party or something
27 2013-11-10 00:20:19 <MC1984> its verifiable, just liket he chain should be
28 2013-11-10 00:20:38 <MC1984> ship with a huge bootstrap file by all means
29 2013-11-10 00:20:50 <phantomcircuit> MC1984, i meant the guy talking about a trusted blockchain delivered along with the device
30 2013-11-10 00:21:22 <MC1984> yeah
31 2013-11-10 00:23:44 <Luke-Jr> phantomcircuit: not the same level of trust imo
32 2013-11-10 00:23:56 <Luke-Jr> trusting a UTXO set is an ongoing trust
33 2013-11-10 00:24:16 <Luke-Jr> trusting delivery of hardware is usually just trust-until-you-get-it
34 2013-11-10 00:24:23 <Luke-Jr> although I suppose ASICs could be time-bombed :/
35 2013-11-10 00:24:45 <phantomcircuit> Luke-Jr, i more meant that the hardware could be backdoored
36 2013-11-10 00:24:58 <Luke-Jr> phantomcircuit: not really, it has no communication means
37 2013-11-10 00:25:08 <phantomcircuit> Luke-Jr, not for an asic
38 2013-11-10 00:25:17 <phantomcircuit> <jouke> What would be the minimum kind of hardware one needs to run a full node? Wouldn't it be nice to develop a real small and cheap device that one could just plugin in and be a bitcoin-node?
39 2013-11-10 00:25:18 <phantomcircuit> for that
40 2013-11-10 00:25:25 <Luke-Jr> oh
41 2013-11-10 00:30:41 <MC1984> maybe if the freedombox thing was ever more than a pipe dream
42 2013-11-10 00:31:11 <MC1984> in my utopian socialist paradise every home would have a server running all these emancipatory p2p projects
43 2013-11-10 00:31:25 <MC1984> because there are many things far too important for anyone to ahve control over
44 2013-11-10 00:32:38 <MC1984> instead were running face first into a wall of techno-fuedalism, as schinier puts it
45 2013-11-10 00:32:58 <sipa> schneier?
46 2013-11-10 00:33:03 <sipa> feudalism?
47 2013-11-10 00:33:12 <MC1984> bruce schiner
48 2013-11-10 00:33:17 <MC1984> or whatever
49 2013-11-10 00:33:24 <sipa> bruce schneier :)
50 2013-11-10 00:33:31 <MC1984> yea
51 2013-11-10 00:33:41 <MC1984> his blog is dark as hell these days....
52 2013-11-10 00:37:51 <groglogic> Luke-Jr: the advantage of sw miners over hw is we can see & audit the source; whereas with hw miners the advantage is more throughput per dollar, but, the "source" is opaque; are people thinking about those risks already, to hw/asic miners? ie, what if backdoors are being baked into those chips/boards?
53 2013-11-10 00:40:10 <RoboTeddy> groglogic: aren't blocks validated in software? if an asic were backdoored, wouldn't it just produce blocks that no one would accept?
54 2013-11-10 00:40:14 <K1773R> groglogic: backdoor? WTF?
55 2013-11-10 00:40:31 <K1773R> RoboTeddy: right...
56 2013-11-10 00:51:57 <sipa> groglogic: mining hardware can be made in a way so it does not know what it is mining on
57 2013-11-10 00:53:08 <guymann> hi all
58 2013-11-10 00:56:39 <MC1984> sipa if thats true thats the first thing to be regulated away
59 2013-11-10 00:56:54 <groglogic> RoboTeddy: well no. i think the model people were considering is if an ASIC hardware miner is produced that normally does it job. it mines honestly and legitimately by default, 99.9%%% of the time. but then the attack executes his backdoor, and, say, either causes them all to stop mining, which causes a big drop in the network's ability to verify transactions and thus produce new blocks with the recent txns baked
60 2013-11-10 00:56:55 <groglogic> in, or, could try to fork with double-spends in it. you'd still need those compromised miners to have a very large % of the total mining job. so this "does ASIC backdoor make a diff" threat, I think, collapses back to the orig well-known vuln of needing am honest majority. but at least with sw miners we can audit the source, with hw miners we can't.
61 2013-11-10 00:57:51 <groglogic> sipa: good point. i see. so in theory you could trust them more, because the hw thinks it's just been givin some generic computation to do (SHA256 or whatever) and since it doesn't know it's doing Bitcoin mining...
62 2013-11-10 00:58:50 <RoboTeddy> groglogic: ah, I misunderstood the possible threat, thanks
63 2013-11-10 01:00:21 <groglogic> a lot of the time, maybe always all the time i think about attack vectors, they risk tends to collapse back to either the "core" risk of requiring an honest majority, and just the fact that regardless of the application/payload, any P2P system can have risks mitigated by whitelists/blacklists
64 2013-11-10 01:00:47 <groglogic> and air gaps, etc.
65 2013-11-10 01:00:58 <groglogic> and offline private keys, etc
66 2013-11-10 01:01:43 <groglogic> such an elegant design, the more I absorb it, learn about its subtle aspects/implications. imo
67 2013-11-10 01:13:30 <s7r> what's new in 0.8.5? any improvements or security updates?
68 2013-11-10 01:14:34 <RoboTeddy> s7r: can see release notes here - http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/
69 2013-11-10 01:17:42 <iceTwy> any Coinpunk dev here?
70 2013-11-10 01:17:48 <iceTwy> or anyone who runs Coinpunk on a server
71 2013-11-10 01:18:11 <warren> iceTwy: talk to the author of coinpunk directly
72 2013-11-10 01:19:06 <warren> http://imgur.com/BUoujw7 p2pool BTC growth over time. Impressive. =)
73 2013-11-10 01:21:22 <iceTwy> but
74 2013-11-10 01:21:22 <iceTwy> it's not an issue, directly
75 2013-11-10 01:21:22 <iceTwy> right, so, CoinPunk uses sipa's patch for watch-only addresses
76 2013-11-10 01:21:22 <iceTwy> well I'm simply asking myself one thing
77 2013-11-10 01:21:35 <iceTwy> right, so, CoinPunk uses sipa's patch for watch-only addresses
78 2013-11-10 01:21:53 <iceTwy> and it recommends downloading an archive of sipa's bitcoin repo, instead of the main one
79 2013-11-10 01:22:10 <warren> iceTwy: https://github.com/wtogami/bitcoin/tree/btc-0.8.5-watchonly
80 2013-11-10 01:22:14 <iceTwy> aaand afaik, sipa's bitcoin repo hasn't been updated to 0.8.5
81 2013-11-10 01:22:19 <warren> iceTwy: my branch of 0.8.5 + watchonly here is well tested
82 2013-11-10 01:22:32 <warren> iceTwy: it is what kyledrake uses for now
83 2013-11-10 01:22:42 <iceTwy> oh
84 2013-11-10 01:22:44 <iceTwy> sweet
85 2013-11-10 01:22:54 <iceTwy> then the install guide for CoinPunk should be modified. I'll send in a pull request
86 2013-11-10 01:23:09 <warren> iceTwy: I tried to merge it with my larger 0.8.5 branch but it conflicts with Coin Control so it remains separate for now.
87 2013-11-10 01:23:14 <iceTwy> warren: will my bitcoin data repo be cross compatible?
88 2013-11-10 01:23:26 <iceTwy> should be I guess
89 2013-11-10 01:23:26 <warren> iceTwy: yes
90 2013-11-10 01:23:29 <iceTwy> cool
91 2013-11-10 01:23:42 <warren> iceTwy: https://bitcointalk.org/index.php?topic=320695 here's bitcoin 0.8.5 with lots of other features, just not watchonly, sadly.
92 2013-11-10 01:23:45 <iceTwy> I would really mind redownloading the blockchain for the 3rd time, haha
93 2013-11-10 01:24:08 <iceTwy> warren: eh :/
94 2013-11-10 01:24:28 <iceTwy> so essentially, your repo runs on mainline 0.8.5 and just adds support for watch-only addresses?
95 2013-11-10 01:25:02 <warren> iceTwy: https://github.com/wtogami/bitcoin/commits/btc-0.8.5-watchonly this branch has disablewallet and watchonly
96 2013-11-10 01:25:07 <warren> seems to work
97 2013-11-10 01:25:11 <iceTwy> hmkay
98 2013-11-10 01:25:39 <warren> iceTwy: these branches exist because litecoin 0.8 has been testing 0.9 features for months and we figured we might as well publish experimental bitcoin client branches
99 2013-11-10 01:25:51 <warren> iceTwy: it's helped to expose bugs that were fixed before 0.9
100 2013-11-10 01:25:57 <iceTwy> interesting, lol
101 2013-11-10 01:26:07 <iceTwy> litecoin's a sort of playground for bitcoin experimental features then?
102 2013-11-10 01:26:13 <warren> iceTwy: it can be, yes.
103 2013-11-10 01:26:15 <iceTwy> (with all due respect to litecoin)
104 2013-11-10 01:26:25 <iceTwy> that's pretty great actually
105 2013-11-10 01:26:31 <warren> iceTwy: litecoin dev is open to shipping and testing things quickly
106 2013-11-10 01:26:56 <warren> iceTwy: litecoin dev has even donated lots of money to bitcoin devs to thank for certain features
107 2013-11-10 01:27:20 <warren> iceTwy: ~$2,600 donated to p2pool dev to improve decentralized mining for both BTC and LTC.
108 2013-11-10 01:28:02 <iceTwy> o.o
109 2013-11-10 01:28:03 <sipa> iceTwy: my watchonly branch is rebased to git head as of a few days ago; far past 0.8.5
110 2013-11-10 01:28:41 <warren> sipa: any bug fixes since the previous rebase?
111 2013-11-10 01:28:44 <iceTwy> sipa: ah, really?
112 2013-11-10 01:29:09 <sipa> warren: no, just rebase
113 2013-11-10 01:29:12 <warren> sipa: ok
114 2013-11-10 01:29:22 <iceTwy> sipa: I did clone your git repo and compile bitcoin from there but
115 2013-11-10 01:29:29 <iceTwy> I still have the corrupt block database error
116 2013-11-10 01:29:34 <iceTwy> (I've reindexed twice)
117 2013-11-10 01:29:47 <sipa> :(
118 2013-11-10 01:29:55 <iceTwy> and since that was fixed in 0.8.5, I was thinking that your version might not have fixed that
119 2013-11-10 01:29:59 <iceTwy> I mean
120 2013-11-10 01:30:06 <iceTwy> yeah
121 2013-11-10 01:30:06 <warren> iceTwy: you may have more luck with my watchonly 0.8.5 branch
122 2013-11-10 01:30:12 <iceTwy> warren: yeah I'll try it out
123 2013-11-10 01:30:31 <sipa> git head has no known errorneous corrupt chaim issues
124 2013-11-10 01:30:36 <iceTwy> my VPS provider probably hates me by now
125 2013-11-10 01:30:38 <iceTwy> but heh
126 2013-11-10 01:30:45 <warren> sipa: well, there's the mac thing
127 2013-11-10 01:30:50 <sipa> except of course cases where the chain is actually corrupted
128 2013-11-10 01:31:01 <sipa> yes, but that's not what he was talking about
129 2013-11-10 01:31:12 <sipa> on mac it frequently actually corrupts
130 2013-11-10 01:31:20 <warren> sipa: toffoo is uploading to me his datadir from 0.7.2 that works with 0.7.2, indexes and works fine in 0.8.5, but crashes after a clean shutdown and restart of 0.8.5.
131 2013-11-10 01:31:47 <sipa> ok
132 2013-11-10 01:31:55 <gavinandresen> sipa: I'm thinking of merging https://github.com/bitcoin/bitcoin/pull/2767 now, because I agree wil wladimirs "sooner better than later"
133 2013-11-10 01:31:55 <sipa> that sounds weird
134 2013-11-10 01:32:03 <warren> weird indeed
135 2013-11-10 01:32:08 <warren> he said this datadir originates from 0.3.x
136 2013-11-10 01:32:09 <gavinandresen> sipa: ⦠but it'll probably create merge conflicts with EVERYTHING else
137 2013-11-10 01:32:43 <iceTwy> sipa: well yeah. I just finished reindexing my blockchain
138 2013-11-10 01:32:48 <iceTwy> and it /still/ is 'corrupted'
139 2013-11-10 01:32:50 <BW^-> is "libbitcoin" the best btc lib around? reliable logics?
140 2013-11-10 01:32:55 <iceTwy> I can't see how it would be
141 2013-11-10 01:33:01 <warren> gavinandresen: did you test win64 builds?
142 2013-11-10 01:33:18 <Luke-Jr> gavinandresen: I've been using it for a number of months with no problems, FWIW.
143 2013-11-10 01:33:18 <warren> gavinandresen: how's build time improvement now?
144 2013-11-10 01:33:20 <gavinandresen> warren: nope. if it works on win32 it almost certainly works on win64, though
145 2013-11-10 01:33:39 <warren> gavinandresen: I did some preliminary win64 tests and performance gains are HUGE
146 2013-11-10 01:33:51 <gavinandresen> warren: you mean compiling performance gains
147 2013-11-10 01:34:03 <warren> oh, runtime in this case, sorry, different topic
148 2013-11-10 01:34:14 <warren> and I was comparing win32 vs win64 with secp256k1
149 2013-11-10 01:34:26 <sipa> gavinandresen: i'd like to have a look over it still, will do tomorrow
150 2013-11-10 01:34:58 <gavinandresen> sipa: perfect enemy of the better and all that⦠can fix any nits in a further pull...
151 2013-11-10 01:35:01 <warren> gavinandresen: it appears worthwhile to make a win64 option for 0.9 if someone has time to craft it.
152 2013-11-10 01:35:25 <warren> gavinandresen: we also haven't yet fixed the build flags for mingw gitian
153 2013-11-10 01:35:48 <sipa> warren: how so?
154 2013-11-10 01:36:01 <warren> sipa: the missing hardening
155 2013-11-10 01:36:58 <sipa> ah
156 2013-11-10 01:37:07 <sipa> is there an issue for that?
157 2013-11-10 01:37:15 <gavinandresen> yes, one of our oldest pull requests
158 2013-11-10 01:37:27 <sipa> ooh, that
159 2013-11-10 01:37:35 <warren> cfields has a number of improvements to gitian that he wanted to push
160 2013-11-10 01:37:39 <warren> but he seems to be busy lately.
161 2013-11-10 01:37:40 <gavinandresen> "we" need to update the pull-tester machine, though...
162 2013-11-10 01:38:03 <warren> I'm waiting on his pushes before updating all the win32 deps.
163 2013-11-10 01:42:00 <MC1984> warren win64 builds are actually a alot faster? You mean like actual running?
164 2013-11-10 01:42:16 <MC1984> verifying?
165 2013-11-10 01:43:04 <Luke-Jr> no surprise there
166 2013-11-10 01:43:18 <warren> MC1984: yes
167 2013-11-10 01:43:46 <warren> I have win64 builds based on 0.8
168 2013-11-10 01:43:59 <warren> too much of a hack to ship
169 2013-11-10 01:44:10 <MC1984> faster even than the 32 bit w/ libsecp256
170 2013-11-10 01:44:23 <Luke-Jr> MC1984: libsecp256k1 doesn't really optimise 32-bit
171 2013-11-10 01:44:24 <warren> MC1984: libsecp256k1 itself is wayyyy slower on 32bit
172 2013-11-10 01:44:38 <MC1984> oh yeah i remember someone saying
173 2013-11-10 01:46:05 <MC1984> its because the processor can process 64 bits of whatevers in the registers per clock instead of 32 or somthing right
174 2013-11-10 01:51:01 <Luke-Jr> MC1984: no.
175 2013-11-10 01:51:10 <Luke-Jr> well, maybe partly
176 2013-11-10 01:51:26 <Luke-Jr> but sipa didn't even try to optimise 32-bit IIRC
177 2013-11-10 01:53:05 <iceTwy> warren: erm.
178 2013-11-10 01:53:14 <iceTwy> here's another issue that could be solved with sipa's bitcoin repo haha
179 2013-11-10 01:54:00 <iceTwy> I'm building bitcoin w/ your watch-only repo. but my libdb package is too recent
180 2013-11-10 01:54:09 <iceTwy> I have libdb5.1 installed, not libdb4.8
181 2013-11-10 01:54:16 <gmaxwell> Luke-Jr: it's somewhat optimized.
182 2013-11-10 01:55:31 <sipa> iceTwy: has nothing to do with my repo
183 2013-11-10 01:55:41 <warren> iceTwy: 0.8 which you're building can build against either 4.8 or 5.1
184 2013-11-10 01:55:42 <sipa> iceTwy: you can use --with-incompatible-bdb
185 2013-11-10 01:56:29 <sipa> Luke-Jr: 32-bit libsecp256k1 is still 2-3 times faster than 32-bit openssl
186 2013-11-10 01:57:55 <warren> sipa: any progress on getting an audit of libsecp256k1?
187 2013-11-10 02:00:25 <iceTwy> god
188 2013-11-10 02:00:39 <iceTwy> still getting the corrupted DB error
189 2013-11-10 02:00:42 <iceTwy> I guess it is legit corrupt then
190 2013-11-10 02:00:55 <warren> which db is corrupt?
191 2013-11-10 02:01:13 <iceTwy> warren: : Corrupted block database detected.
192 2013-11-10 02:01:16 <iceTwy> Do you want to rebuild the block database now?
193 2013-11-10 02:01:24 <iceTwy> that's when I launch bitcoind
194 2013-11-10 02:01:46 <gmaxwell> uh. hey, can someone restart a node with a big dbcache and checkblocks tuened up? My laptop barfs at 268699 minus ~20 blocks.
195 2013-11-10 02:02:12 <iceTwy> warren: does that mean I have to redownload the blockchain for a 4th time
196 2013-11-10 02:02:17 <warren> gmaxwell: 0.8.5 fine?
197 2013-11-10 02:02:22 <warren> gmaxwell: give me the exact parameters to use
198 2013-11-10 02:02:38 <warren> iceTwy: what OS are you running?
199 2013-11-10 02:03:02 <iceTwy> warren: Debian Wheezy
200 2013-11-10 02:03:20 <warren> iceTwy: are you certain your hardware is fine?
201 2013-11-10 02:03:26 <warren> iceTwy: check for smart errors
202 2013-11-10 02:03:32 <gmaxwell> warren: bitcoind -dbcache=2000 (hopefully you have 2gb availble) -checkblocks=2000
203 2013-11-10 02:03:32 <iceTwy> warren: can't be sure. it's a VPS
204 2013-11-10 02:03:34 <warren> iceTwy: and weird stuff in dmesg
205 2013-11-10 02:03:48 <iceTwy> agh, dmesg is full of iptables spam
206 2013-11-10 02:03:51 <iceTwy> but yeah
207 2013-11-10 02:03:58 <warren> gmaxwell: I'm likely a few thousand blocks behind, should I sync normally first then restart with that?
208 2013-11-10 02:04:11 <gmaxwell> warren: warren yea sure.
209 2013-11-10 02:04:14 <warren> gmaxwell: ok
210 2013-11-10 02:05:27 <warren> syncing
211 2013-11-10 02:05:51 <iceTwy> warren: no errors whatsoever in dmesg
212 2013-11-10 02:07:02 <warren> TBF, i did see unexplained corruption on linux recently =(
213 2013-11-10 02:12:27 <iceTwy> ACTION sighs
214 2013-11-10 02:12:28 <iceTwy> ugggggggggggggh
215 2013-11-10 02:16:55 <dobry-den> is that corruption in leveldb
216 2013-11-10 02:17:04 <iceTwy> can't know for sure
217 2013-11-10 02:17:10 <iceTwy> but apparently.
218 2013-11-10 02:17:21 <iceTwy> warren: the disk of the VPS host machine is not failing
219 2013-11-10 02:17:56 <iceTwy> warren: wouldn't it come from the fact that I use libdb5.1?
220 2013-11-10 02:18:01 <iceTwy> I see no other possible explanation
221 2013-11-10 02:22:36 <warren> hmmm
222 2013-11-10 02:22:39 <warren> I'm seeing tons of this:
223 2013-11-10 02:22:40 <warren> ERROR: ProcessBlock() : already have block 268697 00000000000000016a7c02a2e5961c3b221fe7ea66b3f8be8e9bd759a5c7dd45
224 2013-11-10 02:22:40 <warren> received block 00000000000000016a7c02a2e5961c3b221fe7ea66b3f8be8e9bd759a5c7dd45
225 2013-11-10 02:22:47 <warren> I mean LOTS
226 2013-11-10 02:23:29 <iceTwy> aaaah
227 2013-11-10 02:23:31 <iceTwy> I'm getting this
228 2013-11-10 02:23:33 <iceTwy> ERROR: VerifyDB() : *** coin database inconsistencies found (last 83 blocks, 824 good transactions before that)
229 2013-11-10 02:23:57 <iceTwy> think I should remove the most recent blk.dat files
230 2013-11-10 02:24:01 <iceTwy> like, one or two of em
231 2013-11-10 02:24:03 <iceTwy> ?
232 2013-11-10 02:25:44 <dobry-den> maybe you can try rebuilding from blk*.dats first
233 2013-11-10 02:26:05 <dobry-den> to ensure leveldb isnt in busted state (dunno how it works or if it's applicable, tho)
234 2013-11-10 02:26:43 <iceTwy> nonono
235 2013-11-10 02:26:51 <iceTwy> as recently as 12 days ago
236 2013-11-10 02:26:53 <iceTwy> someone had the issue
237 2013-11-10 02:27:04 <iceTwy> https://github.com/bitcoin/bitcoin/issues/3156
238 2013-11-10 02:27:11 <warren> block index 73824ms
239 2013-11-10 02:27:11 <warren> No coin database inconsistencies in last 2001 blocks (565244 transactions)
240 2013-11-10 02:27:11 <warren> Verifying last 2000 blocks at level 3
241 2013-11-10 02:27:14 <warren> gmaxwell: no errors
242 2013-11-10 02:27:16 <iceTwy> and the fix is here:https://github.com/bitcoin/bitcoin/commit/377cd749308d43bc718cac806a3f8a1710652b0e
243 2013-11-10 02:27:40 <sipa> iceTwy: and are you running with that fix?
244 2013-11-10 02:29:19 <iceTwy> sipa: about to
245 2013-11-10 02:29:27 <iceTwy> adding it in so as to recompile
246 2013-11-10 02:29:44 <sipa> iceTwy: my branch should have it, no?
247 2013-11-10 02:29:51 <iceTwy> sipa
248 2013-11-10 02:29:53 <iceTwy> iunno
249 2013-11-10 02:29:58 <iceTwy> I'll just reclone your branch
250 2013-11-10 02:30:06 <iceTwy> just for the sake of being sure
251 2013-11-10 02:30:10 <sipa> apparently it doesn't have it
252 2013-11-10 02:30:16 <sipa> indeed better to always merge with master
253 2013-11-10 02:30:27 <sipa> there are frequent bugs in it that get fixed quickly
254 2013-11-10 02:30:37 <sipa> gmaxwell: does 0.8.5 do provably pruning?
255 2013-11-10 02:31:02 <sipa> gmaxwell: if we're (again...) seeing a problem because of it, 0.8.5 won't catch it
256 2013-11-10 02:31:58 <iceTwy> sipa: your branch doesn't have it then?
257 2013-11-10 02:32:01 <iceTwy> hm
258 2013-11-10 02:32:03 <iceTwy> guess a patch will do for the moment
259 2013-11-10 02:32:14 <sipa> iceTwy: just merge with master
260 2013-11-10 02:32:19 <sipa> it applies cleanly
261 2013-11-10 02:32:22 <sipa> gmaxwell:
262 2013-11-10 02:32:24 <sipa> 2013-11-10 02:31:52 No coin database inconsistencies in last 289 blocks (117631 transactions)
263 2013-11-10 02:32:27 <sipa> 2013-11-10 02:31:52 block index 24404ms
264 2013-11-10 02:32:32 <iceTwy> sipa: ?
265 2013-11-10 02:32:52 <iceTwy> master of what repo
266 2013-11-10 02:32:55 <sipa> iceTwy: bitcoin
267 2013-11-10 02:33:01 <iceTwy> bitcoin/bitcoin?
268 2013-11-10 02:33:03 <sipa> yes
269 2013-11-10 02:33:09 <iceTwy> hmkay
270 2013-11-10 02:33:11 <iceTwy> I'll try it out
271 2013-11-10 02:33:20 <iceTwy> as for your repo
272 2013-11-10 02:33:27 <iceTwy> should I checkout the watchonly branch
273 2013-11-10 02:33:30 <sipa> yes
274 2013-11-10 02:33:33 <iceTwy> k
275 2013-11-10 02:33:36 <sipa> git checkout watchonly
276 2013-11-10 02:33:42 <sipa> git reset --hard sipa/watchonly
277 2013-11-10 02:33:50 <sipa> git merge upstream/master
278 2013-11-10 02:33:59 <sipa> i'll rebase my branch on master
279 2013-11-10 02:34:36 <sipa> done
280 2013-11-10 02:34:52 <iceTwy> right
281 2013-11-10 03:01:10 <iceTwy> now.. that is odd
282 2013-11-10 03:01:20 <iceTwy> I've just compiled libdb4.8 with c++ support
283 2013-11-10 03:01:36 <iceTwy> linked db_cxx.h to /usr/include
284 2013-11-10 03:01:44 <iceTwy> aaaand wrong version
285 2013-11-10 03:01:58 <iceTwy> (I'm using 4.8.30NC, got it from Oracle's website)
286 2013-11-10 03:03:06 <Luke-Jr> generally it's a bad idea to mess with your rootfs
287 2013-11-10 03:03:54 <iceTwy> it is
288 2013-11-10 03:04:08 <iceTwy> but I'm just linking one file to compile Bitcoin properly
289 2013-11-10 03:04:12 <iceTwy> could remove it after, no probs
290 2013-11-10 03:29:27 <gmaxwell> sipa: hm crud. well I have a git build as of e2130051778 which (again) isn't coming up. I guess I'll look into it in the morning.
291 2013-11-10 04:37:25 <Evilmax> all sleeping?
292 2013-11-10 05:00:30 <BlueMatt> Evilmax: ask. never ask to ask
293 2013-11-10 05:09:04 <Evilmax> BlueMatt
294 2013-11-10 05:09:15 <Evilmax> my bitcoin -server balance
295 2013-11-10 05:09:21 <Evilmax> doesn't refresh
296 2013-11-10 05:10:57 <Evilmax> i asked...
297 2013-11-10 05:36:15 <BlueMatt> Evilmax: in what sense?
298 2013-11-10 05:36:22 <BlueMatt> there are many balances you could be looking for
299 2013-11-10 05:36:30 <BlueMatt> "confirmed" vs "immature" vs "unconfirmed"
300 2013-11-10 05:36:46 <BlueMatt> account balances?
301 2013-11-10 05:47:55 <Evilmax> yes
302 2013-11-10 05:47:58 <Evilmax> account balance
303 2013-11-10 05:48:42 <Evilmax> after more than 8 confirmation....my bitcoind still show old balance
304 2013-11-10 05:49:22 <BlueMatt> does it have peers? does it have the right block count?
305 2013-11-10 05:49:32 <Evilmax> yes
306 2013-11-10 05:49:36 <Evilmax> block updated
307 2013-11-10 05:49:40 <Evilmax> i explain..:
308 2013-11-10 05:49:51 <Evilmax> i run on windows the bitcoin-qt
309 2013-11-10 05:49:55 <Evilmax> in mode -server
310 2013-11-10 05:50:04 <Evilmax> i sent all my btc (0.9)
311 2013-11-10 05:50:07 <Evilmax> on bitstamp
312 2013-11-10 05:50:11 <Evilmax> for exchange them
313 2013-11-10 05:50:25 <Evilmax> but if i do "bitcoind getbalance username"
314 2013-11-10 05:50:31 <Evilmax> it sill show old balance
315 2013-11-10 05:50:39 <Evilmax> username= a user of mine
316 2013-11-10 05:50:51 <Evilmax> instead...the client gui show 0 balance
317 2013-11-10 05:50:54 <Evilmax> why?
318 2013-11-10 05:51:08 <BlueMatt> when you sent the coins, they were sent from the default account
319 2013-11-10 05:51:24 <BlueMatt> so that account has positive balance, the default account has negative balance
320 2013-11-10 05:51:27 <BlueMatt> in total, its 0
321 2013-11-10 05:51:44 <Evilmax> what i have to do...to get user balances updated?
322 2013-11-10 05:51:46 <Evilmax> then?
323 2013-11-10 05:51:55 <Belxjander> Evilmax: each "Address" is a seperate wallet or storage... the wallet on your computer saw the transfer of funds to the BitStamp wallet and now they are outside what it is looking at on the blockchain
324 2013-11-10 05:51:56 <BlueMatt> bitcoind's accounts feature does not handle sends from bitcoin-qt well
325 2013-11-10 05:52:09 <Evilmax> maybe next time i have to send btc from every user balance?
326 2013-11-10 05:52:30 <BlueMatt> if you do getbalance without the user, what does it show?
327 2013-11-10 05:52:41 <Evilmax> it shows old balance
328 2013-11-10 05:52:53 <Evilmax> 0.9 were divided in various users
329 2013-11-10 05:53:01 <Evilmax> i sent btc from qt client
330 2013-11-10 05:53:06 <Evilmax> not from every single user
331 2013-11-10 05:53:08 <Evilmax> of course
332 2013-11-10 05:53:21 <BlueMatt> well, there should be a negative balance on one of the accounts that offsets the rest
333 2013-11-10 05:53:25 <Evilmax> it would show 0 balance for every users
334 2013-11-10 05:53:35 <BlueMatt> using bitcoind's accounts feature in combination with bitcoin-qt will break things
335 2013-11-10 05:53:48 <Evilmax> excuseme
336 2013-11-10 05:53:53 <Evilmax> maybe next time i have to send btc from every user balance???
337 2013-11-10 05:53:54 <BlueMatt> and since no one really uses the accounts feature, no one has bothered to fix it
338 2013-11-10 05:54:31 <BlueMatt> if you want to get them all to show 0, yes, youd have to do that...but you'd create a transaction each time and thus pay more in fees and wait longer for confirms
339 2013-11-10 05:54:35 <Evilmax> i am ussing server mode and account futures because my bitcoind is hosted on a site
340 2013-11-10 05:54:37 <BlueMatt> there really isnt a way to win this
341 2013-11-10 05:54:42 <Evilmax> i have done a walet online
342 2013-11-10 05:54:45 <Evilmax> wallet
343 2013-11-10 05:55:00 <Evilmax> next time i will try to send btc from single account
344 2013-11-10 05:55:20 <BlueMatt> yea, you probably just want to manage accounts yourself and let bitcoind just use the default account
345 2013-11-10 05:55:26 <Evilmax> but i was afraid...because value of btc tonight is fall downn again
346 2013-11-10 05:55:32 <BlueMatt> it'll save you trouble
347 2013-11-10 05:55:45 <Evilmax> the only important thing is that...my users will not get erroneus balance
348 2013-11-10 05:56:07 <BlueMatt> well short modifying your wallet by hand, there is little you can do to fix it
349 2013-11-10 05:56:15 <Evilmax> surely all will work because they do it inside their single accounts
350 2013-11-10 05:56:35 <Evilmax> how i can modify it "by hand"?
351 2013-11-10 05:56:53 <BlueMatt> maybe use bitcointools, but you'd probably have to modify bitcointools to do it right
352 2013-11-10 05:57:11 <Evilmax> bitcoin tools?
353 2013-11-10 05:57:17 <Evilmax> what do you mean?
354 2013-11-10 05:57:25 <BlueMatt> https://github.com/gavinandresen/bitcointools
355 2013-11-10 05:57:45 <Evilmax> i ll take a look...
356 2013-11-10 06:00:25 <gavinandresen> Evilmax: listaccounts will tell you balances for all of the accounts. If balances are incorrect because you did a send from bitcoin-qt, you can use the 'move' command to adjust them.
357 2013-11-10 06:00:49 <Evilmax> now i tryed to send from that account...it says "insufficient funds" but still show old balance
358 2013-11-10 06:00:51 <Evilmax> bah!
359 2013-11-10 06:01:07 <Evilmax> yes
360 2013-11-10 06:01:09 <BlueMatt> oh, I forgot we had a move command
361 2013-11-10 06:01:19 <Evilmax> surely because i sent from client gui, from general client gui
362 2013-11-10 06:01:30 <Evilmax> anyway it is a bug, no?
363 2013-11-10 06:02:26 <gmaxwell> Oh great. Apparently blockchain.info subtracts some multiple of the txfee it uses from the user's balance, so they still have coins when it shows zero... thats gotta be great for the utxo set long term.
364 2013-11-10 06:02:39 <gavinandresen> yes, it surely is a bug. The bitcoind accounts feature and bitcoin-qt don't play well together.
365 2013-11-10 06:02:51 <Evilmax> "bitcoind listaccounts" shows all received, not the balance
366 2013-11-10 06:03:12 <Evilmax> otherwise i would be rich now!
367 2013-11-10 06:03:15 <BlueMatt> gmaxwell: hope to god they clean up their utxo set with a big claim tx at some point...
368 2013-11-10 06:03:21 <Evilmax> i moved more thann 1500 btc
369 2013-11-10 06:03:29 <BlueMatt> Evilmax: some of the accounts should have negative balances, no?
370 2013-11-10 06:03:34 <Evilmax> no
371 2013-11-10 06:03:35 <Evilmax> no one
372 2013-11-10 06:03:37 <gavinandresen> Evilmax: really? that would be another bug. Sum of balances in listaccounts should equal the wallet balance
373 2013-11-10 06:04:15 <Luke-Jr> BlueMatt: blockchain.info doesn't have control over their users' keys :/
374 2013-11-10 06:04:19 <Evilmax> i use qt 4.8.3: it is bugged?
375 2013-11-10 06:04:32 <Luke-Jr> Evilmax: I doubt Qt is at fault for this
376 2013-11-10 06:04:33 <gavinandresen> the move RPC command just adjusts account balances, it doesn't send bitcoins anywhere.
377 2013-11-10 06:04:42 <BlueMatt> Luke-Jr: oh...great
378 2013-11-10 06:04:48 <phantomcircuit> Evilmax, have you paid your own addresses?
379 2013-11-10 06:04:56 <Evilmax> paid?
380 2013-11-10 06:05:26 <phantomcircuit> have you created a transactions which uses inputs in your wallet and can be spent by private keys in your wallet
381 2013-11-10 06:05:34 <gmaxwell> BlueMatt: they can't, since the utxo are in users wallets which they could only access by cracking the keys... at least if the users abandon them because their balance is zero..
382 2013-11-10 06:05:40 <Evilmax> i run qt in server mode on windows...and a bitcoin site on linux...it perform command through lan by using curl
383 2013-11-10 06:06:05 <Evilmax> on linux site...balance are still the old ones
384 2013-11-10 06:06:10 <BlueMatt> gmaxwell: well, great
385 2013-11-10 06:06:20 <Evilmax> on qt client (windows) al works well
386 2013-11-10 06:06:38 <Evilmax> but if i check daemon in prompt (windows) still it show incorrect balance
387 2013-11-10 06:06:40 <gmaxwell> BlueMatt: they could have the wallet do a dust-be-gone when it gets to zero.
388 2013-11-10 06:06:42 <Evilmax> balances
389 2013-11-10 06:06:57 <BlueMatt> gmaxwell: yea, they need to do that
390 2013-11-10 06:07:09 <Evilmax> in win prompt, of course, i do not use curl...but simply "bitcoind" command
391 2013-11-10 06:07:12 <gmaxwell> petertodd: ^ make it so.
392 2013-11-10 06:07:26 <Evilmax> i don't know...
393 2013-11-10 06:07:41 <BlueMatt> gmaxwell: wait, petertodd has control over bc.i?
394 2013-11-10 06:09:19 <gmaxwell> BlueMatt: he's caused them to make more changes than anyone else I know.
395 2013-11-10 06:09:34 <gmaxwell> they sure as heck don't listen to me!
396 2013-11-10 06:09:49 <BlueMatt> hmm, fun
397 2013-11-10 06:09:55 <BlueMatt> yea, I know they generally dont listen to much that comes out of here
398 2013-11-10 06:10:31 <phantomcircuit> in related news
399 2013-11-10 06:10:38 <phantomcircuit> i broke their shitty captcha
400 2013-11-10 06:10:43 <phantomcircuit> can you say
401 2013-11-10 06:10:49 <phantomcircuit> free key/value database???
402 2013-11-10 06:17:08 <phantomcircuit> lol
403 2013-11-10 06:17:09 <phantomcircuit> reason = "mucho-data";
404 2013-11-10 06:17:11 <phantomcircuit> really guys
405 2013-11-10 06:17:28 <phantomcircuit> jgarzik, :)
406 2013-11-10 06:23:53 <warren> hmm, p2pool is stuck at 2% of both BTC and LTC's network. I wonder why it is there in particular.
407 2013-11-10 06:24:25 <Polyatomic> bitcoind 0.8.5 Question(Windows): Is it possible to do move <all> <toaccount> <amount> from command prompt ?.
408 2013-11-10 06:25:08 <BlueMatt> Polyatomic: use a shell that has support for loops?
409 2013-11-10 06:27:59 <Polyatomic> All the balances are incorrect , so I do not know how much is really in the accounts.
410 2013-11-10 06:50:45 <warren> Is it possible for a regular tx to be an input to supplement the coinbase tx?
411 2013-11-10 06:51:09 <warren> Thinking of ways to further incent decentralized mining...
412 2013-11-10 06:53:00 <Luke-Jr> warren: no
413 2013-11-10 06:53:36 <warren> Luke-Jr: would that be a reasonable idea for a long distant hardfork?
414 2013-11-10 06:53:59 <Luke-Jr> warren: maybe.
415 2013-11-10 06:54:08 <Luke-Jr> probably not very important though.
416 2013-11-10 06:54:25 <warren> oh. the fee does supplement the coinbase tx.
417 2013-11-10 06:54:44 <Luke-Jr> yes, but you can't stop other miners from stealing it
418 2013-11-10 06:54:54 <warren> crap ... especially for p2pool
419 2013-11-10 06:54:58 <Luke-Jr> 50 BTC fee? great, let's risk replacing them..
420 2013-11-10 06:55:02 <warren> a non-p2pool pool could grab it
421 2013-11-10 06:55:55 <warren> the bigger problem will be figuring out how to incent relaying
422 2013-11-10 07:02:30 <lachesis> are there any bitcoin clients that (a) implement the full security model, (b) don't retain the full transaction history (the parts that are only required for bootstrapping other clients), and (c) support deterministic wallets?
423 2013-11-10 07:03:59 <maaku> lachesis:
424 2013-11-10 07:04:01 <maaku> lachesis: no
425 2013-11-10 07:04:33 <maaku> there are no other clients which can be said with confidence to implement "the full security model"
426 2013-11-10 07:04:45 <maaku> bug-for-bug compatability with bitcoind
427 2013-11-10 07:05:16 <maaku> not sure your context, but probabably best to use another wallet connected to bitcoind for validation
428 2013-11-10 07:06:32 <warren> lachesis: bitcoin itself will eventually have pruning, which allows fully verifying nodes to discard old blocks
429 2013-11-10 07:06:57 <lachesis> warren, is that targeted for a particular release?
430 2013-11-10 07:07:19 <warren> lachesis: I don't know for bitcoin. litecoin is attempting that for 0.9, or at least prototyping it.
431 2013-11-10 07:24:47 <warren> phantomcircuit: I'm seeing weird behavior after the processgetdata patch
432 2013-11-10 07:24:57 <warren> phantomcircuit: not incorrect behavior, just weird log spam
433 2013-11-10 07:54:10 <phantomcircuit> warren, like what?
434 2013-11-10 07:55:34 <warren> phantomcircuit: are you seeing incremental getblocks from peers, and a great many instances where all peers are sending blocks you already have? might be a coincidence ...
435 2013-11-10 07:57:36 <phantomcircuit> hmm no
436 2013-11-10 08:04:00 <phantomcircuit> warren, the node i have running master has a bunch of other stuff so give me a few to builda clean one
437 2013-11-10 08:05:46 <Evilmax> nothing to do
438 2013-11-10 08:05:52 <Evilmax> i am not able to resolve this issue
439 2013-11-10 08:08:17 <phantomcircuit> Evilmax, what's the problem?
440 2013-11-10 08:08:39 <Evilmax> bitcoin balance
441 2013-11-10 08:08:58 <phantomcircuit> Evilmax, write a more complete description
442 2013-11-10 08:10:16 <Evilmax> i have a qt client on windows in server mode...then, on linux, through lan, i use curl for control some accounts of the bitcoind daemon...i sent all my btc, that were distribuited on several accounts, from my qt client...where now balance is 0. But on linux bitcoind account thare are still old balances
443 2013-11-10 08:11:10 <Evilmax> and if i ask balance to daemon by use windows prompt shell...it alway tell me that some account have still bitcoins
444 2013-11-10 08:11:33 <Evilmax> i want get updated balance on every accounts
445 2013-11-10 08:11:40 <Evilmax> that is 0, zero
446 2013-11-10 08:12:14 <phantomcircuit> Evilmax, listaccounts
447 2013-11-10 08:12:20 <Evilmax> done
448 2013-11-10 08:12:26 <Evilmax> it shows old balances
449 2013-11-10 08:12:27 <phantomcircuit> that will probably show some positive and negative accounts
450 2013-11-10 08:12:47 <phantomcircuit> Evilmax, do you have two clients running?
451 2013-11-10 08:12:50 <Evilmax> no, only positive...and does not show balances but all received
452 2013-11-10 08:12:59 <Evilmax> nno, just one in server mode on windows
453 2013-11-10 08:13:12 <Polyatomic> phantomcircuit: will listaccounts show immature balances.
454 2013-11-10 08:13:14 <phantomcircuit> so what about the linux box?
455 2013-11-10 08:13:19 <Evilmax> i connect daemon (qt in server mode) from a linux in the lan
456 2013-11-10 08:13:26 <phantomcircuit> Polyatomic, by default no
457 2013-11-10 08:13:30 <Evilmax> linux box only host a site
458 2013-11-10 08:13:41 <Evilmax> that ask to daemon on windows
459 2013-11-10 08:13:45 <phantomcircuit> Evilmax, oh you're the guy we warned not to use the accounts feature
460 2013-11-10 08:13:49 <Evilmax> through curl command
461 2013-11-10 08:13:49 <phantomcircuit> yeah im out gl with that
462 2013-11-10 08:14:09 <Evilmax> but i need to use account futures
463 2013-11-10 08:14:17 <Evilmax> because the site on linux
464 2013-11-10 08:14:22 <Apocalyptic> as phantomcircuit said, people should make their own accounting overlay
465 2013-11-10 08:14:25 <Evilmax> it's an online wallet
466 2013-11-10 08:14:35 <Apocalyptic> don't rely on the wallet's one
467 2013-11-10 08:14:43 <phantomcircuit> Apocalyptic, it's pointless he's never going to listen to us
468 2013-11-10 08:15:01 <phantomcircuit> Evilmax, you might as well just sell your bitcoins and burn the cash
469 2013-11-10 08:15:11 <Evilmax> no
470 2013-11-10 08:15:16 <Evilmax> i host a service
471 2013-11-10 08:15:23 <Apocalyptic> so do I
472 2013-11-10 08:15:28 <Evilmax> let me use the translator, pls
473 2013-11-10 08:15:31 <Apocalyptic> why don't you write your own accounting system ?
474 2013-11-10 08:15:58 <Evilmax> guys, I do not want to preach, but only explanations
475 2013-11-10 08:16:08 <Apocalyptic> that gets notified on each received block and does the changes related to incoming transactions
476 2013-11-10 08:16:15 <Alina-malina> Hello all! I am newbiew trying to understand bitcoin source code, please tell me what kind of technic it uses inside beside multithreading what kind of database modules it uses to intaract with the 8 gig database file?
477 2013-11-10 08:16:15 <Evilmax> guys, I do not want sermons, but only explanations
478 2013-11-10 08:16:31 <Evilmax> if you can
479 2013-11-10 08:16:41 <Evilmax> only answer my questions pls
480 2013-11-10 08:17:33 <warren> Evilmax: the accounts feature within bitcoin-qt needs to be removed.
481 2013-11-10 08:17:34 <phantomcircuit> lol
482 2013-11-10 08:17:37 <warren> Evilmax: it sucks
483 2013-11-10 08:17:44 <warren> Evilmax: and nobody will fix it
484 2013-11-10 08:18:05 <warren> Evilmax: the major services wrote their own accounting system that bypasses the bitcoin wallet entirely
485 2013-11-10 08:18:10 <Evilmax> everyone said "but no! impossible ... you have to use jscript"
486 2013-11-10 08:18:10 <Evilmax> in the channel of the php ... wondering how to get one thing just using php
487 2013-11-10 08:18:10 <Evilmax> Well I obtained it using php only!
488 2013-11-10 08:19:09 <Evilmax> because i need to use the server...the daemon...but i like to have gui too
489 2013-11-10 08:19:45 <Evilmax> about php...it was a simple slider box of images
490 2013-11-10 08:19:50 <Evilmax> i used php+css
491 2013-11-10 08:19:54 <Evilmax> no jscript
492 2013-11-10 08:21:14 <warren> ACTION sets ignore.
493 2013-11-10 08:22:48 <Evilmax> "the major services wrote their own accounting system that bypasses the bitcoin wallet entirely" good info
494 2013-11-10 08:22:50 <Evilmax> tnx
495 2013-11-10 08:23:06 <Evilmax> at least you said something usefull
496 2013-11-10 08:25:38 <Apocalyptic> haha warren
497 2013-11-10 08:26:49 <Evilmax> Apocalyptic
498 2013-11-10 08:27:02 <Evilmax> what do you mean for "my own accounting system"?
499 2013-11-10 08:28:11 <Apocalyptic> create your own database/file/whatever to store bitcoin amounts you receive
500 2013-11-10 08:28:40 <Evilmax> but it has alway to interact with daemon?
501 2013-11-10 08:28:45 <Evilmax> always
502 2013-11-10 08:28:50 <Apocalyptic> sure it has
503 2013-11-10 08:29:23 <Apocalyptic> otherwise where do you get the info from .
504 2013-11-10 08:29:37 <Evilmax> sorry i do not understand what you mean...you say that i have to create a database file similar to that one i can find in bitcoin directory?
505 2013-11-10 08:29:56 <Evilmax> yes?
506 2013-11-10 08:30:15 <Apocalyptic> not at all...
507 2013-11-10 08:30:44 <Evilmax> consider that i do not know bitcoin source etc
508 2013-11-10 08:31:06 <Evilmax> in this momennt i just use some bitcoind command like getbalance, sendfrom etc
509 2013-11-10 08:31:31 <Evilmax> explain better please, let me understand
510 2013-11-10 08:31:38 <Evilmax> i thank you for this
511 2013-11-10 08:31:55 <Evilmax> db file...a txt?
512 2013-11-10 08:39:50 <swulf--> Hey, I'm not getting much feedback on the forums, so I was wondering if anyone in here had a few minutes to check out and test my new site? http://ms-brainwallet.github.io/
513 2013-11-10 08:40:29 <wumpus> Alina-malina: the databases used are leveldb for the block chain database, berkelydb (currently) for the wallet
514 2013-11-10 08:40:47 <nox404> hi guys !
515 2013-11-10 08:40:50 <gmaxwell> swulf--: oh why oh why are you calling it *brainwallet?
516 2013-11-10 08:41:10 <nox404> QT is giving me some "cryptic" error
517 2013-11-10 08:41:14 <swulf--> gmaxwell: maybe a misnomer at this point, but the idea was that one of the keys would come from brainwallet.org
518 2013-11-10 08:41:29 <swulf--> gmaxwell: I posted a thread describing the motivation for it in project development
519 2013-11-10 08:41:33 <Apocalyptic> utterly bad idea
520 2013-11-10 08:41:44 <gmaxwell> your example is using uncompressed keys which is lame.
521 2013-11-10 08:41:45 <nox404> who to report ?
522 2013-11-10 08:41:58 <gmaxwell> swulf--: thats nailing the poor users with high transaction fees. :P
523 2013-11-10 08:41:58 <swulf--> gmaxwell: easy to fix, point noted
524 2013-11-10 08:42:36 <swulf--> Most transactions should remain under 1kb in size, keeping the tx fee <0.0002 (if my math was correct?)
525 2013-11-10 08:42:58 <swulf--> it's also just proof-of-concept and "beta", so these critiques are good
526 2013-11-10 08:43:53 <gmaxwell> swulf--: the general problem there is that addresses are created today, spent from tomorrow, fees may be higher tomorrow, better to be conservative since it costs you nothing.
527 2013-11-10 08:44:04 <swulf--> Sure, makes sense
528 2013-11-10 08:44:11 <swulf--> Is it better to use compressed pubkeys in the subscript, then?
529 2013-11-10 08:44:19 <swulf--> knocks off 32*3 bytes
530 2013-11-10 08:44:24 <gmaxwell> yea, always use compressed pubkeys.
531 2013-11-10 08:44:33 <swulf--> ok, added to the TODO list
532 2013-11-10 08:45:09 <gmaxwell> swulf--: as far as the brainwallet.org thing, I'm sure you've seen my many complaints about that. People have very low success rates at using it safely.
533 2013-11-10 08:45:34 <gmaxwell> Plus its just bad software.. if you were to use a brainwallet (still a bad idea) it should have a computationally expensive KDF not .... sha256.
534 2013-11-10 08:45:40 <swulf--> right, part of my motivation for this was .. well, perhaps you could quickly skim my post?
535 2013-11-10 08:45:51 <gmaxwell> link to post
536 2013-11-10 08:45:54 <swulf--> https://bitcointalk.org/index.php?topic=325468
537 2013-11-10 08:46:12 <swulf--> one of the keys ought to be completely randomly generated for you by some bitcoin software, using SSL and a good RNG
538 2013-11-10 08:46:33 <swulf--> then combined with a brainwallet key in a multisig transaction, you can feel a bit safer about not having a strong-enough brainwallet passphrase
539 2013-11-10 08:46:35 <gmaxwell> thats a nice idea.
540 2013-11-10 08:47:17 <gmaxwell> though ... no excuse for not using a good kdf on the human provided side. Also, the fact that its a single address is less good.
541 2013-11-10 08:47:42 <swulf--> well... yeah
542 2013-11-10 08:47:58 <gmaxwell> More awesome would be a spec that had three BIP32 seeds and made a swulf-three-key wallet instead of a swulf-three-key-address.
543 2013-11-10 08:48:14 <swulf--> hmmm
544 2013-11-10 08:48:32 <swulf--> interesting, I'm only vaguely familiar with bip32
545 2013-11-10 08:48:33 <gmaxwell> (then using your scheme wouldn't force people into constant address reuse)
546 2013-11-10 08:48:48 <swulf--> right, because once you spend from my current scheme you shouldn't ever send back to it
547 2013-11-10 08:49:07 <gmaxwell> it's just a way to get infinite keys from a single seed ... with a lot of special features... like being able to derrive new pubkeys without having the private keys.
548 2013-11-10 08:49:20 <gmaxwell> meaning in your three way scheme you could keep generating keys for the private data you have offline.
549 2013-11-10 08:49:31 <swulf--> if that seed is ever compromised you're in trouble
550 2013-11-10 08:49:48 <gmaxwell> swulf--: no more than in your scheme plus address reuse.
551 2013-11-10 08:50:04 <swulf--> if the seed was only for pubkey1 and you still used a different scheme for pubkey2, then it'd be ok?
552 2013-11-10 08:51:12 <gmaxwell> swulf--: I'd assume you'd have three seeds.. one for the pubkey1s one for the pubkey2s.. one for the pubkey3s.. the security is the same as your scheme, but without the forced address reuse.
553 2013-11-10 08:51:33 <swulf--> right
554 2013-11-10 08:52:00 <swulf--> (I assumed brainwallet people would have some "seed" like appending an incrementing number), but integrating something like that would be more convenient
555 2013-11-10 08:52:18 <gmaxwell> the other issue your idea has is redeemscript preservation. say you forget the backuped key but have the brain and online.. how do you recover the redeem script? assume the online has it?
556 2013-11-10 08:52:32 <swulf--> I assume you can always rebuild it
557 2013-11-10 08:52:44 <swulf--> but not if you forget one of the keys, huh?
558 2013-11-10 08:52:47 <gmaxwell> how can you rebuild it if you've lost one of the keys? yea..
559 2013-11-10 08:52:50 <swulf--> damn
560 2013-11-10 08:53:17 <gmaxwell> swulf--: well the increment thing requires you to have the private data handty to increment which is kinda lame.. bip32 gives you a way to increment the pubkey without having the private key.
561 2013-11-10 08:53:27 <swulf--> oh, cool.
562 2013-11-10 08:53:37 <swulf--> Didn't know that's what bip32 was about, but it makes sense
563 2013-11-10 08:54:02 <gmaxwell> Thats one of its features. (it can create keys which either have that property or not)
564 2013-11-10 08:54:13 <gmaxwell> swulf--: obviously the backup and online can have the redeemscript.. and I guess thats enough since you're 2 of 3.
565 2013-11-10 08:54:47 <swulf--> yeah, and it doesn't really hurt your security *that* much if the keys are found, so you could email them to yourself and/or keep a copy online somewhere
566 2013-11-10 08:54:52 <gmaxwell> in the case of doing the bip32 based thing you'd have a 'meta redeemscript' which tells you how to build the per address redeemscripts.
567 2013-11-10 08:54:55 <swulf--> s/keys/redeemscript
568 2013-11-10 08:55:11 <swulf--> ah, cool.
569 2013-11-10 08:56:14 <swulf--> then you could just paste in your redeemscript (which extracts the seed pubkeys) instead of pasting in three different seeds
570 2013-11-10 08:56:16 <swulf--> ?
571 2013-11-10 08:58:10 <gmaxwell> yep. might be better to call it something other than redeemscript though, "master redeemscript"
572 2013-11-10 08:58:27 <gmaxwell> I suggest you go read and internalize BIP32. :)
573 2013-11-10 08:59:00 <swulf--> I will, thanks!
574 2013-11-10 08:59:19 <swulf--> I gotta run, thanks for reviewing the site and providing feedback.
575 2013-11-10 09:05:24 <warren> https://bitcointalk.org/index.php?topic=329860 Litecoin Dev donated $2,000 to p2pool development. We need decentralized mining to grow much larger in order to protect Bitcoin network security in the long-term. Please consider supporting p2pool with an added donation.
576 2013-11-10 09:10:18 <gmaxwell> warren: you might want to drop a post in this thread: https://bitcointalk.org/index.php?topic=303046.0
577 2013-11-10 09:13:27 <warren> gmaxwell: I know others have differing opinions. I think earlier donations to incent miners to stick to p2pool were well intentioned, but p2pool needs more technical work in order to comfortably accomodate those miners. As it stands now the documentation and UI sucks, exacerbating the confusion pertaining to rejects being expected. If major improvements are made to both reduce confusion and also reduce real orphan/DOA across the network then
578 2013-11-10 09:13:27 <warren> it can scale much larger without one-time incentive donations.
579 2013-11-10 09:13:39 <warren> gmaxwell: btw, would you like to have access to edit the brainstorming doc?
580 2013-11-10 09:19:55 <gmaxwell> warren: it was very successful the first time we did it with p2pool and basically grew it 10 fold.
581 2013-11-10 09:20:06 <gmaxwell> And yea, sure, I agree docs and ui and such need to improve.
582 2013-11-10 09:20:18 <gmaxwell> esp since it gives a lot of stats which are normal and harmless which people misread as concerning.
583 2013-11-10 09:20:39 <midnightmagic> warren: What do you mean here: "and also reduce real orphan/DOA across the network"?
584 2013-11-10 09:21:20 <gmaxwell> warren: I believe that bitcoin p2pool has the lowest orphan rate of any bitcoin pool big enough to measure it for.
585 2013-11-10 09:21:31 <warren> that's share orphan
586 2013-11-10 09:21:34 <gmaxwell> I think it's had just two orphan blocks since march or something like that.
587 2013-11-10 09:21:42 <gmaxwell> warren: ah.
588 2013-11-10 09:22:02 <warren> Through various means, if share rejects can be reduced p2pool can naturally grow larger.
589 2013-11-10 09:22:44 <warren> there is some low hanging fruit in propagation latency improvement
590 2013-11-10 09:22:56 <warren> likely compatible with the existing version 13 protocol
591 2013-11-10 09:23:08 <warren> other changes would require a hardfork I think
592 2013-11-10 09:23:22 <midnightmagic> p2pool'ers eat up hardforks as a matter of course.
593 2013-11-10 09:30:15 <gmaxwell> warren: I ... don't see why you think that.
594 2013-11-10 09:30:33 <warren> gmaxwell: I actually measured it.
595 2013-11-10 09:30:43 <warren> gmaxwell: it's tiny I know
596 2013-11-10 09:30:47 <gmaxwell> Measured what?
597 2013-11-10 09:30:56 <warren> gmaxwell: wiat, why I think what?
598 2013-11-10 09:31:01 <gmaxwell> 01:22 < warren> Through various means, if share rejects can be reduced p2pool can naturally grow larger.
599 2013-11-10 09:31:04 <gmaxwell> 01:22 < warren> Through various means, if share rejects can be reduced p2pool can naturally grow larger.
600 2013-11-10 09:31:50 <warren> gmaxwell: people quit for irrational reasons. share orphan/DOA increases as the network grows in size. at some point people are uncomfortable with it and they quit.
601 2013-11-10 09:31:57 <gmaxwell> ...
602 2013-11-10 09:32:23 <gmaxwell> Then stop @#$@# calling it orphan/doa and instead focus on the efficiency metric.
603 2013-11-10 09:32:29 <warren> gmaxwell: all those people bragging about > 100% efficiency in the p2pool thread is at the expense of someone
604 2013-11-10 09:33:02 <gmaxwell> user misunderstanding can't be fixed by twiddling the network.
605 2013-11-10 09:33:53 <warren> it's different ways of improving the problem
606 2013-11-10 09:33:59 <gmaxwell> And a 30 second sharechain is going to have a non-trivial amount of stales, it's unavoidable.
607 2013-11-10 09:34:36 <gmaxwell> warren: changing how the network works for that reason is hard and risky, it is bad engineering to change how something works on the basis of misunderstandings.
608 2013-11-10 09:35:10 <warren> gmaxwell: the misunderstanding is orthogonal to techncal ways of enabling greater scaling.
609 2013-11-10 09:35:19 <gmaxwell> warren: it can scale fine.
610 2013-11-10 09:35:35 <warren> yes, we've been debating this since .. March... and it doesn't
611 2013-11-10 09:35:50 <warren> it always gets stuck at a certain size
612 2013-11-10 09:36:00 <gmaxwell> warren: You've been telling people not to use p2pool since you discovered it.
613 2013-11-10 09:36:26 <gmaxwell> warren: because you don't understand it yourself and you're particularly vulnerable to obsessing over the states, as far as I can tell.
614 2013-11-10 09:36:29 <warren> gmaxwell: that isn't entirely true.
615 2013-11-10 09:36:41 <warren> gmaxwell: you're being quite rude.
616 2013-11-10 09:37:23 <warren> gmaxwell: I'm realistic when it comes to its limitations. Fixing the confusion problem alone will not allow it to scale much larger.
617 2013-11-10 09:37:35 <gmaxwell> warren: P2pool is currently around the same size eligius was six months ago and had been 'stuck' at for a year. It finally broke out of that when many of the larger pools got DOSed.
618 2013-11-10 09:38:07 <gmaxwell> warren: I've actually seen very little evidence of realism from you on the subject. I've seen a lot of confusion and FUD.
619 2013-11-10 09:40:06 <gmaxwell> warren: the things p2pool does are roughly constant load regardless of the hashrate. This is also supported by the fact that although its hashrate has grown from 6 TH/s some months ago to now 50 TH/s its still behaving pretty much the same.
620 2013-11-10 09:40:09 <warren> gmaxwell: I believe that fixing the confusion issue to the maximum extent will not allow it scale much more. The network-wide orphan/DOA rate escalates whenever it does.
621 2013-11-10 09:41:27 <gmaxwell> I don't know why you're saying that it escilates, considering that p2pool has had roughly constant stale/ophan rates with an order of magnitude change in hashrate, .... but moreover, beyond people getting confused by poorly presented stats, I don't see why you think the share orphan/doa rate matters?
622 2013-11-10 09:42:25 <warren> We're still stuck in the same debate, and I simply disagree.
623 2013-11-10 09:42:37 <gmaxwell> This isn't a matter of opinion, you know?
624 2013-11-10 09:43:40 <sipa> If the orphan/doa rate on the sharechain grows very large, it becomes a problem as it impacts variance on payouts.
625 2013-11-10 09:43:45 <warren> gmaxwell: I would also call it inaccurate that I've been warning people away from p2pool. I did at times when it was incapable of supporting ASIC's comfortably (which was fixed thanks in part to us.) I also warned LTC users away from it until dust reduction locked into protocol 13.
626 2013-11-10 09:46:54 <gmaxwell> warren: when you started asking people not to use it p2pool was a supermajority of LTC's hashrate. It's 2% now.
627 2013-11-10 09:47:19 <warren> gmaxwell: it never was a supermajority of LTC's hashrate, not even close, I have no idea where that rumor came from.
628 2013-11-10 09:49:24 <warren> gmaxwell: when I started using p2pool Litecoin had a nearly 50% centralized pool (notroll.in) that later died after a payout bug bankrupted the owner. Other huge centralized pools (wemine, giveme, coinotron, litecoinpool, ltcmine.ru) filled the vacuum.
629 2013-11-10 09:49:48 <warren> p2pool was barely a blip on the radar
630 2013-11-10 09:49:55 <gmaxwell> The orphan/doa rate does not increase. :(
631 2013-11-10 09:49:56 <gmaxwell> http://people.xiph.org/~greg/p2pstale.png
632 2013-11-10 09:50:04 <gmaxwell> This is something any p2pool node can show you.
633 2013-11-10 09:51:19 <gmaxwell> The bottom graph is the proportional one.
634 2013-11-10 09:52:40 <Polyatomic> The client is reporting 18 %
635 2013-11-10 09:54:36 <warren> sigh. my tiny research miner just burned out.
636 2013-11-10 09:54:43 <gmaxwell> Polyatomic: 6+8 = 14, thats a month scale graph so it has a lot of time averaging.
637 2013-11-10 09:54:56 <gmaxwell> Polyatomic: the most recent number swings around a fair bit.
638 2013-11-10 09:56:28 <Polyatomic> Yeah man , Im pro p2pool.
639 2013-11-10 09:58:32 <warren> gmaxwell: perhaps my guesses as to why people too easily quit p2pool are wrong. In any case forrestv seems to like some ideas to help it scale bigger. Whatever he decides is a good idea we'll follow.
640 2013-11-10 09:59:02 <midnightmagic> warren: Is there some place where these ideas are presented and I can read them?
641 2013-11-10 09:59:08 <warren> midnightmagic: yes
642 2013-11-10 09:59:24 <warren> midnightmagic: https://bitcointalk.org/index.php?topic=329860 linked in that doc, anyone can comment in the doc or reply in the thread.
643 2013-11-10 10:00:56 <gmaxwell> warren: yea, sure improving it is fine and ducky, no objection from me on that. But I would expect that the bariers are resource usage, and education ... and the cost of running bitcoind.
644 2013-11-10 10:01:00 <midnightmagic> warren: I would think just reducing average variance of the doa/orphans would be enough, but the mining devices themselves have a lot to do with that
645 2013-11-10 10:01:22 <gmaxwell> midnightmagic: there are things other than fixing the devices that could probably be done to reduce mining variance.
646 2013-11-10 10:02:38 <warren> gmaxwell: we offered to sponsor petertodd in implementing the final pieces of pruning for fully verifying nodes, he's a bit too busy now though.
647 2013-11-10 10:02:46 <warren> (re: cost of running bitcoind)
648 2013-11-10 10:03:00 <gmaxwell> warren: incidentally it was you that told me that "majority of litecoin's UXTO are actually from p2pool" which furthered my prior belief that p2pool was the largest ltc pool (due to the centeralized ones dos attacking each other, and otherwise being shady)
649 2013-11-10 10:03:35 <warren> gmaxwell: it was true, p2pool had lots of blocks/day and approaching 1,000 txo per block
650 2013-11-10 10:04:21 <warren> but "lots" is relative
651 2013-11-10 10:04:42 <warren> gmaxwell: back then p2pool had 30 blocks/day. now it's like 10.
652 2013-11-10 10:06:37 <warren> gmaxwell: after p2pool protocol 13 it seems UTXO growth stopped and even reversed a bit as dust combines at a rate faster than it is created.
653 2013-11-10 10:08:23 <gmaxwell> did your wallet software ever change so that it stopped simply forever ignoring tiny payments?
654 2013-11-10 10:10:40 <warren> how is this relevant?
655 2013-11-10 10:11:05 <gmaxwell> it was just wrt "dust combines" comment.
656 2013-11-10 10:11:42 <warren> That patch was added well before my involvement and it just wasn't changed.
657 2013-11-10 10:12:37 <gmaxwell> warren: in any case, sorry for flaming you there. I was, and continue to be really irritated about cases where I think you chased people off p2pool for unfair reasons which were not supported by the data available to me. I think it materially set back p2pool, but on that point I only have opinion, not data, I felt like I had to constantly watch the channel for a span of time because when I didn't you were frequently telling yet another ...
658 2013-11-10 10:12:43 <gmaxwell> ... person to not even try it. I don't generally hold grudges, but when you were saying the same stuff again you ruffled my feathers.
659 2013-11-10 10:13:01 <gmaxwell> warren: oh I wasn't blaming you for it! I was wondering if it got removed if dust was actually getting combined.
660 2013-11-10 10:13:20 <gmaxwell> warren: e.g. you said dust was getting confined and I thought "oh did warren remove that patch".
661 2013-11-10 10:15:04 <warren> gmaxwell: prior to p2pool-13 it was a confusing wreck as ASIC miners tried and failed to use it.
662 2013-11-10 10:15:35 <warren> Yes, I acknoledge the point that technically they could have used it with massive DOA if they only accepted that is normal.
663 2013-11-10 10:15:40 <gmaxwell> warren: prior to asic miners existing you were directing people not to use it. Shall I paste logs?
664 2013-11-10 10:15:52 <warren> gmaxwell: for what reasons?
665 2013-11-10 10:16:32 <gmaxwell> "high stales", variance, dust.
666 2013-11-10 10:16:52 <warren> gmaxwell: that way way earlier, and you educated me on that.
667 2013-11-10 10:16:56 <warren> was*
668 2013-11-10 10:17:12 <warren> gmaxwell: I then passed on that education to many others
669 2013-11-10 10:17:35 <warren> gmaxwell: after that point I only warned pre-13 ASIC miners and pre-13 LTC dust miners away.
670 2013-11-10 10:18:10 <warren> and I gave up on p2pool entirely for a while and left the channel because I didn't have any ability to mine BTC anymore
671 2013-11-10 10:20:29 <gmaxwell> warren: there was a while when the p2pool channel lighting up was filling me with dread. I guess I haven't gotten over that, but thats my malfunction not yours. Though people are still repeating the warnings away: https://bitcointalk.org/index.php?topic=325737.msg3494149#msg3494149
672 2013-11-10 10:20:34 <gmaxwell> :(
673 2013-11-10 10:21:17 <Anduck> bah
674 2013-11-10 10:21:42 <Anduck> i ran a p2pool node for a day or two to find out my getblocktemplate delay was to big
675 2013-11-10 10:21:47 <Anduck> too*
676 2013-11-10 10:21:57 <gmaxwell> Anduck: huh?
677 2013-11-10 10:22:05 <gmaxwell> whats "too big"?
678 2013-11-10 10:22:13 <Anduck> 0.6 secs i think it was
679 2013-11-10 10:22:21 <warren> gmaxwell: there is something odd in recent p2pool master. sometimes python is using 100% CPU for seemingly no reason.
680 2013-11-10 10:22:24 <Anduck> asked about it and people around said its too muc
681 2013-11-10 10:22:29 <Anduck> too much to run p2pool node really*'
682 2013-11-10 10:23:11 <Anduck> gmaxwell: whats your nodes getblocktemplate delay?
683 2013-11-10 10:23:45 <warren> Anduck: what version of bitcoin?
684 2013-11-10 10:23:55 <gmaxwell> Anduck: I'm actually not sure if having a high GBT delay has any direct adverse effect at all, but at least its a general proxy for your system being slow.
685 2013-11-10 10:23:57 <Anduck> it was 083 or 084
686 2013-11-10 10:24:10 <Anduck> the drives are slow
687 2013-11-10 10:24:15 <gmaxwell> Anduck: 0.04 seconds.
688 2013-11-10 10:24:30 <Anduck> ran it on a 4-core system but HDDs suck
689 2013-11-10 10:24:40 <Anduck> so i guess it's due to HDDs
690 2013-11-10 10:24:58 <Polyatomic> fully blown sickeness gmaxwell .
691 2013-11-10 10:25:06 <gmaxwell> though I have spikes to .25 seconds here and there.
692 2013-11-10 10:25:21 <Anduck> i had 500-600 ms afair
693 2013-11-10 10:25:38 <gmaxwell> Anduck: what speed machine, hdd shouldn't have been causing consistent delays, just spikes perhaps.
694 2013-11-10 10:25:53 <Anduck> what do you mean?
695 2013-11-10 10:25:57 <sipa> unless low ram & swapping
696 2013-11-10 10:26:04 <gmaxwell> sipa: good call.
697 2013-11-10 10:26:16 <Anduck> i had 8 gb ram
698 2013-11-10 10:26:23 <Anduck> using max 2 gb of it so 6gb free
699 2013-11-10 10:26:36 <gmaxwell> Anduck: had you changed any of your bitcoin defaults... like changing your relay fees?
700 2013-11-10 10:26:39 <Anduck> yes
701 2013-11-10 10:26:52 <gmaxwell> How did you change them.
702 2013-11-10 10:27:02 <Anduck> hmm i think relay tx fee to smaller.. like 0.0001 or so
703 2013-11-10 10:27:04 <gmaxwell> Well that would be why.
704 2013-11-10 10:27:06 <Anduck> why?
705 2013-11-10 10:27:15 <gmaxwell> GBT time is proportional to the mempool size.
706 2013-11-10 10:27:19 <Anduck> ohh
707 2013-11-10 10:27:25 <Anduck> well that makes sense
708 2013-11-10 10:31:19 <warren> gmaxwell: hmm, maybe we should have allocated a portion of that $2,000 to a designer to redo the UI ...
709 2013-11-10 10:32:08 <warren> I know some talented designers who code that would be perfect for this.
710 2013-11-10 10:32:09 <Anduck> nah thats not important
711 2013-11-10 10:32:15 <gmaxwell> I think it is important.
712 2013-11-10 10:32:17 <Anduck> there are a lot more important things to use money
713 2013-11-10 10:32:32 <Anduck> bitcoin-qt doesnt need to look super awesome.
714 2013-11-10 10:32:43 <Anduck> other lighter clients can do that
715 2013-11-10 10:32:48 <warren> let's see how much forrestv raises in donations ...
716 2013-11-10 10:32:54 <gmaxwell> But beyond that, I don't know how to make any of these people who won't stop spamming the forum with claims that it doesn't work stop short of bribing them to actually use it.
717 2013-11-10 10:32:56 <Anduck> i think what should be 100% focused is the protocol itself
718 2013-11-10 10:33:14 <Anduck> oh you meant p2pool
719 2013-11-10 10:33:47 <warren> gmaxwell: p2pool is a lot easier to use when you have it in a data center with unlimited bandwidth, SSD's, lots of RAM ... the average home user can easily get things wrong.
720 2013-11-10 10:34:12 <Anduck> are the SSDs really that important?
721 2013-11-10 10:34:53 <warren> Anduck: I've never tested that personally, but that guy who wrote the FUD busting p2pool thread claims so.
722 2013-11-10 10:34:55 <Alina-malina> Hello all! I am trying to install bitcoind with apt-get on my debian machine, but it gives an error, how can i install it to run in console mode?
723 2013-11-10 10:36:20 <Anduck> ok
724 2013-11-10 10:36:43 <gmaxwell> my node shows 1.86kB/s out, 2.62kB/s in. And yes, you do need a real computer to run it. okay not some kind of crazy ultrafast box. My p2pool node is a ~$600 PC and its overkill. ... but there are miners trying to run this crap on atoms and rpis and indeed it doesn't work well if at all. The whole notion of miners with 100k in mining gear trying to run it on a glorified gameboy is .. broken, but I don't know how to reset that expectation.
725 2013-11-10 10:40:09 <gmaxwell> warren: I'm worried less about "Average home user" because I don't think they're an enormous part of the potential hashrate (though it's good if they're happy too), I'm more worried about people with $5-$50k in mining gear... which does justify .. you know, a dedicated pc to run the miners .. or two. geesh. Right now a single KNC jupiter box is bringing in about $120 in BTC per day. I cannot fathom why people with several of these ...
726 2013-11-10 10:40:13 <warren> http://www.reddit.com/r/Bitcoin/new/ want to vote up the p2pool post?
727 2013-11-10 10:40:15 <gmaxwell> ... don't think a dedicated bitcoin node is an unreasonable investment.
728 2013-11-10 10:47:17 <warren> gmaxwell: even ordinary pool ops are getting it wrong all the time ...
729 2013-11-10 10:48:10 <sipa> Alina-malina: what error?
730 2013-11-10 10:48:15 <sipa> Alina-malina: and what version?
731 2013-11-10 10:49:01 <sipa> Alina-malina: distro-distributed packages are often out of data
732 2013-11-10 10:51:23 <gmaxwell> warren: I suspect you're spamcanned, I don't see it there.
733 2013-11-10 10:53:12 <warren> gmaxwell: "Advancement of Decentralized Mining - Vital to Bitcoin Network Security" ?
734 2013-11-10 10:53:42 <gmaxwell> warren: ah its there, I searched for p2pool and warren. :)
735 2013-11-10 10:54:41 <Belxjander> gmaxwell: I'm currently looking at how to expand bitcoin support onto my niche OS of choice and may go forward with converting an existing application or two onto it
736 2013-11-10 10:55:21 <Alina-malina> sipa, i am trying to install it on debian 7, i think there is some specialy way to install it, i have not figure it out yet
737 2013-11-10 10:58:30 <sipa> Alina-malina: i mean what bitcoin version
738 2013-11-10 10:58:34 <Alina-malina> sipa, it gives the following error: Unable to allocate bitcoind package
739 2013-11-10 10:58:34 <sipa> Alina-malina: and what error do you get?
740 2013-11-10 10:58:40 <Alina-malina> i try to do apt-get install bitcoind
741 2013-11-10 10:58:42 <sipa> allocate?
742 2013-11-10 10:59:13 <sipa> i would advise against using distro-provided bitcoin packages
743 2013-11-10 10:59:47 <Belxjander> Alina-malina: better to pull sources for the bitcoin-qt client and bitcoind and build them yourself
744 2013-11-10 11:08:43 <iceTwy> Hola
745 2013-11-10 11:09:35 <iceTwy> I'm still trying to build Bitcoin with BDB 4.8.30 NC (built it myself), but configure keeps complaining about the version
746 2013-11-10 11:09:53 <warren> gmaxwell: heh, someone is voting it down
747 2013-11-10 11:09:58 <iceTwy> "Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)"
748 2013-11-10 11:10:24 <sipa> iceTwy: yes
749 2013-11-10 11:10:29 <sipa> ah
750 2013-11-10 11:10:37 <iceTwy> erm
751 2013-11-10 11:10:43 <iceTwy> my guess is that I should try with BDB 4.8.30
752 2013-11-10 11:10:47 <iceTwy> and not BDB 4.8.30 NC
753 2013-11-10 11:10:56 <sipa> meh, unless you really care about your wallet to be comaptible with release binaries, just use 5.1
754 2013-11-10 11:11:05 <iceTwy> ACTION shrugs
755 2013-11-10 11:11:14 <iceTwy> alright
756 2013-11-10 11:14:34 <Alina-malina> Belxjander, how to do that?
757 2013-11-10 11:36:59 <iceTwy> sipa: successsss
758 2013-11-10 11:37:08 <iceTwy> no more corrupted DB error
759 2013-11-10 11:45:45 <sipa> iceTwy: good to hear
760 2013-11-10 11:48:20 <iceTwy> sipa: well, it's actually reindexing the whole blockchain
761 2013-11-10 11:48:31 <iceTwy> since it'll probably be corrupted again I've just deleted the blocks directory
762 2013-11-10 11:48:39 <iceTwy> will download blocks again. not a problem
763 2013-11-10 11:49:20 <sipa> iceTwy: aargh, no
764 2013-11-10 11:49:25 <sipa> there was no corruption at all
765 2013-11-10 11:49:37 <sipa> it was a bug that it errorneously detected corruption
766 2013-11-10 11:49:51 <sipa> and deleting blocks is something you should never do; use -reindex instead
767 2013-11-10 11:51:50 <iceTwy> sipa: hmm
768 2013-11-10 11:51:59 <iceTwy> :/
769 2013-11-10 11:51:59 <iceTwy> sipa: at least I'll keep that in mind should it pop up again
770 2013-11-10 11:52:06 <iceTwy> and btw sipa
771 2013-11-10 11:52:07 <sipa> it shouodn't
772 2013-11-10 11:52:42 <iceTwy> right now I'm just setting up bitcoind
773 2013-11-10 11:52:44 <iceTwy> so yeah
774 2013-11-10 11:53:04 <gmaxwell> sipa: re: my earlier error throwing node, a pull; make clean; make fixed it... I .. guess?? I had a stale binary.
775 2013-11-10 11:53:06 <iceTwy> now though
776 2013-11-10 11:53:42 <iceTwy> does bitcoin automatically move the blk.dat files to .bitcoin when testnet is disabled?
777 2013-11-10 11:53:58 <iceTwy> from .bitcoin/testnet3/blocks to .bitcoin/blocks that is
778 2013-11-10 11:56:58 <Belxjander> Alina-malina: if you can find the project sources on github and have usage of a "git" tool?
779 2013-11-10 11:57:22 <sipa> iceTwy: move? no, it just uses a different directory
780 2013-11-10 11:58:57 <sipa> gmaxwell: let's hope
781 2013-11-10 11:59:32 <iceTwy> sipa: but I could move manually the blocks directory
782 2013-11-10 11:59:36 <iceTwy> when I switch to production
783 2013-11-10 11:59:38 <iceTwy> hmm?
784 2013-11-10 12:00:54 <pigeons> iceTwy: testnet blocks and the files are of course totally different, than mainnet and not compatible, different network created them, different transactions, different genesis block, different everything
785 2013-11-10 12:01:25 <pigeons> testnet and its blocks and those files are distinct from mainnet
786 2013-11-10 12:01:40 <iceTwy> agh
787 2013-11-10 12:03:10 <gmaxwell> tcatm: People in #bitcoin are complaining about bitcoin charts.