1 2016-02-13T00:08:32  *** bsm1175321 has quit IRC
  2 2016-02-13T00:34:58  *** AaronvanW has quit IRC
  3 2016-02-13T00:35:36  *** gevs has quit IRC
  4 2016-02-13T00:38:33  *** gevs has joined #bitcoin-core-dev
  5 2016-02-13T00:38:57  *** bityogi has quit IRC
  6 2016-02-13T00:42:38  *** davec has quit IRC
  7 2016-02-13T00:43:21  *** davec has joined #bitcoin-core-dev
  8 2016-02-13T00:49:36  *** gevs has quit IRC
  9 2016-02-13T00:50:08  *** gevs has joined #bitcoin-core-dev
 10 2016-02-13T00:50:08  *** gevs has joined #bitcoin-core-dev
 11 2016-02-13T01:03:56  *** zooko has joined #bitcoin-core-dev
 12 2016-02-13T01:04:52  *** lahwran is now known as lauren
 13 2016-02-13T01:10:35  *** zooko has quit IRC
 14 2016-02-13T01:20:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 15 2016-02-13T01:24:14  *** raedah has joined #bitcoin-core-dev
 16 2016-02-13T01:30:20  *** Chris_Stewart_5 has quit IRC
 17 2016-02-13T01:48:24  *** laurentmt has joined #bitcoin-core-dev
 18 2016-02-13T01:52:44  *** laurentmt has quit IRC
 19 2016-02-13T01:58:10  <Luke-Jr> is it expected for valgrind to whine about libsecp256k1?
 20 2016-02-13T02:06:40  <gmaxwell> Luke-Jr: more details required?
 21 2016-02-13T02:07:00  <Luke-Jr> jumps based on uninit'd values
 22 2016-02-13T02:07:00  <gmaxwell> do you mean the tests? yes--- if it's compiled with openssl then openssl taints the whole thing with uninitilized random numbers.
 23 2016-02-13T02:07:34  <gmaxwell> Do you mean when compiled with clang?  yes-- clang violates the C-spec usage for libc and will generate memcpy calls on overlapping areas.
 24 2016-02-13T02:07:45  <gmaxwell> otherwise, no absolutely not.
 25 2016-02-13T02:09:14  <Luke-Jr> k
 26 2016-02-13T02:09:20  <Luke-Jr> (yes, it's with tests)
 27 2016-02-13T02:09:30  <gmaxwell> you can compile without openssl to make those go away.
 28 2016-02-13T02:09:45  <gmaxwell> I suppose I should make configure warn that this will happen.
 29 2016-02-13T02:09:45  <Luke-Jr> it wasn't enough to bother me, unless it was indicative of a problem
 30 2016-02-13T02:10:38  <gmaxwell> if you ever get code that has gone through my hands that emits valgrind warnings, please report.
 31 2016-02-13T02:11:17  <gmaxwell> as an aside, if you compile your openssl with -DPURIFY it will stop executing undefined behavior and causing spurrious valgrind warnings in callers.
 32 2016-02-13T02:38:26  *** Ylbam has quit IRC
 33 2016-02-13T02:54:41  <Luke-Jr> ugh, why is descendantfees not called descendantmodfees? :/
 34 2016-02-13T02:54:47  <Luke-Jr> sdaftuar: ^
 35 2016-02-13T02:56:26  <sipa> gmaxwell:
 36 2016-02-13T03:04:36  <GitHub67> [bitcoin] luke-jr opened pull request #7529: Bugfix: Rename descendantfees to descendantmodfees (master...bugfix_descendantfees) https://github.com/bitcoin/bitcoin/pull/7529
 37 2016-02-13T03:14:01  *** frankenmint has joined #bitcoin-core-dev
 38 2016-02-13T03:20:47  *** frankenmint has quit IRC
 39 2016-02-13T04:00:58  <gmaxwell> sipa: hm?
 40 2016-02-13T04:01:07  <sipa> gmaxwell: ?
 41 2016-02-13T04:01:15  <sipa> oh, i said something above
 42 2016-02-13T04:01:23  <sipa> crap, i don't even remember typing that
 43 2016-02-13T04:02:05  *** jcorgan has joined #bitcoin-core-dev
 44 2016-02-13T04:02:38  <Luke-Jr> lol
 45 2016-02-13T04:21:39  *** frankenmint has joined #bitcoin-core-dev
 46 2016-02-13T04:27:36  *** frankenmint has quit IRC
 47 2016-02-13T04:44:17  *** p15x has joined #bitcoin-core-dev
 48 2016-02-13T04:45:27  *** brg444 has joined #bitcoin-core-dev
 49 2016-02-13T05:07:52  *** frankenmint has joined #bitcoin-core-dev
 50 2016-02-13T05:13:04  *** binns_ has joined #bitcoin-core-dev
 51 2016-02-13T05:13:32  *** binns_ has quit IRC
 52 2016-02-13T05:17:13  <warren> Anyone had trouble with gitian-builder precise amd64 recently?  It seems to install the VM just fine but it isn't bootable
 53 2016-02-13T05:17:30  *** dermoth has quit IRC
 54 2016-02-13T05:28:08  *** cj has joined #bitcoin-core-dev
 55 2016-02-13T05:34:34  *** binns has quit IRC
 56 2016-02-13T05:41:04  *** dermoth has joined #bitcoin-core-dev
 57 2016-02-13T05:46:19  *** binns has joined #bitcoin-core-dev
 58 2016-02-13T05:52:36  <warren> hmm, seems to be an issuer with newer versions of gitian-builder.  older versions install a working VM but it gets stuck on ssh login due to some change elsewhere in the OS.
 59 2016-02-13T05:52:38  <warren> "debug1: Skipping ssh-dss key ./var/id_dsa for not in PubkeyAcceptedKeyTypes"
 60 2016-02-13T06:02:55  *** p15x has quit IRC
 61 2016-02-13T06:05:17  <Luke-Jr> morcos: why does CTxMemPool::UpdateForDescendants seem to be backward? ie, it's updating fields that should be on ancestors..?
 62 2016-02-13T06:05:40  <Luke-Jr> warren: pseudo-fixed upstream, you need to redo the keying
 63 2016-02-13T06:06:15  <warren> Luke-Jr: yeah found that, using git bisect to figure out what else changed between March 2015 and December 2015 that broke the VM install
 64 2016-02-13T06:07:02  * Luke-Jr wonders why CTxMemPool code was rewritten obfuscated when there seems to be so many clearer possible ways to have done it :/
 65 2016-02-13T06:11:08  <phantomcircuit> Luke-Jr, because it's keeping track of the opposite thing from cpfp
 66 2016-02-13T06:11:18  <phantomcircuit> which ends up being weird
 67 2016-02-13T06:11:28  <Luke-Jr> phantomcircuit: yeah, but I mean it should be UpdateForAncestors?
 68 2016-02-13T06:11:38  <Luke-Jr> since it's updating the ancestor CTxMemPoolEntries
 69 2016-02-13T06:12:14  <Luke-Jr> this code is all so obfuscated, I'm about to just go back to writing less-than-optimal CPFP code
 70 2016-02-13T06:14:21  *** zooko has joined #bitcoin-core-dev
 71 2016-02-13T06:16:53  <Luke-Jr> or maybe I should just go update 0.11 :/
 72 2016-02-13T06:21:42  <warren> http://pastebin.com/eA2MmQ2j  Things break in the name of progress.
 73 2016-02-13T06:29:13  *** adnn has joined #bitcoin-core-dev
 74 2016-02-13T06:30:26  <Luke-Jr> warren: already PR'd a fix
 75 2016-02-13T06:38:08  *** wallet42 has joined #bitcoin-core-dev
 76 2016-02-13T06:45:58  *** zooko has quit IRC
 77 2016-02-13T07:37:02  *** Alopex has quit IRC
 78 2016-02-13T07:38:07  *** Alopex has joined #bitcoin-core-dev
 79 2016-02-13T07:52:42  <wumpus> cfields: made a mistake yesterday in buildling linux and mac, did not properly wipe the cache. Trying again...
 80 2016-02-13T07:53:13  <cfields> wumpus: i just redid and got matches on both
 81 2016-02-13T07:53:27  <wumpus> good
 82 2016-02-13T07:53:28  <cfields> wumpus: if you don't match now, you're going to set my world on fire :p
 83 2016-02-13T07:53:29  <btcdrak> music!
 84 2016-02-13T07:56:30  <cfields> wumpus: ofc confirmation is most welcome. Still need another sig before signing though. After all that, I'm really not comfortable until we get 3rd party confirmation
 85 2016-02-13T07:56:42  <cfields> midnightmagic / michagogo / PRab:  ping ^^
 86 2016-02-13T07:57:16  <cfields> tl;dr: nuke cache, fresh base image, rebuild windows
 87 2016-02-13T07:57:23  <wumpus> cfields: yes, that must be it, and they upgraded the compiler for linux and mingw at the same time. I don't understand the macosx .tar.gz difference tho - does it contain a native executable somehow?
 88 2016-02-13T07:57:38  <wumpus> cfields: oh, you rebuilt linux and it still matched?
 89 2016-02-13T07:58:06  *** Ylbam has joined #bitcoin-core-dev
 90 2016-02-13T07:58:09  <cfields> wumpus: i must've not wiped properly
 91 2016-02-13T07:58:13  <wumpus> my build yesterday was done on the wrong circumstances so I can't confirm linux and macosx stay the same
 92 2016-02-13T07:58:16  <cfields> yikes, context needed there :)
 93 2016-02-13T07:58:40  <cfields> wumpus: 2 fresh builds tonight of osx/linux, and they matched
 94 2016-02-13T07:58:41  <wumpus> I apparently wiped the windows cache only :(
 95 2016-02-13T07:58:58  <wumpus> cfields: ok
 96 2016-02-13T07:59:09  <cfields> well, let's see how yours end up
 97 2016-02-13T08:00:10  <wumpus> in my case no new base image was needed, the gcc upgrade is unavoidable :)
 98 2016-02-13T08:01:25  <warren> cfields: the toolchain changing from under us is one reason why we eventually  need to replace gitian
 99 2016-02-13T08:01:45  <warren> (not to mention not fully knowing what's in that toolchain binary)
100 2016-02-13T08:02:39  <cfields> warren: yea, i think we're kinda purposely avoiding addressing the real issue here... that we're at the whim of the ubuntu toolchain packagers
101 2016-02-13T08:02:54  <cfields> but this is a good way to shed a light on that
102 2016-02-13T08:03:12  <cfields> (purposely for now, for the sake of getting the release out)
103 2016-02-13T08:06:21  <warren> well, for the purpose of getting the last 20 releases out =)
104 2016-02-13T08:12:46  <wumpus> warren: yes eventually the idea would be to build the toolchains too; I experimented a bit with bulilding specific toolchains myself using crosstool-ng. But as usual, other concerns came up and it went to the background a bit.
105 2016-02-13T08:14:17  *** dermoth has quit IRC
106 2016-02-13T08:14:20  <wumpus> I agree gitian *should* be replaced/improved to not rely on specific a linux distro eventually, but what we do is already much more than most projects do in this regard, and there isn't a replacement at the moment
107 2016-02-13T08:14:33  *** dermoth_ has joined #bitcoin-core-dev
108 2016-02-13T08:14:43  *** dermoth_ is now known as dermoth
109 2016-02-13T08:15:18  *** wallet421 has joined #bitcoin-core-dev
110 2016-02-13T08:15:18  *** wallet421 has joined #bitcoin-core-dev
111 2016-02-13T08:15:18  *** wallet42 has quit IRC
112 2016-02-13T08:15:18  *** wallet421 is now known as wallet42
113 2016-02-13T08:15:42  *** larsk has quit IRC
114 2016-02-13T08:16:26  *** larsk has joined #bitcoin-core-dev
115 2016-02-13T08:16:35  <cfields> wumpus: headed to bed. I'll check for matches in the morning. Please ping/mail me if anything comes up, I don't want to hold up the release
116 2016-02-13T08:17:06  <wumpus> cfields: ok nn
117 2016-02-13T08:23:49  <warren> wumpus: cfields and I have been talking for a few months about an eventual replacement, basic idea is to be able to build a deterministic toolchain on any Linux distro, then use that to build things like Bitcoin.
118 2016-02-13T08:24:56  <warren> wumpus: Then a one-time research effort could be done building toolchains from source from the oldest in history up to this deterministic toolchain and seeing if the result is identical.
119 2016-02-13T08:25:14  <wumpus> warren: yes, that's the basic idea. osx will, as usual, probably be hardest as it requries all kind of funny and weird tools built too
120 2016-02-13T08:26:00  <wumpus> building windows and linux cross-compilers is pretty straightforward
121 2016-02-13T08:26:04  <warren> yup
122 2016-02-13T08:26:53  <wumpus> (I've done it tons of times for embedded projects - it's mainly lots of waiting :-)
123 2016-02-13T08:29:40  <wumpus> (and lots and lots of harddisk space)
124 2016-02-13T08:31:04  <btcdrak> it would be amusing to know how many hours we've all spent in our lifetimes waiting for compiles to finish :p
125 2016-02-13T08:32:36  <wumpus> amusing but also unsetting :p
126 2016-02-13T08:34:51  <wumpus> there was an early commercial from a ISP in the netherlands about a guy that, having to wait so long for downloads, learned all kinds of skills like juggling and read all books inthe library etc, it feels the same sometimes :-)
127 2016-02-13T08:36:04  <wumpus> well I try to plan it usually that I don't have to wait for specific compiles by overlapping multiple
128 2016-02-13T08:43:42  <cfields> wumpus: in working on segwit, i had to mine some segnet coins after difficulty had been jacked up by some asic testing. That's like "I'm working, my code's compiling" x10 :)
129 2016-02-13T08:52:53  <cfields> wumpus: matches for osx/linux?
130 2016-02-13T08:54:10  <wumpus> oh yes the random and progress-less aspect of that makes it even worse
131 2016-02-13T08:54:35  *** degriff has joined #bitcoin-core-dev
132 2016-02-13T08:54:42  <wumpus> linux is different :(
133 2016-02-13T08:55:05  <wumpus> c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a for bitcoin-0.12.0-linux64.tar.gz
134 2016-02-13T08:55:27  <cfields> sigh
135 2016-02-13T08:55:46  <wumpus> (different to my own previous build, at least, haven't checked with yours)
136 2016-02-13T08:56:07  <wumpus> trying mac now
137 2016-02-13T08:56:48  <wumpus> in any case the linux change is to be expected with a toolchain change
138 2016-02-13T08:57:23  <cfields> ok, nuking mine again and retrying
139 2016-02-13T08:57:43  <wumpus> although it makes no sense that you get the same as before
140 2016-02-13T08:59:38  <wumpus> worst case: the  new gcc added some code randomization feature. OTOH we do tend to repeat our own results.
141 2016-02-13T09:00:03  <cfields> wumpus: there's a ton of room for pebcak atm. That's by far the most likely explanation for my results atm.
142 2016-02-13T09:00:40  <wumpus> yes just go to sleep we'll see tomorrow :)
143 2016-02-13T09:00:51  <btcdrak> sleep is a cureall
144 2016-02-13T09:01:05  *** AaronvanW has joined #bitcoin-core-dev
145 2016-02-13T09:01:19  <cfields> can't sleep when there's a mismatch and a result is pending :\
146 2016-02-13T09:07:40  *** wallet42 has quit IRC
147 2016-02-13T09:11:00  *** wallet42 has joined #bitcoin-core-dev
148 2016-02-13T09:27:08  <warren> cfields: if the underlying toolchain changes, perhaps the gitian-descriptors should be bumped so all cached results are invalid, to avoid expected mismatches?
149 2016-02-13T09:27:23  <wumpus> cfields: Good news: for osx, the dmg and -osx64.tar.gz stayed the same, just bitcoin-0.12.0-osx-unsigned.tar.gz changed. Same as you!
150 2016-02-13T09:28:00  <wumpus> cfields: my guess is that the -unsigned.tar.gz contains a locally built native executable?
151 2016-02-13T09:28:09  <wumpus> in any case, no problem for osx
152 2016-02-13T09:28:27  <cfields> wumpus: heh, so my macbook results were good, desktop were off. ok, that's something solid at least
153 2016-02-13T09:28:33  <warren> cfields: It's been over a decade since I've looked at it or tried it, but apt has pinning and particular versions of packages could be forced to stay that way and tested in a gitian-descriptor
154 2016-02-13T09:28:46  <cfields> wumpus: yea, the tools to re-attach and create the dmg are native
155 2016-02-13T09:29:05  <wumpus> we could use pinning for the compiler, on the other hand this is an ubuntu stable, if they do a compiler upgrade I'd expect them to have a very good reason
156 2016-02-13T09:29:10  <wumpus> cfields: okay, solved that then
157 2016-02-13T09:29:18  <cfields> warren: that's not a bad idea for 0.12, actually. the gitian descriptor can disable the cache
158 2016-02-13T09:29:28  <cfields> wumpus: maybe do ^^ and be done with it?
159 2016-02-13T09:29:37  <warren> horray I had an idea
160 2016-02-13T09:29:43  * warren sleep
161 2016-02-13T09:29:56  <cfields> doesn't solve any of the actual issues, but will help with coordinating
162 2016-02-13T09:29:58  <warren> cfields: I'm fighting a gitian problem for something else at the moment, so similarly annoyed
163 2016-02-13T09:29:59  <wumpus> cfields: yea, disabling the cache may be the safest, on the other hand having to rebuild -qt for every rc and minor release is a pain
164 2016-02-13T09:30:49  <cfields> wumpus: i was just speaking for 0.12 rc6/final, not anything permanent
165 2016-02-13T09:31:02  <wumpus> (and not once, five times - qt for win32, qt for win64, qt for linux32, qt for linux64, qt for macosx... did I mention qt takes a long time to build?)
166 2016-02-13T09:31:14  <wumpus> all the other dependencies are a joke in comparison and could as well be built every time
167 2016-02-13T09:31:34  <wumpus> cfields: right, could do that
168 2016-02-13T09:31:49  <cfields> wumpus: specifically: http://pastebin.com/raw/T1ksN7nP
169 2016-02-13T09:32:02  <cfields> yea, qt is terrible :(
170 2016-02-13T09:32:53  <wumpus> I wonder if we build parts of qt that are unnecessary for us, but the cache convenience has always kept me from delving deeper
171 2016-02-13T09:33:39  <cfields> wumpus: i spent several days getting the qt build down to a bare minimum...
172 2016-02-13T09:34:02  <wumpus> okay
173 2016-02-13T09:34:06  <cfields> it might be better now with later versions, but in the ~5.2 days, that was about as slim as it could get
174 2016-02-13T09:34:57  <cfields> don't misunderstand, it's definitely worth taking another look. iirc at that point it wasn't split into separate modules
175 2016-02-13T09:38:17  <cfields> wumpus: but i'm discouraged by gentoo. Luke-Jr mentioned that they use similar hacks as us to build the native tools because it doesn't split up nicely
176 2016-02-13T09:39:05  <Luke-Jr> not sure how similar.. Gentoo just doesn't have them packaged separately
177 2016-02-13T09:39:07  <cfields> (ie there's no "qmake" ebuild, because it's not reasonable to build it without building the rest of base qt)
178 2016-02-13T09:39:10  <wumpus> cfields: I also don't expect them to have done much changes to qt in that regard
179 2016-02-13T09:40:28  <Luke-Jr> cross-compiling in Gentoo is somewhat of an afterthought
180 2016-02-13T09:40:44  <warren> wumpus, cfields: alternative idea, remember the old way of checking hashes if inputs in gitian descriptors prior to depends?  Could do the opposite, include known hashes that it shouldn't be that cause the build to stop with an informative message
181 2016-02-13T09:41:59  <warren> Otoh I suppose versioning a set of expected tool chain is better
182 2016-02-13T09:42:45  <cfields> wumpus: c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a  bitcoin-0.12.0-linux64.tar.gz
183 2016-02-13T09:42:58  <cfields> 46ef9d35b4fbd89e74065647173ae0bbe8e04c6b47413a421576b0800a04ef37  bitcoin-0.12.0-linux32.tar.gz
184 2016-02-13T09:43:45  <cfields> warren: yea, i'd prefer to avoid hard-coding because of the manual work involved. but in this case where the automatic deps failed us, static hashes start to look appealing
185 2016-02-13T09:44:06  <cfields> but i think we can work something out to avoid the static hashes
186 2016-02-13T09:44:32  <warren> The underlying tool chain changing should be something we detect
187 2016-02-13T09:44:40  <wumpus> cfields: match
188 2016-02-13T09:45:15  <cfields> wumpus: no idea what i borked last time, but went smoothly this time. building osx while i sleep. nnite now for real
189 2016-02-13T09:45:16  <cfields> warren: for sure
190 2016-02-13T09:45:19  <wumpus> warren: we can, all the .deb packages are logged to the .assert file
191 2016-02-13T09:45:25  <wumpus> warren: only caching messes with this :(
192 2016-02-13T09:46:00  <wumpus> the cache will have been built with a previous state of packages (or possible even multiple different ones over time), which isn't logged at this moment
193 2016-02-13T09:46:10  <wumpus> but the current state is always tracable and comparable
194 2016-02-13T09:46:50  <wumpus> if two people built with different gcc and have different output, normally we could see that. Except cache + unfortunate timing this time
195 2016-02-13T09:49:50  <warren> Idea: include the package list in the intermediate cached output tar
196 2016-02-13T09:52:49  *** paveljanik has joined #bitcoin-core-dev
197 2016-02-13T10:05:32  <wumpus> yes that at least
198 2016-02-13T10:08:37  <wumpus> comparing the assert files between rc4 and rc5 build the toolchain change can be caught in the act: https://gist.github.com/laanwj/9e065acefcdf93a91b85
199 2016-02-13T10:09:20  <wumpus> all the gcc/g++ debs basically changed inbetween
200 2016-02-13T10:09:49  <wumpus> as long as *someone* builds without cache, these things will be detected
201 2016-02-13T10:10:20  <wumpus> I used to be that someone, but that was before having 6 rcs per release was all the rage :-)
202 2016-02-13T10:12:57  <wumpus> including a hash of the dpkg -l list in the cache hash (through a custom seed, as cfields suggested) may avoid this, although it will result in false positives
203 2016-02-13T10:13:31  <warren> Too many false positives, need to filter to a list of identified important tool chain dpkgs
204 2016-02-13T10:14:04  <warren> Ohhhh
205 2016-02-13T10:14:05  <wumpus> well it beats completely disabling the cache, but sure
206 2016-02-13T10:14:50  <warren> Use ccache as a canary, it's very good at detecting most toolcgain changes
207 2016-02-13T10:15:42  <wumpus> maybe a good idea - depends has support for ccache, but we explicitly disable that right now to rule out another potential issue due to caching
208 2016-02-13T10:16:11  <warren> I didn't mean use ccache for builds, use it only to detect changes
209 2016-02-13T10:16:32  <wumpus> yes I see
210 2016-02-13T10:16:46  <warren> It's a simple but imperfect detector
211 2016-02-13T10:17:47  <GitHub39> [bitcoin] knocte opened pull request #7530: autogen.sh: check for libtool before automake fails to find it (master...libtool-check) https://github.com/bitcoin/bitcoin/pull/7530
212 2016-02-13T10:18:23  <wumpus> I wonder if it would have detected this. I don't think gcc --version output changed :(
213 2016-02-13T10:27:14  <wumpus> otoh if it looks at, say, the timestamps of hashes of the actual tools then it may work
214 2016-02-13T10:27:54  <wumpus> (although gcc is sneaky in that regard, gcc etc is just a launcher it has a directory of actual tools stashed away somewhere else)
215 2016-02-13T10:28:13  <wumpus> anyhow an attempt at detecting this is 100% better than none
216 2016-02-13T11:41:26  *** murch has joined #bitcoin-core-dev
217 2016-02-13T12:22:48  *** adam3us_ is now known as adam3us
218 2016-02-13T12:29:07  *** MarcoFalke has joined #bitcoin-core-dev
219 2016-02-13T12:29:44  <MarcoFalke> wumpus, Is your script to create the release note change log somewhere in the tree?
220 2016-02-13T13:07:00  *** brg444 has quit IRC
221 2016-02-13T13:11:47  *** laurentmt has joined #bitcoin-core-dev
222 2016-02-13T13:11:51  *** laurentmt has quit IRC
223 2016-02-13T13:26:49  *** Squidicc has joined #bitcoin-core-dev
224 2016-02-13T13:30:01  *** Squidicuz has quit IRC
225 2016-02-13T13:38:34  *** davec has quit IRC
226 2016-02-13T13:39:14  *** davec has joined #bitcoin-core-dev
227 2016-02-13T13:48:35  *** wumpus has quit IRC
228 2016-02-13T13:50:23  *** wumpus has joined #bitcoin-core-dev
229 2016-02-13T14:12:16  *** belcher has joined #bitcoin-core-dev
230 2016-02-13T14:28:28  <PRab> Any reason for the delay on rc5's detached sig?
231 2016-02-13T14:29:16  <MarcoFalke> maybe https://github.com/bitcoin/gitian.sigs/pull/305#issuecomment-183665538
232 2016-02-13T14:29:59  <PRab> Ah, that could be it.
233 2016-02-13T14:31:22  <PRab> I know this is overkill, but I think I'm going to blow away my entire VM and rebuild it.
234 2016-02-13T14:31:52  <PRab> I've been using the same one since I started doing gitian builds so I a couple of version behind for debian.
235 2016-02-13T14:32:40  <MarcoFalke> I think wiping the cache is just sufficient
236 2016-02-13T14:33:05  <PRab> Yeah, but I've been meaning to do this anyway.
237 2016-02-13T14:33:20  *** p15x has joined #bitcoin-core-dev
238 2016-02-13T14:56:38  <morcos> Luke-Jr: I didn't write the UpdateForDescendants and associated code.  But I don't really see why its necessary to be so critical about it.
239 2016-02-13T14:56:48  <morcos> It's difficult logic to get correct.
240 2016-02-13T14:57:23  <morcos> And the name to me seems fairly precise, it is well commented in the code.  UpdateForDescendants updates the state of a particular transaction for any dependent txs already in the mempool.
241 2016-02-13T14:57:56  <morcos> I'm not sure what else you could call it.  it isn't called on ancestors of a given tx, its called on all the txs that are readded to the mempool from a disconnected block
242 2016-02-13T14:58:54  <morcos> In any case, I'm sure if you were to rewrite the code better, no one would object, that would be more useful than complaining about its current form.  I think you will find that task non-trivial.
243 2016-02-13T15:08:12  *** laurentmt has joined #bitcoin-core-dev
244 2016-02-13T15:08:16  *** laurentmt has quit IRC
245 2016-02-13T15:22:46  *** murr4y has quit IRC
246 2016-02-13T15:27:57  *** murr4y has joined #bitcoin-core-dev
247 2016-02-13T15:30:31  *** antanst has joined #bitcoin-core-dev
248 2016-02-13T15:32:23  <morcos> sipa: regarding #7521 and attempting to reaccept/rerelay expired/evicted txs.  although i still think not doing that is probably best, if we are going to do that, i think its important to add some timelimit.
249 2016-02-13T15:33:19  <morcos> there needs to be a dynamic way to recognize that some ancient tx from long ago with too little fee is just no longer viable in todays fee market/network
250 2016-02-13T15:33:59  <morcos> i've been thinking a bit about this current mass of giant spam txs floating around, and how we would ever get it to stop bouncing around the network endlessly
251 2016-02-13T15:35:16  <morcos> it seems reasonable to me that if you do want to try to reaccept txs that are no longer in your mempool so you can rebroadcast them, that you stop doing it after some period of time.  a week, a month, something
252 2016-02-13T15:36:10  <morcos> measuring such time from tx creation, not the last time it succeeding in making it into your mempool.
253 2016-02-13T15:44:13  <GitHub134> [bitcoin] btcdrak opened pull request #7531: Add bip68-sequence.py to extended rpc tests (master...bip68-rpc) https://github.com/bitcoin/bitcoin/pull/7531
254 2016-02-13T15:46:12  *** p15x has quit IRC
255 2016-02-13T16:10:19  *** laurentmt has joined #bitcoin-core-dev
256 2016-02-13T16:56:28  *** bityogi has joined #bitcoin-core-dev
257 2016-02-13T17:19:56  *** bityogi has quit IRC
258 2016-02-13T17:27:34  *** otium has joined #bitcoin-core-dev
259 2016-02-13T18:50:00  *** belcher has quit IRC
260 2016-02-13T18:57:44  *** degriff has left #bitcoin-core-dev
261 2016-02-13T19:03:30  *** neilf has quit IRC
262 2016-02-13T19:20:18  *** wallet42 has quit IRC
263 2016-02-13T19:20:37  *** wallet42 has joined #bitcoin-core-dev
264 2016-02-13T19:24:24  <cfields> PRab / MarcoFalke: not sure if you guys saw, but rc5 needs a fresh build with no cache. A toolchain update slipped in and screwed us over
265 2016-02-13T19:24:58  <cfields> still waiting one 1 more sig to match wumpus and me before I can push the detached sigs
266 2016-02-13T19:26:14  <MarcoFalke> Currently I have the "Updating apt-get repository (log in var/install.log)
267 2016-02-13T19:26:15  <MarcoFalke> root@localhost's password:
268 2016-02-13T19:26:15  <MarcoFalke> " error. But I think it's a local issue solved by rebooting my box
269 2016-02-13T19:27:52  *** AtashiCon has quit IRC
270 2016-02-13T19:29:59  *** AtashiCon has joined #bitcoin-core-dev
271 2016-02-13T19:43:39  *** murch has quit IRC
272 2016-02-13T19:44:50  <cfields> MarcoFalke: i got that after updating gitian, you can end up with a mismatch of rsa/dsa keys
273 2016-02-13T19:46:57  <MarcoFalke> I can't remember updating gitian. This happened right after win-rc5 : https://github.com/bitcoin/gitian.sigs/pull/304
274 2016-02-13T19:49:08  <cfields> MarcoFalke: strange, i'm unsure what's going on there
275 2016-02-13T19:57:17  *** laurentmt has quit IRC
276 2016-02-13T20:02:32  *** belcher has joined #bitcoin-core-dev
277 2016-02-13T20:08:59  *** degriff has joined #bitcoin-core-dev
278 2016-02-13T20:09:48  <PRab> cfields: Building now.
279 2016-02-13T20:14:06  <cfields> PRab: great, thanks
280 2016-02-13T20:23:34  <warren> MarcoFalke: saw one of your github issues, you're the fedora user?
281 2016-02-13T20:23:53  <MarcoFalke> jup
282 2016-02-13T20:24:22  <MarcoFalke> I am doing the gitian building on the actual fedora host.
283 2016-02-13T20:24:32  <warren> MarcoFalke: ok, I made that vmbuilder and apt-cacher-ng package.  upgrading gitian-builder to latest and manually populating the cache/ dir works around problems right now
284 2016-02-13T20:24:38  <warren> also need to rebuild the vm's
285 2016-02-13T20:25:40  <MarcoFalke> I am aware of the "rebuild the vm's"-fix because I broke it ;)
286 2016-02-13T20:26:19  <warren> FWIW I got gitian working on fedora last night by manually populating the cache with the intermediate source tarballs
287 2016-02-13T20:28:09  <MarcoFalke> warren, are you sure the vmbuilder hit yum yet? (Bug report shows it as "NEW")
288 2016-02-13T20:28:10  <MarcoFalke> https://bugzilla.redhat.com/show_bug.cgi?id=1074143
289 2016-02-13T20:30:46  <warren> MarcoFalke: nobody approved the package review so it won't go into the repo.  it was packaged over a year ago so maybe we should pull something newer from Ubuntu
290 2016-02-13T20:30:54  <warren> seems to still work though
291 2016-02-13T20:32:49  <MarcoFalke> Looks fine because we did not change the packet: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#installing-gitian
292 2016-02-13T20:32:59  <MarcoFalke> in the meantime
293 2016-02-13T20:40:20  *** Guyver2 has joined #bitcoin-core-dev
294 2016-02-13T20:41:21  *** cjcj has quit IRC
295 2016-02-13T20:45:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
296 2016-02-13T20:49:14  *** MarcoFalke has quit IRC
297 2016-02-13T20:52:57  *** MarcoFalke has joined #bitcoin-core-dev
298 2016-02-13T20:56:23  *** mkarrer_ has quit IRC
299 2016-02-13T20:59:01  *** mkarrer has joined #bitcoin-core-dev
300 2016-02-13T21:02:50  *** PRab has quit IRC
301 2016-02-13T21:05:55  *** Chris_Stewart_5 has quit IRC
302 2016-02-13T21:10:16  *** degriff has quit IRC
303 2016-02-13T21:11:12  *** degriff has joined #bitcoin-core-dev
304 2016-02-13T21:28:56  *** qlql has quit IRC
305 2016-02-13T21:29:07  *** PRab has joined #bitcoin-core-dev
306 2016-02-13T21:31:07  *** laurentmt has joined #bitcoin-core-dev
307 2016-02-13T21:37:36  *** JackH has quit IRC
308 2016-02-13T21:39:18  *** otium has left #bitcoin-core-dev
309 2016-02-13T21:39:40  *** otium has joined #bitcoin-core-dev
310 2016-02-13T21:42:32  *** laurentmt has quit IRC
311 2016-02-13T21:46:17  <BlueMatt> debug.log at 975G...quick someone ping my node a bunch so it hits 1TB :p
312 2016-02-13T21:46:46  *** otium_ has joined #bitcoin-core-dev
313 2016-02-13T21:51:42  *** otium has quit IRC
314 2016-02-13T21:52:51  <morcos> BlueMatt: shhh.  they'll find out the secret reason we don't want to raise block size is we can't handle the larger debug logs
315 2016-02-13T21:53:50  <PRab> gbuild for windows doesn't appear to be finishing.
316 2016-02-13T21:54:14  <PRab> Its been hanging out at "Running build script ..." for over an hour.
317 2016-02-13T21:54:21  <PRab> (probably closer to 2)
318 2016-02-13T21:54:24  <BlueMatt> morcos: heh, well I tried to go to #btrfs to ask why their compression ioctl is screaming at me with no error message and the response I got was "well, go read fs/btrfs/ioctl.c"
319 2016-02-13T21:54:35  <BlueMatt> morcos: clearly the solution to the block size issue is to first fix btrfs
320 2016-02-13T21:55:19  <Luke-Jr> lol
321 2016-02-13T21:55:35  * Luke-Jr wonders if btrfs ever merged his bugfixes
322 2016-02-13T21:55:42  <BlueMatt> probably not
323 2016-02-13T21:56:12  <Luke-Jr> yeah, they don't seem to care about bugs :<
324 2016-02-13T21:56:20  <morcos> BlueMatt: btw, did you see 6977.  its not an issue for fee estimation any more.  but i assume we want the minreasonablerelay rate to change with command line option
325 2016-02-13T21:57:22  <Luke-Jr> Receiving objects:   3% (3787/99184), 1.75 MiB | 50.00 KiB/s <-- slooow
326 2016-02-13T21:59:14  <BlueMatt> morcos: hmm, I havent seen that one...why does -minrelaytxfee continue to exist?
327 2016-02-13T21:59:30  <BlueMatt> morcos: like, did fee estimation think fee was 0 and thus min_fee?
328 2016-02-13T22:00:12  <BlueMatt> morcos: as for adding an option to set the min incremental relay fee, sure, why not...but should be a hidden option
329 2016-02-13T22:00:13  <morcos> BlueMatt: forget about fee esitmation for a second, it basically uses a new variable now anyway: fallbackfee
330 2016-02-13T22:00:26  <BlueMatt> ok, fair enough
331 2016-02-13T22:00:40  <morcos> The point is minrelaytxfee and incremental relay fee are the same thing now
332 2016-02-13T22:00:45  <BlueMatt> i mean then its the same thing - incremental fee for everything
333 2016-02-13T22:00:48  <BlueMatt> its also incremental from 0
334 2016-02-13T22:00:54  <BlueMatt> yea
335 2016-02-13T22:00:57  <morcos> right, thats fine, maybe they dont' need to be separate
336 2016-02-13T22:01:08  <morcos> but my point is if you try to set it (by setting minrelaytxfee)
337 2016-02-13T22:01:20  <morcos> it doesn't affect a couple of the calculations that happen inside mempool
338 2016-02-13T22:01:38  <morcos> b/c that variable is a local copy made before the command line option is set (i think)
339 2016-02-13T22:02:31  <BlueMatt> oh? well we should fix that
340 2016-02-13T22:02:37  <BlueMatt> we should also change minrelaytxfee to a different name
341 2016-02-13T22:02:40  <BlueMatt> and make it a hidden option
342 2016-02-13T22:02:50  <BlueMatt> because people who had previously set that as a spam-prevention thing should reconsider
343 2016-02-13T22:02:56  <morcos> Well, its not entirely clear
344 2016-02-13T22:02:57  <BlueMatt> should have done for 0.12, really
345 2016-02-13T22:02:58  <BlueMatt> but oh well
346 2016-02-13T22:03:06  <morcos> I mostly agree with that
347 2016-02-13T22:03:21  <morcos> but its nice to have the fall back of saying i just don't want any garbage less than X
348 2016-02-13T22:04:11  <morcos> for instance now you still get tons of useless traffic either when your mempoolminfee has temporarily decayed or because the mempool min never goes above 2 sat/B
349 2016-02-13T22:04:45  <morcos> i think your node in practice would actually be nicer behaved if you ran 0.11 with 5 sat/B minrelaytxfee right now.  sadly.
350 2016-02-13T22:05:23  <BlueMatt> sat/B
351 2016-02-13T22:05:28  <morcos> but of course that just happens to be the exact traffic pattern on the network now.  the dynamic solution is still the way to go, but its not a terrible idea to have a minimum which could be different from the increment
352 2016-02-13T22:05:29  <BlueMatt> oh, satoshi/Byte
353 2016-02-13T22:05:51  <morcos> yeah i don't know why we always say 1000 sat/kB instead of 1 sat/B
354 2016-02-13T22:06:04  <Luke-Jr> 1 s/B is way too low a feerate :p
355 2016-02-13T22:06:20  <morcos> Luke-Jr: exactly  :)
356 2016-02-13T22:06:20  <Luke-Jr> morcos: as for reason, it's because size used to be rounded to next kB
357 2016-02-13T22:06:28  <BlueMatt> i mean, sure, having a different incremental from 0 than incremental is a reasonable policy option
358 2016-02-13T22:06:52  <BlueMatt> but the real solution to the problem is to do some basic mempool-sync stuff on startup
359 2016-02-13T22:06:58  <BlueMatt> then your limit will jump right away
360 2016-02-13T22:07:15  <morcos> heh, the real solution is feefilter, its awesome in my testing so far
361 2016-02-13T22:07:43  <morcos> all these damn 15kB size txs of 15000 sat fee that keep being requested and then summarily rejected are really annoying!
362 2016-02-13T22:08:59  <BlueMatt> wow, scalia reported passed away
363 2016-02-13T22:09:07  <BlueMatt> thats gonna be big for scotus
364 2016-02-13T22:09:20  <BlueMatt> feefilter?
365 2016-02-13T22:09:25  <BlueMatt> I havent been paying attention of late, tbh
366 2016-02-13T22:09:53  <morcos> BlueMatt: its a tease, i haven't written it up yet.  i'm procrastinating doing that now.
367 2016-02-13T22:10:04  <BlueMatt> whats the idea?
368 2016-02-13T22:10:07  <morcos> but short idea is you just tell your peers don't even bother inving me txs less than my mempool min fee
369 2016-02-13T22:10:14  <BlueMatt> ahh
370 2016-02-13T22:10:15  <BlueMatt> meh
371 2016-02-13T22:10:20  * Luke-Jr wishes there was somewhere better to move
372 2016-02-13T22:10:28  <morcos> whats the meh
373 2016-02-13T22:10:41  <BlueMatt> that doesnt help if your mempool never fills enough to get medium-fee txn
374 2016-02-13T22:10:48  <BlueMatt> so that you can set the mempool fee
375 2016-02-13T22:10:52  <BlueMatt> but, yes, we should also have that
376 2016-02-13T22:11:01  <BlueMatt> maybe we should revisit segwit having explicit fees
377 2016-02-13T22:11:03  <morcos> whose mempool never fills enough
378 2016-02-13T22:11:27  <BlueMatt> mempools do take a while to fill reasonably
379 2016-02-13T22:11:37  <BlueMatt> because people dont rebroadcast "real" txn
380 2016-02-13T22:11:41  <BlueMatt> just the spam keeps flowing around
381 2016-02-13T22:12:01  *** Guyver2 has quit IRC
382 2016-02-13T22:12:58  *** Guyver2 has joined #bitcoin-core-dev
383 2016-02-13T22:13:25  <morcos> yes, whats typical now is your mempool min fee is 2 sat/B and then slowly decays til you can start accepting the spam again
384 2016-02-13T22:13:27  <Luke-Jr> [22:11:37] <BlueMatt> because people dont rebroadcast "real" txn <-- ⁇
385 2016-02-13T22:13:47  <morcos> but during that decay, you are inved spam, and rereuest it b/c your reject filter is reset
386 2016-02-13T22:13:51  <morcos> feefilter fixes that
387 2016-02-13T22:13:57  <BlueMatt> Luke-Jr: i mean because it gets mined, so they dont have to :p
388 2016-02-13T22:14:11  <BlueMatt> morcos: yes, both are required, is my point
389 2016-02-13T22:14:27  <morcos> sorry, what's the both?
390 2016-02-13T22:14:34  <morcos> you mean dynamic mempool fee?
391 2016-02-13T22:14:38  <morcos> of course
392 2016-02-13T22:14:39  <BlueMatt> both mempool sync and feefilter
393 2016-02-13T22:14:43  <morcos> oh sync
394 2016-02-13T22:15:05  <BlueMatt> ofc sync is hard to do in a privacy-preserving manner, etc, etc
395 2016-02-13T22:15:16  <BlueMatt> we need to redo txn flow completely, really
396 2016-02-13T22:15:19  <BlueMatt> to preserve privacy
397 2016-02-13T22:15:21  <morcos> yeah, i'm not sure what i think about sync.
398 2016-02-13T22:15:33  <morcos> yeah well did you read the privacy concerns around 7521
399 2016-02-13T22:15:39  <morcos> its pretty bad
400 2016-02-13T22:16:01  <BlueMatt> do we really still do that?
401 2016-02-13T22:16:01  <BlueMatt> wow
402 2016-02-13T22:16:22  <BlueMatt> greg's proposal of regular-sync + send txn as you accept them to mempool to a fixed peer or two seems the most reasonable I've heard
403 2016-02-13T22:16:52  <morcos> not sure i heard that, why does the peer need to be fixed
404 2016-02-13T22:17:37  <BlueMatt> same reason rotating your tor guard node regularly is shit
405 2016-02-13T22:17:56  *** otium_ has left #bitcoin-core-dev
406 2016-02-13T22:18:13  <BlueMatt> if you dont rotate your guard node/tx announce node, you have a fixed chance of being deanonymized...if you do, you are guaranteed to be deanonymized eventually
407 2016-02-13T22:18:20  <BlueMatt> with the same chance at each rotation
408 2016-02-13T22:18:40  *** otium has joined #bitcoin-core-dev
409 2016-02-13T22:20:34  <morcos> too many problems..  anyway, ok family time
410 2016-02-13T22:21:44  <BlueMatt> yea, talk to the tor guys....everything you try here fails :(
411 2016-02-13T22:27:34  *** paveljanik has quit IRC
412 2016-02-13T22:33:42  <morcos> BlueMatt: You got me thinking about deanonymization with this feefilter thing.  Is one of the problems I need to always be solving for making it difficult to correlate a tor node with a public node
413 2016-02-13T22:34:11  <morcos> In other words, if my node connects on both networks, i need to make sure someone that sees it on one can't identify it as the same node on the other?
414 2016-02-13T22:34:51  <morcos> The simple feefilter implementation would make that trivial as it would basically announce every time your mempool min fee kicks in or decays to 0.
415 2016-02-13T22:35:11  <morcos> Of course you could add some variance to obfuscate to some degree.
416 2016-02-13T22:35:41  <BlueMatt> I'm not really sure if thats in our threat model or not...I think it should be within reason, but I'm sure we break that all over the place right now
417 2016-02-13T22:35:52  <morcos> But actually even without the fee filter, a limited mempool makes it pretty easy to correlate (with a bit more work)
418 2016-02-13T22:35:58  <BlueMatt> yea
419 2016-02-13T22:36:00  <BlueMatt> kinda
420 2016-02-13T22:45:34  *** degriff has quit IRC
421 2016-02-13T22:47:38  *** Guyver2 has quit IRC
422 2016-02-13T22:49:05  <PRab> Build finally finished. I guess it wasn't stuck, it just took a long time.
423 2016-02-13T23:19:23  *** otium has left #bitcoin-core-dev
424 2016-02-13T23:20:18  *** gevs has quit IRC
425 2016-02-13T23:20:28  *** ghtdak has quit IRC
426 2016-02-13T23:22:29  *** ghtdak has joined #bitcoin-core-dev
427 2016-02-13T23:27:31  *** MarcoFalke has quit IRC
428 2016-02-13T23:31:43  *** gevs has joined #bitcoin-core-dev
429 2016-02-13T23:31:58  *** gevs has joined #bitcoin-core-dev
430 2016-02-13T23:52:02  *** AaronvanW has quit IRC
431 2016-02-13T23:53:42  *** justanotheruser has quit IRC
432 2016-02-13T23:55:56  *** justanotheruser has joined #bitcoin-core-dev