--- Day changed Sat Feb 13 2016 00:00 < wumpus> in my case no new base image was needed, the gcc upgrade is unavoidable :) 00:01 < warren> cfields: the toolchain changing from under us is one reason why we eventually need to replace gitian 00:01 < warren> (not to mention not fully knowing what's in that toolchain binary) 00:02 < 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 00:02 < cfields> but this is a good way to shed a light on that 00:03 < cfields> (purposely for now, for the sake of getting the release out) 00:06 < warren> well, for the purpose of getting the last 20 releases out =) 00:12 < 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. 00:14 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has quit [Disconnected by services] 00:14 < 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 00:14 -!- dermoth_ [~thomas@189-79.162.dsl.aei.ca] has joined #bitcoin-core-dev 00:14 -!- dermoth_ is now known as dermoth 00:15 -!- wallet421 [~wallet42@bitcoin.felixweis.com] has joined #bitcoin-core-dev 00:15 -!- wallet421 [~wallet42@bitcoin.felixweis.com] has quit [Changing host] 00:15 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 00:15 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Killed (adams.freenode.net (Nickname regained by services))] 00:15 -!- wallet421 is now known as wallet42 00:15 -!- larsk [~l4rsk@50.248.81.65] has quit [Read error: Connection reset by peer] 00:16 -!- larsk [~xea@50.248.81.65] has joined #bitcoin-core-dev 00:16 < 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 00:17 < wumpus> cfields: ok nn 00:23 < 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. 00:24 < 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. 00:25 < 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 00:26 < wumpus> building windows and linux cross-compilers is pretty straightforward 00:26 < warren> yup 00:26 < wumpus> (I've done it tons of times for embedded projects - it's mainly lots of waiting :-) 00:29 < wumpus> (and lots and lots of harddisk space) 00:31 < btcdrak> it would be amusing to know how many hours we've all spent in our lifetimes waiting for compiles to finish :p 00:32 < wumpus> amusing but also unsetting :p 00:34 < 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 :-) 00:36 < wumpus> well I try to plan it usually that I don't have to wait for specific compiles by overlapping multiple 00:43 < 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 :) 00:52 < cfields> wumpus: matches for osx/linux? 00:54 < wumpus> oh yes the random and progress-less aspect of that makes it even worse 00:54 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev 00:54 < wumpus> linux is different :( 00:55 < wumpus> c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a for bitcoin-0.12.0-linux64.tar.gz 00:55 < cfields> sigh 00:55 < wumpus> (different to my own previous build, at least, haven't checked with yours) 00:56 < wumpus> trying mac now 00:56 < wumpus> in any case the linux change is to be expected with a toolchain change 00:57 < cfields> ok, nuking mine again and retrying 00:57 < wumpus> although it makes no sense that you get the same as before 00:59 < wumpus> worst case: the new gcc added some code randomization feature. OTOH we do tend to repeat our own results. 01:00 < cfields> wumpus: there's a ton of room for pebcak atm. That's by far the most likely explanation for my results atm. 01:00 < wumpus> yes just go to sleep we'll see tomorrow :) 01:00 < btcdrak> sleep is a cureall 01:01 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:01 < cfields> can't sleep when there's a mismatch and a result is pending :\ 01:07 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 01:11 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 01:27 < warren> cfields: if the underlying toolchain changes, perhaps the gitian-descriptors should be bumped so all cached results are invalid, to avoid expected mismatches? 01:27 < 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! 01:28 < wumpus> cfields: my guess is that the -unsigned.tar.gz contains a locally built native executable? 01:28 < wumpus> in any case, no problem for osx 01:28 < cfields> wumpus: heh, so my macbook results were good, desktop were off. ok, that's something solid at least 01:28 < 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 01:28 < cfields> wumpus: yea, the tools to re-attach and create the dmg are native 01:29 < 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 01:29 < wumpus> cfields: okay, solved that then 01:29 < cfields> warren: that's not a bad idea for 0.12, actually. the gitian descriptor can disable the cache 01:29 < cfields> wumpus: maybe do ^^ and be done with it? 01:29 < warren> horray I had an idea 01:29 * warren sleep 01:29 < cfields> doesn't solve any of the actual issues, but will help with coordinating 01:29 < warren> cfields: I'm fighting a gitian problem for something else at the moment, so similarly annoyed 01:29 < 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 01:30 < cfields> wumpus: i was just speaking for 0.12 rc6/final, not anything permanent 01:31 < 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?) 01:31 < wumpus> all the other dependencies are a joke in comparison and could as well be built every time 01:31 < wumpus> cfields: right, could do that 01:31 < cfields> wumpus: specifically: http://pastebin.com/raw/T1ksN7nP 01:32 < cfields> yea, qt is terrible :( 01:32 < 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 01:33 < cfields> wumpus: i spent several days getting the qt build down to a bare minimum... 01:34 < wumpus> okay 01:34 < cfields> it might be better now with later versions, but in the ~5.2 days, that was about as slim as it could get 01:34 < cfields> don't misunderstand, it's definitely worth taking another look. iirc at that point it wasn't split into separate modules 01:38 < 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 01:39 < Luke-Jr> not sure how similar.. Gentoo just doesn't have them packaged separately 01:39 < cfields> (ie there's no "qmake" ebuild, because it's not reasonable to build it without building the rest of base qt) 01:39 < wumpus> cfields: I also don't expect them to have done much changes to qt in that regard 01:40 < Luke-Jr> cross-compiling in Gentoo is somewhat of an afterthought 01:40 < 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 01:41 < warren> Otoh I suppose versioning a set of expected tool chain is better 01:42 < cfields> wumpus: c713f82859a27e9e0f9e7fb926f074bef855e255bfbb1207ce6987534233137a bitcoin-0.12.0-linux64.tar.gz 01:42 < cfields> 46ef9d35b4fbd89e74065647173ae0bbe8e04c6b47413a421576b0800a04ef37 bitcoin-0.12.0-linux32.tar.gz 01:43 < 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 01:44 < cfields> but i think we can work something out to avoid the static hashes 01:44 < warren> The underlying tool chain changing should be something we detect 01:44 < wumpus> cfields: match 01:45 < cfields> wumpus: no idea what i borked last time, but went smoothly this time. building osx while i sleep. nnite now for real 01:45 < cfields> warren: for sure 01:45 < wumpus> warren: we can, all the .deb packages are logged to the .assert file 01:45 < wumpus> warren: only caching messes with this :( 01:46 < 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 01:46 < wumpus> but the current state is always tracable and comparable 01:46 < wumpus> if two people built with different gcc and have different output, normally we could see that. Except cache + unfortunate timing this time 01:49 < warren> Idea: include the package list in the intermediate cached output tar 01:52 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 02:05 < wumpus> yes that at least 02:08 < 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 02:09 < wumpus> all the gcc/g++ debs basically changed inbetween 02:09 < wumpus> as long as *someone* builds without cache, these things will be detected 02:10 < wumpus> I used to be that someone, but that was before having 6 rcs per release was all the rage :-) 02:12 < 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 02:13 < warren> Too many false positives, need to filter to a list of identified important tool chain dpkgs 02:14 < warren> Ohhhh 02:14 < wumpus> well it beats completely disabling the cache, but sure 02:14 < warren> Use ccache as a canary, it's very good at detecting most toolcgain changes 02:15 < 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 02:16 < warren> I didn't mean use ccache for builds, use it only to detect changes 02:16 < wumpus> yes I see 02:16 < warren> It's a simple but imperfect detector 02:17 < 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 02:18 < wumpus> I wonder if it would have detected this. I don't think gcc --version output changed :( 02:27 < wumpus> otoh if it looks at, say, the timestamps of hashes of the actual tools then it may work 02:27 < 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) 02:28 < wumpus> anyhow an attempt at detecting this is 100% better than none 03:41 -!- murch [~murch@p4FDB7F77.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 04:22 -!- adam3us_ is now known as adam3us 04:29 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev 04:29 < MarcoFalke> wumpus, Is your script to create the release note change log somewhere in the tree? 05:07 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed] 05:11 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 05:11 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 05:26 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 05:30 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 256 seconds] 05:38 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 05:39 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 05:48 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds] 05:50 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 06:12 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 06:28 < PRab> Any reason for the delay on rc5's detached sig? 06:29 < MarcoFalke> maybe https://github.com/bitcoin/gitian.sigs/pull/305#issuecomment-183665538 06:29 < PRab> Ah, that could be it. 06:31 < PRab> I know this is overkill, but I think I'm going to blow away my entire VM and rebuild it. 06:31 < PRab> I've been using the same one since I started doing gitian builds so I a couple of version behind for debian. 06:32 < MarcoFalke> I think wiping the cache is just sufficient 06:33 < PRab> Yeah, but I've been meaning to do this anyway. 06:33 -!- p15x [~p15x@17.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 06:56 < 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. 06:56 < morcos> It's difficult logic to get correct. 06:57 < 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. 06:57 < 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 06:58 < 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. 07:08 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 07:08 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 07:22 -!- murr4y [murray@kvikshaug.no] has quit [Ping timeout: 240 seconds] 07:27 -!- murr4y [murray@kvikshaug.no] has joined #bitcoin-core-dev 07:30 -!- antanst [~antanst@static.9.8.9.5.clients.your-server.de] has joined #bitcoin-core-dev 07:32 < 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. 07:33 < 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 07:33 < 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 07:35 < 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 07:36 < morcos> measuring such time from tx creation, not the last time it succeeding in making it into your mempool. 07:44 < 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 07:46 -!- p15x [~p15x@17.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 248 seconds] 08:10 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 08:56 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev 09:19 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 09:27 -!- otium [~textual@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev 10:50 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] 10:57 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has left #bitcoin-core-dev [] 11:03 -!- neilf [~neilf@40.121.88.219] has quit [Read error: Connection reset by peer] 11:20 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection] 11:20 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 11: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 11:24 < cfields> still waiting one 1 more sig to match wumpus and me before I can push the detached sigs 11:26 < MarcoFalke> Currently I have the "Updating apt-get repository (log in var/install.log) 11:26 < MarcoFalke> root@localhost's password: 11:26 < MarcoFalke> " error. But I think it's a local issue solved by rebooting my box 11:27 -!- AtashiCon [~Arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection] 11:29 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 11:43 -!- murch [~murch@p4FDB7F77.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 11:44 < cfields> MarcoFalke: i got that after updating gitian, you can end up with a mismatch of rsa/dsa keys 11:46 < MarcoFalke> I can't remember updating gitian. This happened right after win-rc5 : https://github.com/bitcoin/gitian.sigs/pull/304 11:49 < cfields> MarcoFalke: strange, i'm unsure what's going on there 11:57 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 12:02 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 12:08 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev 12:09 < PRab> cfields: Building now. 12:14 < cfields> PRab: great, thanks 12:23 < warren> MarcoFalke: saw one of your github issues, you're the fedora user? 12:23 < MarcoFalke> jup 12:24 < MarcoFalke> I am doing the gitian building on the actual fedora host. 12:24 < 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 12:24 < warren> also need to rebuild the vm's 12:25 < MarcoFalke> I am aware of the "rebuild the vm's"-fix because I broke it ;) 12:26 < warren> FWIW I got gitian working on fedora last night by manually populating the cache with the intermediate source tarballs 12:28 < MarcoFalke> warren, are you sure the vmbuilder hit yum yet? (Bug report shows it as "NEW") 12:28 < MarcoFalke> https://bugzilla.redhat.com/show_bug.cgi?id=1074143 12:30 < 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 12:30 < warren> seems to still work though 12:32 < MarcoFalke> Looks fine because we did not change the packet: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#installing-gitian 12:32 < MarcoFalke> in the meantime 12:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 12:41 -!- cjcj [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Ping timeout: 252 seconds] 12:45 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 12:49 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:52 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev 12:56 -!- mkarrer_ [~mkarrer@75.Red-83-43-123.dynamicIP.rima-tde.net] has quit [] 12:59 -!- mkarrer [~mkarrer@75.Red-83-43-123.dynamicIP.rima-tde.net] has joined #bitcoin-core-dev 13:02 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 13:05 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 260 seconds] 13:10 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has quit [Remote host closed the connection] 13:11 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev 13:28 -!- qlql [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Quit: Page closed] 13:29 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 13:31 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 13:37 -!- JackH [~Jack@host-2-103-125-6.as13285.net] has quit [Quit: Leaving] 13:39 -!- otium [~textual@rob76-4-82-238-176-192.fbx.proxad.net] has left #bitcoin-core-dev ["..."] 13:39 -!- otium [~textual@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev 13:42 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 13:46 < BlueMatt> debug.log at 975G...quick someone ping my node a bunch so it hits 1TB :p 13:46 -!- otium_ [~otium@2a01:e35:2eeb:c00:3432:38a7:5adc:1670] has joined #bitcoin-core-dev 13:51 -!- otium [~textual@rob76-4-82-238-176-192.fbx.proxad.net] has quit [Quit: ...] 13:52 < 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 13:53 < PRab> gbuild for windows doesn't appear to be finishing. 13:54 < PRab> Its been hanging out at "Running build script ..." for over an hour. 13:54 < PRab> (probably closer to 2) 13:54 < 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" 13:54 < BlueMatt> morcos: clearly the solution to the block size issue is to first fix btrfs 13:55 < Luke-Jr> lol 13:55 * Luke-Jr wonders if btrfs ever merged his bugfixes 13:55 < BlueMatt> probably not 13:56 < Luke-Jr> yeah, they don't seem to care about bugs :< 13:56 < 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 13:57 < Luke-Jr> Receiving objects: 3% (3787/99184), 1.75 MiB | 50.00 KiB/s <-- slooow 13:59 < BlueMatt> morcos: hmm, I havent seen that one...why does -minrelaytxfee continue to exist? 13:59 < BlueMatt> morcos: like, did fee estimation think fee was 0 and thus min_fee? 14:00 < BlueMatt> morcos: as for adding an option to set the min incremental relay fee, sure, why not...but should be a hidden option 14:00 < morcos> BlueMatt: forget about fee esitmation for a second, it basically uses a new variable now anyway: fallbackfee 14:00 < BlueMatt> ok, fair enough 14:00 < morcos> The point is minrelaytxfee and incremental relay fee are the same thing now 14:00 < BlueMatt> i mean then its the same thing - incremental fee for everything 14:00 < BlueMatt> its also incremental from 0 14:00 < BlueMatt> yea 14:00 < morcos> right, thats fine, maybe they dont' need to be separate 14:01 < morcos> but my point is if you try to set it (by setting minrelaytxfee) 14:01 < morcos> it doesn't affect a couple of the calculations that happen inside mempool 14:01 < morcos> b/c that variable is a local copy made before the command line option is set (i think) 14:02 < BlueMatt> oh? well we should fix that 14:02 < BlueMatt> we should also change minrelaytxfee to a different name 14:02 < BlueMatt> and make it a hidden option 14:02 < BlueMatt> because people who had previously set that as a spam-prevention thing should reconsider 14:02 < morcos> Well, its not entirely clear 14:02 < BlueMatt> should have done for 0.12, really 14:02 < BlueMatt> but oh well 14:03 < morcos> I mostly agree with that 14:03 < morcos> but its nice to have the fall back of saying i just don't want any garbage less than X 14:04 < 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 14:04 < 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. 14:05 < BlueMatt> sat/B 14:05 < 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 14:05 < BlueMatt> oh, satoshi/Byte 14:05 < morcos> yeah i don't know why we always say 1000 sat/kB instead of 1 sat/B 14:06 < Luke-Jr> 1 s/B is way too low a feerate :p 14:06 < morcos> Luke-Jr: exactly :) 14:06 < Luke-Jr> morcos: as for reason, it's because size used to be rounded to next kB 14:06 < BlueMatt> i mean, sure, having a different incremental from 0 than incremental is a reasonable policy option 14:06 < BlueMatt> but the real solution to the problem is to do some basic mempool-sync stuff on startup 14:06 < BlueMatt> then your limit will jump right away 14:07 < morcos> heh, the real solution is feefilter, its awesome in my testing so far 14:07 < morcos> all these damn 15kB size txs of 15000 sat fee that keep being requested and then summarily rejected are really annoying! 14:08 < BlueMatt> wow, scalia reported passed away 14:09 < BlueMatt> thats gonna be big for scotus 14:09 < BlueMatt> feefilter? 14:09 < BlueMatt> I havent been paying attention of late, tbh 14:09 < morcos> BlueMatt: its a tease, i haven't written it up yet. i'm procrastinating doing that now. 14:10 < BlueMatt> whats the idea? 14:10 < morcos> but short idea is you just tell your peers don't even bother inving me txs less than my mempool min fee 14:10 < BlueMatt> ahh 14:10 < BlueMatt> meh 14:10 * Luke-Jr wishes there was somewhere better to move 14:10 < morcos> whats the meh 14:10 < BlueMatt> that doesnt help if your mempool never fills enough to get medium-fee txn 14:10 < BlueMatt> so that you can set the mempool fee 14:10 < BlueMatt> but, yes, we should also have that 14:11 < BlueMatt> maybe we should revisit segwit having explicit fees 14:11 < morcos> whose mempool never fills enough 14:11 < BlueMatt> mempools do take a while to fill reasonably 14:11 < BlueMatt> because people dont rebroadcast "real" txn 14:11 < BlueMatt> just the spam keeps flowing around 14:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] 14:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 14:13 < 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 14:13 < Luke-Jr> [22:11:37] because people dont rebroadcast "real" txn <-- ⁇ 14:13 < morcos> but during that decay, you are inved spam, and rereuest it b/c your reject filter is reset 14:13 < morcos> feefilter fixes that 14:13 < BlueMatt> Luke-Jr: i mean because it gets mined, so they dont have to :p 14:14 < BlueMatt> morcos: yes, both are required, is my point 14:14 < morcos> sorry, what's the both? 14:14 < morcos> you mean dynamic mempool fee? 14:14 < morcos> of course 14:14 < BlueMatt> both mempool sync and feefilter 14:14 < morcos> oh sync 14:15 < BlueMatt> ofc sync is hard to do in a privacy-preserving manner, etc, etc 14:15 < BlueMatt> we need to redo txn flow completely, really 14:15 < BlueMatt> to preserve privacy 14:15 < morcos> yeah, i'm not sure what i think about sync. 14:15 < morcos> yeah well did you read the privacy concerns around 7521 14:15 < morcos> its pretty bad 14:16 < BlueMatt> do we really still do that? 14:16 < BlueMatt> wow 14:16 < 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 14:16 < morcos> not sure i heard that, why does the peer need to be fixed 14:17 < BlueMatt> same reason rotating your tor guard node regularly is shit 14:17 -!- otium_ [~otium@2a01:e35:2eeb:c00:3432:38a7:5adc:1670] has left #bitcoin-core-dev ["..."] 14:18 < 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 14:18 < BlueMatt> with the same chance at each rotation 14:18 -!- otium [~otium@2a01:e35:2eeb:c00:3432:38a7:5adc:1670] has joined #bitcoin-core-dev 14:20 < morcos> too many problems.. anyway, ok family time 14:21 < BlueMatt> yea, talk to the tor guys....everything you try here fails :( 14:27 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 14:33 < 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 14:34 < 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? 14:34 < 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. 14:35 < morcos> Of course you could add some variance to obfuscate to some degree. 14:35 < 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 14:35 < morcos> But actually even without the fee filter, a limited mempool makes it pretty easy to correlate (with a bit more work) 14:35 < BlueMatt> yea 14:36 < BlueMatt> kinda 14:45 -!- degriff [~degriff@rob76-4-82-238-176-192.fbx.proxad.net] has quit [Quit: degriff] 14:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:49 < PRab> Build finally finished. I guess it wasn't stuck, it just took a long time. 15:19 -!- otium [~otium@2a01:e35:2eeb:c00:3432:38a7:5adc:1670] has left #bitcoin-core-dev ["..."] 15:20 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 272 seconds] 15:20 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 256 seconds] 15:22 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 15:27 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:31 -!- gevs [~greg@ip-81-11-223-120.dsl.scarlet.be] has joined #bitcoin-core-dev 15:31 -!- gevs [~greg@ip-81-11-223-120.dsl.scarlet.be] has quit [Changing host] 15:31 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 15:52 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 15:53 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 15:55 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:43 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 17:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 17:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 17:29 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev 17:33 -!- raedah [~raedah@172.58.33.58] has quit [Quit: Leaving] 17:44 -!- raedah [~raedah@172.58.32.152] has joined #bitcoin-core-dev 18:06 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 240 seconds] 18:08 -!- raedah [~raedah@172.58.32.152] has quit [Remote host closed the connection] 18:19 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection] 18:23 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 18:26 -!- raedah [~raedah@172.58.32.152] has joined #bitcoin-core-dev 19:10 -!- raedah [~raedah@172.58.32.152] has quit [Ping timeout: 276 seconds] 19:23 -!- raedah [~raedah@172.58.32.152] has joined #bitcoin-core-dev 19:30 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer] 19:31 < cfields> gitian builders: rc5 detached sigs are pushed. fingers crossed that i got the right versions of everything signed. but they won't run if not, so we'll know :) 19:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xwtfubermsxzlupv] has quit [Quit: Connection closed for inactivity] 19:46 < btcdrak> cfields: you can finally get some sleep! 19:49 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 20:18 < warren> openssl.org "NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES ONLY ARE BEING APPLIED." 20:23 -!- p15x [~p15x@72.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 20:32 -!- jtimon [~quassel@46.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 20:33 < jtimon> https://github.com/bitcoin/bitcoin/pull/7310#issuecomment-183796688 20:51 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 21:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has quit [Read error: Connection reset by peer] 21:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has joined #bitcoin-core-dev 21:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:52 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer] 21:54 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 22:02 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has quit [Read error: Connection reset by peer] 22:03 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev 22:25 < Luke-Jr> I think I'm giving up on CPFP for 0.12, not worth it 22:37 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer] 22:39 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 22:39 -!- otium [~otium@2a01:e35:2eeb:c00:4867:2aef:a7bd:d391] has joined #bitcoin-core-dev 23:18 -!- murch [~murch@p4FE3A8C5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 23:48 -!- Aiden_Khaal [~Aiden@247-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]