1 2015-02-20 00:00:11 <roybadami> Anyway.... it's getting there - I think another night will have it sync'd - so it's not a big deal. It's just way slower than I was expecting
2 2015-02-20 00:00:49 <jtimon> gmaxwell mhmm, I'm thinking about not having exceptions for BIP30 and things like that
3 2015-02-20 00:00:50 <gmaxwell> roybadami: not sure what I can suggest you measure there to help. hm. there is a hidden benchmark option that might get some useful numbers.
4 2015-02-20 00:01:05 <gmaxwell> jtimon: thats one line of code, and it's the only one we have.
5 2015-02-20 00:01:13 <roybadami> Hmmm. I have no idea - as if by magic I'm maxing my network again and CPU has dropped way down
6 2015-02-20 00:01:28 <Luke-Jr> roybadami: btw, are you 32-bit or 64-bit?
7 2015-02-20 00:01:29 <gmaxwell> (e.g. less code than a 'checkpoint' and it doesn't completely break people's understanding of the system)
8 2015-02-20 00:01:38 <roybadami> 64-bit. all OSX is
9 2015-02-20 00:01:56 <Luke-Jr> ACTION ponders if roybadami's performance is related to his own
10 2015-02-20 00:01:57 <jtimon> gmaxwell aren't softforks other things that could be simplified?
11 2015-02-20 00:02:01 <gmaxwell> roybadami: thats uhhh super suspicious.
12 2015-02-20 00:02:26 <jtimon> like years after the softfok I mean
13 2015-02-20 00:02:29 <benjamindees> sounds like my chromebook fwiw -- completely unusable
14 2015-02-20 00:02:33 <gmaxwell> jtimon: I don't believe so currently.
15 2015-02-20 00:02:46 <roybadami> I'm gonna kinda lay the finger at the HFS+ compression experiment for now.....
16 2015-02-20 00:02:55 <gmaxwell> roybadami: you're using the bitcoin.org binaries right?
17 2015-02-20 00:03:06 <Diablo-D3> yeah Im expecting hfs+ compression doesnt use lz4 =P
18 2015-02-20 00:03:08 <gmaxwell> roybadami: you didn't happen to turn compression on the coins directory did you?
19 2015-02-20 00:03:12 <jtimon> gmaxwell for the mining voting? at least for bip16 it should work, no?
20 2015-02-20 00:03:21 <gmaxwell> jtimon: thats all gone.
21 2015-02-20 00:03:50 <roybadami> you can't turn on compression on directories as such - you can just use open source tools like hfsctool to manually compress particular files
22 2015-02-20 00:03:59 <gmaxwell> jtimon: those get replaced with simple height tests.
23 2015-02-20 00:05:11 <gmaxwell> roybadami: I'd suggest restarting with -benchmark=1 but if it's fast now, that probably won't be informative.
24 2015-02-20 00:05:25 <jtimon> well, that's the kind of simplification I was talking about, I know it's not a huge gain, but still a better reason than initial sync IMO
25 2015-02-20 00:05:27 <roybadami> At least, I don't think you can - maybe I've turned some automatic compression option by accident - although I'm 99% certain no such option exists
26 2015-02-20 00:06:13 <roybadami> gmaxwell: no it went through a brief burst of being network bound - now CPU bound again
27 2015-02-20 00:06:39 <roybadami> my optimism was premature
28 2015-02-20 00:07:34 <jtimon> if (simple height test) {...} else {...}, removing the check you can also remove whatever is in the else
29 2015-02-20 00:08:10 <roybadami> "Unsupported argument -benchmark ignored, use -debug=bench"
30 2015-02-20 00:12:27 <jaromil> jtimon: ok, understood you were using abstraction for polymorphism, understand is limited use. if you have doubts make sure you profile the code execution. at the time I did this stuff gprof did not cover clearly the performance loss into the runtime resolution. gmaxwell is totally right to say sometimes this results in a 10x or more performance loss
31 2015-02-20 00:13:27 <jaromil> After I understood all my sins in this game I ended up redeeming myself by coding only in C for the past 10 years.
32 2015-02-20 00:19:05 <roybadami> There's something very odd about this build (or my machine). Startup time ("Loading wallet") is way longer than it used to be
33 2015-02-20 00:20:28 <roybadami> But I don't have time to investigate much more tonight.
34 2015-02-20 00:26:45 <roybadami> It's been saying "Loading wallet" for 15 minutes now - debug log shows progress but something's not right here. I'll investigate further tomorrow.
35 2015-02-20 00:28:36 <gmaxwell> 15 minutes?!
36 2015-02-20 00:28:47 <roybadami> Ok, but before i go - finally restarted it - and this time it started in seconds
37 2015-02-20 00:28:49 <gmaxwell> (make sure you have backups, surprise slowdowns sometimes indicate a failing disk)
38 2015-02-20 00:30:00 <roybadami> hmmm, is an SSD. IME they just die with no warning.
39 2015-02-20 00:30:31 <roybadami> But anyway, my coins are well protected
40 2015-02-20 00:31:46 <roybadami> After a restart, Bitcoin Core is now behaving flawlessly, maxing out the network, and using pretty low CPU
41 2015-02-20 00:33:31 <roybadami> So, you're right - checkpoints are a red herring. About all I can say right now is that something sometimes causes 0.10 to become CPU-bound on my machine.
42 2015-02-20 00:36:05 <roybadami> Ok, so as always I spoke to soon - it slowed down again.
43 2015-02-20 00:36:23 <roybadami> Ok, running with -debug=bench and I'm seeing things like:
44 2015-02-20 00:36:58 <roybadami> 2015-02-20 00:36:19 - Connect 335 transactions: 89.53ms (0.267ms/tx, 0.138ms/txin) [20.54s]
45 2015-02-20 00:36:58 <roybadami> 2015-02-20 00:36:19 - Connect block: 1481.66ms [149.50s]
46 2015-02-20 00:36:58 <roybadami> 2015-02-20 00:36:19 - Load block from disk: 6.17ms [1.16s]
47 2015-02-20 00:37:02 <roybadami> 2015-02-20 00:36:19 - Verify 647 txins: 596.59ms (0.922ms/txin) [137.08s]
48 2015-02-20 00:37:05 <roybadami> 2015-02-20 00:36:19 - Index writing: 5.24ms [1.35s]
49 2015-02-20 00:37:07 <roybadami> 2015-02-20 00:36:19 - Callbacks: 0.15ms [0.02s]
50 2015-02-20 00:37:10 <roybadami> 2015-02-20 00:36:19 - Connect total: 646.81ms [144.75s]
51 2015-02-20 00:37:12 <roybadami> 2015-02-20 00:36:19 - Flush: 8.22ms [3.51s]
52 2015-02-20 00:37:15 <roybadami> 2015-02-20 00:36:19 - Writing chainstate: 0.21ms [0.04s]
53 2015-02-20 00:42:29 <Luke-Jr> Guest17803: gmaxwell, you lost your nickserv
54 2015-02-20 00:42:34 <Luke-Jr> roybadami: use pastebin for that
55 2015-02-20 00:43:00 <roybadami> sorry
56 2015-02-20 02:15:09 <Eliel> hmmh... I'm trying to upgrade to bitcoin core 0.10.0 but bitcoind tells me: Error: Initialization sanity check failed. Bitcoin Core is shutting down.
57 2015-02-20 02:15:40 <Eliel> I'm trying to run the binary from Error: Initialization sanity check failed. Bitcoin Core is shutting down.
58 2015-02-20 02:15:52 <Eliel> oops, was supposed to be this url https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0-linux32.tar.gz
59 2015-02-20 02:17:38 <gmaxwell> Eliel: IIRC the messages in the debug log before the shutdown should tell you which test failed it.
60 2015-02-20 02:17:53 <gmaxwell> Can you look in your debug log and see?
61 2015-02-20 02:18:20 <Eliel> the last line before the error is: 2015-02-20 02:10:39 AppInit2 : parameter interaction: -listen=0 -> setting -upnp=0
62 2015-02-20 02:19:24 <Eliel> nothing that looks like an error, only 3 AppInit messages about settings
63 2015-02-20 02:21:48 <gmaxwell> Eliel: can you try running the included test_bitcoin binary?
64 2015-02-20 02:22:08 <Eliel> gmaxwell: trying that
65 2015-02-20 02:22:24 <Eliel> test/sanity_tests.cpp(14): error in "basic_sanity": stdlib sanity test
66 2015-02-20 02:25:10 <gmaxwell> Eliel: what OS are you on?
67 2015-02-20 02:25:52 <Eliel> Debian squeeze-lts
68 2015-02-20 02:28:25 <gmaxwell> cfields: ^ this is concerning; as it's with the binaries we're shipping.
69 2015-02-20 02:28:53 <gmaxwell> Well it's why we have tests, at least. But I thought we were static enough to avoid this.
70 2015-02-20 02:29:11 <cfields> Eliel: what OS?
71 2015-02-20 02:29:17 <cfields> distro/version
72 2015-02-20 02:30:01 <gmaxwell> 18:26 < Eliel> Debian squeeze-lts
73 2015-02-20 02:30:31 <cfields> ugh, right above me.
74 2015-02-20 02:30:33 <cfields> hmm
75 2015-02-20 02:30:41 <Eliel> oh and 32-bit in case that matters
76 2015-02-20 02:31:57 <cfields> phew. verified ok on my ubuntu machine. So it's not _completely_ broken at least
77 2015-02-20 02:32:01 <cfields> firing up a debian vm
78 2015-02-20 02:32:20 <gmaxwell> could just be that debian lts has a broken stdc++
79 2015-02-20 02:32:40 <gmaxwell> which isn't a shocker, since probably all libstdc++ is broken in some way or another. :)
80 2015-02-20 02:32:52 <cfields> gmaxwell: i suspect it's that try/catch that usually bites
81 2015-02-20 02:33:44 <gmaxwell> well IIRC what you'd said before was that older clang on OSX appeared to be miscompiling that, but in this case it's our binary.
82 2015-02-20 02:35:10 <cfields> gmaxwell: in that case, yes. Someone else also hit it with freebsd with a known-good (for this issue anyway) clang
83 2015-02-20 02:35:32 <cfields> good chance something else was busted there as well, i suppose
84 2015-02-20 02:35:34 <gmaxwell> yea, so might be two distinct issues cause similar bugs: bad compiler; or bad stdc++.
85 2015-02-20 02:35:54 <cfields> maybe this just happens to be an extensive test-case :)
86 2015-02-20 02:36:29 <Eliel> the test_bitcoin with 0.9.2.1 binary goes through with no problems.
87 2015-02-20 02:36:47 <gmaxwell> well, I suspect there are _a lot_ of bugs in exception handling both in libstdc++ and in compilers. (one of the reasons I am not fond of exceptions)
88 2015-02-20 02:37:28 <gmaxwell> Eliel: The test is new IIRC.
89 2015-02-20 02:53:19 <cfields> Eliel: works ok on my 7.1 64bit vm. Which is basically useless as a test here. Grabbing a 32bit squeeze now.
90 2015-02-20 02:55:20 <gmaxwell> Any opinions on making a version of b6347bf8138395117fa6d3a753c8aa266b05ada0 / #5675 for 0.9.5? (this the change to the free transaction priority lookahead to continue to treat unconfirmed as 0)?
91 2015-02-20 03:09:30 <cfields> Eliel: i assume you're on a native 32bit install?
92 2015-02-20 03:10:57 <Eliel> I'm not sure what you mean with native, but it's a xen virtualized system.
93 2015-02-20 03:11:55 <Eliel> installed with xen-create-image command line tool
94 2015-02-20 03:12:39 <cfields> Eliel: just making sure you're not running the 32bit bins with compat on a 64bit install
95 2015-02-20 03:15:45 <jtimon> cfields still around ? I answered on #5747
96 2015-02-20 03:16:27 <jtimon> about making all CCoinsViewEfficient methods virtual
97 2015-02-20 03:21:11 <Eliel> cfields: well, /lib64 doesn't exist, so I'd think it's 32bit.
98 2015-02-20 03:23:51 <jtimon> oh, cfields I misunderstood, thanks
99 2015-02-20 03:24:35 <cfields> jtimon: no prob. They may not be strictly necessary for those classes (i didn't check) but it's a good rule of thumb imo
100 2015-02-20 03:27:17 <jtimon> yeah, it won't hurt and we may save trouble in the future, good call
101 2015-02-20 03:29:28 <jtimon> on 5681, should I just rebase to origin/master to get a different commit ids, for example?
102 2015-02-20 03:30:14 <jtimon> cfields
103 2015-02-20 03:31:12 <cfields> jtimon: that'd invalidate the move-only reviews. Just commit --amend and add a space or something minor
104 2015-02-20 03:31:38 <jtimon> ok
105 2015-02-20 03:32:20 <cfields> Eliel: confirmed on squeeze32. thanks for reporting
106 2015-02-20 03:38:04 <Luke-Jr> wumpus: re https://github.com/bitcoin/bitcoin/pull/4702#issuecomment-73495542 , why not let him improve it? :/
107 2015-02-20 03:40:44 <Luke-Jr> I'm glad jonasschnelli is working on a new wallet, but that shouldn't give him a monopoly on it
108 2015-02-20 03:42:04 <gmaxwell> Luke-Jr: well for one, that change means that a large wallet would immediately result in large memory usage.
109 2015-02-20 03:42:34 <gmaxwell> So there is a band of medium-large sizes where that would be useful, but it would likely break things for very large wallets.
110 2015-02-20 03:43:38 <Luke-Jr> gmaxwell: well, my concern is mainly the reasoning for the close - that the current wallet must be abandoned because a new one might come along soon
111 2015-02-20 03:44:36 <gmaxwell> I suppose I agree with that, but I think perhaps tolerance may be a bit thin because of the (quite rude, IMO) antagonism on the transaction deleting patch which cozz has fanned (unintentionally).
112 2015-02-20 03:44:40 <Luke-Jr> I'm betting that same concept (not sorting on demand) would work just fine using a bdb map of some sort
113 2015-02-20 03:45:18 <Luke-Jr> hm
114 2015-02-20 03:49:44 <gmaxwell> basically #4702 is another hack that likely cannot be taken as is. It would probably be fine if changed to do something else entirely. It's less taxing to just turn it down then try to push it towards something that would make sense, given that the effort to do that on #5839 went so poorly.
115 2015-02-20 03:49:56 <Luke-Jr> mayhe cozz would volunteer to maintain the current-wallet, considering his PRs, if workload is a concern
116 2015-02-20 03:50:46 <Luke-Jr> gmaxwell: yes, but at the same time, I imagine it's quite discouraging to cozz to get merely turned down like that
117 2015-02-20 03:51:38 <gmaxwell> I am super thankful for cozz's work, but in the past he's submitted a fair amount of hacky changes and when they get pushed in a less hacky direction he gives up.
118 2015-02-20 03:52:37 <gmaxwell> Which is his prerogative and all, I don't fault him for it. Better to attempt it at all... still, it isn't a situation where asking him to maintain the current wallet is likely going to be a success.
119 2015-02-20 03:53:10 <gmaxwell> We're not going to accept some of those hacks, even if it means we lose his contributions entirely.
120 2015-02-20 03:53:17 <Luke-Jr> I see, I wasn't aware of that history.
121 2015-02-20 03:53:23 <gmaxwell> (and no one continues to add features)
122 2015-02-20 03:58:28 <gmaxwell> (e.g. on 5839 we expressed the view that simply deleting things was not going to fly. ... instead not loading them or archiving them into another file, or something might be more reasonable.. but instead he closed the PR and went home (and has passively encouraged users to be rude about this.))
123 2015-02-20 04:00:20 <Luke-Jr> (side note: it's 5389, not 5839 :p)
124 2015-02-20 04:04:17 <gmaxwell> oops.
125 2015-02-20 04:04:51 <gmaxwell> I'd still like to know how someone is ending up with 2.5GB+ wallets.
126 2015-02-20 04:11:30 <Luke-Jr> exchange?
127 2015-02-20 04:12:17 <gmaxwell> Luke-Jr: still doesn't follow, I mean, that would suggest that they were on the order of 8% of all transactions ever, assuming there isn't some gross inefficiency remaining.
128 2015-02-20 04:12:37 <Luke-Jr> hm
129 2015-02-20 04:13:02 <gmaxwell> (there probably is some gross inefficiency, indeed. not sure what it is though.)
130 2015-02-20 04:17:57 <Luke-Jr> gmaxwell: actually, re 4702 memory use: don't we need to allocate that memory temporarily every time right now anyway?
131 2015-02-20 04:18:52 <gmaxwell> Luke-Jr: hm. maybe! It's been a long time since I tested with a multiple gigabyte wallet.
132 2015-02-20 05:22:48 <Luke-Jr> ;;later tell hearn Any chance you would consider tagging Bitcoin XT releases with a syntax like 'xt-0.10' rather than 'v0.10' which confuses with Core tags? thanks for consideration
133 2015-02-20 05:22:49 <gribble> The operation succeeded.
134 2015-02-20 05:39:33 <phantomcircuit> gmaxwell, bitcoin-qt doesn't work with large wallets as it stands anyways
135 2015-02-20 05:41:12 <sipa> phantomcircuit: due to it loading all txn in memory, yes
136 2015-02-20 05:41:27 <sipa> which is the suggested solution: not loading all transactiins
137 2015-02-20 05:41:34 <sipa> rather than deleting
138 2015-02-20 05:45:57 <phantomcircuit> sipa, this seems to be doing the opposite of that
139 2015-02-20 05:46:19 <phantomcircuit> ie replacing calls to walletdb.GetAccountCreditDebit with an in memory map
140 2015-02-20 05:46:51 <phantomcircuit> oh i see
141 2015-02-20 05:46:54 <gmaxwell> phantomcircuit: sipa was referring to another PR that basically added an agressive transaction deletion thing.
142 2015-02-20 05:47:04 <phantomcircuit> ah ok
143 2015-02-20 05:47:53 <phantomcircuit> gmaxwell, i actually cant imagine any scenario in which this pr would be bad when used with bitcoin-qt
144 2015-02-20 05:47:59 <phantomcircuit> but with bitcoind it might be annoying
145 2015-02-20 05:48:02 <phantomcircuit> so
146 2015-02-20 05:48:07 <phantomcircuit> yeah i wouldn't bother
147 2015-02-20 05:48:29 <phantomcircuit> but also yes it's dangerous to assume that someone working on improvements to wallet code will end up with something better
148 2015-02-20 05:48:36 <phantomcircuit> ACTION looks around at everybody
149 2015-02-20 07:01:40 <wumpus> Luke-Jr: the continuing problem is that wallet changes hardly get any review and testing, so we have to be selective
150 2015-02-20 07:03:11 <wumpus> and so a complex change to internal data structures that may introduce new bugs is just too risky, and with the new wallet being worked on it didn't seem a good use of time
151 2015-02-20 07:05:25 <Luke-Jr> wumpus: got it
152 2015-02-20 07:07:15 <wumpus> but as I've said before i'm really looking for someone else to maintain the wallet
153 2015-02-20 07:17:47 <Luke-Jr> wumpus: yeah, I was thinking cozz might want to, but gmaxwell explained that away
154 2015-02-20 07:19:06 <Luke-Jr> in other news, looks like Gentoo users will be getting USE=xt with 0.10 - now I just need to wait and see how complex petertodd's RBF patching will be to shove in there too
155 2015-02-20 07:39:14 <wumpus> ... the last thing I want is to prevent people from improving things, but piling on more hacks to work around fundamental isues in other code is something that was should avoid
156 2015-02-20 07:41:16 <Luke-Jr> it didn't look that hacky IMO, but that's neither here nor there
157 2015-02-20 07:50:12 <wumpus> not entirely a hack, but making the wallet (or anything else for that matter) use even more memory goes against our longer term goal of reducing memory usage
158 2015-02-20 08:20:43 <ciemon> Should/will bitcoin-cli help have as much detail as bitcoin-cli -help
159 2015-02-20 08:21:30 <sipa> help sends the 'help' command to the remote bitcoind
160 2015-02-20 08:21:39 <sipa> -help shows help about bitcoin-cli itself
161 2015-02-20 08:21:44 <sipa> they're totally unrelated
162 2015-02-20 08:21:50 <ciemon> Ahh, clarity, thanks.
163 2015-02-20 08:27:03 <moa> seems like it might need a help to differentiate
164 2015-02-20 08:28:21 <wumpus> "bitcoin-cli --help" calls bitcoin-cli help "List all commands"
165 2015-02-20 08:28:34 <ciemon> :) I've run myself in circles endeavouring to write a bitcoin-cli man page
166 2015-02-20 08:28:40 <wumpus> that's pretty much what it does
167 2015-02-20 08:29:10 <wumpus> maybe "of remote Bitcoin Core" could be added to make it clear that it queries something
168 2015-02-20 08:34:28 <sipa> "List all remote commands" ?
169 2015-02-20 08:37:39 <wumpus> or that
170 2015-02-20 09:44:24 <robbak> It looks like the --with<out>-cli configure option has been ditched - is that so?
171 2015-02-20 09:46:43 <moa> robbak: it was encorporated into --with-utils
172 2015-02-20 09:46:48 <moa> --with-utils build bitcoin-cli bitcoin-tx (default=yes)
173 2015-02-20 09:46:58 <gmaxwell> why would someone turn that off?
174 2015-02-20 09:47:13 <gmaxwell> (I'm just curious?)
175 2015-02-20 09:47:52 <moa> headless on rasp or somesuch ... who knows I guess
176 2015-02-20 09:54:09 <Luke-Jr> gmaxwell: to not compile it many times
177 2015-02-20 09:54:49 <Luke-Jr> for example, for Gentoo's bitcoin-tx, libbitcoinconsensus, bitcoin-qt, and bitcoind packages
178 2015-02-20 09:54:55 <Luke-Jr> also to avoid a dependency on boost
179 2015-02-20 09:56:02 <wumpus> also just for consistency, every part can be turned on/off
180 2015-02-20 09:56:21 <wumpus> say, you only want to build the consensus library
181 2015-02-20 09:56:24 <gmaxwell> yea, fair enough. I wouldn't complain about the flag, just wondered why it would get used.
182 2015-02-20 09:58:18 <wumpus> (though even when compiling just the consensus library, you can't actually pass a c++ compiler that is unable to produce executables in itself, e.g. moxie, first have to disable some autoconf checks)
183 2015-02-20 10:02:21 <michagogo> 11:55:43 <Luke-Jr> for example, for Gentoo's bitcoin-tx, libbitcoinconsensus, bitcoin-qt, and bitcoind packages
184 2015-02-20 10:02:21 <michagogo> Gentoo doesn't have the thing that dpkg does where one source package can produce multiple binary packages?
185 2015-02-20 10:02:43 <Luke-Jr> michagogo: no, mainly because there are pretty much only source packages :p
186 2015-02-20 10:03:21 <Luke-Jr> (binary packages do exist, but they're not really used)
187 2015-02-20 10:05:00 <wumpus> so what gentoo does is extract and configure bitcoin 4 times, each time building only one target?
188 2015-02-20 10:05:13 <Luke-Jr> yep
189 2015-02-20 10:05:15 <michagogo> That seems... suboptimal
190 2015-02-20 10:05:18 <Luke-Jr> 5 times*
191 2015-02-20 10:05:26 <michagogo> what's the 5th?
192 2015-02-20 10:05:30 <michagogo> (you named 4)
193 2015-02-20 10:05:32 <Luke-Jr> bitcoin-cli
194 2015-02-20 10:05:43 <michagogo> Erm, really?
195 2015-02-20 10:05:51 <michagogo> I would think that should come with bitcoind
196 2015-02-20 10:06:01 <wumpus> so the end-user would request to say, install bitcoin-tx and nothing else?
197 2015-02-20 10:06:11 <Luke-Jr> wumpus: could
198 2015-02-20 10:06:21 <Luke-Jr> (note KDE is extracted and configured 1185 times)
199 2015-02-20 10:06:26 <wumpus> oh fair enough, most distributions have somewhat larger groupings for packages
200 2015-02-20 10:07:03 <michagogo> But even if someone were to say "<packagemanager> install bitcoin{d,-tx,-cli} it would do the whole thing thrice?
201 2015-02-20 10:07:06 <michagogo> 1185?!?
202 2015-02-20 10:07:27 <wumpus> but one seems sensible for embedded systems where space is really of the essence...
203 2015-02-20 10:09:13 <Luke-Jr> michagogo: right
204 2015-02-20 10:09:23 <wumpus> or ,say, docker containers, which you want to contain only what is absolutely necessary for the application to run
205 2015-02-20 10:09:46 <michagogo> So... do Gentoo users run on extremely fast machines?
206 2015-02-20 10:09:52 <michagogo> (or have tons of spare time?)
207 2015-02-20 10:10:01 <Luke-Jr> wumpus: multiple packages don't really use more space O.o
208 2015-02-20 10:10:17 <wumpus> Luke-Jr: no, they use less space, if you install only the subset that you need
209 2015-02-20 10:10:18 <Luke-Jr> michagogo: things can build in the background :p
210 2015-02-20 10:10:28 <Luke-Jr> ah, misread you
211 2015-02-20 10:10:33 <wumpus> Luke-Jr: it does give more overhead for the user, of course
212 2015-02-20 10:10:45 <Luke-Jr> michagogo: my KDE update is currently on >>> Emerging (145 of 339) kde-base/kdebugdialog-4.14.3::gentoo
213 2015-02-20 10:11:10 <michagogo> emerging?
214 2015-02-20 10:11:21 <Luke-Jr> yes, that's what it's called when you build/install something
215 2015-02-20 10:11:34 <wumpus> michagogo: see it from the positive side, if only everyone ran an OS like gentoo, compiler writers would have great incentive to optimize compilation time :P
216 2015-02-20 10:11:59 <Luke-Jr> wumpus: and maybe some day the entire OS will be deterministic :P
217 2015-02-20 10:12:09 <gmaxwell> it's actually pretty fast for most things. only mega packages like kde or gcc or firefox take forever.
218 2015-02-20 10:12:56 <wumpus> or anything X-related
219 2015-02-20 10:13:21 <wumpus> bulding a base system, even including a kernel and such is fast these days
220 2015-02-20 10:14:52 <wumpus> although I suppose gentoo users use crazy super-optimization flags bringing the compiler to a crawl for every package *ducks*
221 2015-02-20 10:15:38 <Luke-Jr> I don't, at least. I only enable optimisations that don't screw up gdb
222 2015-02-20 10:15:40 <gmaxwell> at least they help flesh out compiler bugs. :)
223 2015-02-20 10:15:44 <sipa> -femit-broken-code
224 2015-02-20 10:15:55 <Luke-Jr> the main advantage of Gentoo really is control over compile-time options
225 2015-02-20 10:16:31 <Luke-Jr> sipa: actually, CFLAGS="-march=core-avx2 -pipe -ggdb -O0 -mavx -fauto-inc-dec -fdce -fdse -fguess-branch-probability -fipa-pure-const -fmerge-constants -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-sra -fthread-jumps -fcaller-saves -finline-small-functions -findirect-inlining -foptimize-sibling-calls -fregmove -fstrict-aliasing -fstrict-overflow -mno-
226 2015-02-20 10:16:33 <Luke-Jr> ssse3"
227 2015-02-20 10:16:39 <sipa> Obviously.
228 2015-02-20 10:17:24 <Luke-Jr> ACTION ponders if glibc is stable with SSSE3 on Haswell yet.
229 2015-02-20 10:19:11 <gmaxwell> Luke-Jr: where is your -funroll-spoiler ? ( http://funroll-loops.teurasporsaat.org/ )
230 2015-02-20 10:19:33 <null> you have an -O0 in there?
231 2015-02-20 10:19:35 <Luke-Jr> gmaxwell: I just use a subset of -O1 (I think)
232 2015-02-20 10:20:26 <Luke-Jr> null: at the start, yes
233 2015-02-20 10:21:20 <Luke-Jr> michagogo: now >>> Emerging (169 of 339) kde-base/kstars-4.14.3::gentoo
234 2015-02-20 10:21:59 <null> why not keep the default? (-O2, right?) -O0 might counteract most of the switches you put in there
235 2015-02-20 10:22:24 <Luke-Jr> null: the options are parsed in order; so the -O0 is overridden by later options
236 2015-02-20 10:22:32 <Luke-Jr> null: -O2 makes the resulting code hard to debug in gdb
237 2015-02-20 10:22:41 <aliakbar> hello everyone! I got a question: Can one set multiple nodes on the same machine without kind of sanboxing each node?
238 2015-02-20 10:22:51 <wumpus> Luke-Jr: I have a similar crazy set of "-O0 then lots of switches" in the build script for binary comparison, to avoid cross-function optimizations and such which complicate analysis
239 2015-02-20 10:22:52 <Luke-Jr> so I spent an afternoon a few years ago hand-picking optimisations that don't make it hard
240 2015-02-20 10:23:32 <Luke-Jr> aliakbar: yes, but it will wreck havoc if you don't have a SSD
241 2015-02-20 10:23:44 <wumpus> it ends up as "O2 minus the interfering options", I tried to do it the other way around but that didn't work for some reason
242 2015-02-20 10:23:51 <null> Luke-Jr: right, the gdb part. but -O0 might prevent some optimizations indirectly nonthelss. e.g. it'll set arithmetic models to strict and you'll hardly get any benefit for the -mavx switch. just saying
243 2015-02-20 10:24:00 <Luke-Jr> aliakbar: also please use #bitcoin for support questions
244 2015-02-20 10:24:21 <gmaxwell> Luke-Jr: gdb / dwarf have improved a lot in the last couple years; I usually don't have big problems with O2 -g.
245 2015-02-20 10:24:33 <aliakbar> okay sorry and thanks for the hint!
246 2015-02-20 10:24:40 <Luke-Jr> null: well, to be fair, I have to disable AVX for glibc specifically anyway since stupid valgrind doesn't understand it
247 2015-02-20 10:24:57 <Luke-Jr> gmaxwell: -O2 likes to reorder statements, so it jumps around
248 2015-02-20 10:25:21 <wumpus> from my experience c++ debugging w/ optimization using gdb is still a curiosity, e.g. single stepping seems to randomly jump through lines of code
249 2015-02-20 10:25:44 <wumpus> and every time I want to print a variable it's optimized out :*
250 2015-02-20 10:25:58 <null> wumpus: you can try 'disas' and just print the register content
251 2015-02-20 10:26:02 <Luke-Jr> wumpus: that's exactly the kind of thing I avoid with these flags :p
252 2015-02-20 10:26:35 <null> that is if the compiler-generated assembly for c++ is readable at all (:
253 2015-02-20 10:26:40 <Luke-Jr> although STL containers are still annoying to print
254 2015-02-20 10:26:43 <wumpus> null: yes, I could debug at assembly level, but that's usually what I'm trying to avoid :)
255 2015-02-20 10:28:18 <wumpus> it's easier with more semantic information, otherwise you keep having to think about what code is generated by what
256 2015-02-20 10:28:52 <gmaxwell> I think ASLR causes me more debugging heartache than optimization these days.
257 2015-02-20 10:29:52 <wumpus> which was kind of easy in the 90's, but today's compilers do crazy optimizations (e.g. lots of moving around and interleaving instructions) so debugging on a source line basis becomes kind of difficult, that's not the debugger's fault
258 2015-02-20 10:30:08 <Luke-Jr> frankly, modern CPUs are so fast, even straight -O0 is unnoticable in most cases
259 2015-02-20 10:30:14 <robbak> moa: Thanks. And that's also why I need to turn it off, Luke-Jr: In the FreeBSD port, which is being split into -gui, -daemon and -cli ports.
260 2015-02-20 10:30:19 <wumpus> the set of instructions generatd by a certain line is a very ragged set
261 2015-02-20 10:30:22 <null> Luke-Jr: I'd like to disagree
262 2015-02-20 10:30:34 <Luke-Jr> robbak: no -tx or lib? :p
263 2015-02-20 10:30:53 <wumpus> gmaxwell: yes, ASLR also cuases headaches
264 2015-02-20 10:31:04 <null> -O0 -g will cause most codes that actually do work to slow down by at least an order of magnitude
265 2015-02-20 10:31:24 <wumpus> null: not if you re-impose all the options that are normally implied by O1
266 2015-02-20 10:31:29 <Luke-Jr> null: but even then, it's so fastâ¦
267 2015-02-20 10:31:47 <wumpus> null: (or, a large subset, apart from some annoying ones)
268 2015-02-20 10:32:40 <Luke-Jr> (I first switched to Gentoo on a Pentium 3 @ 800 MHz)
269 2015-02-20 10:33:55 <null> let's just agree that it boils down to the choise between speed and debugability :) i still doubt your flags, even with a subset of -O1 will get close to the default -O2 when comparing performance across SPEC or something :) but if it's still fast enough, who cares...
270 2015-02-20 10:33:57 <wumpus> Luke-Jr: yep, on one hand you'd say it has gotten faster from there, on the other hand the average pc contains lots more software
271 2015-02-20 10:35:14 <wumpus> I don't think there is anything wrong with distributing binaries if there is a clear authentication chain starting from the source code (e.g. deterministic build like gitian)
272 2015-02-20 10:36:07 <robbak> Luke-Jr: If I had my way, I'd just have one port exposing all the options. But the masters want to be able to do ~everything with pre-compiled packages, so we need multiple ports.
273 2015-02-20 10:37:02 <Luke-Jr> wumpus: yes, it'd be nice if some day it did p2p distcc with signed compiles :p
274 2015-02-20 10:37:07 <wumpus> but if you can't attest that a certain source code results in a certain binary, it may be kind of foolish to trust executables just because they're signed by Someone That You Trust, so compiling everything from source like gentoo makes some sense
275 2015-02-20 10:37:19 <wumpus> Luke-Jr: yes :D
276 2015-02-20 10:38:13 <Luke-Jr> robbak: well, I hope that eventually all 5 components will live in their own repos with separate issue trackers :D
277 2015-02-20 10:39:02 <robbak> Oh great, more work for me ;D
278 2015-02-20 10:39:33 <wumpus> Luke-Jr: does become more complicated logistically if you retain the possible of changing build options, but 'nodes' could still cross-check/share if they used the same options
279 2015-02-20 10:40:06 <Luke-Jr> wumpus: yes, somewhat. but distcc just distributes preprocessed code, so not necessarily
280 2015-02-20 10:40:21 <Luke-Jr> eg, the build options will likely affect the preprocessor, not the compiler/linker
281 2015-02-20 10:40:34 <wumpus> sure, unless it's the optimizations flags
282 2015-02-20 10:41:07 <Luke-Jr> robbak: less in some ways. no need to duplicate bitcoind/bitcoin-qt options for example
283 2015-02-20 10:41:17 <Luke-Jr> wumpus: right
284 2015-02-20 10:47:05 <wumpus> Luke-Jr: in principle you could achieve the same with a distro like Ubuntu by replicating the build server locally as e.g. a VM image, if the build was deterministic, it'd create exactly the same packages as upstream
285 2015-02-20 10:47:28 <Luke-Jr> I suppose. But you lose the customisability. :p
286 2015-02-20 10:47:49 <wumpus> sure, I'm just thinking about check-ability here, not customizability
287 2015-02-20 10:48:54 <wumpus> in any case deterministic building is the key issue here, that should become the standard
288 2015-02-20 14:24:36 <timothy> hi, do you know if "fasan" is really a member of bitcoin foundation?
289 2015-02-20 14:28:29 <sipa> ask them??
290 2015-02-20 14:29:21 <gavinandresen> timothy: anybody can be a member of the Foundation for $25/year.
291 2015-02-20 14:29:39 <timothy> oh right :)
292 2015-02-20 14:44:43 <hearn> does anyone here have a 32 bit linux system and a few minutes they don't mind volunteering to help me test?
293 2015-02-20 15:02:39 <akstunt600> only 64bit here :0
294 2015-02-20 15:03:03 <akstunt600> Just thinking if it would be at all interesting to have a QT client that operated in a "read only" mode
295 2015-02-20 15:03:14 <akstunt600> for wallet and/or block and index
296 2015-02-20 15:04:00 <akstunt600> i realize it can re-index and may bomb on start, but this could work , no?
297 2015-02-20 15:05:21 <wumpus> hearn: is ARM ok?
298 2015-02-20 15:06:28 <wumpus> akstunt600: you mean an isolated node? -nolisten -connect=0.0.0.0 would work
299 2015-02-20 15:07:02 <wumpus> akstunt600: no one can send it new blocks or transactions, and transactions won't get out, so it's basically read-only
300 2015-02-20 15:07:03 <akstunt600> well i want to read a wallet file and be aware of all new accounts, watch only falls short here.
301 2015-02-20 15:07:54 <akstunt600> So readonly in a sense that it only read the wallet and data dir of another client like bitcoind
302 2015-02-20 15:08:26 <wumpus> I guess a conversion tools could convert a wallet.dat, strip out the private keys, and convert it to watch-only-only
303 2015-02-20 15:08:39 <akstunt600> Yup then i just run on interval
304 2015-02-20 15:08:49 <akstunt600> thanks that is kinda where im at now
305 2015-02-20 15:08:58 <akstunt600> I just see more people will be doing what im doing now
306 2015-02-20 15:09:13 <akstunt600> windows as a service, and the wallet.dat storing accounts.
307 2015-02-20 15:09:28 <wumpus> do make sure that you rewrite the database file and not convert it in place, otherwise the 'empty space' will still have private keys
308 2015-02-20 15:10:09 <akstunt600> thx
309 2015-02-20 15:34:46 <hearn> wumpus: nope, needs to be 32 bit x86. just wanted someone to try the 32 bit lighthouse build as i don't have such a vm here
310 2015-02-20 15:34:50 <hearn> but it's not that big a deal
311 2015-02-20 15:34:55 <hearn> i can send out an email asking for testers as well
312 2015-02-20 15:37:34 <ved_> hello, i'm a bit out of the loop - does anyone know what's going on with this testnet fork?
313 2015-02-20 16:56:58 <gmaxwell> ::sigh:: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054580.html
314 2015-02-20 16:57:32 <gmaxwell> FreeBSD kernel has for the last 4 months not had a working RNG apparently.
315 2015-02-20 16:57:51 <gmaxwell> (not in releases just development code)
316 2015-02-20 17:08:54 <bengt_> ouch
317 2015-02-20 17:10:04 <Diablo-D3> gmaxwell: yeah, hit hn's front page like 2 days ago
318 2015-02-20 17:10:37 <wumpus> who needs a RNG anyway
319 2015-02-20 17:13:19 <wumpus> they heard all the fun stories of javascript applications using crappy RNGs and wanted that too
320 2015-02-20 17:43:28 <ciemon> Pull request #5809 is mine. Lots of firsts for me getting it there. Guess I just sit back and watch/wait to see what happens.
321 2015-02-20 17:48:43 <sipa> nice, a manpage is welcome there
322 2015-02-20 17:50:47 <ciemon> Well if that one "works" I'll have a re-work of bitcoind.1
323 2015-02-20 18:34:07 <cfields> hearn: i have a 32bit vm around if you still need a test
324 2015-02-20 18:45:28 <kanzure> is there a delay on blocknotify?
325 2015-02-20 18:46:15 <gmaxwell> No. Is it broken?
326 2015-02-20 18:51:07 <kanzure> weird bug where i'm always two blocks behind
327 2015-02-20 18:51:33 <kanzure> i don't think it's bitcoind's fault. nevermind.
328 2015-02-20 19:00:54 <kanzure> gmaxwell: is there a guaranteed order regarding walletnotify and blocknotify? say if i run setgenerate(True, 100)
329 2015-02-20 19:11:12 <hearn> cfields: thanks!
330 2015-02-20 19:11:14 <hearn> cfields: https://s3-eu-west-1.amazonaws.com/vinumeris/lighthouse/lighthouse-32bit.deb
331 2015-02-20 19:11:23 <hearn> cfields: could you install that and run it? it's in /opt/lighthouse/lighthouse
332 2015-02-20 19:12:22 <cfields> hearn: heh, i hope more exotic == better...
333 2015-02-20 19:12:34 <hearn> more exotic?
334 2015-02-20 19:12:35 <cfields> this happens to be a debian 6 vm i setup last night
335 2015-02-20 19:12:41 <hearn> ah
336 2015-02-20 19:12:44 <cfields> so, old. is that a problem?
337 2015-02-20 19:12:52 <hearn> well it will try and render 3D graphics
338 2015-02-20 19:12:59 <hearn> it will fall back to 2D if it can't do so
339 2015-02-20 19:13:07 <hearn> so i dunno :)
340 2015-02-20 19:13:21 <cfields> well if it's interesting as a test case, i'll fire it up
341 2015-02-20 19:13:23 <hearn> if it doesn't work because debian 6 is too old, then, i probably won't try and fix that. i guess most desktop linux users are on something more modern
342 2015-02-20 19:13:32 <hearn> yeah, it'd be helpful to know if it starts, or how it fails if not
343 2015-02-20 19:13:37 <cfields> ok
344 2015-02-20 19:14:16 <Diablo-D3> http://www.newegg.com/Product/Product.aspx?Item=N82E16820167190&utm_medium=Email&utm_source=IGNEFL022015&nm_mc=EMC-IGNEFL022015&cm_mmc=EMC-IGNEFL022015-_-EMC-022015-Index-_-InternalSSDs-_-20167190-S0A1B
345 2015-02-20 19:14:20 <Diablo-D3> cheap intel 730 240gb
346 2015-02-20 19:21:18 <cfields> hearn: any idea what deps are needed? Running from a base install atm, happy to install whatever's needed
347 2015-02-20 19:21:53 <hearn> cfields: um, X libraries, libstdc++ i guess ..... not sure what else
348 2015-02-20 19:22:05 <hearn> nothing especially odd
349 2015-02-20 19:22:13 <hearn> if you can run tux racer then you can probably run lighthouse :)
350 2015-02-20 19:23:00 <cfields> can't run tux racer from a console :)
351 2015-02-20 19:23:10 <cfields> i'll just install gnome+gdm and be done with it
352 2015-02-20 19:23:32 <kanzure> i am receiving a bunch of unexpected walletnotify. i am using setgenerate(True, 3). i get way more than 3 walletnotify events.
353 2015-02-20 19:23:51 <kanzure> (this didn't happen before?)
354 2015-02-20 19:33:58 <Michail1> Anyone here play with mycelium in exporting the mpubkey to generate future payment addresses, but then realize the the iOS version of mycelium exports diff pubkey even after sucessfully restoring from a master seed list? I am just wondering why mycelium would go two diff formats for android/iOS when initial imports work fine.
355 2015-02-20 19:36:48 <cfields> hearn: mkdir -p ~/.local/share/Lighthouse
356 2015-02-20 19:37:11 <cfields> otherwise i get an exception at startup
357 2015-02-20 19:37:15 <hearn> cfields: it should have done that for you
358 2015-02-20 19:37:15 <hearn> huh
359 2015-02-20 19:37:16 <hearn> ok
360 2015-02-20 19:37:23 <cfields> after that, seems to load up ok
361 2015-02-20 19:37:27 <hearn> let me try blowing away my directory and see what happens
362 2015-02-20 19:37:32 <cfields> want anything tested in particular?
363 2015-02-20 19:37:54 <cfields> hearn: no clue if it's related, but i didn't have X installed when i installed the .deb
364 2015-02-20 19:38:13 <cfields> so it could've failed silently somewhere trying to mkdir inside of an assumed dir
365 2015-02-20 19:38:58 <hearn> no, the deb doesn't do anything like that
366 2015-02-20 19:39:04 <hearn> do you still have the stack trace?
367 2015-02-20 19:39:26 <hearn> oh, wait ....... i bet i know the issue
368 2015-02-20 19:39:32 <hearn> did you have a .local/share directory before?
369 2015-02-20 19:39:55 <cfields> no
370 2015-02-20 19:39:55 <hearn> i bet the issue is that no other app you ran before uses this directory. but more modern linuxes all have stuff in there already
371 2015-02-20 19:40:05 <cfields> sounds about right
372 2015-02-20 19:40:08 <hearn> so i never got to test the codepath where the parent directories don't exist
373 2015-02-20 19:40:12 <hearn> ok, thanks, i'll fix that
374 2015-02-20 19:40:21 <hearn> if it starts up that's good enough for me. it means the native code components are all working. thanks!
375 2015-02-20 19:40:47 <cfields> AppDirectory.java:34
376 2015-02-20 19:41:02 <hearn> yeah
377 2015-02-20 19:41:03 <hearn> thanks
378 2015-02-20 19:41:06 <cfields> ok
379 2015-02-20 19:41:06 <cfields> please don't make me figure out how to get c/p working with virtualbox :). I assume you're good now anyway
380 2015-02-20 19:41:55 <hearn> yep i'm good. thanks! that helps
381 2015-02-20 19:42:02 <cfields> np, happy to help
382 2015-02-20 20:01:06 <cfields> jtimon_: around?
383 2015-02-20 20:04:08 <Luke-Jr> cfields: would it be difficult to move the manpages to the main install using autotools?
384 2015-02-20 20:04:26 <cfields> Luke-Jr: not at all, thought the same thing when i saw that PR
385 2015-02-20 20:11:10 <cfields> Luke-Jr: it'd probably make sense to move it out of debian and into share/, install with 'make install', then let debian just pick it up automatically. I assume that's what you were thinking as well?
386 2015-02-20 20:11:13 <jtimon_> cfields yep
387 2015-02-20 20:11:47 <Luke-Jr> cfields: yes, possibly with autogenerating the CLI options list, but that could come later
388 2015-02-20 20:12:40 <cfields> jtimon_: mind taking a quick look over my work-in-progress to see if we're going to clash?
389 2015-02-20 20:12:50 <jtimon_> sure
390 2015-02-20 20:13:03 <jtimon_> where is it?
391 2015-02-20 20:13:20 <cfields> sec, will push
392 2015-02-20 20:17:38 <cfields> jtimon_: consensus-refactor2 branch
393 2015-02-20 20:17:59 <jtimon_> cool, will take a look
394 2015-02-20 20:18:37 <cfields> it contains #5151 and #5810 which are already PR'd
395 2015-02-20 20:19:12 <cfields> er, i suppose that was a bit redundant :)
396 2015-02-20 20:24:14 <cfields> jtimon_: the aim of the work is to free chainparams/checkpoints/protocol/policy/pow/ from global app state and boost, so that they can be moved to logical modules and/or consensus lib as necessary.
397 2015-02-20 20:24:16 <jtimon_> at a first glance they seem mostly complementary, some probably trivial conflicts in chainparams and some conflicts in pow too
398 2015-02-20 20:24:16 <jtimon_> see 725aba1e and e291e101 in jtimon/consensus2
399 2015-02-20 20:24:43 <jtimon_> I'll look into the PRs now...
400 2015-02-20 20:27:03 <cfields> jtimon_: mm, i'd rather not add a 3rd layer of params. Looks like we should collaborate on that one.
401 2015-02-20 20:28:10 <jtimon_> I considered using the basechainparams instead but I wanted to keep non-consensus stuff out
402 2015-02-20 20:28:38 <cfields> Looks like we basically did the same thing with e291e101
403 2015-02-20 20:29:05 <jtimon_> yeah, very similar
404 2015-02-20 20:29:28 <jtimon_> I'm just keeping server and policy stuff out
405 2015-02-20 20:29:44 <cfields> ok, looking into the details of 725aba1e
406 2015-02-20 20:33:36 <cfields> jtimon_: actually, that makes sense.
407 2015-02-20 20:34:46 <cfields> jtimon_: so, fine by me. why fSkipProofOfWorkCheck in params though?
408 2015-02-20 20:35:36 <jtimon_> actually I went back and forth with that one, it's used by unitestparams
409 2015-02-20 20:38:23 <cfields> seems to kind of negate the purpose of splitting them out if there's still runtime-specific behavior in there, no?
410 2015-02-20 20:38:35 <jtimon_> it could also be a parameter for CheckProofOfWork() (or moved up to its calls) and a param for Consensus::ContextualCheckBlockHeader() [see 6a61028f]
411 2015-02-20 20:39:25 <jtimon_> what do you mean runtime-specific? it depends on the selected params like the rest
412 2015-02-20 20:40:05 <cfields> CheckProofOfWork(bool fdontReallyCheck) :)
413 2015-02-20 20:40:30 <sipa> CheckProofOfWork(bool fHahaJustKidding)
414 2015-02-20 20:40:35 <jtimon_> sipa suggested that it was consensus when I asked him though he was listening to my explanation rather than looking at the code
415 2015-02-20 20:40:53 <cfields> moving it up makes sense to me, since in order to pass it you'd have to already know it at the call-site
416 2015-02-20 20:40:53 <sipa> yeah, i still haven't looked, so i'm not actually commenting :)
417 2015-02-20 20:41:38 <jtimon_> yeah, for CheckProofOfWork seems obvious that the param option doesn't make sense, either keep it as chainparam or move it up to the calls (or both?)
418 2015-02-20 20:41:52 <jtimon_> the key I think is Consensus::ContextualCheckBlockHeader()
419 2015-02-20 20:42:18 <jtimon_> there it could be a parameter or a consensus param
420 2015-02-20 20:43:43 <jtimon_> it's not clear to me either
421 2015-02-20 20:46:22 <paveljanik> wumpus, what is the plan with you 2014_12_bigendian branch?
422 2015-02-20 20:46:37 <sipa> ACTION says: merge it
423 2015-02-20 20:46:47 <paveljanik> +1
424 2015-02-20 20:46:49 <paveljanik> ;-)
425 2015-02-20 20:47:39 <cfields> jtimon_: hmm, 568bb8b394 in my branch probably needs the same treatment as fSkipProofOfWorkCheck in yours
426 2015-02-20 20:49:04 <cfields> mm, nm. tests switch that on/off
427 2015-02-20 20:49:32 <jtimon_> yes, unitestparams switch that on and off
428 2015-02-20 20:50:42 <BlueMatt> ciemon: the man file is just whats in github....I dont have any plans on updating myself
429 2015-02-20 20:50:53 <BlueMatt> but feel free to update it and pull-request it into github
430 2015-02-20 21:21:30 <gmaxwell> paveljanik: bleh. on #5783 please don't let yourself get trapped on the privacy part; that is only one fork of a multifolded complaint.
431 2015-02-20 21:21:46 <gmaxwell> The biggest issue isn't that, it's that it creates awful incentives to sybil attack the network that do not currently exist.
432 2015-02-20 21:22:22 <gmaxwell> It's much easier to spin up tens of thousands of nodes via proxies on botnet hosts that just forward back to a single real node, than it is to setup just a couple real nodes.
433 2015-02-20 21:23:05 <paveljanik> yes and a lot more problems...
434 2015-02-20 21:24:18 <paveljanik> but this is not a problem of bitcoin or bitcoin network. This is the problem of the other side.
435 2015-02-20 21:24:25 <paveljanik> ie. bitnodes or what it is.
436 2015-02-20 21:24:41 <paveljanik> and this piece of information is missing to Pavol, I think.
437 2015-02-20 21:25:20 <paveljanik> He thinks that you are talking about bitcoin/bitcoin core issues where in fact you are talking about bitnodes initiative issues.
438 2015-02-20 21:25:42 <sipa> what does bitnodes have anything to do with it?
439 2015-02-20 21:26:01 <paveljanik> or other domain, sorry, do not remember it...
440 2015-02-20 21:26:02 <paveljanik> mmnt
441 2015-02-20 21:26:51 <sipa> it's just a bad idea 1) to encourage address reuse 2) to encourage node identifiability 3) to encourage using an unauthenticated (and trivially mitm'able) payment destination
442 2015-02-20 21:27:04 <paveljanik> definitely ;-)
443 2015-02-20 21:28:22 <gmaxwell> sipa: "bitnodes" has some crazy thing to pay people to run nodes, quite ill-advisidly. :(
444 2015-02-20 21:28:30 <paveljanik> Hmm, I think Pavol's mission can be solved the other way round.
445 2015-02-20 21:28:32 <gmaxwell> (which apparently BCF was paying for)
446 2015-02-20 21:28:36 <sipa> i've tried to discourage them
447 2015-02-20 21:28:41 <Luke-Jr> if it wasn't for the chicken-and-egg problem, it'd be nice for nodes to require payment for IBD-type use, but that's a lot more complicated than the proposal in the issue
448 2015-02-20 21:29:07 <gmaxwell> Luke-Jr: yea, chicken and egg trups that. well you can hashcash of course (e.g. micropayment via mining)
449 2015-02-20 21:29:21 <gmaxwell> But incentives are concerning indeed.
450 2015-02-20 21:29:27 <paveljanik> bitnodes itself could send a unique one-time hash to them via their user agent as an identification and the administrator/owner of the node could look it up in the logs and input it at their web.
451 2015-02-20 21:30:19 <Luke-Jr> hm
452 2015-02-20 21:30:27 <paveljanik> ie. when the owner of 1.2.3.4 addnode's their IP, they return user-agent as xxx satoshi 0.11.11 (use this hash at our site to ....: ababababa)
453 2015-02-20 21:30:40 <Luke-Jr> I suppose once we support SPV mode, we *could* have the SPV---IBD-->FullNode transition a paid service
454 2015-02-20 21:34:10 <gmaxwell> hm. I was just about to submit a PR removing the useragents from the log. (because they can be used to fingerprint nodes in log files, e.g. you think your logs are anonymous but someone made identifying connections to you). I guess its not that important.
455 2015-02-20 21:35:35 <paveljanik> I think it would be better to make it easier for users/node owners to fake their user-agent, remove version number from it etc.
456 2015-02-20 21:35:43 <Luke-Jr> uh, can we ban changetip from our github? :|
457 2015-02-20 21:39:39 <Luke-Jr> FWIW, due to my DNS seed's slower crawl time, I've increased the timeout on http://luke.dashjr.org/programs/bitcoin/files/charts/security.html to 4 weeks
458 2015-02-20 22:09:39 <sipa> new graph: http://bitcoin.sipa.be/ver-ever.png
459 2015-02-20 22:14:56 <Luke-Jr> heh
460 2015-02-20 22:15:00 <Michail1> heh. I thought it was going to be a picture of Roger
461 2015-02-20 22:15:37 <sipa> lol
462 2015-02-20 22:20:43 <kanzure> would there be any good reasons why blocknotify would start taking an extra 20-30 seconds to trigger?
463 2015-02-20 22:22:11 <Luke-Jr> kanzure: do the blocks take that long to verify?
464 2015-02-20 22:22:31 <Luke-Jr> or maybe to write?
465 2015-02-20 22:23:06 <kanzure> hmm. no.
466 2015-02-20 23:11:04 <smooth> does rest/chaininfo.json work?
467 2015-02-20 23:11:30 <smooth> i get Not Found even though the other rest queries work
468 2015-02-20 23:12:25 <rgenito> =|
469 2015-02-20 23:13:07 <rgenito> is it possible for an app to give a response to bitcoin URLs? for example, "bitcoin:addresshere" is the request, and the response is, "{'status':'paid'}" ?
470 2015-02-20 23:19:43 <kanzure> Luke-Jr: i think my problems were related to prioritizing walletnotifys over blocknotifys. things seem to be resolved now.
471 2015-02-20 23:20:37 <Luke-Jr> rgenito: yes, BIP 70
472 2015-02-20 23:40:14 <rgenito> Luke-Jr, thanks, you just helped me prevent re-inventing the wheel
473 2015-02-20 23:42:11 <rgenito> Luke-Jr, actually, this might not be it
474 2015-02-20 23:42:25 <rgenito> i found x-callback-url as an inspiration
475 2015-02-20 23:42:46 <rgenito> basically, a way to ask the wallet, "what is your bitcoin address?"
476 2015-02-20 23:44:23 <rgenito> ie: bitcoin:?scheme=myapp&key=address
477 2015-02-20 23:45:40 <rgenito> installed bitcoin wallet responds with the equivalent of "myapp://?address=1bitcoinAddressHere
478 2015-02-20 23:45:42 <rgenito> "
479 2015-02-20 23:56:13 <Luke-Jr> rgenito: BIP 70 is it