1 2013-09-09 00:00:08 <gmaxwell> Makes sense. Plus it means that if we've broken gitian we learn early and not right at release time.
2 2013-09-09 00:00:22 <gavinandresen> yup
3 2013-09-09 00:05:43 <Luke-Jr> also means we can sign pulltester builds if we need to
4 2013-09-09 00:06:38 <Luke-Jr> Amir is asking me how to run pulltester tests on his new full node implementation; is there a reference I can point him at?
5 2013-09-09 00:11:04 <gavinandresen> Luke-Jr: Just the test-script.sh. His implementation will need to implement "regtest" mode (super-low difficulty); the blockchain tester is bitcoinj code that communicates via the p2p protocol
6 2013-09-09 00:11:50 <Luke-Jr> I'm not sure where that is even; doesn't seem to be part of github.com/bitcoin at least
7 2013-09-09 00:12:04 <gavinandresen> looking⦠it is in one of Matt's repos....
8 2013-09-09 00:12:20 <gavinandresen> https://github.com/TheBlueMatt/test-scripts/
9 2013-09-09 00:13:32 <Luke-Jr> thx
10 2013-09-09 00:29:42 <maaku> gmaxwell: i'm trying to figure out what a coinjoin offer would look like in absense of standardized token sizes
11 2013-09-09 00:30:03 <maaku> e.g, perhaps specify desired output range? maybe multiple ranges?
12 2013-09-09 00:30:14 <maaku> not sure what the best user experience would be.. advice appreciated
13 2013-09-09 00:33:01 <gmaxwell> maaku: Perhaps if the value is not specified then you should generally give up on value privacy, and just specify a minimum?
14 2013-09-09 00:33:27 <maaku> hm.. i like that
15 2013-09-09 00:33:40 <maaku> much simpler
16 2013-09-09 00:34:51 <gmaxwell> phantomcircuit: /join #bitcoin-wizards I have an improvement to the not-fractional reserve proof that further improves privacy.
17 2013-09-09 00:36:34 <BlueMattBot> Project Bitcoin build #398: STILL FAILING in 24 sec: http://jenkins.bluematt.me/job/Bitcoin/398/
18 2013-09-09 00:45:58 <gmaxwell> 2013-09-09 00:45:19 Verifying last 288 blocks at level 3
19 2013-09-09 00:45:58 <gmaxwell> hurrah
20 2013-09-09 00:45:59 <gmaxwell> 2013-09-09 00:45:20 ERROR: DisconnectBlock() : added transaction mismatch? database corrupted
21 2013-09-09 00:46:02 <gmaxwell> 2013-09-09 00:45:25 ERROR: VerifyDB() : *** coin database inconsistencies found (last 14 blocks, 45068 good transactions before that)
22 2013-09-09 00:46:13 <gmaxwell> finally have a blockdatabase corruption on my laptop.
23 2013-09-09 00:46:35 <gmaxwell> (after an out-of-power event)
24 2013-09-09 00:47:09 <gmaxwell> unfortunately it does not seem reproducable enough that I can use it as a leveldb upgrade test case.
25 2013-09-09 00:49:02 <gmaxwell> I guess its concerning that leveldb doesn't even detect the corruption.
26 2013-09-09 00:49:32 <phantomcircuit> gmaxwell, os x?
27 2013-09-09 00:49:39 <gmaxwell> Fedora 19.
28 2013-09-09 00:50:14 <phantomcircuit> gmaxwell, so it's unlikely the leveldb changes will fix that
29 2013-09-09 00:50:26 <phantomcircuit> gmaxwell, this is why i really dont like leveldbs journal format
30 2013-09-09 00:50:53 <phantomcircuit> (although it is faster since it fairly robustly prevents fragmentation by preallocating journal space with \x00)
31 2013-09-09 00:51:10 <Luke-Jr> gavinandresen: does OSX's libdb_cxx not have db_version? :/
32 2013-09-09 00:51:25 <BlueMattBot> Project Bitcoin build #399: STILL FAILING in 21 sec: http://jenkins.bluematt.me/job/Bitcoin/399/
33 2013-09-09 00:51:58 <gavinandresen> Luke-Jr: I have no idea. How would I tell?
34 2013-09-09 00:52:32 <Luke-Jr> gavinandresen: objdump -T /path/to/libdb_cxx.so
35 2013-09-09 00:52:43 <Luke-Jr> lists the symbols in it
36 2013-09-09 00:53:08 <gavinandresen> Luke-Jr: I've got a /opt/local/lib/db48 directory with .a, .dylib and .la files in it, no .so's
37 2013-09-09 00:53:25 <Luke-Jr> I think it should work with a .a or .dylib too
38 2013-09-09 00:53:40 <gavinandresen> ⦠and I don't have an objdump tool.
39 2013-09-09 00:53:47 <Luke-Jr> ! :/
40 2013-09-09 00:53:48 <gribble> Error: ":/" is not a valid command.
41 2013-09-09 00:53:59 <gavinandresen> I think it is otool on OSX
42 2013-09-09 00:54:05 <Luke-Jr> guess I can just change it back to main for now, although that's technically invalid (but should work I guess)
43 2013-09-09 00:57:36 <warren> oops, I figured out why I broke jgarzik's disablewallet in the backport
44 2013-09-09 01:07:41 <gmaxwell> phantomcircuit: I would be kinda surprised if this were due to that leveldb corner case.
45 2013-09-09 01:09:21 <phantomcircuit> gmaxwell, i wouldn't :/
46 2013-09-09 01:33:19 <bizoro> I want to contribute to the bitcoin project, where can I find some features to work on (c/c++)
47 2013-09-09 01:37:42 <owowo> git
48 2013-09-09 01:46:32 <amiller> everyone who's interested in researchy and futuristic discussions about bitcoin should join #bitcoin-wizards, it's not an exclusive invite-only channel, it's a safe place to talk about big ideas without frightening ordinary developers who need this space for solving immediate problems
49 2013-09-09 02:09:03 <warren> I fixed the backport of disablewallet to 0.8.4, anyone want it for bitcoin? It requires more work as our 0.8.4 is a bit different.
50 2013-09-09 02:10:08 <warren> jgarzik: fixed it, I was doing it late night and I forgot to include the PR before it.
51 2013-09-09 02:13:13 <jgarzik> cool
52 2013-09-09 02:13:41 <warren> jgarzik: I'll post a bitcoin version for folks to test, I think p2pool people will like it.
53 2013-09-09 02:13:54 <warren> jgarzik: just to clarify, this is only for bitcoind right?
54 2013-09-09 02:14:02 <warren> ACTION didn't try bitcoin-qt
55 2013-09-09 02:20:11 <jgarzik> warren, I do not test Bitcoin-QT. It might work, who knows.
56 2013-09-09 02:21:15 <jgarzik> warren, everything goes through wallet registration functions
57 2013-09-09 02:21:51 <warren> well, building it and will see what explodes
58 2013-09-09 02:36:50 <warren> phantomcircuit: your github gravatar looks like mickey mouse
59 2013-09-09 02:39:56 <warren> jgarzik: bitcoin-qt segfaults when you run it with disablewallet. =)
60 2013-09-09 02:47:32 <BlueMattBot> Project Bitcoin build #400: STILL FAILING in 2 min 57 sec: http://jenkins.bluematt.me/job/Bitcoin/400/
61 2013-09-09 02:57:36 <BlueMattBot> Yippie, build fixed!
62 2013-09-09 02:57:37 <BlueMattBot> Project Bitcoin build #401: FIXED in 2 min 46 sec: http://jenkins.bluematt.me/job/Bitcoin/401/
63 2013-09-09 02:59:02 <warren> jgarzik: it seems your early guess was right ... disablewallet is cutting nearly 200MB on some of my nodes... that's unused wallets...
64 2013-09-09 03:01:06 <jgarzik> hrm, lovely
65 2013-09-09 03:01:10 <jgarzik> parallel builds are broken
66 2013-09-09 03:01:58 <gavinandresen> parallel builds? You mean make -j N>1 ? Works for me...
67 2013-09-09 03:02:56 <warren> gavinandresen: did luke-jr fix the issue you found?
68 2013-09-09 03:03:22 <warren> it's hard to test the master tree without his PR
69 2013-09-09 03:03:47 <jgarzik> AR libbitcoin.a
70 2013-09-09 03:03:47 <jgarzik> CXX version.o
71 2013-09-09 03:03:47 <jgarzik> make[1]: *** [check-recursive] Error 1
72 2013-09-09 03:03:47 <jgarzik> make[2]: *** [libbitcoin.a] Error 1
73 2013-09-09 03:03:47 <jgarzik> /usr/bin/ar: addrman.o: No such file or directory
74 2013-09-09 03:03:47 <jgarzik> /usr/bin/ar: creating libleveldb.a
75 2013-09-09 03:03:48 <gmaxwell> jgarzik: they seemed broken to me in terms of performanceâ but I see in ps that multiple files are being compiled at once.
76 2013-09-09 03:03:49 <jgarzik> make: *** [check-recursive] Error 1
77 2013-09-09 03:03:51 <jgarzik> make: *** Waiting for unfinished jobs....
78 2013-09-09 03:03:53 <jgarzik> mv: cannot stat .deps/main.Tpo: No such file or directory
79 2013-09-09 03:03:55 <jgarzik> make[3]: *** [main.o] Error 1
80 2013-09-09 03:03:59 <jgarzik> gavinandresen, not deterministic
81 2013-09-09 03:04:15 <Luke-Jr> warren: workign on it
82 2013-09-09 03:04:18 <jgarzik> libbitcoin.a is missing a dep
83 2013-09-09 03:04:20 <jgarzik> most likely
84 2013-09-09 03:04:47 <Luke-Jr> jgarzik: it is, fixing that too :p
85 2013-09-09 03:04:56 <gavinandresen> warren: what platform are you compiling on? works for me on ubuntu and OSX
86 2013-09-09 03:05:46 <sipa> ACTION guesses: fedora
87 2013-09-09 03:05:51 <warren> gavinandresen: fedora
88 2013-09-09 03:06:21 <gavinandresen> By the way: I neutered Jenkins to get it working, it just does a make check of linux binaries right now.
89 2013-09-09 03:06:30 <gavinandresen> warren: okey dokey, I don't know nuthin about fedora
90 2013-09-09 03:06:58 <gavinandresen> (except they have wimply lawyers who are afraid of ECDSA patents)
91 2013-09-09 03:07:12 <gmaxwell> Without luke's pull the current master can't find bdb on fedora (or, if you have many versions installed, it finds the wrong one)
92 2013-09-09 03:07:42 <warren> Luke-Jr: missing dep explains why it is failing to rebuild leveldb.a (pre-autotools)?
93 2013-09-09 03:12:02 <Luke-Jr> warren: maybe
94 2013-09-09 03:12:51 <Luke-Jr> pushed a new autoconf branch, hopefully addressing everything mentioned more recently
95 2013-09-09 03:13:18 <gavinandresen> ok, so I need to add a new .cpp file. I add it to src/Makefile.am or src/Makefile.in ?
96 2013-09-09 03:13:18 <Luke-Jr> gavinandresen: can you test on OS X again?
97 2013-09-09 03:13:24 <warren> jgarzik: could you please rebase your disablewallet? it's a bit stale
98 2013-09-09 03:13:54 <gavinandresen> Luke-Jr: sure
99 2013-09-09 03:14:29 <jgarzik> warren, patience, Daniel-san
100 2013-09-09 03:15:25 <Luke-Jr> ACTION sets up a bash loop to rebuild everything with -j2000 until it fails, to test
101 2013-09-09 03:15:29 <gavinandresen> Luke-Jr: configure: error: No working boost sleep implementation found
102 2013-09-09 03:15:35 <sipa> gavinandresen: .am
103 2013-09-09 03:15:44 <sipa> there is no .in in the repository
104 2013-09-09 03:15:52 <Luke-Jr> gavinandresen: curious - I didn't touch anything boost-related :x
105 2013-09-09 03:15:55 <Luke-Jr> gavinandresen: does it work before my pullreq?
106 2013-09-09 03:16:16 <Luke-Jr> either way, can you upload config.log somewheres?
107 2013-09-09 03:16:35 <gavinandresen> bah, no, breaks with current master?
108 2013-09-09 03:16:56 <gavinandresen> how do I tell configure "nuke everything so I know I'm starting clean" ?
109 2013-09-09 03:17:03 <sipa> make clean ?
110 2013-09-09 03:17:06 <Luke-Jr> make distclean usually
111 2013-09-09 03:17:11 <Luke-Jr> but I haven't tested that with this yet
112 2013-09-09 03:17:13 <jgarzik> make distclean
113 2013-09-09 03:17:16 <gavinandresen> mmm, I did a make distclean
114 2013-09-09 03:17:26 <jgarzik> use the git command :)
115 2013-09-09 03:17:38 <jgarzik> git help clean
116 2013-09-09 03:17:47 <sipa> what was the incantation for that?
117 2013-09-09 03:17:54 <gmaxwell> I think something is mildly broken with the dependencies. (as is often the case for recursive automake) that is causing it to pickup stale files here and there.
118 2013-09-09 03:18:18 <gmaxwell> careful with the git one, doesn't it nuke all untracked files?
119 2013-09-09 03:18:33 <gmaxwell> (I dunno about y'alls workflow, but I leave files laying around)
120 2013-09-09 03:18:34 <Luke-Jr> I understand why cfields would want to use recursive automake, but it is a PAIN
121 2013-09-09 03:18:40 <jgarzik> git clean -fdx
122 2013-09-09 03:18:42 <jgarzik> is one
123 2013-09-09 03:19:27 <Luke-Jr> (we could almost make Bitcoin-Qt a submodule if this comes out right..)
124 2013-09-09 03:19:40 <jgarzik> Luke-Jr, indeed, but full paths inside the makefile also wind up causing problems, in practice :/
125 2013-09-09 03:19:42 <gmaxwell> Luke-Jr: sometime later can you please tell me? I don't have any idea why anyone would want to use recursive automake except for something like a subproject. I don't think its greatly harmful for us either, but for my on gratification I'd like to understand why anyone would want it.
126 2013-09-09 03:19:44 <gavinandresen> git clean -df fixed it. grrr
127 2013-09-09 03:20:54 <warren> "make distclean" does a good job, except I was surprised it didn't remove the old bitcoin-qt
128 2013-09-09 03:21:30 <Luke-Jr> gmaxwell: it's more modular - if done right, bitcoin-qt, bitcoind, etc could be independent codebases from the satoshi code
129 2013-09-09 03:21:42 <jgarzik> warren, new build system is not supposed to clean up after the old build system
130 2013-09-09 03:21:48 <jgarzik> extra baggage
131 2013-09-09 03:22:00 <gmaxwell> warren: one time cost.
132 2013-09-09 03:22:14 <sipa> Luke-Jr: afaik cfields was mildly against recursive makefiles, but did so at the request of someone
133 2013-09-09 03:22:20 <sipa> i think jgarzik?
134 2013-09-09 03:22:23 <gavinandresen> Now I'm confused⦠with Luke's pull merged, I seem to get the No working boost sleep implementation found every time
135 2013-09-09 03:22:25 <Luke-Jr> ACTION wonders how long until Diapolo comes in here to rage at us for breaking Qt5 <.<
136 2013-09-09 03:22:36 <gmaxwell> considering all the other costs related to the changeâ not a big one. Pluse telling people they MUST cleanup on their own will likely fix a bunch of corner cases which we couldn't hope to solve otherwise.
137 2013-09-09 03:24:27 <Luke-Jr> hmm, seems I broke pulltester
138 2013-09-09 03:24:29 <Luke-Jr> ACTION ponders
139 2013-09-09 03:24:57 <gmaxwell> Luke-Jr: seem your pull breaks the build for gavin on OSX.
140 2013-09-09 03:25:24 <Luke-Jr> gavinandresen: I thought you said master was broken the same way? or did I misunderstand?
141 2013-09-09 03:25:42 <gavinandresen> Luke-Jr: master works fine if I git clean -dfx
142 2013-09-09 03:25:44 <Luke-Jr> hmm
143 2013-09-09 03:25:53 <warren> Luke-Jr: qt5 works, you just refused to pull it
144 2013-09-09 03:25:53 <warren> works*
145 2013-09-09 03:25:54 <Luke-Jr> gavinandresen: can you post the config.log from it not working?
146 2013-09-09 03:25:58 <gavinandresen> config.log is at: http://www.skypaint.com/bitcoin/config.log
147 2013-09-09 03:26:59 <gavinandresen> ah, why is it building conftest with -mmacosx-version-min=10.5 -arch i386
148 2013-09-09 03:29:50 <gavinandresen> ⦠oh, because "configure: Disable debug by default (build release)"
149 2013-09-09 03:29:58 <Luke-Jr> makes sense
150 2013-09-09 03:32:33 <gavinandresen> ./configure --enable-debug works
151 2013-09-09 03:34:31 <gavinandresen> I'd vote for debug-by-default, and --disable-debug for release builds. But y'all can tell me that is crazy-talk, and everybody else in the world builds release by default
152 2013-09-09 03:35:38 <sipa> i have a slight favor for release-by-default, though i don't care strongly
153 2013-09-09 03:36:41 <gavinandresen> Luke-Jr: hmm. FAIL: test_bitcoin
154 2013-09-09 03:37:11 <Luke-Jr> failed to build it? the results failed before my pullreq at least I know
155 2013-09-09 03:37:49 <gavinandresen> build ok, but getting JSON syntax errors in script_tests.cpp
156 2013-09-09 03:38:00 <gavinandresen> ACTION goes back to build the world under master....
157 2013-09-09 03:42:17 <gavinandresen> Luke-Jr: it would be better if you didn't bundle up a bunch of unrelated changes. E.g. it would have saved me a bunch of time if I didn't have to figure out that you changed the --enable-debug setting.
158 2013-09-09 03:42:24 <gavinandresen> Luke-Jr: unit tests pass on master.
159 2013-09-09 03:43:03 <Luke-Jr> O.o
160 2013-09-09 03:50:05 <Luke-Jr> hmm, pre-autoconf master test_bitcoin passes for me too
161 2013-09-09 03:53:02 <sipa> master fails to build leveldb here
162 2013-09-09 03:53:08 <sipa> some strange error
163 2013-09-09 03:53:20 <sipa> didn't work the first time, did work the second time
164 2013-09-09 03:54:49 <Luke-Jr> master test_bitcoin fails for me
165 2013-09-09 03:54:58 <Luke-Jr> unknown location(0): fatal error in "AlertApplies": memory access violation at address: 0x00000010: no mapping at fault address
166 2013-09-09 03:55:43 <Luke-Jr> Program received signal SIGSEGV, Segmentation fault.
167 2013-09-09 03:55:44 <Luke-Jr> 0x56766f55 in CAlert::IsInEffect (this=0x0) at alert.cpp:101
168 2013-09-09 03:57:23 <sipa> running test_bitcoin in valgrind
169 2013-09-09 03:58:05 <Luke-Jr> bah, test_bitcoin wants to run from src/test again
170 2013-09-09 03:58:32 <sipa> ah
171 2013-09-09 03:59:45 <gavinandresen> didn't it always want to run from there? I don't think I ever figured out how to pass command-line argument into the boost unit test runner so I could pass the location of test/data to the unit tester....
172 2013-09-09 04:00:15 <Luke-Jr> gavinandresen: pre-autotools worked fine
173 2013-09-09 04:00:30 <sipa> so why did that change?
174 2013-09-09 04:00:41 <gavinandresen> and why does it work for me post-autotools?
175 2013-09-09 04:00:41 <Luke-Jr> the hard-coded test path is now relative instead of absolute :/
176 2013-09-09 04:00:48 <sipa> Ah.
177 2013-09-09 04:01:28 <Luke-Jr> gavinandresen: you're running it from src/test I guess?
178 2013-09-09 04:01:42 <gavinandresen> I'm just running "make check" from the top-level bitcoin directory
179 2013-09-09 04:01:45 <sipa> so... start with a chdir(dirname($0))?
180 2013-09-09 04:02:27 <Luke-Jr> sipa: I'd like to be able to copy the binary to the base dir
181 2013-09-09 04:02:35 <Luke-Jr> gavinandresen: ah
182 2013-09-09 04:02:42 <sipa> i wonder why the binary isn't in the base dir
183 2013-09-09 04:02:53 <sipa> seems inconvenient they are spread out
184 2013-09-09 04:02:58 <Luke-Jr> ok, have a fix for this too now
185 2013-09-09 04:08:18 <sipa> ACTION tries to sleep() a bit again
186 2013-09-09 04:11:37 <Luke-Jr> gavinandresen: pushed a more minimal set of fixes that passes test_bitcoin for me
187 2013-09-09 04:12:15 <gavinandresen> Luke-Jr: git://github.com/luke-jr/bitcoin.git autoconf ??
188 2013-09-09 04:12:23 <Luke-Jr> yes
189 2013-09-09 04:17:01 <gavinandresen> hmmm, test_bitcoin seems to be taking a very long time to run
190 2013-09-09 04:19:25 <Luke-Jr> the whole compile seems to be taking longer for me, but I suspect it's perception (since I can't explain it with top) :/
191 2013-09-09 04:19:32 <gavinandresen> How do I see what command 'make check-TESTS' is running?
192 2013-09-09 04:19:44 <Luke-Jr> add V=1 to the command
193 2013-09-09 04:19:49 <Luke-Jr> make V=1 check-TESTS
194 2013-09-09 04:20:00 <gavinandresen> that's what I thought, doesn't work
195 2013-09-09 04:20:26 <Luke-Jr> 'make check-TESTS' seems invalid for me :/
196 2013-09-09 04:20:45 <gavinandresen> me too⦠I wonder what Makefile check-TESTS is in
197 2013-09-09 04:20:51 <Luke-Jr> ah, subdirectories
198 2013-09-09 04:21:19 <gavinandresen> src/test/ ....
199 2013-09-09 04:21:54 <gavinandresen> make V=1 check-TESTS inside the src/test directory still doesn't tell me what it is doing. test_bitcoin is using 100% cpu, but never seems to complete
200 2013-09-09 04:22:16 <Luke-Jr> strange
201 2013-09-09 04:22:20 <Luke-Jr> attach gdb or strace?
202 2013-09-09 04:24:22 <Luke-Jr> hmm
203 2013-09-09 04:24:33 <Luke-Jr> I wonder if it's the same thing that caused my test_bitcoin to segfault before I fixed it
204 2013-09-09 04:24:50 <Luke-Jr> but in reverse
205 2013-09-09 04:25:01 <gavinandresen> running test_bitcoin I get malloc: *** error for object 0x7fb39b89b468: incorrect checksum for freed object
206 2013-09-09 04:25:25 <Luke-Jr> :|
207 2013-09-09 04:25:50 <Luke-Jr> pulltester seems to be having some very strange issue
208 2013-09-09 04:26:29 <Luke-Jr> ACTION bisects it
209 2013-09-09 04:28:04 <Luke-Jr> looks unrelated to the malloc issue
210 2013-09-09 04:29:12 <gavinandresen> current git HEAD master works fine for me. I'd suggest stop playing whack-a-mole and wait for cfields to get back and run fixes by him for review.
211 2013-09-09 04:33:04 <Luke-Jr> I'm in no rush, though my branch seems to work for more people than master *shrug*
212 2013-09-09 04:35:02 <Luke-Jr> fwiw, the rest of the stuff is in autoconf_pt{2,3,4} now
213 2013-09-09 04:48:53 <phantomcircuit> <warren> phantomcircuit: your github gravatar looks like mickey mouse
214 2013-09-09 04:48:56 <phantomcircuit> lol wat
215 2013-09-09 04:50:57 <warren> phantomcircuit: https://github.com/pstratem/
216 2013-09-09 04:51:31 <phantomcircuit> doesn't show anything since i have requestpolicy installed
217 2013-09-09 04:51:40 <warren> oh
218 2013-09-09 04:51:45 <warren> well, everyone else sees it
219 2013-09-09 04:52:00 <gavinandresen> definitely looks like mickey.
220 2013-09-09 04:52:08 <warren> hahahhaha
221 2013-09-09 04:52:17 <warren> jgarzik looks like a space invader.
222 2013-09-09 04:52:36 <phantomcircuit> huh that's weird
223 2013-09-09 05:16:20 <dooglus> what is the recommended course of action when debug.log says "": Corrupted block database detected. Do you want to rebuild the block database now??
224 2013-09-09 05:23:04 <maaku> dooglus: rebuilding the block database
225 2013-09-09 05:24:26 <gmaxwell> dooglus: any idea how you got into that state?
226 2013-09-09 05:43:46 <dooglus> gmaxwell: none. I ran 'bitcoind stop', waited for bitcoind process to vanish, rebooted, restarted bitcoind and saw it
227 2013-09-09 05:44:01 <gmaxwell> dooglus: what version of bitcoin?
228 2013-09-09 05:44:21 <dooglus> the version from a few days ago
229 2013-09-09 05:44:25 <dooglus> x.4?
230 2013-09-09 05:44:38 <gmaxwell> Hm. Okay, odd.
231 2013-09-09 05:44:40 <gmaxwell> What OS?
232 2013-09-09 05:44:46 <dooglus> some ubuntu
233 2013-09-09 05:45:10 <gmaxwell> okay. well the checks are really anal for a reason. Concerning though.
234 2013-09-09 05:45:53 <dooglus> also, the "Do you want to rebuild the block database now?" is odd when running as a daemon. it appeared on the console
235 2013-09-09 05:46:14 <dooglus> it looks like it wants me to answer, but it's not really asking
236 2013-09-09 05:46:58 <dooglus> so a "bitcoind -reindex" is the thing to do?
237 2013-09-09 05:47:24 <gmaxwell> yea, a little awkward, though its supposted to be a urgent should never happen your hardware is probably bad case. (though leveldb is turning out to be a little less trustworthy than advertisedâ doesn't seem worse than BDB was at least, but differently flaky)
238 2013-09-09 05:47:27 <gmaxwell> dooglus: correct.
239 2013-09-09 05:47:43 <warren> that "Do you want to rebuild the block database now?" shows up in other unintended places
240 2013-09-09 05:48:41 <gmaxwell> well it does the right thing in the GUI... the gui actually lets you click to get go straight to a reindex.
241 2013-09-09 05:48:41 <warren> https://github.com/bitcoin/bitcoin/issues/2893
242 2013-09-09 07:01:51 <magbo> Interesting, rinning 0.8.4 in testnet, generating a bip0032 root key using pycoin (genwallet -tu | tee mk), getting its WIF (genwallet -wf mk), trying to import it (bitcoind importprivkey $wif somekey false) and get error: {"code":-5,"message":"Invalid private key"}.
243 2013-09-09 07:02:03 <magbo> Fresh installation on Ubuntu LTS 12.04
244 2013-09-09 07:05:59 <sipa> what does the WIF look like?
245 2013-09-09 07:06:06 <sipa> length/first xharacter
246 2013-09-09 07:06:21 <jeremias> magbo: set compressed=False when getting the wif
247 2013-09-09 07:06:30 <jeremias> that fixed the problem for me
248 2013-09-09 07:06:37 <sipa> that would be incorrect
249 2013-09-09 07:06:45 <sipa> bip32 mandates compressed keys
250 2013-09-09 07:08:02 <gmaxwell> sipa: oh this is an interesting bug: I reindexed a node whos blockchain was corrupted while it was unable to connect to the network, long after the reindex finished I STOPed the node in order to fix the config to put it back online. I observed this (uninteresting lines elided)
251 2013-09-09 07:08:07 <gmaxwell> 2013-09-09 06:52:10 SetBestChain: new best=000000000000001205b0e002a81b2bf48fd9827b2a448f21f11f3d7b0d39d115 height=256831 log2_work=71.764124 tx=23501363 date=2013-09-09 00:31:11 progress=0.997490
252 2013-09-09 07:08:11 <gmaxwell> 2013-09-09 07:05:33 Committing 20225 changed transactions to coin database...
253 2013-09-09 07:08:24 <gmaxwell> e.g. 15 minutes after the last SetBestChain it hadn't flushed the coins database.
254 2013-09-09 07:08:47 <gmaxwell> oh.. and .. on restart it claims its corrupted.
255 2013-09-09 07:10:35 <magbo> sipa: it's compressed WIF by the looks of it â âKyâ...; length = 52.
256 2013-09-09 07:13:56 <magbo> when I try to use uncompressed version â5Jâ...; length = 51, I still get errorcode -5. âcat mkâ yields âtprv...â.
257 2013-09-09 07:15:28 <magbo> first line of âcat ~/.bitcoin/bitcoin.confâ is âtestnet=1â, so the private key obtained from tpriv extended key should be importable.
258 2013-09-09 07:16:11 <gmaxwell> uh testnet private keys have a different prefix.
259 2013-09-09 07:16:26 <gmaxwell> 9 or c
260 2013-09-09 07:16:39 <magbo> aha, so it's a bug in pycoin?
261 2013-09-09 07:16:52 <magbo> waaait
262 2013-09-09 07:17:59 <magbo> No, adding -t to genwallet call that gets wif didn't help. :)
263 2013-09-09 07:18:36 <gmaxwell> that would be your problem. (incidentally, where did you get working pycoin from? ... all I get from it is connection errors)
264 2013-09-09 07:22:37 <magbo> gmaxwell: I use pycoin version "0.23" installed with the following script â https://gist.github.com/manpages/6492413. The only piece of functionality I use from it is BIP0032 implementation (via genwallet (cli) and pycoin.wallet (python)).
265 2013-09-09 07:35:52 <sipa> gmaxwell: ewww, any clue what caused the corruption?
266 2013-09-09 07:38:31 <gmaxwell> sipa: all started with running out of power unexpectedly. I reindexed.. and it was corrupted again but I wasn't sure if I was stupid and perhaps killed the process during the reindex. So I attempted the reindex again and saw that curious delay with flusing until shutdown instead of when the reindex finished... and it was corrupt again on startup.
267 2013-09-09 07:38:58 <gmaxwell> I just deleted ~/.bitcoin/chainstate and letting it rebuild now (I also backed up the whole directory before starting)
268 2013-09-09 07:39:18 <gmaxwell> oh also, running git master + leveldb update (I switched to the leveldb update before the first reindex.
269 2013-09-09 07:39:27 <sipa> ~ic
270 2013-09-09 07:39:32 <gmaxwell> because you know, changing one thing at a time is too boring.
271 2013-09-09 07:42:05 <sipa> yeah, and too scientific
272 2013-09-09 07:42:58 <gmaxwell> I didn't expect the first reindex to fail.. :-/ (I upgraded the leveldb to see if maybe I'd get a better error on the corrupteded database.
273 2013-09-09 07:43:01 <gmaxwell> )
274 2013-09-09 07:54:11 <SomeoneWeird> apparently not
275 2013-09-09 08:06:32 <Graet> what di I do in CLI when
276 2013-09-09 08:07:09 <Graet> I see "Do you want to rebuild the block database now?" y and just enter it closes bitcoind
277 2013-09-09 08:07:29 <sipa> start with -reindex
278 2013-09-09 08:07:34 <Graet> ty
279 2013-09-09 08:07:47 <sipa> will take a while
280 2013-09-09 08:07:53 <sipa> increasing -dbcache helps
281 2013-09-09 08:07:55 <Graet> yeah :/
282 2013-09-09 08:08:01 <Graet> ok ty
283 2013-09-09 08:08:20 <sipa> up to 1000 or so (it's anumber in MiB)
284 2013-09-09 08:09:21 <conman> a few of us had corrupted DBs at about the same time... anyone know if there's an issue here?
285 2013-09-09 08:09:25 <gmaxwell> okay.. rebuilt again with the nuked chainstate... time to stop and restart.
286 2013-09-09 08:09:34 <Graet> thanks sipa :)
287 2013-09-09 08:09:38 <gmaxwell> ...
288 2013-09-09 08:09:41 <gmaxwell> fuck.
289 2013-09-09 08:09:47 <sipa> conman: that's bad news
290 2013-09-09 08:09:52 <conman> 3 within an hour
291 2013-09-09 08:09:52 <gmaxwell> Graet: conman: ... I saw that wizkid had a corrupted one toda.y
292 2013-09-09 08:10:03 <conman> and kano just now
293 2013-09-09 08:10:08 <conman> this is not coincidence...
294 2013-09-09 08:10:16 <Graet> this is my 2nd, other was on windows laptop
295 2013-09-09 08:10:16 <warren> master?
296 2013-09-09 08:10:29 <conman> I was on 0.8.3 still, but others were on 0.8.4
297 2013-09-09 08:10:36 <warren> mmm
298 2013-09-09 08:10:40 <Graet> i'm 0.8.4
299 2013-09-09 08:10:44 <sipa> what OS'es, and had these systems seen corrupted databases before?
300 2013-09-09 08:11:10 <conman> linux 64bit, never had it before
301 2013-09-09 08:11:26 <sipa> that doesn't sound like coincidence indeed
302 2013-09-09 08:11:27 <gmaxwell> 13:36 <@wizkid057> 2013-09-06 20:32:32 received block 00000000000000111f9591a156b54ba3614965b748cefa5df13498441ef041a9
303 2013-09-09 08:11:27 <gmaxwell> 13:36 <@wizkid057> wtf www bitcoind
304 2013-09-09 08:11:30 <Graet> ubuntu 12.04 server, machine rebooted and came back with corrupted db message on start, windows8 desktop after a sleep
305 2013-09-09 08:11:31 <gmaxwell> 13:36 <@wizkid057> 2013-09-06 20:32:32 InvalidChainFound: invalid block=00000000000000111f9591a156b54ba3614965b748cefa5df13498441ef041a9 height=256496 log2_work=71.7
306 2013-09-09 08:11:34 <gmaxwell> 13:36 <@wizkid057> 2013-09-06 20:32:32 InvalidChainFound: invalid block=00000000000000111f9591a156b54ba3614965b748cefa5df13498441ef041a9 height=256496 log2_work=71.7
307 2013-09-09 08:11:38 <gmaxwell> 13:36 <@wizkid057> 2013-09-06 20:32:32 ERROR: SetBestBlock() : ConnectBlock 00000000000000111f9591a156b54ba3614965b748cefa5df13498441ef041a9 failed
308 2013-09-09 08:11:41 <gmaxwell> linux 64 bit, never ever ever had corruption before even though trying to cause it.
309 2013-09-09 08:11:53 <gmaxwell> whole network is probably horked.
310 2013-09-09 08:12:00 <Graet> and not seen corruption before (win install is only 24hours old)
311 2013-09-09 08:12:01 <gmaxwell> lemme try restarting a node that is currently healthly.
312 2013-09-09 08:12:11 <gmaxwell> sipa: you approve of my idea of restarting a healty node?
313 2013-09-09 08:13:03 <sipa> gmaxwell: yes
314 2013-09-09 08:13:16 <sipa> the node on my vps seems fine
315 2013-09-09 08:13:23 <sipa> though i didn't restart
316 2013-09-09 08:13:52 <sipa> gmaxwell: the corruotion you reported earlier was applicatiin level, right?
317 2013-09-09 08:13:55 <sipa> noy leveldb
318 2013-09-09 08:13:59 <gmaxwell> : Corrupted block database detected.
319 2013-09-09 08:14:04 <gmaxwell> sipa: correct.
320 2013-09-09 08:14:05 <sipa> is that the same for the orlther reports?
321 2013-09-09 08:14:09 <sipa> *other
322 2013-09-09 08:14:21 <gmaxwell> sipa: so this node just did the same thing.
323 2013-09-09 08:14:28 <sipa> outch
324 2013-09-09 08:14:50 <sipa> what was the actual error?
325 2013-09-09 08:15:13 <gmaxwell> This node is at 2fee100f036626866e5dca3f27b7562da25e43f3
326 2013-09-09 08:15:21 <gmaxwell> (git rev)
327 2013-09-09 08:15:34 <gmaxwell> 2013-09-09 08:13:48 LoadBlockIndexDB(): hashBestChain=0000000000000017260e3e0cd5bcf880e9dc0ae5737334100bf0e3db1c06f1f9 height=256892 date=2013-09-09 08:02:40
328 2013-09-09 08:15:38 <gmaxwell> 2013-09-09 08:13:48 init message: Verifying blocks...
329 2013-09-09 08:15:40 <gmaxwell> 2013-09-09 08:13:48 Verifying last 288 blocks at level 3
330 2013-09-09 08:15:43 <gmaxwell> 2013-09-09 08:13:49 ERROR: DisconnectBlock() : added transaction mismatch? database corrupted
331 2013-09-09 08:15:46 <gmaxwell> 2013-09-09 08:13:51 ERROR: VerifyDB() : *** coin database inconsistencies found (last 75 blocks, 30749 good transactions before that)
332 2013-09-09 08:15:50 <gmaxwell> 2013-09-09 08:13:51 : Corrupted block database detected.
333 2013-09-09 08:15:51 <gmaxwell> Do you want to rebuild the block database now?
334 2013-09-09 08:15:53 <gmaxwell> on the node I just tested.
335 2013-09-09 08:15:55 <gmaxwell> 2013-09-09 08:13:51 Aborted block database rebuild. Exiting.
336 2013-09-09 08:15:58 <gmaxwell> 2013-09-09 08:13:51 Flush(false)
337 2013-09-09 08:16:04 <sipa> this is bad
338 2013-09-09 08:16:27 <gmaxwell> eventually the crap which is triggering the ultraprune inconsistency will get out of the test window.
339 2013-09-09 08:16:43 <gmaxwell> and we just have whatever residual fork risk its creating (if any)
340 2013-09-09 08:16:46 <warren> ACTION syncing
341 2013-09-09 08:16:53 <conman> mine's been reindexing for >1hr, 10 weeks to go
342 2013-09-09 08:17:03 <Graet> urg
343 2013-09-09 08:17:12 <sipa> yes, but there may be a chainstate difference between those who reindexed and those who survived the window
344 2013-09-09 08:17:35 <gmaxwell> my other corrupt node was dying with
345 2013-09-09 08:17:36 <gmaxwell> 2013-09-09 00:45:19 LoadBlockIndexDB(): hashBestChain=000000000000001205b0e002a81b2bf48fd9827b2a448f21f11f3d7b0d39d115 height=256831 date=2013-09-09 00:31:11
346 2013-09-09 08:17:39 <gmaxwell> 2013-09-09 00:45:19 init message: Verifying blocks...
347 2013-09-09 08:17:42 <gmaxwell> 2013-09-09 00:45:19 Verifying last 288 blocks at level 3
348 2013-09-09 08:17:44 <gmaxwell> 2013-09-09 00:45:20 ERROR: DisconnectBlock() : added transaction mismatch? database corrupted
349 2013-09-09 08:17:47 <gmaxwell> 2013-09-09 00:45:25 ERROR: VerifyDB() : *** coin database inconsistencies found (last 14 blocks, 45068 good transactions before that)
350 2013-09-09 08:18:09 <gmaxwell> so this should tell us which blocks contains the inconsistency producing transaction. no?
351 2013-09-09 08:18:24 <gmaxwell> I'll go add some more printfs.
352 2013-09-09 08:18:45 <warren> I'm at height=235554, should I make a snapshot before I get there?
353 2013-09-09 08:19:26 <kinlo> any action to be taken by the mining community?
354 2013-09-09 08:21:25 <sipa> not yet
355 2013-09-09 08:21:33 <sipa> we don't know who is affected
356 2013-09-09 08:21:39 <gmaxwell> It looks like the block in question would be 256817 or one plus minus that one.
357 2013-09-09 08:22:02 <warren> OK, I'm stopping my sync before I get there to make a snapshot.
358 2013-09-09 08:22:04 <sipa> can you print the mismatched transaction?
359 2013-09-09 08:22:42 <gmaxwell> I'm working on it.
360 2013-09-09 08:26:20 <gmaxwell> sipa: http://0bin.net/paste/hRQwG9yRfxwxcjcW#yg3Xk+hF21rjRTnlXjFe8HfaAE0ZlljsM51Lxg8uuuE=
361 2013-09-09 08:27:01 <sipa> gmaxwell: what line is that?
362 2013-09-09 08:27:18 <gmaxwell> thats an assert I inserted in main.c at 1777
363 2013-09-09 08:28:14 <sipa> nVersion == 64
364 2013-09-09 08:28:18 <gmaxwell> yea, I see it.
365 2013-09-09 08:28:21 <sipa> and a negative number
366 2013-09-09 08:28:57 <sipa> the serializer only supports unsigned numbers
367 2013-09-09 08:29:08 <sipa> so whatever got a negative number in there is at fault
368 2013-09-09 08:29:20 <sipa> if that is the block/transaction p2p serializer, we have a problem
369 2013-09-09 08:29:25 <sipa> and i expect that that is the case
370 2013-09-09 08:29:47 <sipa> ignoring it should be fine, as the version number isn't actually used
371 2013-09-09 08:31:36 <gmaxwell> right, it'll make the database inconsistent but we can fix that later.
372 2013-09-09 08:31:43 <sipa> my guess: transaction had a negative nVersion, got serialized into the chainstate as an unsigned number, and we have a mismatxh upon check
373 2013-09-09 08:31:59 <gmaxwell> I don't quite understand how it became 64.
374 2013-09-09 08:32:02 <sipa> but what caused the crash in working nodes?
375 2013-09-09 08:32:13 <gmaxwell> probably nothing: I lost power on my laptop.
376 2013-09-09 08:32:22 <gmaxwell> the corruption was a coincidence.
377 2013-09-09 08:32:40 <gmaxwell> Graet: conman:
378 2013-09-09 08:32:54 <gmaxwell> Did you find your corruption after a normal restart?
379 2013-09-09 08:33:07 <Graet> my laptop went to sleep, and the ubuntu node server rebooted, i got reindex message on restart
380 2013-09-09 08:33:11 <gmaxwell> sipa: someone earlier who reported corruption (doouglas) said it was after a normal restart.
381 2013-09-09 08:33:28 <Graet> neither "normal" i guess
382 2013-09-09 08:34:24 <gmaxwell> ./bitcoind -daemon=1 -checkblocks=1
383 2013-09-09 08:34:31 <gmaxwell> ^ official workaround, I believe.
384 2013-09-09 08:34:48 <sipa> 2 should also work, iirc
385 2013-09-09 08:34:53 <sipa> ah
386 2013-09-09 08:34:56 <sipa> nvm
387 2013-09-09 08:35:04 <gmaxwell> changing the level might be better.
388 2013-09-09 08:35:04 <sipa> -checklevel=2 i mean
389 2013-09-09 08:35:19 <gmaxwell> ACTION tries
390 2013-09-09 08:35:36 <sipa> is there a transaction in the blockchain with nVersion that has ita highest bit set?
391 2013-09-09 08:35:46 <gmaxwell> I confirm ./bitcoind -daemon=1 -checklevel=2 works.
392 2013-09-09 08:35:57 <sipa> can you send out a mail?
393 2013-09-09 08:36:10 <gmaxwell> it would be block 256818 I'll check in a moment, sending out email.
394 2013-09-09 08:36:24 <sipa> ;;blocks
395 2013-09-09 08:36:25 <gribble> 256897
396 2013-09-09 08:36:34 <gmaxwell> how long until its burried?
397 2013-09-09 08:36:50 <sipa> depends on your dbcache
398 2013-09-09 08:37:03 <gmaxwell> about 209 more blocks in the worst case.. but yea.. :-/
399 2013-09-09 08:37:05 <sipa> certainly after 288 blocks
400 2013-09-09 08:37:14 <gmaxwell> let me make sure it's that block.
401 2013-09-09 08:37:17 <sipa> so 1.5 days
402 2013-09-09 08:37:34 <sipa> but we'll need a version soon that can deal with the sign mismatch
403 2013-09-09 08:37:38 <phantomcircuit> gmaxwell, just an fyi i have a 0.8.3 node on windows that is well past the point wizkids crashed
404 2013-09-09 08:37:55 <sipa> as this can be retriggered any time, if it is what we suspect
405 2013-09-09 08:38:57 <sipa> i'll need to go offline soon probably, my phone battery is running empty
406 2013-09-09 08:39:18 <gmaxwell> phantomcircuit: I think wizkid's thing was unrelated
407 2013-09-09 08:42:44 <sipa> the fix would be applying a varint encode+decode on nVersion before comparison in DisconnectBlock
408 2013-09-09 08:43:02 <sipa> or even in CCoins's construxtor
409 2013-09-09 08:43:24 <sipa> that means the highest nVersion bit becomes worthless
410 2013-09-09 08:43:33 <sipa> but we have 31 left
411 2013-09-09 08:46:01 <gmaxwell> getrawtransaction on 0000000000000025b9c431b5486b5be831ab05df8fb6c80879befbbe5b2e1ce4 isn't turning it up.
412 2013-09-09 08:46:10 <sipa> ?
413 2013-09-09 08:46:53 <gmaxwell> oh there is is
414 2013-09-09 08:46:57 <gmaxwell> "version" : -1703168784,
415 2013-09-09 08:46:57 <gmaxwell> "version" : -2107285824,
416 2013-09-09 08:47:57 <gmaxwell> c659729a7fea5071361c2c1a68551ca2bf77679b27086cc415adeeb03852e369 and 637dd1a3418386a418ceeac7bb58633a904dbf127fa47bbea9cc8f86fef7413f
417 2013-09-09 08:49:25 <sipa> so the problem is that these nVersions cannot be correctly serialized in CCoins
418 2013-09-09 08:49:57 <sipa> there are no network rules that depend on the transaction version afaik
419 2013-09-09 08:50:05 <sipa> so it's purely a local problem
420 2013-09-09 08:52:15 <sipa> i'd suggest adding in DisconnextBlock, before that failing outs == outsBlock check:
421 2013-09-09 08:53:04 <sipa> if outsBlock.nVersion < 0)
422 2013-09-09 08:53:19 <sipa> outs.nVersion = outsBlock.nVersion;
423 2013-09-09 08:53:42 <gmaxwell> email sent.
424 2013-09-09 08:54:01 <gmaxwell> I'm trying to figure out what input will result in what output. The obvious reductions didn't seem to worse for me.
425 2013-09-09 08:54:15 <sipa> with a comment explaining the problem, and that serialization of negative versiona needs to be fixed before we ever decide to start using high bits
426 2013-09-09 08:54:44 <gmaxwell> Incidentally with a normaltive UTXO set .. I suppose this would have been a forking bug. :P
427 2013-09-09 08:55:12 <gmaxwell> sipa: yea, I'm testing a patch.
428 2013-09-09 08:55:21 <sipa> well the serialization and deserialization is deterministic, i expect :)
429 2013-09-09 08:55:32 <gmaxwell> sipa: thanks for your support. I wouldn't have the cofidence to post a patch without your second take on this.
430 2013-09-09 08:56:47 <sipa> thanks for still being awake :p
431 2013-09-09 08:56:58 <Graet> should i let reindex finish now? or can i stop bitcoind and restart with -checklevel=2
432 2013-09-09 08:57:03 <sipa> dealing with this from a driving car on a phone would be a pain :)
433 2013-09-09 08:57:13 <Graet> thanks to both of you for being onto it quickly :)
434 2013-09-09 08:57:21 <sipa> Graet: unfortunately, once started, you'll need to complete it
435 2013-09-09 08:57:29 <Graet> ok, thanks
436 2013-09-09 08:57:42 <Graet> thought so :)
437 2013-09-09 08:57:49 <gmaxwell> Graet: sadly I'd been screwing with this broken database for hours but I thought it was just me with some disk corruption.
438 2013-09-09 08:58:32 <Graet> ahh
439 2013-09-09 08:58:55 <gmaxwell> sipa: sergio is going to have a lot of fun with this. :P
440 2013-09-09 08:59:12 <gmaxwell> IIRC he complains about the unsignedness of this seralization or something like that. :P
441 2013-09-09 08:59:18 <gmaxwell> er complained.
442 2013-09-09 08:59:48 <sipa> btw, is there no IsStandard test preventing weird nVersions?
443 2013-09-09 08:59:58 <conman> my bitcoind keeps questioning the date
444 2013-09-09 09:00:01 <conman> could that be related?
445 2013-09-09 09:00:07 <conman> my date's fine
446 2013-09-09 09:00:12 <sipa> or AcceptToMemoryPool
447 2013-09-09 09:00:21 <sipa> conman: i believe that is unrelated
448 2013-09-09 09:00:28 <conman> k
449 2013-09-09 09:00:34 <sipa> it means many peers report a different timestamp
450 2013-09-09 09:00:40 <conman> mine was on a restart after a failed shutdown
451 2013-09-09 09:00:47 <sipa> which is strange thoufh
452 2013-09-09 09:00:48 <conman> but failing to shutdown was virtually routine for mine
453 2013-09-09 09:01:11 <phantomcircuit> sipa, https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L469
454 2013-09-09 09:01:18 <gmaxwell> conman: doublec had reported what appeared to be a network attack that did that.
455 2013-09-09 09:01:19 <phantomcircuit> so
456 2013-09-09 09:01:20 <phantomcircuit> ???
457 2013-09-09 09:01:41 <gmaxwell> phantomcircuit: yea, so people can mine nonstandard txn.
458 2013-09-09 09:02:18 <sipa> ehhh
459 2013-09-09 09:02:26 <sipa> the test is > constant
460 2013-09-09 09:02:29 <sipa> not < 1
461 2013-09-09 09:02:32 <sipa> add that
462 2013-09-09 09:02:33 <gmaxwell> oh! haha
463 2013-09-09 09:02:43 <gmaxwell> will fix.
464 2013-09-09 09:03:02 <gmaxwell> it should be != CTransaction::CURRENT_VERSION right?
465 2013-09-09 09:03:10 <sipa> no
466 2013-09-09 09:03:18 <sipa> well, right niw, yes
467 2013-09-09 09:03:30 <sipa> but older than currentversion may be acceptable
468 2013-09-09 09:03:31 <phantomcircuit> oh
469 2013-09-09 09:03:36 <phantomcircuit> wow that test is 100% wrong
470 2013-09-09 09:03:37 <phantomcircuit> derp
471 2013-09-09 09:03:46 <sipa> no, it's very right
472 2013-09-09 09:03:47 <gmaxwell> or tx.nVersion > CTransaction::CURRENT_VERSION && tx.nVersion >= 0
473 2013-09-09 09:03:51 <sipa> just not complete
474 2013-09-09 09:04:02 <sipa> >= 1 even, afaik
475 2013-09-09 09:04:26 <sipa> > currentversion || < 1
476 2013-09-09 09:04:44 <gmaxwell> yep.
477 2013-09-09 09:04:44 <michagogo> ACTION checks bitcoinstats.com
478 2013-09-09 09:04:57 <phantomcircuit> sipa, shouldn't currentversion always be > 0
479 2013-09-09 09:05:07 <sipa> yes
480 2013-09-09 09:05:40 <sipa> if (nVersion > currentversion || nVersion < 1)
481 2013-09-09 09:05:45 <sipa> is the correct rule
482 2013-09-09 09:05:56 <gmaxwell> thats what my code has now.
483 2013-09-09 09:06:03 <phantomcircuit> oh i see
484 2013-09-09 09:06:05 <phantomcircuit> hmm
485 2013-09-09 09:06:20 <gmaxwell> #@$@# autotools.
486 2013-09-09 09:08:03 <sipa> ACTION afk
487 2013-09-09 09:08:16 <gmaxwell> I really can't express how frustrated the autotools changes are making at the moment, it's taking me ten minutes every time I change something.
488 2013-09-09 09:10:05 <michagogo> Autotools changes?
489 2013-09-09 09:20:00 <gmaxwell> Patch: https://github.com/bitcoin/bitcoin/pull/2982
490 2013-09-09 09:20:05 <gmaxwell> sipa: if back, ^
491 2013-09-09 09:38:48 <gmaxwell> It appears to me that genjix is responsible for this.
492 2013-09-09 09:39:22 <gmaxwell> As coins to the libbitcoin donation address were used to trigger this.
493 2013-09-09 09:39:45 <conman> intentional?
494 2013-09-09 09:40:19 <gmaxwell> Intent is something I cannot determine from the blockchain. The other transactions involved in that address do not have negative versions.
495 2013-09-09 09:41:29 <gmaxwell> Some other reports I heard today might give me reason to assume it intentional, but it's probably better to ask than to assume.
496 2013-09-09 11:10:58 <berndj> i got some "CPrivKey pubkey inconsistency" after building 0.8.4; is there some special trick i need to do to make it work again? I went back to some earlier master version (6cc766f) and it seems okay now
497 2013-09-09 11:11:36 <gmaxwell> berndj: by earlier do you mean much earlier?
498 2013-09-09 11:11:58 <gmaxwell> some kinds of wallet corruption would be silently tolerated in old versions, newer ones got more pedantic about it.
499 2013-09-09 11:13:04 <berndj> gmaxwell, 6cc766f is 2013-08-08
500 2013-09-09 11:13:43 <berndj> not sure what sort of wallet corruption i'd have, i've barely used it - just grabbing blocks at the moment
501 2013-09-09 11:18:16 <gmaxwell> berndj: oh. you were running git. so um 4am here. IIRC there was an accidental wallet format change in git. which was corrected. but I think it left wallets in a state only git can read.
502 2013-09-09 11:18:31 <gmaxwell> give me a second to see if I can confirm that.
503 2013-09-09 11:19:05 <berndj> lol, yikes. don't break a hernia for me now, i'm about to go sleep and it's only 12mBTC
504 2013-09-09 11:19:55 <gmaxwell> berndj: nah nah, you're fine.
505 2013-09-09 11:20:10 <berndj> would you suggest dumpwallet/importwallet to get onto a release version?
506 2013-09-09 11:20:18 <gmaxwell> warren: do you remember the details here / have citations? My logs indicate you were involved in the discussion
507 2013-09-09 11:20:27 <gmaxwell> berndj: I don't believe 0.8.4 has importwallet.
508 2013-09-09 11:21:02 <berndj> i mean the general strategy; i don't mind if i can't run 0.8.4
509 2013-09-09 11:21:02 <gmaxwell> berndj: running git head past the point where we fixed this may fix it for you, sorry, trying to find the commit fixing it now. Gimme a moment more.
510 2013-09-09 11:21:08 <warren> gmaxwell: yeah
511 2013-09-09 11:21:17 <warren> berndj: I have just the thing for you, hold
512 2013-09-09 11:21:51 <gmaxwell> berndj: I'm pretty sure if you just go up to git head yu'll be fine. uh you node may not start anymore, once you get past this current problem due to unrelated reasons though.
513 2013-09-09 11:22:18 <berndj> i *was* running git head, that's the one that complained
514 2013-09-09 11:22:31 <berndj> s/everything//
515 2013-09-09 11:23:14 <warren> berndj: https://github.com/litecoin-project/litecoin/commits/exp-btc09backports cherry-pick everything by sipa from here on top of 0.8.4 and it will fix your problem.
516 2013-09-09 11:23:18 <berndj> how recent is that 16-bit opcode prank thing?
517 2013-09-09 11:23:22 <warren> eh... I'll make a branch for you
518 2013-09-09 11:23:57 <berndj> ok thanks, but i'll do it after i sleep - liable to make mistakes now (my nick catcher / grep will catch your replies)
519 2013-09-09 11:24:50 <warren> berndj: there's likeliy 0.8.5 coming tomorrow anyway...
520 2013-09-09 11:24:58 <berndj> good enough for me :)
521 2013-09-09 11:25:08 <warren> but it won't contain the commmits you need to use your wallet
522 2013-09-09 11:28:46 <warren> crap, not a trivial cherry-pick back to bitcoin, there's some litecoin stuff in my commits
523 2013-09-09 11:31:00 <jgarzik> warren, huhwhuh? I look like a space invader?
524 2013-09-09 11:45:11 <gmaxwell> negative nversion explained.
525 2013-09-09 11:45:18 <gmaxwell> uninitilized memory in libbitcoin.
526 2013-09-09 11:47:46 <warren> jgarzik: github gravatar
527 2013-09-09 11:48:40 <warren> berndj: remind me tomorrow, I'll make a branch for you, too tired now, and might as well do it on top of 0.8.5
528 2013-09-09 12:19:17 <phantomcircuit> sipa, i just did a reindex on 0.8.3 under windows
529 2013-09-09 12:19:29 <phantomcircuit> successfully upto block 256934 (current best)
530 2013-09-09 12:19:51 <phantomcircuit> so much wat
531 2013-09-09 12:25:50 <jcorgan_> does anyone have the txid of the TX that caused the issue gmaxwell reported?
532 2013-09-09 13:24:26 <michagogo> Is the client smart enough to detect changes of external address?
533 2013-09-09 13:24:57 <michagogo> (for example, if I put my laptop to sleep at school and wake it up at home)
534 2013-09-09 13:29:06 <michagogo> ...odd. Apparently I had a block database corruption.
535 2013-09-09 13:29:23 <phantomcircuit> michagogo, https://github.com/bitcoin/bitcoin/pull/2982
536 2013-09-09 13:30:08 <michagogo> negative transaction versions?
537 2013-09-09 13:30:22 <phantomcircuit> michagogo, a quirk of the protocol
538 2013-09-09 13:30:45 <michagogo> "A patch free workaround is to start with -checklevel=2 which skips the consistency checks, but the IsStandard change is important for miners in order to protect unpatched nodes."
539 2013-09-09 13:31:12 <michagogo> Erm, if this transaction has been mined, how will changing IsStandard for future blocks change anything?
540 2013-09-09 13:31:33 <phantomcircuit> michagogo, the consistency checks are only run for the last 200 blocks
541 2013-09-09 13:31:47 <michagogo> Aha.
542 2013-09-09 13:32:12 <phantomcircuit> so if miners stop mining things with negative nVersion (althrough that's documented as being unsigned everywhere...) then it'll stop happening and there is more time to find unsigned/signed issues
543 2013-09-09 13:32:16 <gribble> 0.555555555556
544 2013-09-09 13:32:16 <michagogo> So in ,,(calc 2000/60/60) hours it'll be fine?
545 2013-09-09 13:32:17 <phantomcircuit> instead of pushing a fix now
546 2013-09-09 13:32:22 <michagogo> er
547 2013-09-09 13:32:27 <michagogo> I mean, 2000/60
548 2013-09-09 13:32:38 <phantomcircuit> ..calc 2000/60
549 2013-09-09 13:32:43 <gribble> (calc <math expression>) -- Returns the value of the evaluated <math expression>. The syntax is Python syntax; the type of arithmetic is floating point. Floating point arithmetic is used in order to prevent a user from being able to crash to the bot with something like '10**10**10**10'. One consequence is that large values such as '10**24' might not be exact.
550 2013-09-09 13:32:43 <michagogo> ~30ish
551 2013-09-09 13:32:43 <phantomcircuit> ,,calc 2000/60
552 2013-09-09 13:32:50 <phantomcircuit> lol seriously
553 2013-09-09 13:32:51 <michagogo> phantomcircuit: you want ;;
554 2013-09-09 13:33:03 <gribble> 33.3333333333
555 2013-09-09 13:33:03 <phantomcircuit> ;;calc 2000.0/60
556 2013-09-09 13:33:07 <phantomcircuit> yeah that
557 2013-09-09 13:33:09 <michagogo> ,, is for inline commands, and it doesn't take parameters without ()
558 2013-09-09 13:33:15 <phantomcircuit> oh
559 2013-09-09 13:33:26 <michagogo> So,
560 2013-09-09 13:33:30 <michagogo> ;;ticker --last
561 2013-09-09 13:33:31 <gribble> 127.65000
562 2013-09-09 13:34:06 <michagogo> And in the middle of a command, ;;blocks won't work, but ,,tslb will
563 2013-09-09 13:34:08 <gribble> Time since last block: 2 minutes and 12 seconds
564 2013-09-09 13:34:20 <michagogo> ;;list bitcoindata
565 2013-09-09 13:34:21 <gribble> avgprc, bcstats, blockdiff, blocks, bounty, diff, diffchange, estimate, genprob, genrate, gentime, halfreward, hextarget, interval, nethash, nextretarget, prevdiff, prevdiffchange, tblb, timetonext, totalbc, and tslb
566 2013-09-09 13:34:21 <phantomcircuit> i'll uh
567 2013-09-09 13:34:25 <phantomcircuit> probably forget that
568 2013-09-09 13:34:29 <phantomcircuit> i mean keep that in mind
569 2013-09-09 13:34:34 <phantomcircuit> yeah that oen
570 2013-09-09 13:34:45 <michagogo> And, ,,genrate 100000 won't do what it should
571 2013-09-09 13:34:46 <gribble> (genrate <hashrate> [<difficulty>]) -- Calculate expected bitcoin generation rate using <hashrate> Mhps, at current difficulty. If optional <difficulty> argument is provided, expected generation time is for supplied difficulty.
572 2013-09-09 13:34:51 <michagogo> But ,,(genrate 100000) will
573 2013-09-09 13:34:52 <gribble> The expected generation output, at 100000.0 Mhps, given difficulty of 86933017.7712, is 0.57849885961 BTC per day and 0.0241041191504 BTC per hour.
574 2013-09-09 13:35:41 <michagogo> ;;calc [blocks] - 256818 * 10
575 2013-09-09 13:35:42 <gribble> -2311237
576 2013-09-09 13:35:44 <michagogo> er
577 2013-09-09 13:35:50 <michagogo> ;;calc ([blocks] - 256818) * 10
578 2013-09-09 13:35:51 <gribble> 1250
579 2013-09-09 13:36:09 <michagogo> ;;calc ([blocks] - 256818) * 10 / 60
580 2013-09-09 13:36:10 <gribble> 20.8333333333
581 2013-09-09 13:36:30 <michagogo> It was mined 20 hours ago, so it will stop being a problem in about 12 more
582 2013-09-09 13:37:11 <phantomcircuit> michagogo, sounds about right
583 2013-09-09 13:37:15 <phantomcircuit> although interestingly my 64 bit windows 0.8.3 client didn't choke on the block in question
584 2013-09-09 13:37:31 <phantomcircuit> so there's something screwey with the way that's being compiled or something
585 2013-09-09 13:37:45 <michagogo> That you built yourself?
586 2013-09-09 13:38:44 <phantomcircuit> michagogo, nope
587 2013-09-09 13:38:47 <phantomcircuit> the normal binary
588 2013-09-09 13:39:00 <michagogo> So it's not 64 bit
589 2013-09-09 13:39:31 <michagogo> Releases are built for linux32, linux64, and win32
590 2013-09-09 13:39:54 <michagogo> phantomcircuit: If you run 0.8.4, does the problem happen?
591 2013-09-09 13:41:28 <kinlo> the block is only a prolbem when the bitcoind starts up and does it's validation
592 2013-09-09 13:41:38 <kinlo> if you just keep the daemon running, there is no issue
593 2013-09-09 13:41:46 <michagogo> kinlo: Yeah, got that
594 2013-09-09 13:42:23 <phantomcircuit> michagogo, it could very well be 32 bit actually
595 2013-09-09 13:42:30 <phantomcircuit> windows 8 obnoxiously doesn't show
596 2013-09-09 13:42:42 <michagogo> phantomcircuit: If it's the Windows release version, it is
597 2013-09-09 13:42:54 <michagogo> phantomcircuit: There's no " * 32" in taskmgr?
598 2013-09-09 13:43:04 <hydromet> hi, I'm running Bitcoin-Qt v0.8.2-313-gbb7d0fc-beta on Mac OS X ... upon running it today I received a panel stating "Corrupted block database detected. Do you want to rebuild the block database now?" Is this normal or common?
599 2013-09-09 13:43:06 <michagogo> " *32"*
600 2013-09-09 13:43:22 <kinlo> it's not because the program is running in 64 bit that it cannot handle 32 bit numbers anymore
601 2013-09-09 13:43:28 <michagogo> hydromet: There's a known bug with that at the moment
602 2013-09-09 13:43:51 <michagogo> phantomcircuit: You can check by looking at the program files folder
603 2013-09-09 13:43:57 <hydromet> michagogo: I have not yet selected "Abort" or "OK". What should I do?
604 2013-09-09 13:44:00 <michagogo> hydromet: There's no need to reindex
605 2013-09-09 13:44:04 <michagogo> Choose "Abort"
606 2013-09-09 13:44:05 <phantomcircuit> michagogo, ok yeah it is 32 bit
607 2013-09-09 13:44:20 <hydromet> thanks michagogo:
608 2013-09-09 13:44:41 <michagogo> hydromet: Choose "Abort", and then start the client by running this in Terminal:
609 2013-09-09 13:44:48 <kinlo> hydromet: just add checklevel=2 to your config file
610 2013-09-09 13:44:49 <michagogo> open /Applications/Bitcoin-Qt.app --args -checklevel=2
611 2013-09-09 13:45:01 <kinlo> more info at https://bitcointalk.org/index.php?topic=290923.0
612 2013-09-09 13:45:21 <michagogo> kinlo: Isn't it better to give it as a start argument, considering that the problem will go away in 12 hours?
613 2013-09-09 13:45:40 <kinlo> michagogo: I doubt the problem will be gone in 12h
614 2013-09-09 13:45:44 <jcorgan> michagogo: if another tx doesn't arrive
615 2013-09-09 13:45:47 <kinlo> it will take some time for the pools to upgrade
616 2013-09-09 13:45:53 <michagogo> Right, if another tx doesn't arrive
617 2013-09-09 13:46:03 <kinlo> anyone can create a new transaction, there is no special privilege involved
618 2013-09-09 13:46:03 <michagogo> kinlo: I was told that the blocks are only checked 200 blocks back
619 2013-09-09 13:46:18 <michagogo> kinlo: Do you think this attack was malicious?
620 2013-09-09 13:46:22 <hydromet> kinlo: thanks for the suggestion ... would it be helpful to build from source 0.8.4? I can pull it from GitHub
621 2013-09-09 13:46:30 <kinlo> michagogo: correct, but it's *very* easy to create a new tx that is bad
622 2013-09-09 13:46:58 <michagogo> hydromet: If you want to build a fixed version from source, you need pull request #2982
623 2013-09-09 13:47:15 <michagogo> kinlo: But unless this was malicious, it probably won't happen
624 2013-09-09 13:47:52 <kinlo> michagogo: perhaps the first one wasn't malicious, but that doesn't mean any other will be
625 2013-09-09 13:48:03 <michagogo> Ah, interesting.
626 2013-09-09 13:48:12 <kinlo> pools have been notified, but I don't think many have upgraded to reject those transactions
627 2013-09-09 13:48:40 <michagogo> (for example, if I put my laptop to sleep at school and wake it up at home)
628 2013-09-09 13:48:40 <michagogo> Is the client smart enough to detect changes of external address?
629 2013-09-09 13:49:03 <kinlo> michagogo: what do you mean by external address?
630 2013-09-09 13:49:33 <hydromet> michagogo: should I build 0.8.4? This article mentions security improvements http://thegenesisblock.com/bitcoin-0-8-4-update-provides-security-improvements/
631 2013-09-09 13:49:49 <michagogo> hydromet: 0.8.4 won't fix the problem
632 2013-09-09 13:50:01 <michagogo> hydromet: https://github.com/bitcoin/bitcoin/pull/2982 fixes the problem
633 2013-09-09 13:50:10 <michagogo> kinlo: The external IP address
634 2013-09-09 13:50:20 <kinlo> oh
635 2013-09-09 13:50:42 <kinlo> I expect it to recover just fine, but I'm not familiar with that part of the code
636 2013-09-09 13:53:34 <aoeu> Any Windows Phone user here?
637 2013-09-09 13:53:39 <aoeu> I built an app. Here are some details: https://github.com/miguelrochefort/Bitcoin-for-Windows-Phone
638 2013-09-09 13:53:53 <jeremias> cool
639 2013-09-09 13:54:02 <jeremias> so it is web wallet based?
640 2013-09-09 13:54:10 <aoeu> Yes.
641 2013-09-09 13:54:18 <aoeu> Not standalone/native.
642 2013-09-09 13:54:40 <aoeu> It works with both Blockchain and Coinbase. It integrates into the OS.
643 2013-09-09 13:54:45 <aoeu> (the Wallet hub)
644 2013-09-09 13:55:09 <hydromet> michagogo: sorry, I'm also new to git / github and am using an app called SourceTree for github ... I see pull 2982 is in the master branch on the web page you directed me to but I don't see it in my SourceTree view even though I just updated all the available pull requests
645 2013-09-09 13:55:58 <michagogo> ACTION doesn't know what SourceTree is
646 2013-09-09 13:56:46 <michagogo> You could always see https://github.com/gmaxwell/bitcoin/tree/20130908_ccoins_corrupt
647 2013-09-09 13:56:54 <hydromet> http://www.sourcetreeapp.com/
648 2013-09-09 13:57:55 <michagogo> If you're not using it for merchant or mining applications and you're willing to run master (bleeding edge unsupported), you can download and build https://github.com/gmaxwell/bitcoin/tree/20130908_ccoins_corrupt
649 2013-09-09 13:58:35 <sipa> phantomcircuit: there is no problem at all, and there is no corruption or condition that crashes nodes
650 2013-09-09 13:58:36 <michagogo> Otherwise you could try rebasing commit f8b7aa862519ab2efd1ce327d2ed4bea1325dc11 onto v0.8.4
651 2013-09-09 13:58:38 <hydromet> I'm not using it for mining or merchant applications
652 2013-09-09 13:59:01 <sipa> phantomcircuit: it's just that the check at startup fails if a particular transaction is wirhin the chexk window
653 2013-09-09 14:00:14 <michagogo> sipa: Is the client smart enough to detect changes of external address?
654 2013-09-09 14:00:30 <michagogo> (for example, if I put my laptop to sleep at school and wake it up at home)
655 2013-09-09 14:00:52 <hydromet> michagogo: I can probably live with the known bug with regard to that error panel ... I should (first step) figure out how to get myself to 0.8.4, thank you for your suggestions
656 2013-09-09 14:01:11 <michagogo> What linux distro?
657 2013-09-09 14:01:17 <hydromet> OS X
658 2013-09-09 14:01:20 <michagogo> Ah
659 2013-09-09 14:01:22 <hydromet> Like Gavin
660 2013-09-09 14:01:43 <michagogo> Oh, sorry -- it was someone in #bitcoin who was on linux
661 2013-09-09 14:01:48 <sipa> michagogo: no, it only detects the own ip at startup
662 2013-09-09 14:01:57 <michagogo> anyway, http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/bitcoin-0.8.4-macosx.dmg/download
663 2013-09-09 14:02:04 <michagogo> sipa: So what happens if it moves networks?
664 2013-09-09 14:02:26 <sipa> michagogo: it will probably report a wrong ip to others
665 2013-09-09 14:02:27 <hydromet> thanks
666 2013-09-09 14:02:34 <michagogo> Does it just advertise wrong addresses?
667 2013-09-09 14:02:36 <michagogo> Hmm
668 2013-09-09 14:02:50 <sipa> michagogo: and become less reachable over time
669 2013-09-09 14:03:01 <michagogo> Hmm, okay
670 2013-09-09 14:03:04 <michagogo> ACTION restarts his nodes
671 2013-09-09 14:05:31 <jgarzik> sipa, gmaxwell, just got asked a fair question: if the TX w/ bad version got mined (and is thus valid), why does the validation code complain?
672 2013-09-09 14:05:35 <hydromet> Hmm ... I selected "Abort" when the aforementioned bug presented itself and after selecting, Bitcoin-Qt quits on me.
673 2013-09-09 14:05:50 <jgarzik> seems like we want harmonization of rules
674 2013-09-09 14:06:35 <michagogo> hydromet: Yes, "abort" tells it to abort the startup
675 2013-09-09 14:06:59 <michagogo> hydromet: What you want to do is click Abort to have it abort the startup, and then start with the -checklevel=2 option
676 2013-09-09 14:07:04 <sipa> jgarzik: validation works fine, the block is valid
677 2013-09-09 14:07:21 <sipa> jgarzik: it just gets stored in a way that mismatches the transaction data
678 2013-09-09 14:07:26 <hydromet> michagogo: ah, got it now (sequence)
679 2013-09-09 14:07:30 <sipa> so the consistency check at startup complains
680 2013-09-09 14:07:40 <sipa> so the consisitency check is wrong
681 2013-09-09 14:08:04 <michagogo> hydromet: Assuming that you have Bitcoin-Qt in /Applications, click Abort, then execute `open /Applications/Bitcoin-Qt.app --args -checklevel=2` in Terminal
682 2013-09-09 14:08:57 <michagogo> (-checklevel=2 will make it reduce the stringency of the block validation, skipping the part that has the bug)
683 2013-09-09 14:10:34 <hydromet> michagogo: yep, that worked, thanks!
684 2013-09-09 14:10:44 <michagogo> Great
685 2013-09-09 14:10:49 <hydromet> why would this bug start to appear today? iIs it spurious?
686 2013-09-09 14:11:01 <michagogo> It's a certain transaction
687 2013-09-09 14:11:06 <hydromet> really?
688 2013-09-09 14:11:13 <hydromet> one specific transaction in the blockchain?
689 2013-09-09 14:11:13 <michagogo> hydromet: see https://bitcointalk.org/index.php?topic=290923.0
690 2013-09-09 14:11:48 <michagogo> Yes -- the way it's formed causes the storage to mess up
691 2013-09-09 14:11:54 <michagogo> so the consistency check fails
692 2013-09-09 14:12:09 <michagogo> skips these and other checks and allows the node to proceed as usual."
693 2013-09-09 14:12:09 <michagogo> "The problem that an inconsistency in the transaction database has been caused by some unusual whos version cannot be represented in the database. This inconsistency is correctly detected by the agressive database sanity-checks on startup. Because this inconsistency happens to be in a field we currently do not use for anything, it is safe to ignore it for now. Lowering the checklevel
694 2013-09-09 14:12:25 <hydromet> fascinating
695 2013-09-09 14:12:52 <michagogo> Within about 200 blocks (~30 hours), if no other transactions like this are mined, the issue will resolve itself
696 2013-09-09 14:13:19 <michagogo> But now that the problem's exposed, other transactions like this may very well get mined.
697 2013-09-09 14:13:22 <hydromet> even more fascinating ... the learning journey into bitcoin is amazing
698 2013-09-09 14:13:30 <phantomcircuit> sipa, i know but shouldn't it still be for an upto date client?
699 2013-09-09 14:14:06 <michagogo> phantomcircuit: Come again?
700 2013-09-09 14:14:39 <phantomcircuit> shouldn't it still be failing for a node with all the blocks on start
701 2013-09-09 14:14:54 <hydromet> I have only made six transactions with my wallet using Bitcoin-Qt. The first five were receives of payment. The sixth was a payment I made to another address.
702 2013-09-09 14:15:04 <hydromet> When I made this payment using the Send section of Bitcoin-Qt
703 2013-09-09 14:15:36 <hydromet> I didn't notice that the address to send to would eventually display in the Addresses section
704 2013-09-09 14:15:45 <hydromet> So this is automatically what happens every time you send?
705 2013-09-09 14:15:50 <michagogo> hydromet: It doesn't if you don't give it a label