--- Day changed Tue Nov 17 2015
00:07 < jonasschnelli> sipa: BlueMatt: i'll go see him when i'm in .ch (assuming he doesn't hate my face)  <--- Hah. The question is, if you don't hate my face after bothering your with tons of wallet/main.cpp questions. :)
00:08 < jonasschnelli> sipa: I would be in Zurich next Tuesday 24., if you want to sign my key
00:13 < btcdrak> I see wumpus has been untruncated thankfully :-P 
00:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:38 -!- MarcoFalke [c3523fc5@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.197] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
01:02 -!- guest234234 [~guest2342@171.5.156.180] has joined #bitcoin-core-dev
01:14 -!- MarcoFalke [8af60236@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.54] has joined #bitcoin-core-dev
01:15 -!- guest234234 [~guest2342@171.5.156.180] has quit [Read error: Connection reset by peer]
01:32 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
01:39 -!- MarcoFalke [8af60236@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.54] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
01:40 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
01:43 -!- tulip [~tulip@128.199.135.43] has quit []
01:56 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:58 < CodeShark> The usual procedure for BIP proposals is to discuss on mailing list first. But given that at least a few important reviewers/critics either have unsubscribed to the ML entirely or else just ignore it, should we discuss it here or in bitcoin-dev?
02:01 < wumpus> well definitely not here, this channel is just for bitcoin core related programming work. The proper answer to your question is stil 'the mailing list'. #bitcoin-dev is fine, but IRC discussion tends to be more ephermal than mailing lists
02:01 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
02:01 < wumpus> (or #bitcoin-wizards if it is moonmath related :-) )
02:05 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
02:05 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
02:05 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit]
02:10 < wumpus> btcdrak: tends to happen when I get disconnected from the IRC server, the client will automatically butcher my name when it is already used
02:10 < btcdrak> wumpus: it have us all a giggle yesterday :)
02:10 < btcdrak> I was going to suggest we all truncate in solidarity!
02:10 < btcdrak> :)
02:12 < wumpus> lol :)
02:20 < wumpus> gmaxwell: re: valgrind tests, what version of libevent are you using?
02:21 < wumpus> please use an up-to-date version of libevent, I know for fact a few (minor) memory leaks have been fixed over time
02:23 < wumpus> (it's very possible that there is an actual leak caused by our code, but to avoid getting stuck in unnecessary rabbit holes I'd like to rule out issues that were already fixed years ago :-) )
02:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]
02:34 -!- Anduck [~anduck@unaffiliated/anduck] has quit [Ping timeout: 260 seconds]
02:35 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
02:49 < btcdrak> who maintains the Ubuntu ppa packages for bitcoin? there are issues being reported https://www.reddit.com/r/Bitcoin/comments/3t04fp/psa_please_upgrade_to_bitcoin_core_0112_to/cx33vpw?context=3
02:51 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev
02:52 -!- tulip [~tulip@128.199.135.43] has quit []
03:00 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:04 < sipa_> btcdrak: BlueMatt 
03:04 -!- sipa_ is now known as sipa
03:04 < btcdrak> hi
03:05 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
03:08 < BlueMatt> btcdrak: huh? ubuntu 11.04???
03:09 < BlueMatt> 11.04 has been fully deprecated since 2013?!
03:12 < wumpus> right - 11.04 is not a LTS release
03:12 < wumpus> they should upgrade to 12.04, at the least
03:33 -!- guest234234 [~guest2342@171.5.156.180] has joined #bitcoin-core-dev
03:42 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.]
03:45 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev
03:46 -!- rav3n_pl [~rav3n_pl@91.235.254.37] has joined #bitcoin-core-dev
03:48 < rav3n_pl> hello. im looking to simple way to check for double spends of unconfirmed transaction. ive found bitcoinXT that return some info on "gettransaction" rpc, but it can be used only for in-wallet transactions. is there a way, to check it for non-wallet transactions?
03:51 < rav3n_pl> i can parse mempool transactions, but trying to avoid it
03:54 < phantomcircuit> rav3n_pl, that's impossible
03:55 < rav3n_pl> :/ bad
03:55 < phantomcircuit> rav3n_pl, also you're way offtopic
03:55 < rav3n_pl> :D
03:55 < rav3n_pl> sorry
03:55 < rav3n_pl> not found anythin closer in channel list
03:55 < wumpus> #bitcoin please
03:56 < rav3n_pl> okay, ty
04:44 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
04:48 -!- ParadoxSpiral [~ParadoxSp@p508B9730.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
04:49 -!- rav3n_pl is now known as rav3n_pl_away
04:52 -!- ParadoxSpiral [~ParadoxSp@p508B9730.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
04:56 -!- Guest96832 is now known as pigeons
05:03 -!- MarcoFalke [8af60236@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.54] has joined #bitcoin-core-dev
05:09 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.]
05:12 -!- Anduck [~anduck@unaffiliated/anduck] has quit [Ping timeout: 260 seconds]
05:13 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
05:15 -!- ParadoxSpiral [~ParadoxSp@p508B9730.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:17 < jtimon> what I was supposed to do with "undefined reference to `secp256k1_ecdsa_sign_recoverable'", git clean -f and make clean didn't do it...
05:18 < phantomcircuit> jtimon, git clean -fdx
05:19 < jtimon> phantomcircuit: thanks
05:22 -!- MarcoFalke [8af60236@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.54] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
05:31 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev
05:42 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
05:42 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
05:42 -!- Arnavion3 is now known as AtashiCon
05:44 -!- murr4y [murray@kvikshaug.no] has quit [Ping timeout: 240 seconds]
05:48 -!- murr4y [murray@kvikshaug.no] has joined #bitcoin-core-dev
05:49 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
05:50 < fanquake> Do you still need to pass —with-gui=qt5 to configure to get a qt5 build, or do we change it to default to qt5 when available?
05:59 < jtimon> andytoshi: from what we talked previously, I think you like #6907
06:00 < wumpus> fanquake: no longer necessary to provide that
06:00 < wumpus> if you have qt4 and qt5 development headers installed it will now default to qt5
06:03 < fanquake> wumpus nice; thought I'd seen a pull to change it. Good that we've made that change.
06:03 < jtimon> fanquake: wumpus: maybe something for the release notes?
06:05 < sipa> jtimon: the releases use qt5 for a while already, this only applies to people building from scratch, i think
06:08 -!- GAit [~GAit@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: Leaving.]
06:08 < wumpus> jtimon: there's already so many "notable changes" for 0.12 that I doubt this one will make the cut - it'll be in the long list of pulls/commits anyway
06:08 < wumpus> sipa: right
06:09 < jtimon> sipa: wumpus fair enough
06:11 < fanquake> You use [skip-ci] in the body of a pull to skip travis right?
06:12 < wumpus> yes, that should be possible
06:12 < wumpus> (I'm not sure what the exact incantation is)
06:15 < GitHub159> [bitcoin] fanquake opened pull request #7040: [doc] Update OS X build notes for new qt5 configure (master...patch-4) https://github.com/bitcoin/bitcoin/pull/7040
06:23 < GitHub45> [bitcoin] fanquake opened pull request #7041: [doc][trivial] Update OS X install instructions (master...patch-5) https://github.com/bitcoin/bitcoin/pull/7041
07:03 -!- guest234234 [~guest2342@171.5.156.180] has quit [Ping timeout: 252 seconds]
07:09 < GitHub64> [bitcoin] fanquake opened pull request #7042: [doc] Update Debian watch & control (master...update-debian) https://github.com/bitcoin/bitcoin/pull/7042
07:13 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:13 -!- Anduck [~anduck@unaffiliated/anduck] has quit [Remote host closed the connection]
07:30 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:33 -!- go1111111 [~go1111111@104.200.154.41] has quit [Ping timeout: 250 seconds]
07:36 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
07:38 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
07:38 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
07:38 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
07:58 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
08:00 < sdaftuar> sipa: wumpus: any thoughts on 7020?  morcos and i both have pulls that change the CTxMemPoolEntry constructor which causes a lot of work updating unit tests.
08:01 < sdaftuar> if 7020 is likely to go in i can rebase #6915 on it though
08:02 < sdaftuar> (it needs to be rebased anyway)
08:06 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
08:06 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
08:07 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:15 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
08:19 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Quit: Leaving.]
08:22 < Luke-Jr> gmaxwell: I can rebase it easily, but I wonder if I should try to get master to actually build first :/
08:28 < Luke-Jr> looks like I had to manually re-configure. more build system issues, sigh
08:42 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]
08:42 < MarcoFalke> Trying to set up gitian in fedora. What should I do when ./bin/gbuild asks  for a password for ubuntu@localhost?
08:42 < MarcoFalke> wumpus ?
08:42 < sipa> MarcoFalke: try 'ubuntu'
08:43 < wumpus> with lxc? you could add a sudoers rule that allows 'lxc-start' without password, there's an example in doc/gitian-building.md
08:43 < MarcoFalke> nice
08:44 < MarcoFalke> Why would I need to type the password 'ubuntu' five times? I tried it up to three times and assumed it failed because there was no response.
08:44 < MarcoFalke> Anyway, why isn't it using the keys I created?
08:45 < MarcoFalke> I am using kvm
08:45 < wumpus> with kvm it shouldn't be asking passwords at all, kvm sandboxes can be run as unprivileged users, IIRC you only need a few root commands to make the VM in make-base-vm
08:46 < wumpus> but not on gbuild, gbuild asking passwords is absolutely wrong
08:46 < MarcoFalke> make-base-vm asked for my password on the fedora machine
08:46 < wumpus> yes, that's normal
08:47 < wumpus> if gbuild asks for a password *inside* the image there's certainly something wrong with it
08:47 < wumpus> what vmbuilder version did you use?
08:48 < MarcoFalke> 0.12.4
08:49 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:49 < wumpus> installed from source or from a package?
08:50 < MarcoFalke> wget http://archive.ubuntu.com/ubuntu/pool/universe/v/vm-builder/vm-builder_0.12.4+bzr494.orig.tar.gz
08:50 < MarcoFalke> Now it's asking for root@localhost password
08:50 < wumpus> ok, shouldn't be anything wrong with that
08:50 < wumpus> not sure what causes your issues then
08:53 < wumpus> but my guess is that something went wrong while building the image
08:55 < MarcoFalke> The var/id_dsa key is supposed to be used by the ubuntu@localhost user?
08:58 < GitHub86> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eac53ec99201...e8df8a5077df
08:58 < GitHub86> bitcoin/master e587bc3 Alex Morcos: Implement helper class for CTxMemPoolEntry constructor...
08:58 < GitHub86> bitcoin/master e8df8a5 Wladimir J. van der Laan: Merge pull request #7020...
08:58 < GitHub93> [bitcoin] laanwj closed pull request #7020: Implement helper class for CTxMemPoolEntry constructor (master...EntryHelper) https://github.com/bitcoin/bitcoin/pull/7020
09:00 < wumpus> yes, those keys are passed into vmbuilder
09:00 < wumpus> I think they are supposed to be installed inside the VM for both the root and ubuntu user
09:01 < wumpus> --ssh-key=var/id_dsa.pub --ssh-user-key=var/id_dsa.pub
09:03 < morcos> thanks wumpus!
09:11 < MarcoFalke> Trying with precise, now.
09:22 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
09:25 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has joined #bitcoin-core-dev
09:51 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-ycavaifvoqdrsxim] has quit [Ping timeout: 240 seconds]
09:53 -!- MarcoFalke [8af6027e@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.126] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
09:53 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-estmhssftbtzwzlu] has quit [Read error: Connection reset by peer]
09:55 -!- zmanian_ [uid113594@gateway/web/irccloud.com/x-hajqnxerbyvtyssb] has quit [Ping timeout: 250 seconds]
09:59 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]
10:00 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
10:05 -!- d4de [~d4de@41.234.213.218] has quit [Remote host closed the connection]
10:06 -!- zooko [~user@50.246.213.169] has joined #bitcoin-core-dev
10:13 -!- rav3n_pl_away is now known as rav3n_pl
10:43 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 250 seconds]
10:51 < gmaxwell> wumpus: I'll repro on something very new (though this particular system isn't an old one); mostly making sure that it wasn't known and harmless.
11:04 -!- zooko [~user@50.246.213.169] has quit [Ping timeout: 240 seconds]
11:11 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-nhhpsseihgioqkpd] has joined #bitcoin-core-dev
11:15 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-nimlgqombgnllegr] has joined #bitcoin-core-dev
11:17 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev
11:39 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has joined #bitcoin-core-dev
11:40 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-tktxznjpsgfjzthy] has joined #bitcoin-core-dev
11:44 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]
11:51 < GitHub126> [bitcoin] instagibbs opened pull request #7044: RPC: Added additional config option for multiple RPC users. (master...multrpc) https://github.com/bitcoin/bitcoin/pull/7044
12:02 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
12:21 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has quit [Ping timeout: 250 seconds]
12:38 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
12:53 < GitHub121> [bitcoin] luke-jr opened pull request #7045: Bugfix: Use unique autostart filenames on Linux for testnet/regtest (master...linux_autostart_unique) https://github.com/bitcoin/bitcoin/pull/7045
12:53 -!- zooko [~user@2601:281:8001:26aa:8874:a77d:6fe6:611e] has joined #bitcoin-core-dev
13:02 -!- moli [~molly@unaffiliated/molly] has quit [Quit: //..//..]
13:02 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
13:08 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
13:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:21 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
13:30 < Luke-Jr> I wonder if #6978 (qt -fPIC stuff) should be backported?
13:32 -!- SatoshisCat [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
13:32 -!- MarcoFalke [c3523fc5@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.197] has joined #bitcoin-core-dev
13:37 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
13:47 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
13:51 < GitHub102> [bitcoin] pstratem opened pull request #7046: [WIP] Net: Ignore "tx" messages in blocks only mode. (master...2015-11-17-blocksonly) https://github.com/bitcoin/bitcoin/pull/7046
13:58 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:00 < phantomcircuit> gmaxwell, oops i just realized i messed up the whitelistalways stuff
14:00  * phantomcircuit goes to fix
14:01 < phantomcircuit> (it technically works but it drops the inv so the whitelisted peer has to actually push the tx blindly)
14:01 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:02 < phantomcircuit> sipa, i end up calculating bool fAcceptTxs, is that something you would see being in CNodeState? (currently it's constant during runtime)
14:03 < phantomcircuit> (unless you can remove the whitelist flag at runtime, can you?)
14:03 < sipa> no, whitelist won't change at runtime
14:05 < phantomcircuit> BlueMatt, can i disable the mempool by limiting the size to 0?
14:05 < phantomcircuit> morcos, same question^
14:06 < BlueMatt> i think you have to set it to some big number
14:06 < BlueMatt> but i dont recall now
14:06 < phantomcircuit> although i guess if im going to be relaying whitelisted peers transactions i might as well also be keeping them in the mempool
14:06 < phantomcircuit> gmaxwell, any opinion there?
14:06 < sipa> BlueMatt: he means disabling the mempool, not disabling limiting :)
14:06 < morcos> phantomcircuit: also don't recall, sorry
14:06 < morcos> oh
14:07 < phantomcircuit> yes
14:08 < tulip> Leaving block file 375: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
14:08 < morcos> yikes, it looks like you can't because of bad interaction with descendantlimit
14:08 < phantomcircuit> so blocksonly=1 whitelistalwaysrelay=1 should the node be adding the transaction to it's mempool or just blindly passing it to every peer
14:09 < sipa> tulip: oh, i think that's harmless
14:09 < morcos> BlueMatt: do you think it should be completely prohibited from violating the desired ratio, or just warn
14:10 < BlueMatt> phantomcircuit: I assume you'll break things if you do, but it should disable mempool, yes
14:10 < BlueMatt> oh, yea, what morcos said
14:10 < phantomcircuit> BlueMatt, im not sure what i'd break doing that though since it's already relaying whitelisted peers transactions even if they're rejected from the mempool entirely
14:10 < BlueMatt> morcos: hmm? which ratio?
14:11 < morcos> BlueMatt: if you look at 6557, i implemented that check differently, so the descendentsizelimit is automatically maxed at the right ratio of your mempool size unless you explicitly set it
14:11 < BlueMatt> phantomcircuit: mostly "there be dragons" (of unspecified type)
14:11 < tulip> sipa:  nothing seems to be on fire otherwise. is it caused by something broken in my local state, or a recent change in master? 
14:11 < morcos> that might be a better parameter interaction
14:12 < BlueMatt> morcos: sorry, I've been behind on bitcoin core...people were starting to notice the relay network had been broken for a long time so i figured i needed to fix it
14:12 < morcos> BlueMatt: you return error if the mempool is less than 40 * the descendant size limit.  i'm saying if the descendant size limit isn't set, you should just silently cap it at 1/40 of mempool.  and if it is explicitly set, let any two values go, evne if lmiting will be adversely affected
14:13 < michagogo> 16:11:00 <fanquake> You use [skip-ci] in the body of a pull to skip travis right?
14:13 < morcos> 6557 was just our version of the limiting pull, its closed now, i'm just pointing out a different way to do the parameter interaction
14:13 < michagogo> I think it's [skip ci] or [ci skip], both work
14:13 < michagogo> I don't know if - works
14:13 < sipa> tulip: i believe it's due to a recent change in master
14:13 < michagogo> And I think it's the commit message, though I'm not sure about that
14:14 < phantomcircuit> BlueMatt, hmm well then i'll have to muck about with the "tx" ProcessMessage logic a lot more than i wanted to
14:14 < phantomcircuit> would anybody be opposed to moving it to it's own function?
14:14 < phantomcircuit> (indeed most of the logic in ProcessMessage would do well in it's own function)
14:16 < morcos> phantomcircuit: ha ha, sdaftuar and i would LOVE that.  its the most annoying part of our historical data simulator right now
14:18 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
14:18 < phantomcircuit> is anybody going to kill me if i submit a pr that moves each of the message handling routines into it's own function?
14:18 < phantomcircuit> speak now or yell at me later
14:19 < BlueMatt> morcos: hmm...I'm inclined to say leave it as is...I prefer the documented parameters to just refuse to run if it's gonna end up doing something dumb (people will shoot themselves in the foot if you let them
14:19 < BlueMatt> phantomcircuit: please god do
14:20 < BlueMatt> morcos: i wouldnt complain loudly if it was changed, but its not like the limit enforced now is crazy
14:20 < phantomcircuit> bool static ProcessVersionMessage(CNode* pfrom, CDataStream& vRecv, int64_t nTimeReceived) EXCLUSIVE_LOCKS_REQUIRED(cs_main)
14:20 < phantomcircuit> etc
14:22 < phantomcircuit> hmm need strCommand too
14:23 < tulip> sipa: thanks.
14:24  * BlueMatt -> lunch
14:24 < sipa> phantomcircuit: i've argued against that before, because it will conflict with pretty much every PR there is
14:24 < sipa> phantomcircuit: though that was under the assumption that some decent modularization of msg handling would happen instead, and so far, it hasn't
14:25 < phantomcircuit> sipa, it probably will, and it probably always will
14:25 < sipa> yes, but moving things now, and then doing clean modularization later means it breaks everything twice :)
14:25 < sipa> for the same benefit
14:26 -!- sdaftuar_ [~sdaftuar@139.sub-70-199-111.myvzw.com] has joined #bitcoin-core-dev
14:26 < phantomcircuit> sipa, it'll at least be easier to modularize once it's "cleaned" up a bit
14:26 < sipa> hardly, i think
14:27 < phantomcircuit> sipa, when you say modularization you're referring to having a ping module etc
14:27 < phantomcircuit> right?
14:29 < sipa> yes
14:29 -!- sdaftuar_ [~sdaftuar@139.sub-70-199-111.myvzw.com] has quit [Client Quit]
14:31 < phantomcircuit> sipa, i would be worried about such a system being too complicated
14:31 < phantomcircuit> the basic protocol is really very simple
14:31 < phantomcircuit> the only complexity is in scheduling block download really
14:32 < phantomcircuit> (which i assume is part of your interest in doing that?)
14:37 -!- devpo [af6e7a0f@gateway/web/freenode/ip.175.110.122.15] has joined #bitcoin-core-dev
14:37 < devpo> hi is anybdy here to help me a little
14:37 < devpo> ?
14:38 < devpo> :'(
14:39 < btcdrak> devpo: what's up?
14:41 < devpo> i need a php script
14:41 < btcdrak> better move to #bitcoin
14:41 < devpo> ok
14:42 -!- devpo [af6e7a0f@gateway/web/freenode/ip.175.110.122.15] has quit [Client Quit]
14:45 < sipa> phantomcircuit: no, my interest is allowing the message handler to run in multiple threads
14:46 < sipa> (and making things cleaner in the process)
14:48 < phantomcircuit> sipa, assuming things are holding the correct locks i dont see why we cant do that now
14:48 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
14:48 < sipa> phantomcircuit: the problem is that it isn't clear what those locks are
14:49 < sipa> if all handler ran in their own module, with their own state, with their own encapsulated lock, it would be trivially correct
14:50 < sipa> anyway, no big objection if you want to move code out of processblock into smaller functions, but not everything at once...
14:50 < phantomcircuit> sipa, it would work today with very if any problems because of cs_vRecvMsg/cs_vSend
14:50 < phantomcircuit> (assuming for a second that there's nothing in SendMessages looking at vRecvMsg
14:51 < phantomcircuit> )
14:51 < sipa> you can't do that now
14:51 < sipa> all shared handler state is locked by cs_main
14:51 < phantomcircuit> it doesn't get you much of anything though since virtually everything they're doing that's cpu intensive requires cs_main
14:51 < sipa> yes
14:52 < sipa> but many of those cs_main only protect handler state, and not consensus/block related structures
14:52 < sipa> those need to be replaced by their own handler-spoecific locks
14:53 < phantomcircuit> what would be an appropriate DoS level for a peer that's sending transactions despite fRelayTxs=false (keeping in mind fRelayTxs will be true for whitelisted peers)
14:53 -!- d_t [~textual@204.28.124.82] has joined #bitcoin-core-dev
14:54 < phantomcircuit> (and it's sending a protocol version high enough to support fRelayTxs in version)
14:55 < gmaxwell> phantomcircuit: I think we shouldn't DOS now.
14:55 < gmaxwell> not without studying more what it'll do. I know BTCD in the past wanted the protocol to define sending unsolicited transactions as misbehavior.
14:56 < tulip> phantomcircuit: a least one piece of SPV wallet software pushes all of their transactions directly without inv'ing them. 
15:00 < gmaxwell> perhaps in the blocks only context is a fine way to introduce that behavior, but I think we shouldn't rush into it.
15:00 < gmaxwell> We can try asking davec if he has any insight into observed behavior.
15:01 < gmaxwell> phantomcircuit: One thing you could do is log when a non-whitelisted peer sends a tx message in blocksonly mode.
15:11 < phantomcircuit> gmaxwell, is it important that GetMainSignals().Inventory(inv.hash); runs regardless of whether we call pfrom->AskFor(inv); or not?
15:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:11 < phantomcircuit> (if so it needs to be moved)
15:12 < gmaxwell> phantomcircuit: my belief was no, if we're not relaying we don't care what others have relayed to us.
15:13 < gmaxwell> (and in particular, we don't want to know: just another way for a peer to use our memory)
15:13 < phantomcircuit> the version in master actually does call GetMainSignals().Inventory(inv.hash); even if we dont ask anybody for the data
15:13 < phantomcircuit> yeah that's what i thought
15:27 < phantomcircuit> im afraid to ask but, GetBoolArg has it's own locks... right?
15:27 < sipa> phantomcircuit: no, but mapArgs etc are immutable :)
15:28 < sipa> (apart from initialization which happens single-threadedly)
15:28 < phantomcircuit> sipa, so... practically safe but technically a threading violation
15:28 < sipa> phantomcircuit: no, no threading violation
15:28 < sipa> reading data that can't change is safe
15:30 < gmaxwell> phantomcircuit: the memory model is that shared reading is okay, but as soon as there is a potential write (even of the same data) then there must be locks that exclude all other readers and writers.
15:32 < gmaxwell> as the complier is allowed to do things like "oh I can see in this block I will, for sure, overwrite location X.. that means I have exclusive access.. so until then I can spill random registers into it."
15:32 -!- MarcoFalke [c3523fc5@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.197] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
15:37 -!- ParadoxSpiral [~ParadoxSp@p508B9730.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
15:41 < phantomcircuit> gmaxwell, ah right
15:45 -!- zooko [~user@2601:281:8001:26aa:8874:a77d:6fe6:611e] has quit [Ping timeout: 246 seconds]
15:46 < phantomcircuit> gmaxwell, pr updated
15:47 < phantomcircuit> only thing im not happy with is that it's not obvious why transactions dont end up in the orphan pool
15:50 < gmaxwell> phantomcircuit: you should improve your commit messages some;  e.g. https://github.com/pstratem/bitcoin/commit/17e6157c1975a4f5e0afa97d632ca0310b227158  should explain that previously if we recieved an unsolicited TX message (which we shouldn't) we'd process it anyways, even in blocks only mode.
15:50 -!- SatoshisCat [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
15:51 < davec> Regarding the DoS banning, in general I've never seen much point in allowing protocol level misbehavior.  It's TCP, so if the peer isn't following the protocol, they should be disconnected with prejudice.
15:52 < phantomcircuit> gmaxwell, can do
15:52 < phantomcircuit> er is there an easy way to edit an arbitrary commit message?
15:53 < sipa> git commit --amend
15:53 < davec> git commit --amend   for the top commit
15:53 < davec> if it's further back, git rebase -i
15:53 < davec> and use 'r'
15:56 < phantomcircuit> oh rebase e
15:56 < phantomcircuit> r*
15:56 < phantomcircuit> that's nice
15:56 < tulip> davec: in 0.8.x nodes were banned for their own internal misbehaviour which was distinctly non-optimal. it's good to be strict, but there's definitely some risk to it. 
15:57 < sipa> davec, tulip: i don't think the question is whether we should allow protocol misbehaviour (imho, we shouldn't), but what is considered misbehaviour :)
16:00 < gmaxwell> I think davec's comment was about the difference between disconnect instantly vs the score?  I don't think the score has much use, but most of the reason we bother disconnecting is to avoid resource wasting attacks, and a little bit of vioation is fine on those terms. ... and handwave handwave, maybe the network is a bit more robust if its a little tolerant there.  I'm skeptical.
16:01 < davec> indeed.  We're extremely strict in btcd.  For example, if you claim to be a protocol version after the nonce was added to ping/pong, but you don't include them, you aren't following the protocol, so you get disconnected, etc
16:02 < gmaxwell> Thats good feedback.
16:02 < davec> unless things have changed recently that I missed, core doesn't care
16:02 < gmaxwell> davec: do you disconnect on unsolicited TX messages (no getdata first?)
16:02 < davec> we used to, but BitcoinJ didn't work, so we allow them now
16:04 < phantomcircuit> gmaxwell, hmm that's kind of nasty the only way to relay a transaction is to place it into the mempool
16:05 < davec> Another thing we added which I don't believe core does is maximums for every protocol message type
16:05 < gmaxwell> phantomcircuit: Thats fine, we'll only allow whitelisted peers to do that.
16:05 < davec> so like a transaction can't possibly be < x or > y so it's disallowed
16:06 < phantomcircuit> gmaxwell, could soft change mempoolexpirey to 1 so at least they're thrown away rapidly
16:06 < phantomcircuit> or not
16:06 < gmaxwell> phantomcircuit: nah, I don't see a reason to.
16:06 < gmaxwell> they'll only come in from whitelisted peers. Don't whitelist (and allow relay for them) stuff you don't want adding things to your mempool.
16:07 < phantomcircuit> ok comments added and that commit removed
16:07 < gmaxwell> phantomcircuit: I understood this completely and was comfortable with it before merging your prior code, FWIW!
16:09 < phantomcircuit> gmaxwell, heh
16:09 < gmaxwell> davec: any idea if bitcoinj still sends unsolicited transactions if its connected to something that has set the relay flag to false? 
16:09 < phantomcircuit> yes i tried to "fix" something which after thinking about it more is basically not fixable unless you're willing to push the tx messages instead of inv
16:10 < phantomcircuit> which isn't very nice
16:14 < gmaxwell> phantomcircuit: your first commit is changing too much of the logic, e.g. bypassing nSendsize check.
16:15 < phantomcircuit> gmaxwell, the nSendSize check still runs if we do something that could change it
16:17 < gmaxwell> phantomcircuit: right now. Creates non-local action; I'd prefer you just make the minimial change and then elseif the other reasons, and emit the log entry.
16:18 < phantomcircuit> ok
16:20 < davec> gmaxwell: I don't watch it's dev to know if it has changed, but back when we were getting them to work together the answer is yes.  It always sent unsolicited txns regardless.
16:20 < davec> its*
16:20 < gmaxwell> davec: thanks. Yea, thats all I needed to know (expected the answer too)
16:20 < davec> I believe the reasoning was that if it authored the transaction they are 100% sure you don't have it, so no point in the round trip
16:21 < davec> except it did it for more than that case
16:21 < sipa> that's only true when relaying to just a single peer
16:21 < gmaxwell> also only true if you'd never relay a third party txn and don't care about privacy at all. 
16:22 < davec> I agree, but that was the reasoning provided when we asked about it
16:23 < davec> at any rate, we either had to loosen up and allow them or not work with BitcoinJ, so we chose to interop
16:23 < tulip> I didn't think btcd implemented BIP37 anyway? 
16:24 < gmaxwell> davec: sure, I'll see if I can convince the new maintership to change.
16:24 < davec> it does
16:24 < davec> We allow it to be disabled via --nobloom, but it fully supports it
16:24 < tulip> ok, crossed wires. 
16:24 < dcousens> gmaxwell: to change [it]
16:24 < gmaxwell> Even if it doesn't ... we may start kicking when fRelay is off-- because it's in their interest if they're relaying to us and we're just going to drop it.
16:25 < dcousens> :P
16:28 < davec> oh, if it's of any interest to you, we do d/c on unsolicited blocks and have not seen anything that doesn't follow the inv/getdata model there
16:29 < sipa> ah, that is good to know!
16:32 < tulip> I don't think the relaynode software sends inv for blocks either, I'll have to check though. 
16:33 < tulip> that looks right. 
16:35 < phantomcircuit> gmaxwell, i can do it as if(inv.type != MSG_BLOCK) {if (fBlocksOnly) Log() else if (!fAlreadyHave && !fImporting && !fReindex) AskFor();}
16:35 < phantomcircuit> i think that's the cleanest change
16:36 < phantomcircuit> without it being slightly insane
16:36 < davec> tulip: hmmm I don't recall seeing any of them hit that, but I can comb back through the logs.  We might have to change that as well.
16:38 < davec> Although it seems pretty wasteful to send a full block only to have it ignored by the other end because they already have it or have already reusted it from another peer and its in-flight, etc
16:39 < gmaxwell> phantomcircuit: I think you can do it clear, take existing code, add the whitelist. Then add an else that checks everything except the whitelist and the blocks only)
16:39 < gmaxwell> tulip: relaynetwork client purposefully does not, but it's local.
16:39 < tulip> davec: the relaynode software is only meant to communicate with local nodes anyway. 
16:40 < GitHub144> [bitcoin] luke-jr opened pull request #7047: [WIP] Backports for 0.11.3 (updated to e8df8a5) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7047
16:42 < davec> tulpi: Oh, right.  I thought you were talking about the relay network (which I know does things quite a bit differently)
16:42 < sipa> davec: he is, i think
16:43 < tulip> davec: we're talking about the same thing, just different name 
16:43 < gmaxwell> he's talking about the relay network client local gateway.
16:44 < gmaxwell> As far as I know the normal relay network bitcoin nodes do nothing special on the bitcoin p2p protocol.
16:45 < davec> Yeah that makes sense.  I would say that's probably a case for whitelisted nodes accepting them but not allowing random unknown p2p nodes to do it
16:45 < phantomcircuit> gmaxwell, like this? 
16:45 < phantomcircuit> https://gist.github.com/pstratem/a8bc031b959cd2225ef1
16:46 < phantomcircuit> that definitely does what we want but... well it's the kind of thing im going to see in six months and go "what idiot did this! oh right me"
16:47 < gmaxwell> phantomcircuit: you can reorg the branches to eliminate the duplication  but be functionally equal then.
16:48 < gmaxwell> also why are you keeping up with the fBlocks only flag. If its only getting used once, no need to make a new flag.
16:48 < davec> or even from local conns
16:49 < phantomcircuit> gmaxwell, without it as a flag the expression is insanely difficult to understand
16:52 < phantomcircuit> gmaxwell, to be pedantic fRelayTxes literally only prevents transactions from being relayed, so if we were to add a new inv type in the future that isn't MSG_BLOCK this logic would be wrong
16:53 < phantomcircuit> it would still do the right thing except for the logging
16:54 < davec> iirc there is already a MSG_FILTERED_BLOCK too
16:55 < phantomcircuit> davec, yeah but that's not relevant for "inv"
16:55 < sipa> davec: only in getdata, not in iv
16:57 < GitHub150> [bitcoin] fanquake opened pull request #7048: [doc][trivial] Update miniupnpc version in build-unix (master...miniupnpc-build-unix) https://github.com/bitcoin/bitcoin/pull/7048
16:57 < phantomcircuit> gmaxwell, oh and using the flag in "inv" prevents calling GetBoolArg in a potentially tight loop
16:58 < gmaxwell> phantomcircuit: K leave the flag but ditch the continue.
16:58 < davec> sipa/phantomcircuit: right.  thanks -- been a while since I looked so forgot the particulars there
16:58 < phantomcircuit> gmaxwell, done
17:10 -!- zooko [~user@2601:281:8001:26aa:8874:a77d:6fe6:611e] has joined #bitcoin-core-dev
17:23 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
17:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aebyobfgbxedgxua] has quit [Quit: Connection closed for inactivity]
17:52 -!- Guest16267 [~s1w@2400:6180:0:d0::4e1:5001] has quit [Changing host]
17:52 -!- Guest16267 [~s1w@unaffiliated/someoneweird] has joined #bitcoin-core-dev
17:52 -!- Guest16267 is now known as s1w
18:06 < dcousens> gmaxwell: maybe I should clarify, my NACK on that was weak
18:06 < dcousens> I just didn't see a need for it except in highly custom setups which IMHO don't fit the bill for most node operators, I may be wrong though
18:07 < gmaxwell> dcousens: ya thats fine, if I sounded too eager there in responding I'm sorry; wasn't communicating well.
18:08 < dcousens> On reviewing the code, its plain enough (less than 40-50 lines), the rest is tests
18:08 < gmaxwell> Does the thought of removing the old mechenism make it more appealing to you?
18:08 < dcousens> I just saw +240 and jumped the gun 
18:09 < dcousens> and yes
18:09 < dcousens> If the alterior method is removed, then this is an easy win
18:09 < gmaxwell> whew
18:11 < gmaxwell> Okay, I confess some paranoia here-- I don't want this to be like the rpc hangs issue. Where we pigheadily avoid improvements for some silly footgun which is making people stop using bitcoin core and switch to hosted apis.
18:11 < gmaxwell> no reason to let me ramrod the feature though.
18:11 < gmaxwell> If it goes in it should be the best possible.
18:14 < dcousens> IMHO, 1 day, walletd, bitcoind, indexd.  1 day.  Probably 10 years haha
18:15 < instagibbs> it's a beautiful dream :)
18:15 < dcousens> We need some Shia to make it happen
18:16 < gmaxwell> dcousens: agreed, though we can't halt incremental progress on the way to that vision; ... we'll never get there if we lose all the users who might help support that work. :)
18:16 < dcousens> haha, indeed
18:16 < instagibbs> Oh, I was thinking "Shia Muslim" and was quite confused...
18:16 < dcousens> instagibbs: haha, I meant Laboef
18:17 < dcousens> Labouef*
18:18 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:18 < gmaxwell> #include <culturally_insentive_joke_of_some_form.h>
19:00 -!- neha [~narula@mint-square.mit.edu] has quit [Ping timeout: 240 seconds]
19:01 -!- neha [~narula@mint-square.mit.edu] has joined #bitcoin-core-dev
19:01 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 240 seconds]
19:02 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev
19:05 < morcos> sipa: that "Leaving block file" showing 0's thing.  There is no reason not to fix that right?
19:24 < morcos> nm, just did it.. :)
19:24 < GitHub85> [bitcoin] morcos opened pull request #7050: Fix debug log message for block files (master...nitfix) https://github.com/bitcoin/bitcoin/pull/7050
19:32 -!- parazyd [parazyd@gateway/shell/firrre/x-byqgwelkqeyxupry] has joined #bitcoin-core-dev
19:59 < phantomcircuit> gmaxwell, ok i've stopped updating 7046 every ten minutes
20:12 < phantomcircuit> gmaxwell, i still really do not like having Get*Arg everywhere
20:12 < phantomcircuit> but alas my brain is currently jello so im not doing that tonight
20:14 -!- Greybits [~Tongas@unaffiliated/sam--/x-573746] has joined #bitcoin-core-dev
20:23 -!- jgarzik [~jgarzik@64.196.201.2] has joined #bitcoin-core-dev
20:23 -!- jgarzik [~jgarzik@64.196.201.2] has quit [Changing host]
20:23 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
20:27 -!- guest234234 [~guest2342@171.4.234.68] has joined #bitcoin-core-dev
20:32 -!- guest234234 [~guest2342@171.4.234.68] has quit [Read error: Connection reset by peer]
20:42 -!- d_t [~textual@204.28.124.82] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:12 -!- Greybits [~Tongas@unaffiliated/sam--/x-573746] has quit [Ping timeout: 272 seconds]
21:39 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Remote host closed the connection]
21:40 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
21:40 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:51 -!- tulip [~tulip@128.199.135.43] has quit [Read error: Connection reset by peer]
21:53 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
22:07 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
22:12 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
22:22 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds]
22:23 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
23:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zumblqpiwjatdqxa] has joined #bitcoin-core-dev
23:28 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
23:29 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
23:29 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has joined #bitcoin-core-dev