1 2013-09-15 00:04:08 <kuzetsa> sipa: also, looking at AddTimeData() in util.cpp there is a calculation which seems to look at minutes offset and then seems to assume things like "plus or minus 70 minutes will account for summer time, and up to a 10 minute variance"
2 2013-09-15 00:04:51 <kuzetsa> but I can only guess, as the reasons for the code: if (abs64(nMedian) < 70 * 60) generically says "// Only let other nodes change our time by so much" in commentary
3 2013-09-15 00:06:12 <kuzetsa> and I had to infer that was minutes, because there's no commentary a few lines prior where the value was quantized to 60 second granularity without any comment explaining the operation
4 2013-09-15 00:09:32 <kuzetsa> incidentally, gcc's non-optimization / implementation for mingw target does a bad job with int64 division... but for readability sake letting the divides be done using a more readable version is fine I guess (this bug was recently fixed in #cgminer-dev, but in that case it was being called millions of times per day & really added up to alot)
5 2013-09-15 00:12:00 <Luke-Jr> kuzetsa: can you provide a reference/citation for this? sounds pretty weird that something so simple would work poorly
6 2013-09-15 00:12:52 <kuzetsa> Luke-Jr: we actually tested it / profiled the code and looked at CPU usage
7 2013-09-15 00:13:36 <Luke-Jr> kuzetsa: so nobody disassembled it to confirm?
8 2013-09-15 00:14:27 <Luke-Jr> kuzetsa: can you post a summary of what was found, or at least maybe an IRC log?
9 2013-09-15 00:16:18 <Luke-Jr> not sure it makes sense to workaround compiler bugs in any case - probably best to fix the compiler
10 2013-09-15 00:20:08 <kuzetsa> http://pastebin.com/j6ErQxYw <-- #cgminer-dev log for luke, Paste expiration 1 hour (also contains a link for the commit in question)
11 2013-09-15 00:21:04 <kuzetsa> lldiv is a windows API (OS-level syscall to work around various compilers not doing a good job at optimization)
12 2013-09-15 00:22:45 <kuzetsa> I'll leave the details for how much more accurate the timing code is on this routine (and how much more efficient it is compared to using a 64 bit divide provided by gcc's mingw target)
13 2013-09-15 00:23:04 <kuzetsa> like... I'll leave that for you to wonder about
14 2013-09-15 00:32:46 <Luke-Jr> kuzetsa: that seems to just talk about a suspicion?
15 2013-09-15 00:33:28 <Luke-Jr> using a syscall for lldiv sounds.. very odd
16 2013-09-15 00:42:01 <TradeFortress> any way to reduce the frequency of wallet.dat flushes?
17 2013-09-15 00:42:29 <kuzetsa> just log where we profiled the lldiv versus a "/" operator provided by gcc's mingw target... microsoft's optimized lldiv API routine exist isn't called by mingw. period.
18 2013-09-15 00:42:54 <kuzetsa> *exists for a reason, and isn't called by gcc mingw target.
19 2013-09-15 00:43:21 <kuzetsa> just test it in a loop if you don't believe that it works better than "/"
20 2013-09-15 00:44:32 <TradeFortress> Is it safe to reduce the frequency of wallet.dat flushes?
21 2013-09-15 00:46:17 <gavinandresen> TradeFortress: if you are running with a UPS in an area that doesn't have prolonged power outages on a RAID-redundant filesystem⦠sure, should be safe.
22 2013-09-15 00:47:02 <TradeFortress> Thanks.
23 2013-09-15 01:07:50 <Luke-Jr> kuzetsa: was this with current mingw64, or the older one that only supports 32-bit?
24 2013-09-15 01:08:04 <Luke-Jr> guess I can do a few tests myself
25 2013-09-15 01:16:04 <TradeFortress> hmm
26 2013-09-15 01:16:25 <TradeFortress> even after wallet flushing throttled, bitcoind still bursts to 100% cpu for a few seconds frequently
27 2013-09-15 01:18:47 <gmaxwell> b< kuzetsa> incidentally, gcc's non-optimization / implementation for mingw target does a bad job with int64 division...
28 2013-09-15 01:18:54 <gmaxwell> ^ where do you need int64 division?
29 2013-09-15 01:19:10 <gmaxwell> esp division not by a constant?
30 2013-09-15 01:22:12 <warren> grr... bitcoin-qt.pro is a bit confusing to modify
31 2013-09-15 01:25:49 <TradeFortress> Anyway to find out what is causing the high CPU usage?
32 2013-09-15 01:26:44 <gmaxwell> TradeFortress: -EINSUFFICENTINFORMATION
33 2013-09-15 01:26:51 <gmaxwell> TradeFortress: do you mean during syncup?
34 2013-09-15 01:27:07 <TradeFortress> gmaxwell, no, during "normal usage" / json-rpc calls
35 2013-09-15 01:27:20 <TradeFortress> I do not see anything particularly interesting in debug.log
36 2013-09-15 01:27:26 <gmaxwell> TradeFortress: does your wallet contain a lot of unconfirmed coins?
37 2013-09-15 01:27:50 <gmaxwell> can you try running without a wallet to see if the issue is wallet related?
38 2013-09-15 01:28:03 <TradeFortress> Not unconfirmed coins, but it does contain a significant amount of addresses and coins.
39 2013-09-15 01:28:12 <warren> TradeFortress: master?
40 2013-09-15 01:28:20 <warren> TradeFortress: phantomcircuit has two patches that boost wallet performance
41 2013-09-15 01:28:36 <TradeFortress> hmm, I'll have to convert my wallet.dat first
42 2013-09-15 01:29:10 <gmaxwell> TradeFortress: Convert?
43 2013-09-15 01:29:12 <TradeFortress> It only bursts to 100% CPU for certain amounts of time.
44 2013-09-15 01:29:37 <warren> TradeFortress: you still have those addresses that are unable to be read by 0.8.x?
45 2013-09-15 01:29:40 <gmaxwell> TradeFortress: is this when it's recieving a new block? Do you have incoming connections?
46 2013-09-15 01:29:52 <gmaxwell> wait. this is on an old version?
47 2013-09-15 01:29:56 <TradeFortress> warren, No, remember when master had a bug in it that made addresses unreadable?
48 2013-09-15 01:30:10 <warren> TradeFortress: yeah, did you migrate from those addresses?
49 2013-09-15 01:30:44 <TradeFortress> I'm using a patch that allows it to read those. With v0.8.4, I see "Error reading wallet database: CPrivKey pubkey inconsistency"
50 2013-09-15 01:31:11 <warren> TradeFortress: right, litecoin actually ships that in our 0.8.x
51 2013-09-15 01:31:35 <TradeFortress> gmaxwell, it happens when receiving a new block but that is expected. Yes, I am accepting incoming connections.
52 2013-09-15 01:32:16 <gmaxwell> not entirely expected, due to caching accepting a new block shouldn't be that much of a hit.
53 2013-09-15 01:32:22 <gmaxwell> so you are running what version?
54 2013-09-15 01:32:51 <gmaxwell> and I do not understand why you wrote "I'll have to convert my wallet.dat first"
55 2013-09-15 01:33:10 <sipa> gmaxwell: i suppose he means fix the pubkey/privkey correspondence in it
56 2013-09-15 01:33:14 <TradeFortress> gmaxwell, the wallet.dat I have right now is unreadable on v0.8.4 / etc
57 2013-09-15 01:33:41 <sipa> so what version are you running now?
58 2013-09-15 01:33:59 <TradeFortress> I'm running 0.8.3 with a patch that allows it to be read
59 2013-09-15 01:34:15 <sipa> such a patch should apply cleanly on 0.8.5
60 2013-09-15 01:34:23 <sipa> as the changes in .4 and .5 are very small
61 2013-09-15 01:34:31 <gmaxwell> I would suggest you turn off incoming connections if you plan on contiuning to run 0.8.3 for now.
62 2013-09-15 01:34:35 <sipa> ah, but you mean master
63 2013-09-15 01:34:36 <gmaxwell> But thats an aside.
64 2013-09-15 01:34:40 <sipa> master likely has larger changes
65 2013-09-15 01:35:09 <gmaxwell> TradeFortress: in any case, are you able to try running without a wallet for a bit and see if the cpu spikes still happen? (I do not know what you use this node for)
66 2013-09-15 01:35:25 <sipa> that'd be interesting indeed
67 2013-09-15 01:36:05 <gmaxwell> alternatively, running without inbound connections would be interesting (and less disruptive than swapping out the wallet)
68 2013-09-15 01:36:10 <gmaxwell> (perhaps)
69 2013-09-15 01:36:12 <TradeFortress> I'll try both of them
70 2013-09-15 01:36:36 <gmaxwell> one at a time please. :P
71 2013-09-15 01:36:55 <TradeFortress> blocking port 8333 incoming should do?
72 2013-09-15 01:37:53 <gmaxwell> -listen=0 is probably better... assuming you already have incoming connections;
73 2013-09-15 01:38:05 <TradeFortress> Ok.
74 2013-09-15 01:38:47 <warren> TradeFortress: if you still have problems let me know, I'll make a bitcoin-0.8.5 for you with support for those addresses + huge wallet performance patches
75 2013-09-15 01:39:05 <warren> TradeFortress: we already are testing those backports in litecoin so it'll be easy for me
76 2013-09-15 01:39:50 <TradeFortress> warren, we are referring to the same issue right? the addresses were not from an ancient version of bitcoind, it's just corrupt due to a broken change in master
77 2013-09-15 01:40:18 <warren> TradeFortress: yes, same issue
78 2013-09-15 01:40:26 <warren> TradeFortress: litecoin ships all that in our 0.8.x
79 2013-09-15 01:40:32 <gmaxwell> warren: why?
80 2013-09-15 01:40:57 <warren> gmaxwell: we were shipping the patches to allow drop-in replacement of secp256k1 for months now
81 2013-09-15 01:41:07 <gmaxwell> huh?
82 2013-09-15 01:41:40 <gmaxwell> How is that related?
83 2013-09-15 01:41:52 <warren> gmaxwell: master had a series of patches that refactored cprivkey stuff, introduced that non-backward compatible address issue that was later fixed in another patch
84 2013-09-15 01:42:17 <warren> gmaxwell: we shipped those patches in 0.8.x because we had been shipping both openssl and secp256k1 builds for months
85 2013-09-15 01:42:52 <warren> gmaxwell: and after we realized it wasn't backward compatible, we just kept the master patches. not a big deal because we had no older 0.8 versions to worry about.
86 2013-09-15 01:42:53 <gmaxwell> oh because the secp256k1 patches were ontop of the cprivkey refactor?
87 2013-09-15 01:42:57 <warren> yes
88 2013-09-15 01:43:06 <gmaxwell> Okay, I understand now.
89 2013-09-15 01:43:34 <TradeFortress> disabling incoming connections does not help with the 100% cpu issue
90 2013-09-15 01:43:59 <gmaxwell> TradeFortress: so you restarted with incoming connections disabled and you're still seeing new block unrelated cpu spikes?
91 2013-09-15 01:44:05 <TradeFortress> yes
92 2013-09-15 01:44:12 <gmaxwell> cool okay.
93 2013-09-15 01:44:22 <gmaxwell> how are you measuring the spikes btw?
94 2013-09-15 01:44:32 <TradeFortress> top
95 2013-09-15 01:44:40 <gmaxwell> how often are they?
96 2013-09-15 01:44:40 <warren> TradeFortress: how many addresses/tx are in that wallet?
97 2013-09-15 01:45:29 <gmaxwell> (I'm asking so I can figure out how long I have to watch to know if I'm getting them too)
98 2013-09-15 01:45:44 <warren> TradeFortress: I didn't fully test backports of this yet, but there are three proposed huge wallet performance PR's. https://github.com/bitcoin/bitcoin/pull/2950 https://github.com/bitcoin/bitcoin/pull/2952 https://github.com/bitcoin/bitcoin/pull/2966
99 2013-09-15 01:47:00 <TradeFortress> I think the problem is with the lack of scalability for getbalance on a wallet with 8000 addresses
100 2013-09-15 01:47:12 <TradeFortress> doesn't happen with an empty wallet
101 2013-09-15 01:47:16 <sipa> the cpu spike is when you call getbalance?
102 2013-09-15 01:47:26 <gmaxwell> 8000 addresses shouldn't be a problem. Though getbalance does a lot of things.
103 2013-09-15 01:47:45 <sipa> it's the number of transactions that counts for getbalance
104 2013-09-15 01:48:11 <TradeFortress> with a lot of transactions.
105 2013-09-15 01:48:16 <gmaxwell> (this was also why I asked about unconfirmed transactions)
106 2013-09-15 01:48:33 <sipa> the cpu spike is when you call getbalance?
107 2013-09-15 01:48:43 <TradeFortress> sipa, yes, when it's called frequently
108 2013-09-15 01:48:54 <sipa> every time it's called?
109 2013-09-15 01:48:55 <TradeFortress> gmaxwell, There's not too many unconfirmed transactions.
110 2013-09-15 01:49:07 <sipa> or only when it's called in rapid succession?
111 2013-09-15 01:49:35 <sipa> ACTION zZ
112 2013-09-15 01:49:42 <TradeFortress> sipa, I'm investigating it more.
113 2013-09-15 01:51:35 <TradeFortress> " in response to a getbalance call?
114 2013-09-15 01:51:35 <TradeFortress> Is it normal to see "CWalletTx::GetAmounts: Unknown transaction type found, txid 3a3d980ea453dde11e9b7954ef2882d6888013e8b7e3d69a399cd373bbbdc378
115 2013-09-15 01:51:38 <TradeFortress> (in debug.log)
116 2013-09-15 01:52:19 <TradeFortress> I'm guessing it is, looks like p2pool
117 2013-09-15 01:55:51 <TradeFortress> sipa, without getbalance it's at 1%, with a getbalance it spikes to 34% (according to top) for a second.
118 2013-09-15 01:56:05 <TradeFortress> so multiple getbalances would push it to 100%.
119 2013-09-15 01:57:07 <gmaxwell> TradeFortress: I've gotten that message during rescan in my own wallet that has some crazy stuff in it.
120 2013-09-15 01:57:13 <gmaxwell> But I do not get it on getbalance.
121 2013-09-15 01:57:26 <gmaxwell> though perhaps if I had some unconfirmed crazy stuff in my wallet I would.
122 2013-09-15 01:58:08 <TradeFortress> There are 21 unconfirmed TXes.
123 2013-09-15 02:01:42 <gmaxwell> The really expensive case is when there is a chain of unconfirmed transactions.
124 2013-09-15 02:03:12 <TradeFortress> A chain as in unconfirmed txes that spends unconfirmed coins, or?
125 2013-09-15 02:03:45 <gmaxwell> right.
126 2013-09-15 02:03:47 <warren> anyone familiar with how to modify bitcoin-qt.pro to build one .cpp file with -msse2? hmmm
127 2013-09-15 02:04:36 <TradeFortress> I don't think that is what's happening here.
128 2013-09-15 02:14:49 <TradeFortress> At what number of transactions should getbalance be slowing down?
129 2013-09-15 02:35:55 <kuzetsa> gmaxwell: AddTimeData() ... int64 nOffsetSample ... more than one printf debug or logging line contains: "nOffsetSample/60" <--- so probably not an issue really. I wasn't paying attention & the code in question isn't called very often (and seems to be debug / logging related)
130 2013-09-15 02:43:46 <Luke-Jr> kuzetsa: ironically, my benchmark found that WINE performs int64_t division faster than native Linux!
131 2013-09-15 02:44:10 <Luke-Jr> with -O0
132 2013-09-15 02:48:43 <kuzetsa> that's not really a useful benchmark
133 2013-09-15 02:49:10 <Luke-Jr> and why not?
134 2013-09-15 02:49:21 <kuzetsa> because wine was clean room reverse engineered
135 2013-09-15 02:49:23 <Luke-Jr> â¦
136 2013-09-15 02:49:31 <Luke-Jr> WINE isn't related
137 2013-09-15 02:49:37 <Luke-Jr> it's just loading the program
138 2013-09-15 02:49:45 <Luke-Jr> the program itself runs exactly like it would in Windows
139 2013-09-15 02:49:54 <Luke-Jr> it's not like there's any translation involved in dividing
140 2013-09-15 02:49:57 <kuzetsa> no, it doesn't
141 2013-09-15 02:50:03 <Luke-Jr> for this it does
142 2013-09-15 02:50:08 <kuzetsa> it's quite common for benchmarks on wine to run better than on native windows
143 2013-09-15 02:51:01 <Luke-Jr> this is a simple division operator
144 2013-09-15 02:51:08 <Luke-Jr> it doesn't use any windows API calls at all
145 2013-09-15 02:52:19 <kuzetsa> if you're not testing the behavior & profiling it on an actual windows machine on bare metal hardware, don't bother claiming you did a benchmark based on real-world usage scenarios
146 2013-09-15 02:52:32 <kuzetsa> wine / VM is not the same thing
147 2013-09-15 02:52:45 <kuzetsa> it really doesn't matter for this anyway
148 2013-09-15 02:52:59 <kuzetsa> it's not called often enough for the increased performance to matter
149 2013-09-15 02:53:10 <Luke-Jr> whatever, you're obviously completely wrong about this and I don't care
150 2013-09-15 02:53:44 <kuzetsa> I just helped con fix the bug in implementation. I'm not the one who discovered it or did the profiling.
151 2013-09-15 02:54:12 <Luke-Jr> it wouldn't be the first time con has fixed non-bugs
152 2013-09-15 02:55:19 <kuzetsa> 15ms timing granularity VS sub-microsecond is an actual bug, all I did was help come up with an efficient way to rebase the syscall to posix-style format :P
153 2013-09-15 02:56:59 <Luke-Jr> meh, for timing QueryPerformanceCounter :P
154 2013-09-15 03:02:12 <warren> hmm, does bitcoin-qt.pro and qmake have anything to do with the src/makefile.*?
155 2013-09-15 03:02:15 <warren> entirely separate right?
156 2013-09-15 03:08:08 <Luke-Jr> right
157 2013-09-15 03:36:56 <Luke-Jr> According to https://howsecureismypassword.net/ , the password "aaaaaaaaaaaaaaaaaaaaa" would take 4 trillion years to crack.
158 2013-09-15 03:36:58 <Luke-Jr> <.<
159 2013-09-15 03:39:34 <gmaxwell> blockchain.info claims "It would take a desktop PC About 65 trillion years to hack your password"
160 2013-09-15 03:40:47 <gmaxwell> way more secure than qwertyqwerty! which it says would take a hundred thousand years to crack.
161 2013-09-15 03:41:50 <Luke-Jr> haha
162 2013-09-15 03:42:30 <gmaxwell> all these things way underestimate the speed of password crackers and way overestimate the entropy of strings users actually produce.
163 2013-09-15 04:54:08 <hydromet> gavinandersen: I have apparently succeeded in getting Bitcoin-Qt.app to build on my Mac running OS X 10.8.4
164 2013-09-15 04:54:33 <hydromet> but with a possible caveat
165 2013-09-15 04:54:50 <hydromet> in that the only way I could do so was with -> make deploy
166 2013-09-15 04:55:21 <hydromet> and make deploy has issues on my system (it want to create a .dmg file but fails) ... this is ok, I don't want a .dmg file
167 2013-09-15 04:55:49 <hydromet> so I end up with Bitcoin-Qt.app in dist/
168 2013-09-15 04:56:01 <hydromet> but not in the root source directory
169 2013-09-15 04:56:19 <hydromet> fanquake: nice to see you here
170 2013-09-15 04:56:52 <fanquake> hey hydromet
171 2013-09-15 04:57:02 <hydromet> fanquake: yesterday I think you said for building Bitcoin-Qt.app on OS X, it was correct to use ...
172 2013-09-15 04:57:03 <hydromet> ./autogen.sh && ./configure && make
173 2013-09-15 04:57:19 <fanquake> Correct
174 2013-09-15 04:57:30 <hydromet> in doing so I was unable to generate an actual Bitcoin-Qt.app on my system (OS X 10.8.4)
175 2013-09-15 04:57:39 <hydromet> so I tried sipa's suggestion of following that up with ...
176 2013-09-15 04:57:41 <hydromet> make deploy
177 2013-09-15 04:57:52 <hydromet> but make deploy wants to build a .dmg file and fails to do so
178 2013-09-15 04:58:04 <hydromet> however, I am left with dist/Bitcoin-Qt.app
179 2013-09-15 04:58:25 <hydromet> do you think its safe to run dist/Bitcoin-Qt.app ?
180 2013-09-15 04:59:03 <hydromet> fanquake: how did you end up getting Bitcoin-Qt.app to generate on your Mac?
181 2013-09-15 04:59:45 <fanquake> hydromet .When you do /autogen.sh && ./configure && make, do you get a corrupted .app, or no .app at all?
182 2013-09-15 04:59:53 <hydromet> no .app at all
183 2013-09-15 05:00:26 <hydromet> fanquake: and this is all from the latest Master (with autotools etc.)
184 2013-09-15 05:00:54 <hydromet> fanquake: I have Qt-4 installed on my machine via MacPorts (paralleling Gavin)
185 2013-09-15 05:01:19 <fanquake> Check in your config.log, it should be in the bitcoin dir
186 2013-09-15 05:02:36 <hydromet> fanquake: what should I be looking for in config.log?
187 2013-09-15 05:03:39 <hydromet> fanquake: btw, before make deploy, I do get a binary executable named "bitcoin-qt" in src/qt
188 2013-09-15 05:04:19 <hydromet> fanquake: likewise I get bitcoind binary executable to build no problem in src/
189 2013-09-15 05:05:19 <hydromet> fanquake: on your Mac, can you check to see if you have appscript installed such as /Library/Python/2.7/site-packages/appscript-1.0.1-py2.7-macosx-10.7-intel.egg
190 2013-09-15 05:05:39 <hydromet> Gavin mentioned earlier today he has that file (albeit its for OS X 10.7 aka "Lion")
191 2013-09-15 05:06:01 <hydromet> fanquake: are you running OS X 10.8.x?
192 2013-09-15 05:06:37 <fanquake> hydromet yep, 10.8.4
193 2013-09-15 05:07:29 <hydromet> fanquake: so you have no problems building Bitcoin-Qt.app straight out of Master with autotools?
194 2013-09-15 05:08:44 <fanquake> hydromet, I can build a .app, but with it's corrupted at the moment.
195 2013-09-15 05:09:24 <hydromet> fanquake: sigh, sorry to learn this ... I wonder how it became corrupted?
196 2013-09-15 05:09:50 <fanquake> It's just because it can't find the bdb library
197 2013-09-15 05:10:11 <hydromet> are you using brew?
198 2013-09-15 05:10:17 <fanquake> Yea
199 2013-09-15 05:10:37 <hydromet> I wish I could help - I'm using MacPorts (paralleling Gavin)
200 2013-09-15 05:11:17 <fanquake> I'll take a look at it again this arvo, should be able to fix it up.
201 2013-09-15 05:13:04 <hydromet> fanquake: my intuition is that there could be problems down the road for OS X and Bitcoin-Qt (concerns about Qt-4 being maintained as new OS X systems come out) ... we're a month or so away from OS X 10.9 release from Apple
202 2013-09-15 05:13:32 <hydromet> fanquake: there might be maintenance issues, regarding Qt-4 and OS X 10.9
203 2013-09-15 05:13:39 <fanquake> hydromet, I just install the app script needed for make deploy, and it builds a perfectly good .dmg, and the .app runs fine.
204 2013-09-15 05:13:43 <fanquake> *installed
205 2013-09-15 05:14:10 <hydromet> fanquake: to install appscript you ran easy_install ?
206 2013-09-15 05:14:20 <fanquake> yep
207 2013-09-15 05:14:42 <hydromet> fanquake: what about python on your system, are you using Apple's included python or Brew installed python?
208 2013-09-15 05:15:11 <fanquake> Brew Python
209 2013-09-15 05:15:12 <hydromet> fanquake: I ask because the mac deploy script is a python script which imports appscript
210 2013-09-15 05:15:29 <hydromet> interesting
211 2013-09-15 05:16:02 <hydromet> fanquake after installing appscript you ran "make deploy" or only "./autogen.sh && ./configure && make" ?
212 2013-09-15 05:17:09 <fanquake> I just ran ./autogen.sh && ./configure, then make deploy
213 2013-09-15 05:42:39 <hydromet> fanquake: glad you got yours to work, it didn't help me to run easy_install
214 2013-09-15 05:43:18 <hydromet> make deploy complains as in:
215 2013-09-15 05:43:35 <hydromet> Processing libtiff.5.dylib ...
216 2013-09-15 05:43:45 <hydromet> install_name_tool: changing install names or rpaths can't be redone for: dist/Bitcoin-Qt.app/Contents/Frameworks/libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
217 2013-09-15 05:44:13 <fanquake> If you already had the app script in place, easy install shouldn't have done much. You wouldn't have be able to get to building the dmg with said script.
218 2013-09-15 05:44:18 <fanquake> *without
219 2013-09-15 05:45:05 <hydromet> fanquake: I was not able to build the .dmg
220 2013-09-15 05:45:22 <hydromet> this is nuts
221 2013-09-15 05:46:21 <hydromet> I have no idea how Gavin et al have been able to build on OS X ... good luck once Bitcoin 0.9 becomes available and autotools are required
222 2013-09-15 05:46:52 <hydromet> fanquake: I might see if I can simply build the 0.8.5 branch which does not require autotools (but try to use Qt-4 instead of Qt-5)
223 2013-09-15 05:47:50 <gmaxwell> the person who did most of the autotools work is primarly on OSX. ... I suspect that there is just something obvious you're missing.
224 2013-09-15 05:48:13 <gmaxwell> hopefully you'll hang around and get it figured out so we can make sure it's clear in the documentation.
225 2013-09-15 05:48:27 <hydromet> gmaxwell: I'm not about to give up :-)
226 2013-09-15 05:48:44 <hydromet> gmaxwell: I will definitely help out
227 2013-09-15 05:49:04 <hydromet> is the person who did most of the autotools work wumpus?
228 2013-09-15 05:49:56 <gmaxwell> no, it was cfields / theuni
229 2013-09-15 05:49:57 <fanquake> hydromet you should be able to build the 0.8.5 branch just fine
230 2013-09-15 05:51:58 <hydromet> fanquake: I had problems with 0.8.5 and Qt-5 yesterday, but now I have Qt-4 installed (as a MacPort similar to Gavin) I am crossing my fingers it will work
231 2013-09-15 05:53:12 <hydromet> gmaxwell: I should probably get cfields and theuni some feedback, perhaps best via email then
232 2013-09-15 05:53:47 <gmaxwell> cfields == theuni
233 2013-09-15 05:54:02 <gmaxwell> But yes, talking with him will be helpful.
234 2013-09-15 05:54:13 <hydromet> oops
235 2013-09-15 05:54:46 <hydromet> I didn't realize he/she is both
236 2013-09-15 05:54:54 <hydromet> he
237 2013-09-15 05:57:31 <fanquake> hydromet in regards to your make deploy error, it looks like it could be related to building for >= osx 10.6
238 2013-09-15 06:00:59 <hydromet> fanquake: hmm ... I guess so ... make deploy seems to have a problem with my having libtiff and libjpeg installed as a MacPort (something to that effect if I'm parsing the errors correctly)
239 2013-09-15 06:02:12 <fanquake> hydromet see https://trac.macports.org/ticket/39221
240 2013-09-15 06:03:16 <hydromet> gmaxwell: one thing about me, I don't give up ... and I emphatically believe bitcoin is massively important to the world
241 2013-09-15 06:04:31 <hydromet> fanquake: you are awesome! thank you, that looks like an excellent thread to read!
242 2013-09-15 06:06:34 <fanquake> hydromet try port -ns upgrade --force tiff
243 2013-09-15 06:07:25 <hydromet> fanquake: that's exactly what I was thinking
244 2013-09-15 06:08:59 <hydromet> fanquake: I just noticed my tiff libraries in MacPorts are from February of this year so it could very well be that the upgrade is required
245 2013-09-15 06:15:55 <hydromet> fanquake: I have installed (via MacPorts) qt4-mac but not qt4-creator-mac
246 2013-09-15 06:16:01 <hydromet> would that matter?
247 2013-09-15 06:18:16 <fanquake> Not entirely sure, but I don't think so, have you rebuilt libtiff and tried make deploy again?
248 2013-09-15 06:19:38 <hydromet> fanquake: I'm about to rebuild tiff - I was first checking some things (I want to make sure there are not any unintended consequences of rebuilding tiff)
249 2013-09-15 06:25:59 <hydromet> fanquake: I just rebuilt tiff ... now about to try again (crossing fingers)
250 2013-09-15 06:31:48 <warren> amazingly how much pain it is to add a compile flag to one file but not others in a qmake pro file
251 2013-09-15 06:32:05 <warren> you need to define an entire QMAKE_EXTRA_COMPILERS
252 2013-09-15 06:32:09 <hydromet> fanquake: gmaxwell: SHAZAM! I go it to work!
253 2013-09-15 06:32:19 <hydromet> hurray!
254 2013-09-15 06:32:27 <fanquake> hydromet great
255 2013-09-15 06:32:45 <hydromet> this is really going to be helpful for others who are using the older tiff (from MacPorts)
256 2013-09-15 06:33:24 <hydromet> this makes me wonder when gavinandresen: had installed tiff from MacPorts on his system?
257 2013-09-15 06:34:47 <gavinandresen> tiff @4.0.3 graphics/tiff
258 2013-09-15 06:35:24 <hydromet> gavinandresen: tiff @4.0.3_1 (active)
259 2013-09-15 06:36:01 <hydromet> fanquake: thanks a TON for your help!
260 2013-09-15 06:51:02 <numismatics> osx bitcoin-qt 0.8.5 seems copasetic now
261 2013-09-15 06:58:35 <nsh> nu
262 2013-09-15 07:00:42 <hydromet> numismatics: did you build 0.8.5 from source?
263 2013-09-15 07:02:00 <hydromet> gavinandresen: the macports tiff versioning nuance is quite important - there might be quite a few people who have the older version, so it will be good to get this in the documentation for 0.9
264 2013-09-15 07:02:50 <hydromet> I may rebuild my ports that depend on the tiff port as noted by the forced upgrade this warning
265 2013-09-15 07:02:54 <hydromet> Warning: Uninstall forced. Proceeding despite dependencies.
266 2013-09-15 08:15:45 <hydromet> gavinandresen: you should be able to remove /Library/Python/2.7/site-packages/appscript-1.0.1-py2.7-macosx-10.7-intel.egg and use the MacPorts for example ...
267 2013-09-15 08:16:03 <hydromet> sudo port install py27-appscript
268 2013-09-15 08:16:44 <hydromet> I just tested building Master with py27-appscript from MacPorts and had no problems
269 2013-09-15 08:17:21 <hydromet> given you use MacPorts, it probably make things a bit cleaner to stick with py27-appscript
270 2013-09-15 08:19:00 <hydromet> also you never know when Apple might have an update (such a security update) for OS X that could wipe out the contents of /Library/Python/2.7/site-packages
271 2013-09-15 08:20:20 <hydromet> unless its required for making distributions for the general public who may not have MacPorts installed
272 2013-09-15 09:42:59 <hydromet> fanquake: are you still here?
273 2013-09-15 09:44:23 <hydromet> fanquake: I was thinking of being a little bit bold and upgrading my Mac to OS X 10.8.5 (a minor point update from Apple released a few days ago0
274 2013-09-15 09:44:39 <hydromet> and seeing how everything hangs together with Bitcoin-Qt on 10.8.5
275 2013-09-15 09:47:16 <fanquake> I'll be doing the same shortly. Just don't want to restart right now.
276 2013-09-15 09:47:38 <hydromet> fanquake: how are you coming along with your install of Bitcon-Qt with brew?
277 2013-09-15 09:48:52 <hydromet> fanquake: I also do not like restarting my machine, check this out (my MacBook dev machine) ...
278 2013-09-15 09:48:54 <fanquake> Looking at that is still on the todo list
279 2013-09-15 09:48:55 <hydromet> 23:47 up 48 days, 1:03, 10 users, load averages: 1.94 1.82 1.67
280 2013-09-15 09:49:11 <hydromet> 48 days!
281 2013-09-15 09:49:29 <hydromet> lots of swapping out to vm though
282 2013-09-15 09:55:58 <fanquake> Pretty sure my build is sorted. Just installing Qt 5
283 2013-09-15 09:57:00 <hydromet> fanquake: are you building from master with autotools against Qt-5?
284 2013-09-15 09:59:40 <sipa> BlueMatt: present?
285 2013-09-15 09:59:47 <fanquake> hydromet WIll be in a second.
286 2013-09-15 10:03:10 <hydromet> fanquake: cool, it would be great to know how you managed to do this
287 2013-09-15 10:14:21 <gribble> The operation succeeded.
288 2013-09-15 10:14:21 <sipa> ;;later tell BlueMatt ok, investigated a debug.log from pulltester a bit... seems i'm receiving orphan blocks; do you ever send blocks without them being requested? it seems there's getheaders support now, but i do receive headers which don't connect to the block tree...
289 2013-09-15 10:16:01 <sipa> cfields: being able to run pulltester locally is very nice!
290 2013-09-15 10:16:19 <CodeShark> run pulltester locally? how?!?!
291 2013-09-15 10:16:22 <hydromet> fanquake: and gavinandresen: interesting observation - I ripped out my MacPorts with dependencies on tiff (including qt4-mac), then I ripped out tiff ... then reinstalled
292 2013-09-15 10:16:45 <hydromet> I then re-installed tiff and only one dependency required for Bitcoin-Qt with autotools: qt4-mac
293 2013-09-15 10:17:02 <sipa> CodeShark: put a jar somewhere, ./configure --with-comparison-tool=/tmp/BitcoindComparisonTool.jar, and then just make check
294 2013-09-15 10:17:18 <hydromet> it turns out that *after* re-installing, I had to once again run this sudo port -ns upgrade --force tiff
295 2013-09-15 10:17:56 <CodeShark> wow, we really went all out with the autotools stuff, didn't we?
296 2013-09-15 10:18:03 <CodeShark> is all this documented somewhere?
297 2013-09-15 10:18:05 <hydromet> fanquake: and gavinandresen: this is a weird anomaly with tiff and qt4-mac ... I predict problems downstream in the timeline due to this issue
298 2013-09-15 10:18:19 <sipa> CodeShark: it was just merged, documentation updates will follow, i'm told :)
299 2013-09-15 10:18:45 <sipa> CodeShark: technically i suppose i should say "run the bitcoinj comparison tool locally", as pulltester does more than that (like building under mingw)
300 2013-09-15 10:19:08 <hydromet> fanquake: and gavinandresen: the MacPorts community appears slow to work on Qt-5 as a MacPort ... only one guy and he might need some funding, maybe Bitcoin Foundation can help?
301 2013-09-15 10:19:44 <hydromet> Qt looks like a complex pain to deal with for cross platform GUI but its probably the best option out there
302 2013-09-15 10:20:11 <hydromet> at least for desktop/laptop OS
303 2013-09-15 10:21:39 <CodeShark> compared to web-based stuff, I suppose it is somewhat complex - but compared to just about any other windowing toolkit out there, Qt is not only quite portable - it also integrates nicely with the native environment
304 2013-09-15 10:24:22 <hydromet> CodeShark: good points
305 2013-09-15 10:25:13 <hydromet> CodeShark: am somewhat concerned though about progress moving forward - Gavin reverted to Qt-4 on his Mac for OS X builds due to the move to using autotools in Master which will become a requirement in Bitcoin-Qt 0.9
306 2013-09-15 10:25:35 <hydromet> CodeShark: because Qt-5 and autotools on OS X apparently don't play well together yet (needs addressing)
307 2013-09-15 10:25:49 <hydromet> CodeShark: but maybe fanquake: will have something to say about this?
308 2013-09-15 10:25:55 <sipa> hydromet: cfields has commented that he has a working qt5 branch, but it needs some tweaking still
309 2013-09-15 10:25:59 <sipa> hydromet: so i wouldn't worry
310 2013-09-15 10:30:49 <hydromet> sipa: I'm a worry wart when it comes to something as important as bitcoin
311 2013-09-15 10:31:26 <fanquake> hydromet I'd rather get my gitian building sorted than get to concerned over Qt 5
312 2013-09-15 10:31:44 <CodeShark> for bitcoin to survive, most important is that most verification/relay node implementations agree
313 2013-09-15 10:31:59 <CodeShark> as for GUI, anyone can write one for all I care
314 2013-09-15 10:33:36 <CodeShark> in fact, competition is good :)
315 2013-09-15 10:33:53 <sipa> well, preferably it's a bit more than a gui
316 2013-09-15 10:33:54 <hydromet> CodeShark: I agree ... but the GUI is going to important to the end user who needs to be confident their GUI will help them manage their wallet
317 2013-09-15 10:34:11 <hydromet> CodeShark: in the virtual world, the GUI is the window onto the wallet
318 2013-09-15 10:34:21 <sipa> i mean... there are enough gui frontends for centralized wallets
319 2013-09-15 10:34:35 <sipa> and making a working wallet is significantly harder than making a gui
320 2013-09-15 10:35:06 <hydromet> sipa: well, some people might not like centralized systems after the latest NSA / Snowden episodes
321 2013-09-15 10:36:06 <sipa> ok, very good
322 2013-09-15 10:36:28 <sipa> but i agree with CodeShark to an extent: bitcoin-qt as a wallet implementation isn't that important for the ecosystem
323 2013-09-15 10:37:27 <hydromet> sipa: that's reasonable / makes sense
324 2013-09-15 10:37:57 <sipa> however, since bitcoin-qt is the only wallet application with builtin full node, it does contribute to the network independently from its function as a wallet
325 2013-09-15 10:38:34 <sipa> i guess bitsofproof also qualifies, but it's not really an end-user application as far as i understand
326 2013-09-15 10:39:59 <gmaxwell> I'm not sure if any alternatives have a complete networking stack. (e.g. doesn't just depend on getting good results from dns seeds)
327 2013-09-15 10:40:20 <gmaxwell> Maybe genjix's software does.
328 2013-09-15 10:40:48 <CodeShark> wallet != GUI
329 2013-09-15 10:41:39 <CodeShark> some wallets will be primarily used via GUI - but other wallets will be primarily used via API
330 2013-09-15 10:41:46 <sipa> sure
331 2013-09-15 11:40:43 <Mqrius_> Eh, I updated to the Ubuntu PPA, which is 0.8.4, not 0.8.5 yet. Now it doesn't say that my blockchain is corrupt, but it does display a warning "Displayed transactions may not be correct! You may need to upgrade [etc]." It also refuses to download past 2 weeks ago.
332 2013-09-15 11:40:55 <Mqrius_> Any suggestions?
333 2013-09-15 11:41:14 <sipa> anything in debug.log?
334 2013-09-15 11:41:34 <sipa> sounds like actual corruption
335 2013-09-15 11:42:54 <Mqrius_> sipa: A bunch of InvalidChainFound
336 2013-09-15 11:43:25 <sipa> can you find the first?
337 2013-09-15 11:44:44 <Mqrius_> Not sure if the log deletes old messages. The one at the top is at height 257704, but it says the current best is at height 254627
338 2013-09-15 11:45:38 <sipa> yes, so they've falled off
339 2013-09-15 11:45:39 <sipa> bummer
340 2013-09-15 11:45:43 <sipa> hardware/os?
341 2013-09-15 11:46:27 <Mqrius_> Ubuntu 12.04 iirc, on an acer aspire one
342 2013-09-15 11:46:45 <sipa> a -reindex will fix it
343 2013-09-15 11:46:57 <sipa> but that doesn't give us any idea of the reason...
344 2013-09-15 11:47:47 <Mqrius_> Could it be related to me trying to run the old version with checklevel=2? I did that after accepting re-downloading the blockchain and such
345 2013-09-15 11:47:49 <gmaxwell> you might want to -debug=1 -reindex so if it fails again you'll have more logs.
346 2013-09-15 11:49:39 <sipa> Mqrius_: no, that just reduces the integrity checks done at startup
347 2013-09-15 11:50:21 <Mqrius_> Yeah I figured as much. Oh well, I'll do a reindex with debug=1, and see what happens.
348 2013-09-15 14:58:05 <ThomasV> how does bitcoind verifymessage handle unicode characters?
349 2013-09-15 14:58:44 <sipa> it encodes a byte sequence, really
350 2013-09-15 14:59:15 <sipa> i suppose utf-8 would be a reasonable assumption for character encoding
351 2013-09-15 14:59:54 <ThomasV> does bitcoin-qt pass a utf8 sequence to it?
352 2013-09-15 15:00:01 <Subo1977_> [WTS] BFL Jala 8.2 http://www.ebay.de/itm/Bitcoin-Miner-Butterfly-Labs-Jalapeno-Asic-5-GHs-geflasht-auf-8-2-GH-IN-HAND-/290973968724?pt=DE_Computer_Sonstige&hash=item43bf666954 45 min to go
353 2013-09-15 15:00:44 <sipa> ThomasV: no idea about Qt
354 2013-09-15 15:17:55 <nkuttler> hrm, can I get a list of transactions for a specific address through the API? can't find it
355 2013-09-15 15:18:12 <nkuttler> getreceivedbyaddress seems to return the sum?
356 2013-09-15 15:21:42 <sipa> listreceivedbyaddress ?
357 2013-09-15 15:22:15 <sipa> oh, no
358 2013-09-15 15:22:16 <nkuttler> sipa: ah, that's it.. was grepping for passed args
359 2013-09-15 15:22:19 <nkuttler> not?
360 2013-09-15 15:22:35 <sipa> listtransactions can filter by account, though
361 2013-09-15 15:22:39 <nkuttler> hm, right, no transaction id
362 2013-09-15 15:22:52 <nkuttler> sipa: that will only work for local accounts though, won't it?
363 2013-09-15 15:23:06 <sipa> yes, this is the wallet api
364 2013-09-15 15:23:11 <nkuttler> ok, thanks
365 2013-09-15 15:26:28 <Mikej0h> heya!
366 2013-09-15 15:26:40 <Mikej0h> anybody has a clue howto run bitcoind as a windows service?
367 2013-09-15 15:27:11 <Mikej0h> already did it like this: C:\Services\bitcoin\daemon\bitcoind.exe -datadir="C:\Services\bitcoin-data" -server (in a service by sc create)
368 2013-09-15 15:27:35 <Mikej0h> but then got: The Bitcoin Server service failed to start due to the following error:
369 2013-09-15 15:27:35 <Mikej0h> The service did not respond to the start or control request in a timely fashion.
370 2013-09-15 15:32:04 <michagogo> Mikej0h: It's not designed as a Windows Service
371 2013-09-15 15:32:23 <michagogo> And I think there's a certain interface that Services are supposed to have to talk to the OS
372 2013-09-15 15:32:24 <edcba> there is some program that can answers to service controller
373 2013-09-15 15:32:39 <edcba> and then run your program
374 2013-09-15 15:33:38 <edcba> http://www.msfn.org/board/topic/83272-how-to-run-a-program-as-a-service/ srvany
375 2013-09-15 15:34:07 <michagogo> http://rozanski.org.uk/software
376 2013-09-15 15:34:10 <michagogo> srvstart
377 2013-09-15 15:34:37 <michagogo> srvstart is better than srvany, according to Google
378 2013-09-15 15:34:43 <edcba> haha
379 2013-09-15 15:35:12 <edcba> it's open source at least
380 2013-09-15 15:35:19 <Mikej0h> michagogo, thanks
381 2013-09-15 15:35:40 <Mikej0h> although it would be better if the bitcoind incorporates the service methods
382 2013-09-15 15:35:51 <Mikej0h> (so you don't have to do this stuff)
383 2013-09-15 15:35:52 <Mikej0h> :)
384 2013-09-15 15:36:07 <Mikej0h> s/incorporates/implements
385 2013-09-15 15:37:17 <edcba> not many ppl use bitcoind on windows i guess
386 2013-09-15 15:37:34 <michagogo> Looks like for bitcoind, you'll need svcstart if you want to use it
387 2013-09-15 15:37:39 <michagogo> svcany will be bad
388 2013-09-15 15:37:52 <michagogo> Because svcany just kills the process on shutdown
389 2013-09-15 15:38:04 <Mikej0h> will look into that
390 2013-09-15 15:38:27 <michagogo> To safely shut down bitcoind and make sure you don't get any database corruption, you always want to stop it with the "stop" rpc
391 2013-09-15 15:38:55 <Mikej0h> edcba, because now you have to do all kinds of work arounds?
392 2013-09-15 15:39:04 <michagogo> http://rozanski.org.uk/services, 4.5.2
393 2013-09-15 15:39:16 <Mikej0h> probably now everybody starts it with a batch script, however that requires an active user session
394 2013-09-15 15:39:26 <Mikej0h> (interactive session)
395 2013-09-15 15:39:31 <sipa> i think most bitcoind's run on linux VPS'es
396 2013-09-15 15:39:33 <michagogo> Mikej0h: Well, it's not developed as a Windows Service
397 2013-09-15 15:39:50 <michagogo> It's designed as a cross-platform executable
398 2013-09-15 15:39:52 <Mikej0h> I know
399 2013-09-15 15:39:58 <Mikej0h> I understand where it comes from
400 2013-09-15 15:40:05 <sipa> patches welcome, i 'd say
401 2013-09-15 15:40:15 <sipa> if someone wants to improve the service behaviur on windows
402 2013-09-15 15:40:29 <ThomasV> sipa: do you know how the message needs to be typed with bitcoind, on the command line? typing "N\xc3\xb8stdal" does not seem to work
403 2013-09-15 15:40:35 <Mikej0h> I would love to, but unfortunately I don't know C++
404 2013-09-15 15:40:39 <ThomasV> (verifymessage)
405 2013-09-15 15:40:48 <sipa> ThomasV: in bash?
406 2013-09-15 15:40:51 <ThomasV> yes
407 2013-09-15 15:41:06 <sipa> $'N\xc3\xb8stdal'
408 2013-09-15 15:41:20 <sipa> but why would you sign such a message?
409 2013-09-15 15:41:26 <Mikej0h> well I could make a wrapper service in .NET ;)
410 2013-09-15 15:41:34 <ThomasV> sipa: thanks :)
411 2013-09-15 15:41:56 <ThomasV> sipa: because of this: https://github.com/spesmilo/electrum/issues/223
412 2013-09-15 15:42:08 <Mikej0h> services like sabnzbd do the same
413 2013-09-15 15:42:09 <ThomasV> it works, ideed :)
414 2013-09-15 15:42:44 <sipa> ah
415 2013-09-15 15:43:48 <edcba> yeah a service wrapper in .net should be quite easy
416 2013-09-15 15:45:14 <edcba> wait what corruption were you talking about ?
417 2013-09-15 15:46:08 <edcba> you can have a corrupted db when stopped at wrong time ??
418 2013-09-15 15:46:21 <Mikej0h> service stop just kills the process, instead of "gracefully shutdown"
419 2013-09-15 15:46:21 <Mikej0h> that would corrupt the db
420 2013-09-15 15:46:37 <Mikej0h> so with a wrapper you could sigterm it properly but executing a RPC command
421 2013-09-15 15:46:44 <edcba> why would the db corrpted ?
422 2013-09-15 15:46:48 <Mikej0h> s/but/by
423 2013-09-15 15:47:12 <sipa> edcba: it shouldn't, but apparently it does
424 2013-09-15 15:47:23 <edcba> still recoverable ?
425 2013-09-15 15:47:30 <sipa> reindex is always possible
426 2013-09-15 15:47:37 <Mikej0h> don't know michagogo refered to it
427 2013-09-15 15:57:05 <michagogo> Mikej0h: svcstart can stop it by sending the stop command
428 2013-09-15 15:57:22 <michagogo> It's svcany that will just kill it on service stop
429 2013-09-15 16:54:47 <jgarzik> hey
430 2013-09-15 16:54:57 <jgarzik> kudos to "BurtW" on the "NSA and ECC" forum thread
431 2013-09-15 16:55:12 <jgarzik> he is working via email, tracking down the people who authored our curve parameters
432 2013-09-15 17:02:16 <jgarzik> Jerry Solinas (sp?) responded to BurtW, redirecting the search from NIST to Certicom
433 2013-09-15 17:02:27 <jgarzik> (as we inferred independently anyway)
434 2013-09-15 17:08:16 <justusranvier> Luke-Jr: * Failed Patch: 9999-sys_leveldb.patch
435 2013-09-15 17:10:43 <sipa> jgarzik: cool
436 2013-09-15 17:10:56 <sipa> jgarzik: i'd really like some explanation about that
437 2013-09-15 17:11:07 <sipa> though i'm not very worried
438 2013-09-15 17:14:07 <Luke-Jr> justusranvier: expected
439 2013-09-15 17:18:31 <TheLordOfTime> there's no way to trace back an address to the IP that owns/generates it, correct?
440 2013-09-15 17:18:40 <TheLordOfTime> AIUI the system there's no system in place to trace that
441 2013-09-15 17:19:24 <Luke-Jr> TheLordOfTime: there's plenty of ways people could try to trace that, but nothing builtin
442 2013-09-15 17:19:41 <TheLordOfTime> Luke-Jr, how would you be able to track an address back to the IP that owns it?
443 2013-09-15 17:20:03 <TheLordOfTime> AIUI the Internet, such things can be spoofed
444 2013-09-15 17:20:42 <Luke-Jr> you can't easily spoof IPs with TCP..
445 2013-09-15 17:20:59 <TheLordOfTime> Luke-Jr, it's the point of contention on an argument in -otc, that a single address can be traced back to a specific IP address
446 2013-09-15 17:21:18 <TheLordOfTime> so short of beating everyone arguing with the banstick, well...
447 2013-09-15 17:21:37 <Luke-Jr> O.o
448 2013-09-15 17:22:00 <Luke-Jr> very unreliably, at best
449 2013-09-15 17:22:01 <Luke-Jr> but I wouldn't bet on it being impossible
450 2013-09-15 17:22:01 <Luke-Jr> that's my point
451 2013-09-15 17:32:07 <TheLordOfTime> Luke-Jr, true, however my point is if it's easily able to be done, or rather practically feasible to get a reliable IP trace. But, since the guy decided to mouth off in multiple channels and be an ass, he's banned.
452 2013-09-15 17:55:36 <BlueMatt> sipa: no, it shouldnt ever send blocks until it gets a request
453 2013-09-15 17:59:55 <BlueMatt> sipa: in terms of getting headers that connect to crap/dont connect, yea, I think that should happen, though I dont recall how I implemented it (probably incorrectly...)
454 2013-09-15 18:25:02 <BlueMatt> 0.8.5 (finally) put on the ppa, sorry for the delay
455 2013-09-15 18:27:34 <sipa> BlueMatt: hmm, and is getheaders implemented?
456 2013-09-15 18:28:03 <BlueMatt> sipa: sort of, I hacked it together in 15 minutes untested...since the only test was your code...
457 2013-09-15 18:28:29 <sipa> i haven't looked at it, but i would guess there's a bug in it
458 2013-09-15 18:28:36 <sipa> (or in my code...)
459 2013-09-15 18:28:49 <BlueMatt> well, there's a bug somewhere
460 2013-09-15 18:29:19 <BlueMatt> sipa: https://code.google.com/r/bluemattme-bitcoinj/source/detail?r=f499e2e8bc8b4fb9c122adfde3d3d38667fe1d92&name=blocktester
461 2013-09-15 18:29:23 <jcorgan> what is a reasonable maximum time to wait after receiving an inv on one connection to see if it arrives on another, before concluding that inv didn't propagate to that node
462 2013-09-15 18:29:30 <sipa> so what happens: you send an inv, i send a getheaders + getdata, you send headers and a block, but the headers do not attach to the header tree
463 2013-09-15 18:30:38 <sipa> and the block is considered an orphan
464 2013-09-15 18:30:43 <sipa> and discarded
465 2013-09-15 18:30:48 <sipa> after that, all tests fail
466 2013-09-15 18:31:00 <BlueMatt> do you have a log somewhere?
467 2013-09-15 18:31:56 <sipa> i'm at the airport now, i'll go sit somewhere with my laptop soon
468 2013-09-15 18:33:10 <BlueMatt> ok, well Ill look at it and see if I can find anything obvious in bitcoindcomparisontool
469 2013-09-15 18:33:25 <jcorgan> in my instrumentation code, i note the first time of arrival of a specific inv on any connection, then accumulate arrival times for that same inv on other connections
470 2013-09-15 18:34:09 <jcorgan> a lot of the time it only shows up on a fraction of connections, so i'm trying to think of a reasonable time to stop waiting and push the data record into my stats collecting struct
471 2013-09-15 18:38:27 <sipa> BlueMatt: does pulltester have the latest comparison tool?
472 2013-09-15 18:38:36 <BlueMatt> no
473 2013-09-15 18:39:04 <BlueMatt> its quite out-of-date iirc
474 2013-09-15 18:40:34 <jcorgan> aside from that, i'm curious what the expected behavior is for the fraction of connections one might expect a give inv to show up on
475 2013-09-15 18:40:42 <jcorgan> s/give/given/
476 2013-09-15 18:41:00 <BlueMatt> sipa: that patch always responds to getheaders with /only/ the header of the block requested, possibly not connecting to the chain
477 2013-09-15 18:41:10 <BlueMatt> which is probably the problem since that breaks spec, no?
478 2013-09-15 18:41:27 <sipa> indeed
479 2013-09-15 18:41:47 <BlueMatt> ok, well some of the test framework needs rewritten then
480 2013-09-15 18:42:11 <sipa> can't just send *all* headers insead of just the last one? :p
481 2013-09-15 18:42:35 <BlueMatt> the way its written it doesnt have headers until its processed the block list up to there
482 2013-09-15 18:42:51 <sipa> hmm
483 2013-09-15 18:43:01 <BlueMatt> probably just need to keep a header tree structure and send the set of headers from base to requested block whenever it gets a request for headers
484 2013-09-15 18:43:12 <sipa> it should be very similar to getblocks?
485 2013-09-15 18:43:22 <BlueMatt> getblocks always gets one block too
486 2013-09-15 18:43:22 <sipa> just with full headers ibstead of just hashes
487 2013-09-15 18:43:28 <sipa> oh
488 2013-09-15 18:43:35 <sipa> really?
489 2013-09-15 18:43:48 <BlueMatt> yea, well if you only ever send invs with one block it doesnt matter
490 2013-09-15 18:43:58 <BlueMatt> +/-
491 2013-09-15 18:44:02 <sipa> no no, not getdata
492 2013-09-15 18:44:11 <BlueMatt> oh, it doesnt respond to getblocks
493 2013-09-15 18:44:15 <sipa> ah :D
494 2013-09-15 18:50:34 <sipa> BlueMatt: anyway, when an inv is received, i ask for both headers leading up to it, and the block itself, so that all headers are known before the block
495 2013-09-15 18:50:41 <sipa> and it can be stored instantly
496 2013-09-15 18:50:46 <sipa> so we never have orphans
497 2013-09-15 18:51:51 <BlueMatt> yep, makes sense, though there are tons of test-cases you should totally write for strange (read: long) chains that might trigger orphans and such
498 2013-09-15 18:53:53 <sipa> it's just an optimization
499 2013-09-15 18:54:07 <sipa> though you are of course right that test cases would be good
500 2013-09-15 18:54:54 <sipa> but normally there is really only a headers-sync process, which is also used for initial sync
501 2013-09-15 18:58:56 <BlueMatt> makes sense...but the coverage on chain-download code used to be +/- 100% with bitcoind comparison tool, so more test-cases would be nice
502 2013-09-15 19:03:38 <sipa> BlueMatt: if i ever find time, i'll try to understand the tester code :)
503 2013-09-15 19:03:54 <BlueMatt> sipa: if I ever find time, Ill write more tests :)
504 2013-09-15 19:04:00 <sipa> you're very right that we should aim for 100% code coverage her
505 2013-09-15 19:04:12 <sipa> what are you doing now, actually? :p
506 2013-09-15 19:05:25 <BlueMatt> at this very moment? researching the ohci 1394 spec...more generally? dealing with schoolwork+research+job interviews+trying to find free time
507 2013-09-15 19:05:52 <sipa> haha :D
508 2013-09-15 19:05:58 <sipa> right, school and stuff
509 2013-09-15 19:07:33 <BlueMatt> yea, two more years then masters and I can actually go do interesting things
510 2013-09-15 19:08:54 <sipa> i'm sure you could go do interesting stuff right now too
511 2013-09-15 19:09:04 <sipa> though i strongly advise getting a degree first :)
512 2013-09-15 19:09:15 <BlueMatt> yea, gotta get two more years done so I can have a sheet of paper, really
513 2013-09-15 19:09:50 <sipa> no worries, i did useless things for 9 years, to get 2 pieces of paper :)
514 2013-09-15 19:11:16 <BlueMatt> yep, all gotta do it
515 2013-09-15 19:12:07 <sipa> excluding high school of course
516 2013-09-15 19:13:18 <BlueMatt> well, some of us (as in the us) get two sheets of paper pretty quick because we like papers (bachelors and masters in like 3-4 years if you work at it)
517 2013-09-15 19:14:50 <sipa> yeah, we switched to bama as well, but only the year after me
518 2013-09-15 19:15:24 <BlueMatt> ahh
519 2013-09-15 19:15:38 <sipa> so i only got an "ingenieur" (engineer) degree after 5 years (there's also a "kandidaat" after 2 years, but that's worthless on itself)
520 2013-09-15 19:16:30 <sipa> now they get a bachelor in engineerig after 3 years, and a master after 2 more
521 2013-09-15 19:16:44 <sipa> though bachelor in engineering is equally useless
522 2013-09-15 19:17:01 <BlueMatt> yea, these days a bachelors is largely useless...
523 2013-09-15 19:17:20 <sipa> well, university here was always 4-5 years
524 2013-09-15 19:17:30 <sipa> taking off!
525 2013-09-15 19:17:37 <BlueMatt> enjoy your flights
526 2013-09-15 19:23:26 <sipa> it's a single 45-minite flight :p
527 2013-09-15 19:23:45 <sipa> followed by a 1.5h train ride...
528 2013-09-15 19:23:53 <BlueMatt> fuuuunnnn
529 2013-09-15 19:24:05 <BlueMatt> should've flown more direct :p
530 2013-09-15 19:24:14 <sipa> no kidding
531 2013-09-15 19:24:21 <sipa> that cost 8x as much
532 2013-09-15 19:24:32 <BlueMatt> heh, I love travel costs, they are always so logical
533 2013-09-15 19:25:04 <sipa> now really maybe taking off
534 2013-09-15 19:25:10 <BlueMatt> heh
535 2013-09-15 19:25:15 <sipa> cya!
536 2013-09-15 20:50:53 <nkuttler> i assume the comment-to in "sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]" a comment the receiver gets?
537 2013-09-15 20:51:09 <sipa> no, it's purely local
538 2013-09-15 20:51:17 <sipa> bitcoin transactions do not carry comments
539 2013-09-15 20:51:53 <nkuttler> sipa: i see. what's the difference to comment then?
540 2013-09-15 20:52:04 <sipa> the payment protocol will add a layer on top that allows metadata to be transferred along with transactions
541 2013-09-15 20:52:11 <sipa> nkuttler: no clue
542 2013-09-15 20:52:28 <nkuttler> sipa: ok :)
543 2013-09-15 20:55:23 <Cusipzzz> i vaguely remember you could send to ip address with a comment
544 2013-09-15 20:55:59 <nkuttler> i guess i'll rtfs sometime
545 2013-09-15 20:56:10 <nkuttler> hopefully it's documented ;)
546 2013-09-15 20:56:25 <Cusipzzz> back in 0.3.x or earlier
547 2013-09-15 21:00:25 <sipa> Cusipzzz: even in 0.3.20 or so it was already deprecated and disabled by default
548 2013-09-15 21:00:34 <sipa> it was removed in 0.6 or so
549 2013-09-15 21:01:49 <BlueMatt> sipa: it took till 0.6 to remove send-to-ip???
550 2013-09-15 21:02:06 <Cusipzzz> sipa: ok, i'm oldchool, I remember it
551 2013-09-15 21:02:43 <sipa> BlueMatt: i thibk i silently "forgot" it in a refactor or so :)
552 2013-09-15 21:02:51 <BlueMatt> ahh, well good for you
553 2013-09-15 21:02:51 <sipa> and it depends
554 2013-09-15 21:03:01 <sipa> sendong and receiving were removed separately
555 2013-09-15 21:03:05 <sipa> *sending
556 2013-09-15 21:03:22 <sipa> se wallet refactors removed support for ip addressea in the address book
557 2013-09-15 21:03:51 <sipa> and i think support for receiving may have been removed together with cwallet
558 2013-09-15 21:06:07 <sipa> anyway, we're adding something similar again :)
559 2013-09-15 21:06:13 <michagogo> sipa: I think the wiki said it was removed in 0.8...
560 2013-09-15 21:06:13 <sipa> (payment protocol)
561 2013-09-15 21:06:58 <sipa> maybe the last trace
562 2013-09-15 21:07:16 <michagogo> https://en.bitcoin.it/wiki/IP_Transactions
563 2013-09-15 21:14:48 <jgarzik> michagogo, it was disabled by default for years
564 2013-09-15 21:14:58 <michagogo> I kniw
565 2013-09-15 21:15:04 <michagogo> s/i/o/
566 2013-09-15 21:15:06 <sipa> i don't think i've known it being enabled by default
567 2013-09-15 21:15:24 <sipa> and i first look at the source code at 0.3.17 iirc
568 2013-09-15 21:16:45 <sipa> BlueMatt: how hard would full getheaders support be, you think?
569 2013-09-15 21:22:01 <BlueMatt> sipa: its really just a structural change (well...kinda), build up a tree and return N from the tree when you get a getheaders
570 2013-09-15 21:22:26 <BlueMatt> then return the blocks in order ignoring the getdata order
571 2013-09-15 21:22:40 <sipa> getdata?
572 2013-09-15 21:22:57 <BlueMatt> getblocks
573 2013-09-15 21:22:59 <BlueMatt> get*
574 2013-09-15 21:24:56 <sipa> ?
575 2013-09-15 21:25:32 <BlueMatt> the request for block data
576 2013-09-15 21:26:10 <sipa> what does that have to do with it?
577 2013-09-15 21:26:35 <BlueMatt> tests orphan handling?
578 2013-09-15 21:27:22 <sipa> i'm not following
579 2013-09-15 21:27:26 <sipa> but nevermind
580 2013-09-15 21:27:29 <BlueMatt> many tests rely on the ordering of blocks being sent to bitcoind
581 2013-09-15 21:27:38 <sipa> sure
582 2013-09-15 21:27:39 <BlueMatt> (ie tests for orphan handling, etc)
583 2013-09-15 21:28:03 <sipa> but what "getdata order" exists while executing a getheaders.command?
584 2013-09-15 21:28:16 <BlueMatt> so...you just have to send in the order in the list, not the order requested (eg A->B, A->D->C, send in order A, B, C, D even if bitcoind requests C first)
585 2013-09-15 21:28:39 <BlueMatt> none, Im just saying ignore how bitcoind wants to order block requests and send it in the order you want
586 2013-09-15 21:29:52 <sipa> i still don't get it
587 2013-09-15 21:30:06 <sipa> you just send them in order of tree dependency, right?
588 2013-09-15 21:30:17 <BlueMatt> no, not always, bitcoind will request them in that order
589 2013-09-15 21:30:29 <BlueMatt> but the tests dont always specifically to test orphan handling
590 2013-09-15 21:31:11 <sipa> you can choose the order in whih you announce blocks
591 2013-09-15 21:31:25 <sipa> but within a getheaders response, they should be sorted
592 2013-09-15 21:31:33 <BlueMatt> yes, within the getheaders they are
593 2013-09-15 21:31:42 <sipa> ok, then what are we talking about?
594 2013-09-15 21:31:55 <BlueMatt> after the getheaders, when the actual blocks are being requested
595 2013-09-15 21:32:08 <sipa> ah, ok
596 2013-09-15 21:32:36 <sipa> yeah, makes sense if you can do that
597 2013-09-15 22:26:08 <nkuttler> am i reading it right that i could send btc from specific transaction/addresses by creating raw transactions?
598 2013-09-15 22:27:52 <Luke-Jr> nkuttler: not quite
599 2013-09-15 22:28:05 <Luke-Jr> nkuttler: you cannot send FROM an address at akk
600 2013-09-15 22:28:07 <Luke-Jr> all*
601 2013-09-15 22:29:13 <nkuttler> Luke-Jr: well, yes, but the coins that were received with that address?
602 2013-09-15 22:29:40 <Luke-Jr> nkuttler: sure
603 2013-09-15 22:29:59 <nkuttler> Luke-Jr: ok, that's what i meant :) will have to look into the details tomorrow. thanks!
604 2013-09-15 23:37:52 <nfx11> hello
605 2013-09-15 23:38:22 <nfx11> is somebody interesting working on an advanced message-board?
606 2013-09-15 23:56:15 <Ry4an> c
607 2013-09-15 23:56:20 <Ry4an> (bah)