12016-02-13T00:08:32  *** bsm1175321 has quit IRC
  22016-02-13T00:34:58  *** AaronvanW has quit IRC
  32016-02-13T00:35:36  *** gevs has quit IRC
  42016-02-13T00:38:33  *** gevs has joined #bitcoin-core-dev
  52016-02-13T00:38:57  *** bityogi has quit IRC
  62016-02-13T00:42:38  *** davec has quit IRC
  72016-02-13T00:43:21  *** davec has joined #bitcoin-core-dev
  82016-02-13T00:49:36  *** gevs has quit IRC
  92016-02-13T00:50:08  *** gevs has joined #bitcoin-core-dev
 102016-02-13T00:50:08  *** gevs has joined #bitcoin-core-dev
 112016-02-13T01:03:56  *** zooko has joined #bitcoin-core-dev
 122016-02-13T01:04:52  *** lahwran is now known as lauren
 132016-02-13T01:10:35  *** zooko has quit IRC
 142016-02-13T01:20:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 152016-02-13T01:24:14  *** raedah has joined #bitcoin-core-dev
 162016-02-13T01:30:20  *** Chris_Stewart_5 has quit IRC
 172016-02-13T01:48:24  *** laurentmt has joined #bitcoin-core-dev
 182016-02-13T01:52:44  *** laurentmt has quit IRC
 192016-02-13T01:58:10  <Luke-Jr> is it expected for valgrind to whine about libsecp256k1?
 202016-02-13T02:06:40  <gmaxwell> Luke-Jr: more details required?
 212016-02-13T02:07:00  <Luke-Jr> jumps based on uninit'd values
 222016-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.
 232016-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.
 242016-02-13T02:07:45  <gmaxwell> otherwise, no absolutely not.
 252016-02-13T02:09:14  <Luke-Jr> k
 262016-02-13T02:09:20  <Luke-Jr> (yes, it's with tests)
 272016-02-13T02:09:30  <gmaxwell> you can compile without openssl to make those go away.
 282016-02-13T02:09:45  <gmaxwell> I suppose I should make configure warn that this will happen.
 292016-02-13T02:09:45  <Luke-Jr> it wasn't enough to bother me, unless it was indicative of a problem
 302016-02-13T02:10:38  <gmaxwell> if you ever get code that has gone through my hands that emits valgrind warnings, please report.
 312016-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.
 322016-02-13T02:38:26  *** Ylbam has quit IRC
 332016-02-13T02:54:41  <Luke-Jr> ugh, why is descendantfees not called descendantmodfees? :/
 342016-02-13T02:54:47  <Luke-Jr> sdaftuar: ^
 352016-02-13T02:56:26  <sipa> gmaxwell:
 362016-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
 372016-02-13T03:14:01  *** frankenmint has joined #bitcoin-core-dev
 382016-02-13T03:20:47  *** frankenmint has quit IRC
 392016-02-13T04:00:58  <gmaxwell> sipa: hm?
 402016-02-13T04:01:07  <sipa> gmaxwell: ?
 412016-02-13T04:01:15  <sipa> oh, i said something above
 422016-02-13T04:01:23  <sipa> crap, i don't even remember typing that
 432016-02-13T04:02:05  *** jcorgan has joined #bitcoin-core-dev
 442016-02-13T04:02:38  <Luke-Jr> lol
 452016-02-13T04:21:39  *** frankenmint has joined #bitcoin-core-dev
 462016-02-13T04:27:36  *** frankenmint has quit IRC
 472016-02-13T04:44:17  *** p15x has joined #bitcoin-core-dev
 482016-02-13T04:45:27  *** brg444 has joined #bitcoin-core-dev
 492016-02-13T05:07:52  *** frankenmint has joined #bitcoin-core-dev
 502016-02-13T05:13:04  *** binns_ has joined #bitcoin-core-dev
 512016-02-13T05:13:32  *** binns_ has quit IRC
 522016-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
 532016-02-13T05:17:30  *** dermoth has quit IRC
 542016-02-13T05:28:08  *** cj has joined #bitcoin-core-dev
 552016-02-13T05:34:34  *** binns has quit IRC
 562016-02-13T05:41:04  *** dermoth has joined #bitcoin-core-dev
 572016-02-13T05:46:19  *** binns has joined #bitcoin-core-dev
 582016-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.
 592016-02-13T05:52:38  <warren> "debug1: Skipping ssh-dss key ./var/id_dsa for not in PubkeyAcceptedKeyTypes"
 602016-02-13T06:02:55  *** p15x has quit IRC
 612016-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..?
 622016-02-13T06:05:40  <Luke-Jr> warren: pseudo-fixed upstream, you need to redo the keying
 632016-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
 642016-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 :/
 652016-02-13T06:11:08  <phantomcircuit> Luke-Jr, because it's keeping track of the opposite thing from cpfp
 662016-02-13T06:11:18  <phantomcircuit> which ends up being weird
 672016-02-13T06:11:28  <Luke-Jr> phantomcircuit: yeah, but I mean it should be UpdateForAncestors?
 682016-02-13T06:11:38  <Luke-Jr> since it's updating the ancestor CTxMemPoolEntries
 692016-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
 702016-02-13T06:14:21  *** zooko has joined #bitcoin-core-dev
 712016-02-13T06:16:53  <Luke-Jr> or maybe I should just go update 0.11 :/
 722016-02-13T06:21:42  <warren> http://pastebin.com/eA2MmQ2j  Things break in the name of progress.
 732016-02-13T06:29:13  *** adnn has joined #bitcoin-core-dev
 742016-02-13T06:30:26  <Luke-Jr> warren: already PR'd a fix
 752016-02-13T06:38:08  *** wallet42 has joined #bitcoin-core-dev
 762016-02-13T06:45:58  *** zooko has quit IRC
 772016-02-13T07:37:02  *** Alopex has quit IRC
 782016-02-13T07:38:07  *** Alopex has joined #bitcoin-core-dev
 792016-02-13T07:52:42  <wumpus> cfields: made a mistake yesterday in buildling linux and mac, did not properly wipe the cache. Trying again...
 802016-02-13T07:53:13  <cfields> wumpus: i just redid and got matches on both
 812016-02-13T07:53:27  <wumpus> good
 822016-02-13T07:53:28  <cfields> wumpus: if you don't match now, you're going to set my world on fire :p
 832016-02-13T07:53:29  <btcdrak> music!
 842016-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
 852016-02-13T07:56:42  <cfields> midnightmagic / michagogo / PRab:  ping ^^
 862016-02-13T07:57:16  <cfields> tl;dr: nuke cache, fresh base image, rebuild windows
 872016-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?
 882016-02-13T07:57:38  <wumpus> cfields: oh, you rebuilt linux and it still matched?
 892016-02-13T07:58:06  *** Ylbam has joined #bitcoin-core-dev
 902016-02-13T07:58:09  <cfields> wumpus: i must've not wiped properly
 912016-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
 922016-02-13T07:58:16  <cfields> yikes, context needed there :)
 932016-02-13T07:58:40  <cfields> wumpus: 2 fresh builds tonight of osx/linux, and they matched
 942016-02-13T07:58:41  <wumpus> I apparently wiped the windows cache only :(
 952016-02-13T07:58:58  <wumpus> cfields: ok
 962016-02-13T07:59:09  <cfields> well, let's see how yours end up
 972016-02-13T08:00:10  <wumpus> in my case no new base image was needed, the gcc upgrade is unavoidable :)
 982016-02-13T08:01:25  <warren> cfields: the toolchain changing from under us is one reason why we eventually  need to replace gitian
 992016-02-13T08:01:45  <warren> (not to mention not fully knowing what's in that toolchain binary)
1002016-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
1012016-02-13T08:02:54  <cfields> but this is a good way to shed a light on that
1022016-02-13T08:03:12  <cfields> (purposely for now, for the sake of getting the release out)
1032016-02-13T08:06:21  <warren> well, for the purpose of getting the last 20 releases out =)
1042016-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.
1052016-02-13T08:14:17  *** dermoth has quit IRC
1062016-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
1072016-02-13T08:14:33  *** dermoth_ has joined #bitcoin-core-dev
1082016-02-13T08:14:43  *** dermoth_ is now known as dermoth
1092016-02-13T08:15:18  *** wallet421 has joined #bitcoin-core-dev
1102016-02-13T08:15:18  *** wallet421 has joined #bitcoin-core-dev
1112016-02-13T08:15:18  *** wallet42 has quit IRC
1122016-02-13T08:15:18  *** wallet421 is now known as wallet42
1132016-02-13T08:15:42  *** larsk has quit IRC
1142016-02-13T08:16:26  *** larsk has joined #bitcoin-core-dev
1152016-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
1162016-02-13T08:17:06  <wumpus> cfields: ok nn
1172016-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.
1182016-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.
1192016-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
1202016-02-13T08:26:00  <wumpus> building windows and linux cross-compilers is pretty straightforward
1212016-02-13T08:26:04  <warren> yup
1222016-02-13T08:26:53  <wumpus> (I've done it tons of times for embedded projects - it's mainly lots of waiting :-)
1232016-02-13T08:29:40  <wumpus> (and lots and lots of harddisk space)
1242016-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
1252016-02-13T08:32:36  <wumpus> amusing but also unsetting :p
1262016-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 :-)
1272016-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
1282016-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 :)
1292016-02-13T08:52:53  <cfields> wumpus: matches for osx/linux?
1302016-02-13T08:54:10  <wumpus> oh yes the random and progress-less aspect of that makes it even worse
1312016-02-13T08:54:35  *** degriff has joined #bitcoin-core-dev
1322016-02-13T08:54:42  <wumpus> linux is different :(
1332016-02-13T08:55:05  <wumpus> c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a for bitcoin-0.12.0-linux64.tar.gz
1342016-02-13T08:55:27  <cfields> sigh
1352016-02-13T08:55:46  <wumpus> (different to my own previous build, at least, haven't checked with yours)
1362016-02-13T08:56:07  <wumpus> trying mac now
1372016-02-13T08:56:48  <wumpus> in any case the linux change is to be expected with a toolchain change
1382016-02-13T08:57:23  <cfields> ok, nuking mine again and retrying
1392016-02-13T08:57:43  <wumpus> although it makes no sense that you get the same as before
1402016-02-13T08:59:38  <wumpus> worst case: the  new gcc added some code randomization feature. OTOH we do tend to repeat our own results.
1412016-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.
1422016-02-13T09:00:40  <wumpus> yes just go to sleep we'll see tomorrow :)
1432016-02-13T09:00:51  <btcdrak> sleep is a cureall
1442016-02-13T09:01:05  *** AaronvanW has joined #bitcoin-core-dev
1452016-02-13T09:01:19  <cfields> can't sleep when there's a mismatch and a result is pending :\
1462016-02-13T09:07:40  *** wallet42 has quit IRC
1472016-02-13T09:11:00  *** wallet42 has joined #bitcoin-core-dev
1482016-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?
1492016-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!
1502016-02-13T09:28:00  <wumpus> cfields: my guess is that the -unsigned.tar.gz contains a locally built native executable?
1512016-02-13T09:28:09  <wumpus> in any case, no problem for osx
1522016-02-13T09:28:27  <cfields> wumpus: heh, so my macbook results were good, desktop were off. ok, that's something solid at least
1532016-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
1542016-02-13T09:28:46  <cfields> wumpus: yea, the tools to re-attach and create the dmg are native
1552016-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
1562016-02-13T09:29:10  <wumpus> cfields: okay, solved that then
1572016-02-13T09:29:18  <cfields> warren: that's not a bad idea for 0.12, actually. the gitian descriptor can disable the cache
1582016-02-13T09:29:28  <cfields> wumpus: maybe do ^^ and be done with it?
1592016-02-13T09:29:37  <warren> horray I had an idea
1602016-02-13T09:29:43  * warren sleep
1612016-02-13T09:29:56  <cfields> doesn't solve any of the actual issues, but will help with coordinating
1622016-02-13T09:29:58  <warren> cfields: I'm fighting a gitian problem for something else at the moment, so similarly annoyed
1632016-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
1642016-02-13T09:30:49  <cfields> wumpus: i was just speaking for 0.12 rc6/final, not anything permanent
1652016-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?)
1662016-02-13T09:31:14  <wumpus> all the other dependencies are a joke in comparison and could as well be built every time
1672016-02-13T09:31:34  <wumpus> cfields: right, could do that
1682016-02-13T09:31:49  <cfields> wumpus: specifically: http://pastebin.com/raw/T1ksN7nP
1692016-02-13T09:32:02  <cfields> yea, qt is terrible :(
1702016-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
1712016-02-13T09:33:39  <cfields> wumpus: i spent several days getting the qt build down to a bare minimum...
1722016-02-13T09:34:02  <wumpus> okay
1732016-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
1742016-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
1752016-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
1762016-02-13T09:39:05  <Luke-Jr> not sure how similar.. Gentoo just doesn't have them packaged separately
1772016-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)
1782016-02-13T09:39:10  <wumpus> cfields: I also don't expect them to have done much changes to qt in that regard
1792016-02-13T09:40:28  <Luke-Jr> cross-compiling in Gentoo is somewhat of an afterthought
1802016-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
1812016-02-13T09:41:59  <warren> Otoh I suppose versioning a set of expected tool chain is better
1822016-02-13T09:42:45  <cfields> wumpus: c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a  bitcoin-0.12.0-linux64.tar.gz
1832016-02-13T09:42:58  <cfields> 46ef9d35b4fbd89e74065647173ae0bbe8e04c6b47413a421576b0800a04ef37  bitcoin-0.12.0-linux32.tar.gz
1842016-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
1852016-02-13T09:44:06  <cfields> but i think we can work something out to avoid the static hashes
1862016-02-13T09:44:32  <warren> The underlying tool chain changing should be something we detect
1872016-02-13T09:44:40  <wumpus> cfields: match
1882016-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
1892016-02-13T09:45:16  <cfields> warren: for sure
1902016-02-13T09:45:19  <wumpus> warren: we can, all the .deb packages are logged to the .assert file
1912016-02-13T09:45:25  <wumpus> warren: only caching messes with this :(
1922016-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
1932016-02-13T09:46:10  <wumpus> but the current state is always tracable and comparable
1942016-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
1952016-02-13T09:49:50  <warren> Idea: include the package list in the intermediate cached output tar
1962016-02-13T09:52:49  *** paveljanik has joined #bitcoin-core-dev
1972016-02-13T10:05:32  <wumpus> yes that at least
1982016-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
1992016-02-13T10:09:20  <wumpus> all the gcc/g++ debs basically changed inbetween
2002016-02-13T10:09:49  <wumpus> as long as *someone* builds without cache, these things will be detected
2012016-02-13T10:10:20  <wumpus> I used to be that someone, but that was before having 6 rcs per release was all the rage :-)
2022016-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
2032016-02-13T10:13:31  <warren> Too many false positives, need to filter to a list of identified important tool chain dpkgs
2042016-02-13T10:14:04  <warren> Ohhhh
2052016-02-13T10:14:05  <wumpus> well it beats completely disabling the cache, but sure
2062016-02-13T10:14:50  <warren> Use ccache as a canary, it's very good at detecting most toolcgain changes
2072016-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
2082016-02-13T10:16:11  <warren> I didn't mean use ccache for builds, use it only to detect changes
2092016-02-13T10:16:32  <wumpus> yes I see
2102016-02-13T10:16:46  <warren> It's a simple but imperfect detector
2112016-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
2122016-02-13T10:18:23  <wumpus> I wonder if it would have detected this. I don't think gcc --version output changed :(
2132016-02-13T10:27:14  <wumpus> otoh if it looks at, say, the timestamps of hashes of the actual tools then it may work
2142016-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)
2152016-02-13T10:28:13  <wumpus> anyhow an attempt at detecting this is 100% better than none
2162016-02-13T11:41:26  *** murch has joined #bitcoin-core-dev
2172016-02-13T12:22:48  *** adam3us_ is now known as adam3us
2182016-02-13T12:29:07  *** MarcoFalke has joined #bitcoin-core-dev
2192016-02-13T12:29:44  <MarcoFalke> wumpus, Is your script to create the release note change log somewhere in the tree?
2202016-02-13T13:07:00  *** brg444 has quit IRC
2212016-02-13T13:11:47  *** laurentmt has joined #bitcoin-core-dev
2222016-02-13T13:11:51  *** laurentmt has quit IRC
2232016-02-13T13:26:49  *** Squidicc has joined #bitcoin-core-dev
2242016-02-13T13:30:01  *** Squidicuz has quit IRC
2252016-02-13T13:38:34  *** davec has quit IRC
2262016-02-13T13:39:14  *** davec has joined #bitcoin-core-dev
2272016-02-13T13:48:35  *** wumpus has quit IRC
2282016-02-13T13:50:23  *** wumpus has joined #bitcoin-core-dev
2292016-02-13T14:12:16  *** belcher has joined #bitcoin-core-dev
2302016-02-13T14:28:28  <PRab> Any reason for the delay on rc5's detached sig?
2312016-02-13T14:29:16  <MarcoFalke> maybe https://github.com/bitcoin/gitian.sigs/pull/305#issuecomment-183665538
2322016-02-13T14:29:59  <PRab> Ah, that could be it.
2332016-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.
2342016-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.
2352016-02-13T14:32:40  <MarcoFalke> I think wiping the cache is just sufficient
2362016-02-13T14:33:05  <PRab> Yeah, but I've been meaning to do this anyway.
2372016-02-13T14:33:20  *** p15x has joined #bitcoin-core-dev
2382016-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.
2392016-02-13T14:56:48  <morcos> It's difficult logic to get correct.
2402016-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.
2412016-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
2422016-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.
2432016-02-13T15:08:12  *** laurentmt has joined #bitcoin-core-dev
2442016-02-13T15:08:16  *** laurentmt has quit IRC
2452016-02-13T15:22:46  *** murr4y has quit IRC
2462016-02-13T15:27:57  *** murr4y has joined #bitcoin-core-dev
2472016-02-13T15:30:31  *** antanst has joined #bitcoin-core-dev
2482016-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.
2492016-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
2502016-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
2512016-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
2522016-02-13T15:36:10  <morcos> measuring such time from tx creation, not the last time it succeeding in making it into your mempool.
2532016-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
2542016-02-13T15:46:12  *** p15x has quit IRC
2552016-02-13T16:10:19  *** laurentmt has joined #bitcoin-core-dev
2562016-02-13T16:56:28  *** bityogi has joined #bitcoin-core-dev
2572016-02-13T17:19:56  *** bityogi has quit IRC
2582016-02-13T17:27:34  *** otium has joined #bitcoin-core-dev
2592016-02-13T18:50:00  *** belcher has quit IRC
2602016-02-13T18:57:44  *** degriff has left #bitcoin-core-dev
2612016-02-13T19:03:30  *** neilf has quit IRC
2622016-02-13T19:20:18  *** wallet42 has quit IRC
2632016-02-13T19:20:37  *** wallet42 has joined #bitcoin-core-dev
2642016-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
2652016-02-13T19:24:58  <cfields> still waiting one 1 more sig to match wumpus and me before I can push the detached sigs
2662016-02-13T19:26:14  <MarcoFalke> Currently I have the "Updating apt-get repository (log in var/install.log)
2672016-02-13T19:26:15  <MarcoFalke> root@localhost's password:
2682016-02-13T19:26:15  <MarcoFalke> " error. But I think it's a local issue solved by rebooting my box
2692016-02-13T19:27:52  *** AtashiCon has quit IRC
2702016-02-13T19:29:59  *** AtashiCon has joined #bitcoin-core-dev
2712016-02-13T19:43:39  *** murch has quit IRC
2722016-02-13T19:44:50  <cfields> MarcoFalke: i got that after updating gitian, you can end up with a mismatch of rsa/dsa keys
2732016-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
2742016-02-13T19:49:08  <cfields> MarcoFalke: strange, i'm unsure what's going on there
2752016-02-13T19:57:17  *** laurentmt has quit IRC
2762016-02-13T20:02:32  *** belcher has joined #bitcoin-core-dev
2772016-02-13T20:08:59  *** degriff has joined #bitcoin-core-dev
2782016-02-13T20:09:48  <PRab> cfields: Building now.
2792016-02-13T20:14:06  <cfields> PRab: great, thanks
2802016-02-13T20:23:34  <warren> MarcoFalke: saw one of your github issues, you're the fedora user?
2812016-02-13T20:23:53  <MarcoFalke> jup
2822016-02-13T20:24:22  <MarcoFalke> I am doing the gitian building on the actual fedora host.
2832016-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
2842016-02-13T20:24:38  <warren> also need to rebuild the vm's
2852016-02-13T20:25:40  <MarcoFalke> I am aware of the "rebuild the vm's"-fix because I broke it ;)
2862016-02-13T20:26:19  <warren> FWIW I got gitian working on fedora last night by manually populating the cache with the intermediate source tarballs
2872016-02-13T20:28:09  <MarcoFalke> warren, are you sure the vmbuilder hit yum yet? (Bug report shows it as "NEW")
2882016-02-13T20:28:10  <MarcoFalke> https://bugzilla.redhat.com/show_bug.cgi?id=1074143
2892016-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
2902016-02-13T20:30:54  <warren> seems to still work though
2912016-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
2922016-02-13T20:32:59  <MarcoFalke> in the meantime
2932016-02-13T20:40:20  *** Guyver2 has joined #bitcoin-core-dev
2942016-02-13T20:41:21  *** cjcj has quit IRC
2952016-02-13T20:45:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2962016-02-13T20:49:14  *** MarcoFalke has quit IRC
2972016-02-13T20:52:57  *** MarcoFalke has joined #bitcoin-core-dev
2982016-02-13T20:56:23  *** mkarrer_ has quit IRC
2992016-02-13T20:59:01  *** mkarrer has joined #bitcoin-core-dev
3002016-02-13T21:02:50  *** PRab has quit IRC
3012016-02-13T21:05:55  *** Chris_Stewart_5 has quit IRC
3022016-02-13T21:10:16  *** degriff has quit IRC
3032016-02-13T21:11:12  *** degriff has joined #bitcoin-core-dev
3042016-02-13T21:28:56  *** qlql has quit IRC
3052016-02-13T21:29:07  *** PRab has joined #bitcoin-core-dev
3062016-02-13T21:31:07  *** laurentmt has joined #bitcoin-core-dev
3072016-02-13T21:37:36  *** JackH has quit IRC
3082016-02-13T21:39:18  *** otium has left #bitcoin-core-dev
3092016-02-13T21:39:40  *** otium has joined #bitcoin-core-dev
3102016-02-13T21:42:32  *** laurentmt has quit IRC
3112016-02-13T21:46:17  <BlueMatt> debug.log at 975G...quick someone ping my node a bunch so it hits 1TB :p
3122016-02-13T21:46:46  *** otium_ has joined #bitcoin-core-dev
3132016-02-13T21:51:42  *** otium has quit IRC
3142016-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
3152016-02-13T21:53:50  <PRab> gbuild for windows doesn't appear to be finishing.
3162016-02-13T21:54:14  <PRab> Its been hanging out at "Running build script ..." for over an hour.
3172016-02-13T21:54:21  <PRab> (probably closer to 2)
3182016-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"
3192016-02-13T21:54:35  <BlueMatt> morcos: clearly the solution to the block size issue is to first fix btrfs
3202016-02-13T21:55:19  <Luke-Jr> lol
3212016-02-13T21:55:35  * Luke-Jr wonders if btrfs ever merged his bugfixes
3222016-02-13T21:55:42  <BlueMatt> probably not
3232016-02-13T21:56:12  <Luke-Jr> yeah, they don't seem to care about bugs :<
3242016-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
3252016-02-13T21:57:22  <Luke-Jr> Receiving objects:   3% (3787/99184), 1.75 MiB | 50.00 KiB/s <-- slooow
3262016-02-13T21:59:14  <BlueMatt> morcos: hmm, I havent seen that one...why does -minrelaytxfee continue to exist?
3272016-02-13T21:59:30  <BlueMatt> morcos: like, did fee estimation think fee was 0 and thus min_fee?
3282016-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
3292016-02-13T22:00:13  <morcos> BlueMatt: forget about fee esitmation for a second, it basically uses a new variable now anyway: fallbackfee
3302016-02-13T22:00:26  <BlueMatt> ok, fair enough
3312016-02-13T22:00:40  <morcos> The point is minrelaytxfee and incremental relay fee are the same thing now
3322016-02-13T22:00:45  <BlueMatt> i mean then its the same thing - incremental fee for everything
3332016-02-13T22:00:48  <BlueMatt> its also incremental from 0
3342016-02-13T22:00:54  <BlueMatt> yea
3352016-02-13T22:00:57  <morcos> right, thats fine, maybe they dont' need to be separate
3362016-02-13T22:01:08  <morcos> but my point is if you try to set it (by setting minrelaytxfee)
3372016-02-13T22:01:20  <morcos> it doesn't affect a couple of the calculations that happen inside mempool
3382016-02-13T22:01:38  <morcos> b/c that variable is a local copy made before the command line option is set (i think)
3392016-02-13T22:02:31  <BlueMatt> oh? well we should fix that
3402016-02-13T22:02:37  <BlueMatt> we should also change minrelaytxfee to a different name
3412016-02-13T22:02:40  <BlueMatt> and make it a hidden option
3422016-02-13T22:02:50  <BlueMatt> because people who had previously set that as a spam-prevention thing should reconsider
3432016-02-13T22:02:56  <morcos> Well, its not entirely clear
3442016-02-13T22:02:57  <BlueMatt> should have done for 0.12, really
3452016-02-13T22:02:58  <BlueMatt> but oh well
3462016-02-13T22:03:06  <morcos> I mostly agree with that
3472016-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
3482016-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
3492016-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.
3502016-02-13T22:05:23  <BlueMatt> sat/B
3512016-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
3522016-02-13T22:05:29  <BlueMatt> oh, satoshi/Byte
3532016-02-13T22:05:51  <morcos> yeah i don't know why we always say 1000 sat/kB instead of 1 sat/B
3542016-02-13T22:06:04  <Luke-Jr> 1 s/B is way too low a feerate :p
3552016-02-13T22:06:20  <morcos> Luke-Jr: exactly  :)
3562016-02-13T22:06:20  <Luke-Jr> morcos: as for reason, it's because size used to be rounded to next kB
3572016-02-13T22:06:28  <BlueMatt> i mean, sure, having a different incremental from 0 than incremental is a reasonable policy option
3582016-02-13T22:06:52  <BlueMatt> but the real solution to the problem is to do some basic mempool-sync stuff on startup
3592016-02-13T22:06:58  <BlueMatt> then your limit will jump right away
3602016-02-13T22:07:15  <morcos> heh, the real solution is feefilter, its awesome in my testing so far
3612016-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!
3622016-02-13T22:08:59  <BlueMatt> wow, scalia reported passed away
3632016-02-13T22:09:07  <BlueMatt> thats gonna be big for scotus
3642016-02-13T22:09:20  <BlueMatt> feefilter?
3652016-02-13T22:09:25  <BlueMatt> I havent been paying attention of late, tbh
3662016-02-13T22:09:53  <morcos> BlueMatt: its a tease, i haven't written it up yet.  i'm procrastinating doing that now.
3672016-02-13T22:10:04  <BlueMatt> whats the idea?
3682016-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
3692016-02-13T22:10:14  <BlueMatt> ahh
3702016-02-13T22:10:15  <BlueMatt> meh
3712016-02-13T22:10:20  * Luke-Jr wishes there was somewhere better to move
3722016-02-13T22:10:28  <morcos> whats the meh
3732016-02-13T22:10:41  <BlueMatt> that doesnt help if your mempool never fills enough to get medium-fee txn
3742016-02-13T22:10:48  <BlueMatt> so that you can set the mempool fee
3752016-02-13T22:10:52  <BlueMatt> but, yes, we should also have that
3762016-02-13T22:11:01  <BlueMatt> maybe we should revisit segwit having explicit fees
3772016-02-13T22:11:03  <morcos> whose mempool never fills enough
3782016-02-13T22:11:27  <BlueMatt> mempools do take a while to fill reasonably
3792016-02-13T22:11:37  <BlueMatt> because people dont rebroadcast "real" txn
3802016-02-13T22:11:41  <BlueMatt> just the spam keeps flowing around
3812016-02-13T22:12:01  *** Guyver2 has quit IRC
3822016-02-13T22:12:58  *** Guyver2 has joined #bitcoin-core-dev
3832016-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
3842016-02-13T22:13:27  <Luke-Jr> [22:11:37] <BlueMatt> because people dont rebroadcast "real" txn <-- ⁇
3852016-02-13T22:13:47  <morcos> but during that decay, you are inved spam, and rereuest it b/c your reject filter is reset
3862016-02-13T22:13:51  <morcos> feefilter fixes that
3872016-02-13T22:13:57  <BlueMatt> Luke-Jr: i mean because it gets mined, so they dont have to :p
3882016-02-13T22:14:11  <BlueMatt> morcos: yes, both are required, is my point
3892016-02-13T22:14:27  <morcos> sorry, what's the both?
3902016-02-13T22:14:34  <morcos> you mean dynamic mempool fee?
3912016-02-13T22:14:38  <morcos> of course
3922016-02-13T22:14:39  <BlueMatt> both mempool sync and feefilter
3932016-02-13T22:14:43  <morcos> oh sync
3942016-02-13T22:15:05  <BlueMatt> ofc sync is hard to do in a privacy-preserving manner, etc, etc
3952016-02-13T22:15:16  <BlueMatt> we need to redo txn flow completely, really
3962016-02-13T22:15:19  <BlueMatt> to preserve privacy
3972016-02-13T22:15:21  <morcos> yeah, i'm not sure what i think about sync.
3982016-02-13T22:15:33  <morcos> yeah well did you read the privacy concerns around 7521
3992016-02-13T22:15:39  <morcos> its pretty bad
4002016-02-13T22:16:01  <BlueMatt> do we really still do that?
4012016-02-13T22:16:01  <BlueMatt> wow
4022016-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
4032016-02-13T22:16:52  <morcos> not sure i heard that, why does the peer need to be fixed
4042016-02-13T22:17:37  <BlueMatt> same reason rotating your tor guard node regularly is shit
4052016-02-13T22:17:56  *** otium_ has left #bitcoin-core-dev
4062016-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
4072016-02-13T22:18:20  <BlueMatt> with the same chance at each rotation
4082016-02-13T22:18:40  *** otium has joined #bitcoin-core-dev
4092016-02-13T22:20:34  <morcos> too many problems..  anyway, ok family time
4102016-02-13T22:21:44  <BlueMatt> yea, talk to the tor guys....everything you try here fails :(
4112016-02-13T22:27:34  *** paveljanik has quit IRC
4122016-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
4132016-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?
4142016-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.
4152016-02-13T22:35:11  <morcos> Of course you could add some variance to obfuscate to some degree.
4162016-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
4172016-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)
4182016-02-13T22:35:58  <BlueMatt> yea
4192016-02-13T22:36:00  <BlueMatt> kinda
4202016-02-13T22:45:34  *** degriff has quit IRC
4212016-02-13T22:47:38  *** Guyver2 has quit IRC
4222016-02-13T22:49:05  <PRab> Build finally finished. I guess it wasn't stuck, it just took a long time.
4232016-02-13T23:19:23  *** otium has left #bitcoin-core-dev
4242016-02-13T23:20:18  *** gevs has quit IRC
4252016-02-13T23:20:28  *** ghtdak has quit IRC
4262016-02-13T23:22:29  *** ghtdak has joined #bitcoin-core-dev
4272016-02-13T23:27:31  *** MarcoFalke has quit IRC
4282016-02-13T23:31:43  *** gevs has joined #bitcoin-core-dev
4292016-02-13T23:31:58  *** gevs has joined #bitcoin-core-dev
4302016-02-13T23:52:02  *** AaronvanW has quit IRC
4312016-02-13T23:53:42  *** justanotheruser has quit IRC
4322016-02-13T23:55:56  *** justanotheruser has joined #bitcoin-core-dev