1 2015-03-12 00:59:47 <hearn> Luke-Jr: what's the fee policy on your pool?
  2 2015-03-12 01:01:35 <phantomcircuit> hearn, there is no feee
  3 2015-03-12 01:01:59 <gmaxwell> phantomcircuit: I think he means transaction inclusion policy.
  4 2015-03-12 01:02:13 <hearn> yeah
  5 2015-03-12 01:02:28 <phantomcircuit> oh
  6 2015-03-12 01:02:56 <hearn> sorry, that was ambiguous
  7 2015-03-12 01:20:40 <Luke-Jr> hearn: 0.1 TBC per 512 bytes in most cases: http://eligius.st/~gateway/faq/how-are-transactions-selected-blocks
  8 2015-03-12 01:23:49 <hearn> Luke-Jr: do you have conversions from TBC into BTC?
  9 2015-03-12 01:24:50 <Luke-Jr> 0x<TBC> * 0.00065536
 10 2015-03-12 01:25:25 <Luke-Jr> so 0.00004096 BTC in this case
 11 2015-03-12 01:25:54 <hearn> so about 4x the default min fee?
 12 2015-03-12 01:26:31 <Luke-Jr> if you mean relay min fee, yes
 13 2015-03-12 01:27:12 <hearn> ok. is there a rationale for that choice beyond it being a round number of tonal bitcoins? :)
 14 2015-03-12 01:27:16 <hearn> 
ACTION just curious

 15 2015-03-12 01:27:38 <Luke-Jr> actually, more like 8x since it's not per kB?
 16 2015-03-12 01:27:44 <hearn> ah, right
 17 2015-03-12 01:28:05 <Luke-Jr> hearn: besides being a round number, it's slightly less than the default mining min fee
 18 2015-03-12 01:33:59 <hearn> Luke-Jr: default behaviour is to mine transactions that relay, right?
 19 2015-03-12 01:40:09 <Luke-Jr> yes, it looks like that semi-snuck into 0.9 :/
 20 2015-03-12 01:40:30 <Luke-Jr> (rationale makes sense, just not the end result of it actually being accepted)
 21 2015-03-12 01:42:41 <mike420> http://www.ebay.com/itm/271801501789?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1555.l2649
 22 2015-03-12 01:42:44 <mike420> good price?
 23 2015-03-12 01:43:00 <Luke-Jr> ugh, this is spammed in every channel
 24 2015-03-12 01:43:29 <mike420> see who answers
 25 2015-03-12 01:43:47 <Luke-Jr> more likely see how quickly you get banned
 26 2015-03-12 01:44:37 <mike420> i2p prevents that
 27 2015-03-12 01:45:43 <copumpkin> o.O
 28 2015-03-12 01:53:48 <Luke-Jr> anyway, hopefully no miners are actually using that low of a min fee
 29 2015-03-12 05:32:19 <qoqopop> I'm looking for bitcoin code that handles everything related to the (network) status of peers. Which files should I look at?
 30 2015-03-12 05:33:27 <phantomcircuit> qoqopop, pNodes
 31 2015-03-12 05:33:30 <phantomcircuit> pnode?
 32 2015-03-12 05:36:30 <qoqopop> Okay, I should be able to figure out most from there; thanks.
 33 2015-03-12 07:32:01 <jonasschnelli> there are still build/travis issues IMO: https://travis-ci.org/bitcoin/bitcoin
 34 2015-03-12 07:33:52 <jonasschnelli> Still some chainParams issues: https://travis-ci.org/bitcoin/bitcoin/jobs/53977935#L1618
 35 2015-03-12 07:43:29 <wumpus> jonasschnelli: we know
 36 2015-03-12 07:46:22 <wumpus> rebasing won't solve it, unfortunately
 37 2015-03-12 07:49:43 <jonasschnelli> wumpus, hmm... okay. Is it because of the random order of the tests? Or why did 2nd last PR didn't fail: https://github.com/bitcoin/bitcoin/pulls?
 38 2015-03-12 07:50:10 <wumpus> because the tests are a broken mess now
 39 2015-03-12 07:51:00 <jonasschnelli> okay. I see.
 40 2015-03-12 07:51:17 <wumpus> is there a way to execute the boost tests one at a time? randomization will only find part of the tests that fail if they're first...
 41 2015-03-12 07:51:56 <jonasschnelli> wumpus, yes. There is. let me check my bash log
 42 2015-03-12 07:52:03 <wumpus> I'm going to give it a try fixing this, if not I'm going to revert the per-test fixture until it works
 43 2015-03-12 07:52:35 <wumpus> key_tests, bloom_tests all need these parameters
 44 2015-03-12 07:53:20 <jonasschnelli> wumpus, ./src/test/test_bitcoin --run_test=wallet_tests
 45 2015-03-12 07:54:06 <wumpus> setting the parameters at the top of each test seems error prone. It may not have been entirely 'clean' but having tests able to assume they were run with mainnet parameters unless specified otherwise worked very well...
 46 2015-03-12 07:55:00 <jonasschnelli> maybe then it's better to revert and clean it out separately?
 47 2015-03-12 07:55:03 <wumpus> is this fixture called before every individual test or just once at the beginning of the tests in a group?
 48 2015-03-12 07:56:38 <jonasschnelli> wumpus, do you mean TestingSetup::TestingSetup()?
 49 2015-03-12 07:56:52 <wumpus> I'm going to add a fixture that just does SelectParams(MAIN), fPrintToDebugLog=false;   and use it everywhere
 50 2015-03-12 07:57:29 <jonasschnelli> Would be a try
 51 2015-03-12 07:57:47 <wumpus> a try? it's more supposed to be the jackhammer solution
 52 2015-03-12 07:58:08 <wumpus> do you see any way this wouldn't work?
 53 2015-03-12 07:58:23 <sipa> i think we should do this
 54 2015-03-12 07:58:52 <wumpus> there's another problem - noui_connect is called lots of times, but there is no symmetric disconnect function
 55 2015-03-12 08:00:04 <wumpus> not that it matters in practice I think, all the noui does is log some things that would otherwise be shown in the GUI, there is no logging in the case of the tests
 56 2015-03-12 08:00:36 <jonasschnelli> couldn't we not remove noui_connect() from test_bitcoin.cpp? On my side this as no affect. Tests running through even after removing this.
 57 2015-03-12 08:00:37 <wumpus> it may not be necessary at all
 58 2015-03-12 08:00:42 <jonasschnelli> ineed.
 59 2015-03-12 08:00:45 <jonasschnelli> indeed
 60 2015-03-12 08:02:30 <jonasschnelli> wumpus, you could also add a global fixtures? BOOST_GLOBAL_FIXTURE( MyConfig );?
 61 2015-03-12 08:02:49 <wumpus> isn't that were we're coming from?
 62 2015-03-12 08:04:23 <sipa> the global fixture only runs once
 63 2015-03-12 08:04:33 <sipa> despite what the documentation says
 64 2015-03-12 08:04:39 <jonasschnelli> hmm...
 65 2015-03-12 08:22:38 <wumpus> cfields: would it be possible to cut down on the sheer volume of logging in travis? e.g. print portions only when something went wrong, or somehow collapse them, so that the failures stand out more?
 66 2015-03-12 08:35:44 <sipa> ;;nethash
 67 2015-03-12 08:35:45 <gribble> 357152689.034
 68 2015-03-12 09:18:59 <Krellan_> With latest source from github, I get compilation error in compat/endian.h - is this a FAQ?
 69 2015-03-12 09:19:08 <Krellan_> http://pastebin.com/mdhi9YCJ
 70 2015-03-12 09:19:10 <wumpus> Krellan_: run ./autogen.sh
 71 2015-03-12 09:19:21 <Krellan_> Already did
 72 2015-03-12 09:20:52 <wumpus> it is, however, exactly the problem that you get if you don't re-run the autotools bootstrapping process
 73 2015-03-12 09:21:22 <sipa> maybe a stale configure.h in the wrong directory?
 74 2015-03-12 09:22:39 <Krellan_> I will look for that
 75 2015-03-12 09:22:52 <moa> Krellan_ try cleaning everything out and before running ./autogen.sh ... e.g. "git clean -fxd" takes back to a fresh git state
 76 2015-03-12 09:22:57 <wumpus> it could be; maybe clean the entire directory out with 'git clean -f -x -d'
 77 2015-03-12 09:23:16 <wumpus> (warning: that removes any scripts and such you may have added)
 78 2015-03-12 09:24:22 <Krellan_> Cool command!  Was looking for something that would do that.
 79 2015-03-12 09:24:39 <sipa> it's "git clean -dfx"
 80 2015-03-12 09:24:52 <sipa> any other order of flags is blasphemy
 81 2015-03-12 09:25:10 <wumpus> I'm a heretic
 82 2015-03-12 09:25:41 <moa> full faith and credit in the cli
 83 2015-03-12 09:27:38 <Krellan_> Thanks!  It seems much happier now.
 84 2015-03-12 09:27:53 <wumpus> great. This shouldn't happen, but it does...
 85 2015-03-12 09:34:49 <Luke-Jr> so where are the BSD developers? ;)
 86 2015-03-12 09:36:41 <Luke-Jr> koobs: robbak: nerdcore_: https://github.com/bitcoin/bitcoin/pull/5872
 87 2015-03-12 09:38:56 <drizztbsd> Luke-Jr: I fixed something (includes) on bitcoin to work on freebsd some years ago
 88 2015-03-12 09:40:05 <Luke-Jr> drizztbsd: = you're no longer interested in Bitcoin Core working on BSD now? not sure how to interpret that ☺
 89 2015-03-12 09:40:55 <timothy> I don't use bsd anymore :P
 90 2015-03-12 09:41:24 <Luke-Jr> ah
 91 2015-03-12 09:41:46 <qoqopop> hmmm, according to blockchain.info block 347278 was found 4 minutes after 347277, but block 347279 was found 4 minutes _before_ 347278
 92 2015-03-12 09:42:01 <wumpus> qoqopop: that's perfectly normal
 93 2015-03-12 09:42:03 <Luke-Jr> qoqopop: #blockchain.info or #bitcoin
 94 2015-03-12 09:42:36 <deepcore> I have tried to use BSD, but there is always compability/compiling issues with software that I use
 95 2015-03-12 09:42:44 <qoqopop> i guess bitcoin is really lax with checking timestamps?
 96 2015-03-12 09:43:04 <deepcore> so always giving up in the and and installing linux
 97 2015-03-12 09:43:07 <sipa> qoqopop: timestamps can be up to an hour off, and this does nkt matter
 98 2015-03-12 09:43:16 <Luke-Jr> qoqopop: yes, and beyond/besides that, blockchain.info is full of misinformation
 99 2015-03-12 09:43:45 <wumpus> jonasschnelli: re: #5880 it's weird that we need so much macosx specific code, is qt so broken by default?
100 2015-03-12 09:45:19 <qoqopop> sipa: because timestamps are only relevant to the periodic difficulty calculation, right?
101 2015-03-12 09:46:42 <jonasschnelli> wumpus, 5880 only changes the mac specific code.
102 2015-03-12 09:46:47 <sipa> qoqopop: cirrect
103 2015-03-12 09:46:52 <sipa> sorry, correct
104 2015-03-12 09:46:58 <jonasschnelli> wumpus, Qt always had issues with the dock handling
105 2015-03-12 09:47:18 <Krellan_> Nice, got a clean build: https://github.com/bitcoin/bitcoin/pull/5288
106 2015-03-12 09:47:22 <wumpus> jonasschnelli: yes. Ijust wonder what qt is lacking, that we need macosx specific code for that
107 2015-03-12 09:47:31 <jonasschnelli> wumpus, and 5880 will reduce mac spec. code (+24/-31)
108 2015-03-12 09:47:42 <wumpus> jonasschnelli: it also break every time :p
109 2015-03-12 09:47:59 <jonasschnelli> wumpus, yes. Thats really a shame. I would also prefer a proper qt solution.
110 2015-03-12 09:48:51 <jonasschnelli> even if i could submit a PR to qt it would take ages if we could use it for bitcoin-qt
111 2015-03-12 09:50:25 <wumpus> right
112 2015-03-12 09:52:49 <wumpus> going to merge #5883, to avoid all new travis builds from breaking
113 2015-03-12 09:53:52 <jonasschnelli> ACK
114 2015-03-12 09:53:55 <koobs> Luke-Jr: give me a test command to run and ill verify on 9/10/current
115 2015-03-12 09:55:03 <qoqopop> Does bitcoin have any code _specifically_ aimed at mitigating the inconvenience of NATed/firewalled peers? (It doesn't seem like it, so I guess the protocol is designed well enough for it to be a not a big problem?)
116 2015-03-12 09:56:07 <wumpus> qoqopop: UPnP is used where possible to create an outside-reachable port
117 2015-03-12 09:56:26 <Luke-Jr> koobs: move db_cxx.h to <include-root>/bdb48/ and see if the output from `grep BDB_CPPFLAGS config.log` changes (and the whole thing builds)
118 2015-03-12 09:56:36 <wumpus> qoqopop: that is just for the network's sake, it doesn't give the user any inconvenience to not be remotely reachable
119 2015-03-12 09:57:12 <qoqopop> wumpus: oh! still, I didnt know about the UPnP, thanks.
120 2015-03-12 09:59:43 <Luke-Jr> koobs: if you can put a space in the <include-path>, that'd be even betterest
121 2015-03-12 10:00:08 <qoqopop> wumpus: BTW, do you have any rough idea what percentage of otherwise walled off peers become accesible through this UPnP method?
122 2015-03-12 10:00:16 <wumpus> qoqopop: no
123 2015-03-12 10:00:25 <koobs> Luke-Jr: cant i just test for sed syntax? :D
124 2015-03-12 10:00:48 <Luke-Jr> koobs: possibly, rip it out of the generated configure file though, not the autoconf sources
125 2015-03-12 10:01:30 <koobs> if you can give me a test/valid cmd to run, i can do that :)
126 2015-03-12 10:01:37 <koobs> Luke-Jr: otherwise i lack cycles
127 2015-03-12 10:01:49 <koobs> i have a contributor breathing down my neck for Python/LibreSSL support
128 2015-03-12 10:06:30 <Luke-Jr> koobs: echo $(curl -s http://codepad.org/lFFyiFai/raw.txt  | sed -E -e ':a' -e '/\\$/!b b' -e N -e 's/\\\n/ /' -e 't a' -e ':b' -e 's/^[^:]*:[[:space:]]*(([^[:space:]\]|\\.)*[[:space:]])*(([^[:space:]\]|\\.)*)db_cxx\.h([[:space:]].*)?$/\3/' -e 't' -e d)
129 2015-03-12 10:06:49 <koobs> you win the internet luke
130 2015-03-12 10:07:16 <koobs> Luke-Jr: except s/curl/fetch
131 2015-03-12 10:07:23 <koobs> </portability>
132 2015-03-12 10:07:25 <koobs> :D
133 2015-03-12 10:07:46 <Luke-Jr> bash: fetch: command not found
134 2015-03-12 10:08:01 <koobs> touche.
135 2015-03-12 10:08:04 <Luke-Jr> :D
136 2015-03-12 10:08:08 <koobs> different when its on the other foot eh?
137 2015-03-12 10:08:10 <koobs> :D
138 2015-03-12 10:08:13 <koobs> FreeBSD 9: /usr/include/db4.8/
139 2015-03-12 10:08:49 <koobs> Illegal variable name.
140 2015-03-12 10:08:52 <koobs> on 10
141 2015-03-12 10:08:54 <koobs> hmm
142 2015-03-12 10:08:58 <koobs> give me a tick
143 2015-03-12 10:09:07 <koobs> nope, curl is good.
144 2015-03-12 10:09:14 <Luke-Jr> ?
145 2015-03-12 10:09:43 <koobs> could be a shell thing.
146 2015-03-12 10:09:52 <koobs> the echo $() isnt in the invocation is it ?
147 2015-03-12 10:10:04 <timothy> curl -s http://codepad.org/lFFyiFai/raw.txt  | sed -E -e ':a' -e '/\\$/!b b' -e N -e 's/\\\n/ /' -e 't a' -e ':b' -e 's/^[^:]*:[[:space:]]*(([^[:space:]\]|\\.)*[[:space:]])*(([^[:space:]\]|\\.)*)db_cxx\.h([[:space:]].*)?$/\3/' -e 't' -e d
148 2015-03-12 10:10:13 <Luke-Jr> koobs: without that, you won't get a newline at the end
149 2015-03-12 10:10:13 <timothy> echo is not necessary neither $()
150 2015-03-12 10:10:20 <timothy> not a big problem :)
151 2015-03-12 10:10:25 <koobs> Luke-Jr: freebsd 10 (with /bin/sh, not /bin/csh): /usr/include/db4.8/
152 2015-03-12 10:10:51 <koobs> *spins up current*
153 2015-03-12 10:12:02 <koobs> Luke-Jr: FreeBSD-CURRENT (as of a month ago): /usr/include/db4.8/
154 2015-03-12 10:12:51 <Luke-Jr> koobs: is 9 the oldest maintained?
155 2015-03-12 10:13:01 <koobs> Luke-Jr: 8, technically
156 2015-03-12 10:13:13 <koobs> Luke-Jr: its a last minor version -1 type situation
157 2015-03-12 10:13:20 <koobs> Luke-Jr: im confident that it'll workl
158 2015-03-12 10:13:27 <koobs> Luke-Jr: the fact that youve stuck to POSIX for one
159 2015-03-12 10:13:43 <Luke-Jr> well, I'm unsure the -E is POSIX
160 2015-03-12 10:13:48 <koobs> let me look
161 2015-03-12 10:14:37 <koobs> Luke-Jr: our docs rock: https://www.freebsd.org/cgi/man.cgi
162 2015-03-12 10:14:45 <koobs> if you ever want to compare things between versions
163 2015-03-12 10:15:00 <koobs> Luke-Jr: 8 -stable has -E
164 2015-03-12 10:15:16 <Luke-Jr> great, thanks
165 2015-03-12 10:15:18 <koobs>    The sed utility is expected to be a superset of the IEEE Std 1003.2
166 2015-03-12 10:15:20 <koobs>      (``POSIX.2'') specification.
167 2015-03-12 10:15:22 <koobs> specifically
168 2015-03-12 10:15:30 <koobs>  The -E, -I, -a and -i options, the prefixing ``+'' in the second member
169 2015-03-12 10:15:32 <koobs>      of an address range, as well as the ``I'' flag to the address regular
170 2015-03-12 10:15:34 <koobs>      expression and substitution command are non-standard FreeBSD extensions
171 2015-03-12 10:15:36 <koobs>      and may not be available on other operating systems.
172 2015-03-12 10:15:37 <Luke-Jr> can you drop your results on the github issue or shall I summarise?
173 2015-03-12 10:15:47 <koobs> you can summarise :)
174 2015-03-12 10:15:53 <koobs> Just say @koobs test on 9/10/current
175 2015-03-12 10:17:22 <koobs> there might be other inconsistencies though
176 2015-03-12 10:17:37 <koobs> bugs not withstanding
177 2015-03-12 10:18:10 <Luke-Jr> well, if someone has time to test the CXXCPP output too, that would be useful to be sure of (but I can't imagine anything that could break it)
178 2015-03-12 10:18:26 <Luke-Jr> … unless something does a\\nb to get "ab" filename ☺
179 2015-03-12 10:18:28 <koobs> Luke-Jr: add a test for the expected output
180 2015-03-12 10:18:34 <koobs> if you havent already
181 2015-03-12 10:18:42 <koobs> least i can test pre-update then :)
182 2015-03-12 10:18:59 <Luke-Jr> koobs: expected output is dynamic ;)
183 2015-03-12 10:19:14 <koobs>  Darius │ koobs: -E is very old
184 2015-03-12 10:19:16 <koobs> :)
185 2015-03-12 10:19:49 <koobs> also
186 2015-03-12 10:19:51 <koobs> -r     Same as -Efor compatibility with GNU sed.
187 2015-03-12 10:19:58 <Luke-Jr> O.o
188 2015-03-12 10:20:05 <Luke-Jr> oh, the -r option is the same as -E
189 2015-03-12 10:20:18 <koobs> thats how i took it
190 2015-03-12 10:20:20 <koobs> https://www.freebsd.org/cgi/man.cgi?query=sed#end
191 2015-03-12 10:20:36 <koobs> https://lists.freebsd.org/pipermail/freebsd-questions/2011-November/235294.html
192 2015-03-12 10:20:45 <koobs> newline appended
193 2015-03-12 10:20:50 <koobs>  #sparc64 │ <Darius> koobs: FYI FreeBSD 4 supports -E
194 2015-03-12 10:20:53 <koobs> good sign.
195 2015-03-12 10:21:07 <koobs> https://www.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=0&manpath=FreeBSD+4.10-RELEASE&arch=default&format=html
196 2015-03-12 10:21:26 <wumpus> making things BSD-compatible seems to amount to making things 80's compatible
197 2015-03-12 10:21:48 <koobs> *cough*
198 2015-03-12 10:22:07 <Luke-Jr> ☺
199 2015-03-12 10:22:21 <wumpus> still dumbing down everything to the lowest common denominator :)
200 2015-03-12 10:23:16 <koobs> *doesnt take the bait*
201 2015-03-12 10:23:18 <koobs> :]
202 2015-03-12 10:23:39 <wumpus> I'm not anti BSD , but shellscript is an abomination
203 2015-03-12 10:23:46 <koobs> does bitcoin work on windows?
204 2015-03-12 10:23:52 <koobs> osx?
205 2015-03-12 10:24:00 <wumpus> is that a serious question?
206 2015-03-12 10:24:05 <koobs> wumpus: it may be, but thats not a <insert-OS> problem
207 2015-03-12 10:24:30 <koobs> wumpus: i know the answer, the question was serious though
208 2015-03-12 10:24:42 <Luke-Jr> 
ACTION notes Windows at least is supported only thanks to GNU tools :p

209 2015-03-12 10:24:53 <wumpus> both windows and ox advanced a lot since the 80's
210 2015-03-12 10:24:56 <koobs> wumpus: when we've rid outselves of autotools, we'll have a beer together over killing shell compatibility :)
211 2015-03-12 10:25:19 <koobs> wumpus: im not sure what your point is though, you cant code for that common denominator
212 2015-03-12 10:25:44 <koobs> Luke-Jr: \o/ :D
213 2015-03-12 10:25:51 <koobs> in anycase, demotivating conversation
214 2015-03-12 10:25:54 <koobs> lets move on
215 2015-03-12 10:26:05 <koobs> i was helping luke get shit done
216 2015-03-12 10:26:35 <koobs> Luke-Jr: how else can i help?
217 2015-03-12 10:26:44 <wumpus> koobs: yes in the end it's the problem with autotools being based on hellscript
218 2015-03-12 10:27:26 <Luke-Jr> koobs: well, if you're offering.. :D
219 2015-03-12 10:27:42 <koobs> Luke-Jr: wait wait, let me make you jump through BSD hoops first
220 2015-03-12 10:27:44 <koobs> :P
221 2015-03-12 13:22:50 <fanquake> ;;blocks
222 2015-03-12 13:22:51 <gribble> 347304
223 2015-03-12 13:30:12 <Luke-Jr> worst part about submodules is when gitorious dies you can't fix history to use a new URI :|
224 2015-03-12 13:36:18 <Hasimir> Luke-Jr, they're also an absolute pain to manage even when they do "work"
225 2015-03-12 13:36:53 <Luke-Jr> would be nice if it just stored commits inside the main repo
226 2015-03-12 13:39:22 <Hasimir> sounds like you're volunteering to build something better  ;)
227 2015-03-12 13:39:36 <sipa> like git subtree? :)
228 2015-03-12 13:45:22 <Luke-Jr> sipa: git subtree changes stuff though
229 2015-03-12 13:46:09 <Luke-Jr> it's just more ugly in different ways
230 2015-03-12 15:47:08 <jonasschnelli> anyone mind checking bitcoindnsseed.jonasschnelli.ch if it works as expected?
231 2015-03-12 15:55:33 <Luke-Jr> jonasschnelli: IPv4 only?
232 2015-03-12 16:01:03 <jonasschnelli> Luke-Jr: Hmm... How can i enable ipv6?
233 2015-03-12 16:01:14 <Luke-Jr> dunno
234 2015-03-12 16:01:53 <jonasschnelli> Ok. Will check this later. Maybe it's because of the port 5353 to 53 nat?
235 2015-03-12 16:05:25 <Luke-Jr> doubt it
236 2015-03-12 16:05:34 <Luke-Jr> does your server have IPv6 connectivity working?
237 2015-03-12 16:10:36 <jonasschnelli> Should. Will check soon
238 2015-03-12 16:11:55 <sipa> ipv4 works here
239 2015-03-12 16:11:58 <sipa> ipv6 does not
240 2015-03-12 16:29:33 <jonasschnelli> sipa: so you mean only my dnsseed don't support IPv6 or in general?
241 2015-03-12 16:29:46 <sipa> jonasschnelli: it returns 0 ipv6 results
242 2015-03-12 16:30:08 <jonasschnelli> okay. Will have a look.
243 2015-03-12 16:31:42 <bedeho> tx ids should be presented in hex64, not base58check?
244 2015-03-12 16:32:57 <sipa> yes
245 2015-03-12 16:32:59 <bedeho> meant to write hex, not base 64
246 2015-03-12 16:33:05 <Diablo-D3> http://www.thejournal.ie/terry-pratchett-died-1988715-Mar2015/
247 2015-03-12 16:33:05 <sipa> hex, not base64
248 2015-03-12 16:33:05 <sipa> yes
249 2015-03-12 16:33:12 <bedeho> sipa: thanks!
250 2015-03-12 16:38:24 <bedeho> sipa: is it correct that signatures always have a length in the range 71-73 bytes?
251 2015-03-12 16:38:32 <sipa> no
252 2015-03-12 16:38:58 <sipa> they can be as small as 6 bytes, afaik
253 2015-03-12 16:39:01 <sipa> in theory
254 2015-03-12 16:39:13 <sipa> (it's exceptionally unlikely, but not impossible)
255 2015-03-12 16:43:16 <bedeho> I see, no upper bound either?
256 2015-03-12 16:44:00 <hearn> yes there is an upper bound
257 2015-03-12 16:44:01 <sipa> 73
258 2015-03-12 16:44:09 <sipa> if you use the low_s rule, 72
259 2015-03-12 16:46:01 <bedeho> thanks
260 2015-03-12 19:10:57 <morcos> sipa: got a question about setBlockIndexCandidates.  in FindMostWorkChain, you just return if it's empty
261 2015-03-12 19:11:24 <morcos> are you ever expecting it to be empty?  that can happen in invalidate block, but that's a mistake and can cause bad behavior
262 2015-03-12 19:11:33 <sipa> hmm
263 2015-03-12 19:11:44 <sipa> i think you're right; it should never be empty
264 2015-03-12 19:11:52 <sipa> except before genesis is created
265 2015-03-12 19:12:23 <morcos> yeah, bad things happen if you get a old block of less height than chainActiveTip, you'll switch to a less work chain
266 2015-03-12 19:13:02 <sdaftuar> it looks like in InvalidateBlock, we need to add chainActive.Tip() to setBlockIndexCandidates ?
267 2015-03-12 19:14:08 <sipa> sdaftuar: hmm, let me check the code in a few minutes
268 2015-03-12 19:16:58 <sipa> sdaftuar, morcos: you're convincing me that we need a runtime invariants check on tje block chain index structures
269 2015-03-12 19:17:07 <sipa> i'll write that
270 2015-03-12 19:17:26 <sdaftuar> ok, cool
271 2015-03-12 19:18:56 <sdaftuar> we ran into another issue as well while testing autoprune
272 2015-03-12 19:19:28 <sdaftuar> let's say we have a block that is a candidate for the most work chain but one of its parents is missing
273 2015-03-12 19:19:40 <sdaftuar> because it was pruned
274 2015-03-12 19:19:45 <sipa> yes
275 2015-03-12 19:19:50 <sdaftuar> then we download that pruned block
276 2015-03-12 19:20:08 <sdaftuar> we're missing a mechanism now for that child block to be reconsidered as a candidate for the most work chain
277 2015-03-12 19:20:15 <sdaftuar> even though we have it
278 2015-03-12 19:20:54 <sdaftuar> i think maybe a solution would be, in FindMostWorkChain, to move blocks into mapBlocksUnlinked if they're being removed from setBlockIndexCandidates because a parent is missing
279 2015-03-12 19:20:57 <sipa> so i guess that means that setBlockIndexCandidates should contain all fully synced not-invalid tips better or equal to chainActive
280 2015-03-12 19:21:17 <sipa> and ignore pruning?
281 2015-03-12 19:21:37 <sipa> that may be inefficient
282 2015-03-12 19:21:44 <sipa> yes, using unlinked may work
283 2015-03-12 19:21:49 <sipa> it has forward references
284 2015-03-12 19:21:51 <sdaftuar> right
285 2015-03-12 19:22:05 <sdaftuar> and there's already a mechanism to re-add things to setblockindexcandidates when missing parents are added
286 2015-03-12 19:22:29 <sdaftuar> and that's also what we do on startup i think?
287 2015-03-12 19:22:55 <sipa> indeed, but it's actually pretty inefficient
288 2015-03-12 19:23:07 <sdaftuar> that map will just grow i guess...
289 2015-03-12 19:23:57 <sipa> its size is bounded by the block tree itself
290 2015-03-12 19:27:08 <cfields> wumpus: travis only logs stdout and not stderr, so we could redirect if that would help. But it's important to remember that if no changes are made to stdout for a while, the build times out
291 2015-03-12 19:27:33 <sipa> run a second thread that just prints "blah" every minute
292 2015-03-12 19:27:35 <cfields> wumpus: er, ignore that, brainfart.
293 2015-03-12 19:28:00 <cfields> obviously it logs stderr, it just doesn't count towards timeout
294 2015-03-12 19:28:10 <morcos> sipa: when those blocks themselves are pruned, we could erase them from unlinked when we're modifying their entries in mapblockindex to ~HAVE_DATA
295 2015-03-12 19:28:44 <sipa> morcos: good point, which will likely always be many at once
296 2015-03-12 19:28:49 <cfields> so i suppose the idea would be to pipe stdout to /dev/null and print "blah" as sipa suggested :)
297 2015-03-12 20:04:53 <wumpus> cfields: heh, that's not much better; also we don't really want to pipe to /dev/null, it makes sense to print e.g. compiler output when compilation fails
298 2015-03-12 20:06:44 <cfields> wumpus: right, i'm not sure how we could clean it up much without losing what we really want. build/compile are pretty quiet already. The main noise afaik is the comparisontool.
299 2015-03-12 20:07:09 <wumpus> it could have been that travis supported some kind of hierarchical divisioon of the output instead of having it all in one page
300 2015-03-12 20:07:10 <cfields> wumpus: it may be possible to make things collapsable as you suggested though. I think we may be able to achieve that by splitting up some build steps
301 2015-03-12 20:07:40 <wumpus> right :)
302 2015-03-12 20:08:47 <cfields> specifically, we could move tests to after_script
303 2015-03-12 20:09:02 <cfields> so at least there's a logical split between build failures and test failures
304 2015-03-12 20:09:24 <wumpus> yes
305 2015-03-12 20:09:35 <cfields> need to be careful though, some of the step behaviors aren't completely straightforward. iirc after_script is allowed to fail without failing the run
306 2015-03-12 20:10:04 <cfields> looking into it
307 2015-03-12 20:10:15 <wumpus> I suppose it would be possible to log the different phases to files, and print the files when the step fails?
308 2015-03-12 20:11:15 <cfields> yea, that would work too
309 2015-03-12 20:11:19 <wumpus> (and when it succeeds, just a summarty that it succeeded is enough)
310 2015-03-12 20:13:04 <wumpus> there could be cases in which you do want all the output from a succesful run, but that would be rare compared to the cases where one just want to see what failed and with what error message
311 2015-03-12 20:15:29 <cfields> yes
312 2015-03-12 20:16:16 <wumpus> but maybe it's as you say - it's mostly the comparison tool that's so noisy and this would apply to
313 2015-03-12 20:16:56 <wumpus> compile output may be somewhat useful to see warnings that have appeared on some platform (though, who checks the travis output for that...)
314 2015-03-12 20:18:29 <wumpus> in the windows build output, there is a list of all files being added to the setup .exe, that may be a bit overkill too :)
315 2015-03-12 20:19:42 <cfields> yes, nsis can probably be shut up. and i know wine can, i exported something locally for that
316 2015-03-12 20:20:02 <cfields> dunno why i never PR'd that, that's an obvious one