--- Day changed Mon Oct 17 2016
00:00 -!- jeremias1 is now known as jeremias     
00:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
00:06 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]     
00:19 < phantomcircuit> wumpus: in trying to make more of the wallet things private i have run into a problem
00:19 < phantomcircuit> all the things which are private are called by tests
00:19 < phantomcircuit> so i cant just make them private
00:24 -!- cdecker [~quassel@2a02:aa16:1105:4a80:6545:7bd0:62a0:613f] has joined #bitcoin-core-dev     
00:24 < sipa> make them protected, and let the tests work with a subclass
00:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:29 -!- bluerazor [~bluerazor@221.176.33.135] has quit [Remote host closed the connection]     
00:29 -!- bluerazor [~bluerazor@221.176.33.135] has joined #bitcoin-core-dev     
00:43 < phantomcircuit> sipa: that is a good solution
00:46 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 252 seconds]     
00:47 -!- DigiByteDev [~JT2@69.167.31.181] has joined #bitcoin-core-dev     
00:49 -!- _mn3monic [~guido@176.9.68.68] has quit [Ping timeout: 250 seconds]     
00:53 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:53 -!- laurentmt [~Thunderbi@80.215.178.183] has joined #bitcoin-core-dev     
00:56 -!- laurentmt [~Thunderbi@80.215.178.183] has quit [Client Quit]     
01:02 -!- bluerazor [~bluerazor@221.176.33.135] has quit [Ping timeout: 244 seconds]     
01:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
01:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
01:20 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
01:20 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
01:26 -!- laurentmt [~Thunderbi@80.215.178.183] has joined #bitcoin-core-dev     
01:27 -!- laurentmt [~Thunderbi@80.215.178.183] has quit [Client Quit]     
01:29 -!- DigiByteDev [~JT2@69.167.31.181] has quit [Quit: DigiByteDev]     
01:31 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
01:44 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
02:02 < wumpus> phantomcircuit: +1 on sipa's solution
02:02 < wumpus> we do a similar thing for CAddrMan for a test interface to override the randomness
02:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:46 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev     
02:49 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
02:53 -!- DigiByteDev [~JT2@101.78.224.202] has left #bitcoin-core-dev []     
02:55 -!- ill [~ill@108.114.174.110] has joined #bitcoin-core-dev     
03:04 -!- ill [~ill@108.114.174.110] has quit [Ping timeout: 244 seconds]     
03:12 -!- laurentmt [~Thunderbi@80.215.234.141] has joined #bitcoin-core-dev     
03:12 -!- laurentmt [~Thunderbi@80.215.234.141] has quit [Client Quit]     
03:14 -!- jnewbery [~jnewbery@176.136.6.51.dyn.plus.net] has joined #bitcoin-core-dev     
03:17 -!- jnewbery [~jnewbery@176.136.6.51.dyn.plus.net] has quit [Client Quit]     
03:18 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
03:26 < wumpus> cfields_: hey, I've been trying something weird: to build bitcoin core in the 'termux' environment on my android phone. This is basically just a arm (64 bit in this case) Linux system, with one catch: there is no shell interpreter, or anything useful for that matter in /bin. All the shell utilities are available in the path though.
03:27 < wumpus> cfields_: I have no idea whether this can be realistically gotten to work though, so much assumes that /bin/sh is a shell :)
03:27 < wumpus> cfields_: not a high priority thing though building bitcoin core *on* my phone would be quite awesome
03:28 < wumpus> (I know there's debian chroots which avoid this, but that requires root and don't want to bother rooting right now)
03:39 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:03 -!- murch [~murch@p4FE383DB.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
04:13 < GitHub13> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/49c591037289...0329511b9cd6
04:13 < GitHub13> bitcoin/master 032e883 Matt Corallo: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks
04:13 < GitHub13> bitcoin/master a4ad37d Matt Corallo: [qa] Build v4 blocks in p2p-compactblocktests...
04:13 < GitHub13> bitcoin/master 0329511 Wladimir J. van der Laan: Merge #8922: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks...
04:13 < GitHub100> [bitcoin] laanwj closed pull request #8922: [qa] Send segwit-encoded blocktxn messages in p2p-compactblocks (master...segwitcb) https://github.com/bitcoin/bitcoin/pull/8922
04:26 < GitHub8> [bitcoin] sipa opened pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937
04:27 < GitHub80> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/0329511b9cd6...53133c1c041d
04:27 < GitHub80> bitcoin/master 3ade2f6 Johnson Lau: Add standard limits for P2WSH with tests
04:27 < GitHub80> bitcoin/master 4c0c25a Johnson Lau: Require compressed keys in segwit as policy and disable signing with uncompressed keys for segwit scripts
04:27 < GitHub80> bitcoin/master 9f0397a Johnson Lau: Make test framework produce lowS signatures
04:27 < GitHub23> [bitcoin] laanwj closed pull request #8499: Add several policy limits and disable uncompressed keys for segwit scripts (master...badwitnesscheck) https://github.com/bitcoin/bitcoin/pull/8499
04:30 < sipa> petertodd, cdecker, BlueMatt, luke-jr: do your dns seeds support flag filtering?
04:30 < cdecker> sipa: not yet, was intending to implement it for the longest time
04:31 < cdecker> Is there a plan to rely on it in future?
04:31 < sipa> yes, for segwit
04:31 < cdecker> Ok, then I'll invest some time to support it ^^
04:31 < sipa> cool!
04:32 < GitHub27> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/53133c1c041d...c90111314435
04:32 < GitHub27> bitcoin/master 282abd8 fanquake: [build-aux] Boost_Base serial 27
04:32 < GitHub27> bitcoin/master 6dd3723 fanquake: Set minimum required Boost to 1.47.0
04:32 < GitHub27> bitcoin/master c901113 Wladimir J. van der Laan: Merge #8920: Set minimum required Boost to 1.47.0...
04:32 < GitHub135> [bitcoin] laanwj closed pull request #8920: Set minimum required Boost to 1.47.0 (master...set-minimum-boost) https://github.com/bitcoin/bitcoin/pull/8920
04:37 < wumpus> I'm trying to cherry-pick #8499 into #8916 for backporting to 0.13, however I'm running into conflicts in the tests (p2p-segwit.py) - does anyone know if any precursor changes to the RPC tests there that are not in #8916 yet?
04:38 < wumpus> (big conflicts, not trivial one-liners)
04:40 < sipa> https://github.com/bitcoin/bitcoin/commits/master/qa/rpc-tests/p2p-segwit.py 
04:41 < wumpus> may be better to leave this backport to jl2012
04:45 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
04:48 < sipa> $ ./src/bitcoind
04:48 < sipa> Error: -daemon is not supported on this operating system
04:49 < sipa> Ubuntu 14.04.5 LTS
04:49 < wumpus> sipa: you need to clean your tree
04:49 < sipa> ah     
04:49 < sipa> thanks
04:49 < wumpus> (or at least rerun autoconf and configure)
04:50 < wumpus> https://github.com/bitcoin/bitcoin/pull/8813#issuecomment-250788185
04:51 < sipa> ah yes, i remember reading that comment
04:53 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
05:05 -!- fengling_ [~fengling@lax-us.eduvpn.net] has joined #bitcoin-core-dev     
05:08 -!- fengling_ [~fengling@lax-us.eduvpn.net] has quit [Remote host closed the connection]     
05:09 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
05:10 -!- fengling_ [~fengling@lax-us.eduvpn.net] has joined #bitcoin-core-dev     
05:11 < wumpus> never mind on #8499, I was somehow trying to backports the commit in reverse order
05:12 < wumpus> (testing a new script and all that)
05:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:18 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
05:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]     
05:21 -!- Guyver2__ is now known as Guyver2     
05:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
05:23 < jl2012> wumpus, you want me to make a backport?
05:24 < wumpus> jl2012: I was afraid so as the diff looked quite large, but it's no longer necessary
05:24 < wumpus> it's part of #8916 now
05:25 < jl2012> if it could be cleanly cherry-picked, that should be fine
05:25 < wumpus> there was only a trivial two-liner conflict in the tests
05:25 < jl2012> ok     
05:25 < achow101> Yay! 0.13.1 is almost here! #8937 needs to be added to the milestone
05:26 < jl2012> let me know if you need any action from me
05:26 < wumpus> I will, thank you
05:36 < petertodd> sipa: mine does
05:36 < sipa> petertodd: oh, i'm confused, you don't even have a mainnet seed
05:36 < petertodd> sipa: yes, my testnet seed does :)
05:38 < sipa> interesting, my seeder has 8 IPs that already report NODE_WITNESS
05:42 < petertodd> sipa: what else are they reporting? I've noticed that some nodes put total garbage in nServices
05:43 < sipa> i wad about to check, and my laptop battery died
05:43 < petertodd> ha     
05:49 < sipa> 3 of them are possibly legitimate
05:49 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev     
06:09 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Ping timeout: 250 seconds]     
06:11 < BlueMatt> sipa: no, am I supposed to do that?
06:12 < BlueMatt> sipa: oh, you mean to filter to only give segwit peers?
06:23 < sipa> yes     
06:24 < sipa> a request for xHEXFLAGS.your.dns.seed gives only peers that report said flags in their result
06:24 < BlueMatt> oh     
06:24 < BlueMatt> uhhhhh
06:24 < BlueMatt> hum     
06:25 < sipa> if supported, bitcoin core will ask for x9.your.dns.seed
06:25 < BlueMatt> that doesnt work with my dnsseed
06:25 < sipa> (NODE_NETWORK and NODE_WITNESS)
06:25 < sipa> that's fine, it doesn't have to
06:25 < BlueMatt> my seed generates a bind zonefile and schleps that off to a bunch of servers
06:25 < sipa> it's enabled on a per seed basis
06:25 < BlueMatt> so there is no way for me to reasonably do that
06:25 < BlueMatt> though i could do it for a small subset of possible flags
06:26 < sipa> yes, only x9 is needed
06:26 < BlueMatt> mmm, ok
06:26 < BlueMatt> give me a few hours
06:28 < sipa> ha, there isn't *that* much hurry either
06:28 < BlueMatt> all y'all with dnsseed-server-homogeneousness
06:28 < BlueMatt> need some diversity :p
06:28 < sipa> i am not complaining.
06:28 < sipa> :)     
06:29 < BlueMatt> ehh, 0.13.1rc1 today, should get it done :p
06:37 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
06:54 -!- chauncie [~chauncie@95.215.44.99] has quit [Quit: Leaving]     
07:01 < paveljanik> better discussing Oxford comma than FT ;-)
07:02 < instagibbs> FT? :P
07:02 < GitHub66> [bitcoin] laanwj closed pull request #8916: 0.13.1 backports (0.13...2016_10_backports) https://github.com/bitcoin/bitcoin/pull/8916
07:02 < GitHub73> [bitcoin] laanwj pushed 22 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/4ed26277347c...09bc76de60b7
07:02 < GitHub73> bitcoin/0.13 0027672 Johnson Lau: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH...
07:02 < GitHub73> bitcoin/0.13 3e80ab7 Johnson Lau: Add policy: null signature for failed CHECK(MULTI)SIG...
07:02 < GitHub73> bitcoin/0.13 7ae6242 Cory Fields: net: fix a few cases where messages were sent rather than dropped upon disconnection...
07:04 < BlueMatt> instagibbs: flexible transactions - tom zanders shit
07:04 < instagibbs> Oh, haha. 
07:06 < paveljanik> hmm, removing the Oxford commas can save us 2 (two!) bytes!
07:06 < paveljanik> imagine all those forks!
07:06 < instagibbs> I see you've found your scaling bitcoin topic for 2017
07:08 < paveljanik> the next SB will surely be at the date of my wife' birthday or any similar death-important family date as always :-(
07:09 < sipa> well at least we'll have a few topics for the next SB, such as segwit, ft, and the oxford comma.
07:09 < sipa> *ducks*
07:10 < paveljanik> Can't parse the sentence ;-)
07:12 < BlueMatt> I think he meant ft, segwit and the oxford comma
07:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:14 < btcdrak> FTFY: ft, segwit and, the oxford comma
07:14 < BlueMatt> bip 9 bit 1 has def never been used, right?
07:14 < BlueMatt> has someone scanned recent block versions?
07:15 < btcdrak> blocks have only been 0x30000000, 0x20000000, 0x20000001, and 0x30000001
07:15 < BlueMatt> bit 1 being 0x2, right?
07:15 < btcdrak> BlueMatt: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
07:16 < btcdrak> BlueMatt: yes
07:16 < sipa> yes     
07:16 < btcdrak> we used bit 0 for CSV
07:16 < BlueMatt> ok, sounds good
07:16 < BlueMatt> just figued I'd doube check
07:17 < instagibbs> just to make sure what about bip109
07:17 < BlueMatt> sipa: https://github.com/bitcoin/bitcoin/pull/8637#issuecomment-253547659
07:18 < btcdrak> We can save more bytes on the BIPs by aggregating like Schnorr: BIP141+143+147 = BIP431
07:19 < sipa> BlueMatt: last use of bit 1 was over 20k blocks ago
07:19 < BlueMatt> sipa: thanks
07:20 < sipa> though apparently it has been used with some frequency further back
07:20 < BlueMatt> heh, funny
07:20 < sipa> 1128 blocks set bit 1 in the past 50k blocks
07:20 < btcdrak> sipa bit 1?
07:21 < instagibbs> BlueMatt, sigh, at a minimum I'd like the debug help for cmpctblocks(sp!?)
07:21 < BlueMatt> instagibbs: yes, thats why I'm poking sipa :p
07:21 < instagibbs> cmpctblock
07:21 < sipa> cmpctblcks, w dnt spprt th s f vwls hr
07:21 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:22 < BlueMatt> we dont support the use of vowels here, for those with parse-issues
07:22 < sipa> i approve of BlueMatt's compact writing decoder
07:23 < achow101> it would be much more compact if you removed all the spaces
07:23 < jtimon> wumpus: around?
07:23 < jtimon> re https://github.com/bitcoin/bitcoin/pull/8921 "getinfo has been deprecated" when did that happened? for 0.13 or for 0.14 ?
07:23 < jtimon> ie is there any blocker to remove it already or are we just waiting to do it for 0.15 ?
07:24 < instagibbs> 0.14
07:24 < jtimon> instagibbs: I see, so we're in fact waiting for removing it in 0.15, thanks
07:25 < btcdrak> oh why is getinfo for the chop?
07:25 < GitHub170> [bitcoin] s-matthew-english opened pull request #8938: update to bitcoin-qt.desktop (master...master) https://github.com/bitcoin/bitcoin/pull/8938
07:25 < instagibbs> Not sure, just saying it's not deprecated in 0.13.1 
07:25 < achow101> jtimon: apparently it has been deprecated for years
07:25 < instagibbs> it's a hodgepodge of info you can individually get elsewhere
07:25 < GitHub167> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/cb8887e87df315dbc6c560149b3a97b704a676aa
07:25 < GitHub167> bitcoin/0.13 cb8887e Wladimir J. van der Laan: qt: periodic translation update
07:25 < jonasschnelli> getinfo is to general and uses all sorts of locks
07:26 < GitHub185> [bitcoin] s-matthew-english closed pull request #8938: update to bitcoin-qt.desktop (master...master) https://github.com/bitcoin/bitcoin/pull/8938
07:26 < jtimon> btcdrak: it has been for a while, at least jun12 2014, see https://github.com/bitcoin/bitcoin/pull/4333#issuecomment-45882887
07:26 < btcdrak> wow, looks like an RC today
07:26 < achow101> so if rc is tagged today, then should we hold off on that pre-final alert?
07:26 < jtimon> jonasschnelli: are there more locks than cs_main ? :p
07:27 < jonasschnelli> hehe...
07:27 < instagibbs> "Perhaps 0.10 is a good release for killing getinfo :)?" heh
07:27 < jonasschnelli> "all sorts of locks" mostly means: cs_main and cs_wallet
07:28 < sipa> we clearly need to add a cs_getinfo first.
07:28 < jtimon> yeah, not sure if I should wait for 0.15 to remove the "temporal" TestnetToBeDeprecatedFieldRPC or do it directly in #8921, certainly rpcmining can remove its redundant "testnet" field though
07:29 < btcdrak> sipa: you need to update your BIP PR to amend this as well https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
07:30 < btcdrak> maybe I can just edit it
07:32 -!- laurentmt [~Thunderbi@80.215.234.141] has joined #bitcoin-core-dev     
07:32 < sipa> BlueMatt: your rebase of compact block tweaks differs from my manual version
07:32 < sipa> -                        if (mi->second->nHeight >= chainActive.Height() - MAX_CMPCTBLOCK_DEPTH) {
07:32 < sipa> +                        if (CanDirectFetch(Params().GetConsensus()) && mi->second->nHeight >= chainActive.Height() - MAX_CMPCTBLOCK_DEPTH) {
07:32 < sipa> -        LOCK(cs_main);
07:32 < BlueMatt> argh
07:32 < sipa> +        CBlock block;
07:32 < sipa> +        bool fBlockRead = false;
07:32 -!- laurentmt [~Thunderbi@80.215.234.141] has quit [Client Quit]     
07:32 < sipa> we want the '+' side of this, right?
07:33 < BlueMatt> i have no idea, need context
07:33 < sipa> the '-' side lacks your fix for reduction of locks
07:33 < BlueMatt> note that my branch includes one commit on top
07:33 < sipa> ah     
07:33 < BlueMatt> yea, i was suggesting we dont bother with that commit (the cs_main fix)
07:33  * jtimon sees Params().GetConsensus() being used directly...
07:33 < BlueMatt> just because it already has acks on the pr
07:33 < BlueMatt> easy to push it to another pr
07:34 < sipa> BlueMatt: then there is still a difference
07:34 < BlueMatt> jtimon: yea, i think sdaftuar point that out to me on fri or so
07:34 < BlueMatt> should fix
07:36 < jtimon> BlueMatt: great. I mean, not a big deal, but I grep Params() every time I rebase #7829 git blame would blame you
07:36 < BlueMatt> jtimon: no, its already passed into that function, so should not call Params()
07:36 < BlueMatt> sipa: lemme look
07:37 < sipa> BlueMatt: in response to receiving a getdata MSG_CMPCT_BLOCK, and we're likely in IBD, should we respond with a normal block or not?
07:37 < BlueMatt> yes     
07:37 < sipa> i don't remember where this patch originates
07:37 < BlueMatt> normal block
07:37 < sipa> ok     
07:38 < sipa> rebased
07:38 < sipa> (using your history)
07:38 < BlueMatt> kk     
07:39 < BlueMatt> wait, now I'm confused
07:39 < BlueMatt> i thought we did want the CanDirectFetch?
07:39 < sipa> indeed
07:39 < sipa> your version had that, mine does not
07:40 < BlueMatt> i dont see it on the github diff now?
07:40 < sipa> presumably because the CanDirectFetch already exists in master, and my patch unintentionally undid it
07:40 < sipa> while yours leaves it alone
07:40 < BlueMatt> ahh, ok
07:41 -!- jnewbery [~jnewbery@176.136.6.51.dyn.plus.net] has joined #bitcoin-core-dev     
07:41 < sipa> actually, no
07:42 < BlueMatt> yea, no, it should be on L4877
07:42 < sipa> i just pushed the wrong branch
07:42 < sipa> fixed now
07:42 < BlueMatt> (though, as jtimon points out, it shouldnt call Params(), it should use consensusParams)
07:42 < sipa> ah     
07:43 < sipa> fixing
07:43 < BlueMatt> thanks
07:43 < sipa> jtimon: sorry, wasn't clear to me that we actually already had a consensusParams variable there
07:49 < GitHub157> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c90111314435...c6b959efcf2d
07:49 < GitHub157> bitcoin/master f9c23de Pieter Wuille: Define start and end time for segwit deployment
07:49 < GitHub157> bitcoin/master c6b959e Wladimir J. van der Laan: Merge #8937: Define start and end time for segwit deployment...
07:49 < GitHub74> [bitcoin] laanwj closed pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937
07:50 < sipa> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.1
07:50 < sipa> > No results matched your search.
07:50 < sipa> \0/     
07:50 < achow101> \o/     
07:50 < jtimon> sipa: ideally if we don't have it, create it at the top for "my minions" to turn it into a parameter more easily
07:51 < sipa> jtimon: fixed in #8637
07:51  * BlueMatt goes to update his node due to preferential peering stuff
07:51 < jtimon> thanks!
07:51 < sipa> BlueMatt: how ready is FIBRE for segwit?
07:51 < BlueMatt> uhhh, uhhhhh
07:51 < BlueMatt> just needs rebased on master now
07:51 < sipa> You have 6 weeks.
07:52 < BlueMatt> I'll do that this week
07:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
07:52 < sipa> May the blocks be ever in your favor.
07:53 < GitHub97> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8b66659921e6170831f3a043e9a54fa45776aa68
07:53 < GitHub97> bitcoin/0.13 8b66659 Pieter Wuille: Define start and end time for segwit deployment...
07:53 < achow101> rc1 tag now?
07:54 < btcdrak> achow101: we need release notes yet I think?
07:54 < sipa> going to update my node to 0.13 branch
07:54 < instagibbs> cmpctblks twkz, and notes?
07:54 < sipa> i don't think we need the tweaks in 0.13
07:54 < instagibbs> ok fine :( I'll just tattoo it on my arm
07:54 < jtimon> yeah, doesn't 8637 need backporting?
07:55 < jtimon> oh, ok
07:55 < achow101> oh, release notes. can't forget about those
07:55 < instagibbs> Well at this point, I should just proposed we change the debug string to something easier to remember
07:56 < jtimon> what debug string?
07:57 < instagibbs> -debug=cmpctblock. I'll stop complaining now :)
07:57 < wumpus> working on release notes
07:57 < sipa> you need help?
07:58 < wumpus> probably; I'll do the list of pulls and authors, but if something needs special mention please submit a pull
07:58 < BlueMatt> sipa: if i update my dnsseed today do we want that in 0.13?
07:59 < sipa> BlueMatt: i would say so
07:59 < wumpus> yes     
08:00 < BlueMatt> argh, ok, I'll prioritize that today
08:00 < sipa> BlueMatt: you can of course 'trivially' support it by just making x9.* an alias for the normal seed
08:00 < btcdrak> are petertodd and jonasschnelli's seed working ok yet? they seemed really flakey for a while
08:00 < sipa> so you can do the actual implementation work later
08:00 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 258 seconds]     
08:00 < BlueMatt> sipa: ok, true, I'll do that and we can add the tag today
08:01 < sipa> btcdrak: jonasschnelli's seems to work, though it only returns one x9 node
08:01 < btcdrak> I was just about to say
08:02 < btcdrak> sipa: yours in only returning 3 x9s
08:03 < sipa> btcdrak: it knows about 8, though a few are fake
08:03 < sipa> the result corresponds with my database, though
08:03 < sipa> so i think we're good
08:03 < sipa> once 0.13.1 nodes appear, they should be detected
08:04 < sipa> wumpus: are the release notes for 0.13.1 supposed to be relative to 0.13.0 or 0.12?
08:04 < sipa> 0.13.0 i suppose, as the file is empty
08:05 < wumpus> wumpus: 0.13.0
08:06 < sipa> wumpus: is wumpus talking to himself?
08:06 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
08:07 < wumpus> release notes are relative to the last minor release in case of a major release, and relative to the previous release on that branch in case of a minor release
08:08 < wumpus> lol     
08:08 < achow101> what are x9 nodes?
08:09 < sipa> achow101: 9 == hex for NODE_NETWORK|NODE_WITNESS
08:09 -!- fengling_ [~fengling@lax-us.eduvpn.net] has quit [Ping timeout: 268 seconds]     
08:09 < achow101> i see
08:10 < BlueMatt> dig x9.dnsseed.bluematt.me
08:10 < BlueMatt> ;; ANSWER SECTION:
08:10 < BlueMatt> x9.dnsseed.bluematt.me.	120	IN	CNAME	dnsseed.bluematt.me.
08:10 < gribble> Error: "ANSWER" is not a valid command.
08:10 < BlueMatt> is that sufficient sipa ?
08:10 -!- laurentmt [~Thunderbi@80.215.234.141] has joined #bitcoin-core-dev     
08:10 -!- laurentmt [~Thunderbi@80.215.234.141] has quit [Client Quit]     
08:10 < sipa> ack     
08:10 < BlueMatt> if you add it to src, please include a comment noting that this is only active for x9, and someone needs to ping me if they want more
08:11 < sipa> same for my seeder
08:11 < sipa> it supports only a few combinations
08:11 < BlueMatt> ok, should add a comment, then :)
08:11 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
08:11 < achow101> how do i see what nodes the seeder reports for those nodes?
08:11 < achow101> for x9
08:12 < sipa> dig x9.[seedername]
08:12 < achow101> thnx
08:12 < GitHub16> [bitcoin] sipa opened pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
08:16 < sipa> BlueMatt: send PR?
08:22 < BlueMatt> sipa: I'ma add lots o comments
08:22 < sipa> k!     
08:23 < BlueMatt> sipa: which does yours support?
08:23 < sipa> x1, x5, x9, x13
08:24 < BlueMatt> jonasschnelli: which does yours support?
08:24 < BlueMatt> I assume the same as sipa?
08:24 < sipa> presumably the same - it's the software default, though it can be configured with a cmdline flag
08:25 < sipa> so NETWORK, NETWORK|BLOOM, NETWORK|WITNESS, NETWORK|BLOOM|WITNESS.
08:26 < achow101> does the current master advertise WITNESS?
08:26 < sipa> yes     
08:26 < sipa> it should!
08:27 < GitHub145> [bitcoin] TheBlueMatt opened pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
08:27 < BlueMatt> sipa: ^
08:27 < achow101> hmm. I don't see my node in the seeders for x9
08:28 < BlueMatt> achow101: lol, they're not /that/ fast to pick up updates
08:28 < sipa> achow101: wait a few days
08:29 < achow101> I've been running builds of master since a very long time ago
08:29 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
08:29 < sipa> master only advertizes NODE_WITNESS since the merge of 8937, 40 minutes ago
08:29 < BlueMatt> achow101: master has only supported it for like the last hour
08:30 < achow101> oh. I thought it advertised it earlier.
08:31 < instagibbs> achow101, NODE_WITNESS is only advertised once bip9 parameters have been defined for a chain
08:32 < achow101> yup. just realized that
08:46 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev     
08:48 < sipa>     "subver": "/Satoshi:0.13.99(Ereshkigal)/",
08:48 < sipa> anyone know what that is?
08:49 < MarcoFalke> just someone setting -uacomment?
08:49 < sipa> there are multiple nodes reporting that
08:49 < wumpus> should be only one, mine
08:50 < sipa> ah     
08:50 < MarcoFalke> Anything holding back 8928?
08:50 < sipa> wumpus: i have hereby deanonimized your onion address (i have two connections reporting that, one onion one ipv4)
08:52 < wumpus> good one :-) luckily it's a public node
08:53 < wumpus> though good point on deanonimization using bitcoin user agents, woudl be something to add as warning to onionscan
08:54 < wumpus> though one shouldn't have their node listening on both onion and clearnet if the intention is to hide, I hope we mention that in tor.md
08:55 < sipa> i believe we do
08:57 < wumpus> MarcoFalke: completely focused on 0.13.1 right now, will look later
09:03 < wumpus> sipa: I can't find the commit for #8651 (Predeclare PrecomputedTransactionData as struct) in https://github.com/bitcoin/bitcoin/pull/8679 , am I missing something or was it squashed into another one?
09:04 < wumpus> (need to manually fix these as they have no Github-Pull header)
09:04 < sipa> wumpus: seems it was squashed
09:05 < wumpus> yes, seems to be part of b8c79a057c48c871a5e48bdcdf600fbfe68f656b, thanks
09:05 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
09:06 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
09:08 < sipa> wumpus: i'll remember to add Github-Pull tags in the future
09:08 < sipa> wumpus: is there some reference for that in the developer notes?
09:09 < wumpus> no, I don't think it's mentioned anywhere, it should be
09:10 < wumpus> I recently wrote my own auto-backport script and there's one by luke-jr floating around, should probably reference at least one of them there then
09:12 < wumpus> anyhow having to sort a few manually is not a big deal, it's a lot of manual work anyway
09:13 < MarcoFalke> I like the script by luke-jr. Makes sure the formatting is consistent and it requires less brain power, so less typos.
09:14 < MarcoFalke> Oh, Is 8939 the last pull before tagging 0.13.1?
09:14 < BlueMatt> also need #8940
09:14 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Quit: MarcoFalke]     
09:14 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
09:14 < wumpus> a script does help, it's easy to mistype pull numbers
09:15 < wumpus> they should have an error correcting digit :)
09:16 < btcdrak> wumpus: https://en.wikipedia.org/wiki/Ereshkigal
09:16 < btcdrak> s/wumpus/sipa/
09:17 < sipa> btcdrak: i had found that myself, but didnt answer who was running the node :)
09:17 < btcdrak> pagans
09:18 < wumpus> releases are still too infrequent to warrant automating a lot of the things, though it would be good for consistency
09:19 < wumpus> btcdrak: :D
09:19 < sipa> we need wumpus.sh, though
09:20 < btcdrak> testnet is running 0.13 now
09:20 < btcdrak> ^ mining with
09:20 < sipa> 0.13.1?
09:21 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:21 < btcdrak> yes     
09:21 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 250 seconds]     
09:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:22 < btcdrak> cfields_: any update on cgminer?
09:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
09:39 < btcdrak> proof reading appreciated please https://github.com/bitcoin-core/bitcoincore.org/pull/235
09:40 < wumpus> wumpus.sh hah, could at least spawn a few instances in parallel then
09:44 < sipa> btcdrak: will read
09:47 < waxwing> btcdrak: "Despite the keyhash formula is same as" should be "Despite the fact that the .. is the same as"
09:48 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:49 < GitHub169> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/7462125724ed3b88de490ab1bc3a4c3bea65fe2d
09:49 < GitHub169> bitcoin/0.13 7462125 Wladimir J. van der Laan: doc: Fill in changelog and authors in release notes
09:51 < GitHub124> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/614ef85ff97602c31f471436004210a74f2d8946
09:51 < GitHub124> bitcoin/0.13 614ef85 Wladimir J. van der Laan: doc: Properly sort authors list
09:52 < waxwing> btcdrak: i think you intended P2SH-P2WSH here: https://github.com/bitcoin-core/bitcoincore.org/pull/235/files#diff-6db9954f8386d196f3fcdc81537ced87R113
09:53 < waxwing> well, for some values of 'you'
09:54 < waxwing> scrip*t*PubKey here: https://github.com/bitcoin-core/bitcoincore.org/pull/235/files#diff-6db9954f8386d196f3fcdc81537ced87R119
09:55 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
09:56 < waxwing> lines 122-124 'permanent(ly)'
09:57 < jl2012> waxing: thanks for reviewing. Sorry for many typos. I'll fix later
09:57 < GitHub61> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c6b959efcf2d...ef3402d9a8cb
09:57 < GitHub61> bitcoin/master 0941f55 Pieter Wuille: Update implemented bips for 0.13.1
09:57 < GitHub61> bitcoin/master ef3402d Wladimir J. van der Laan: Merge #8939: Update implemented bips for 0.13.1...
09:58 < GitHub44> [bitcoin] laanwj closed pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
09:58 < waxwing> actually just s/scripPubKey/scriptPubKey/g
10:01 < BlueMatt> sipa: https://github.com/bitcoin/bitcoin/pull/8940#discussion_r83682480
10:02 < GitHub22> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/06d15fbea6fafb714f9576664422615704ad05fb
10:02 < GitHub22> bitcoin/0.13 06d15fb Pieter Wuille: Update implemented bips for 0.13.1...
10:13 < wumpus> https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md#notable-changes I guess the segwit activation needs special mention? Is there any text we can take over from any of the FAQs for this?
10:15 < GitHub195> [bitcoin] cdecker opened pull request #8941: Marking filter support for cdecker's DNS seed (master...dns-filter) https://github.com/bitcoin/bitcoin/pull/8941
10:17 < harding> wumpus: I can probably find and adapt something.
10:17 < wumpus> harding: that'd be awesome
10:17 < cdecker> sipa: DNS filtering support added :-)
10:17 < wumpus> cdecker: thanks
10:17 < sipa> cdecker vs BlueMatt: 1-0
10:17 < sipa> ;)     
10:18 < cdecker> Didn't know it was a competition
10:18 < sipa> (just kidding, i'm amazed you both started working on this immediately)
10:18 < cdecker> But I'll take the point ^^
10:18 < BlueMatt> wait, do you have your own seeder codebase cdecker?
10:19 < BlueMatt> sipa: also, have you seen my seeder codebase? good god its horendous
10:19 < cdecker> Yep, I have implemented my own crawler + dns seed
10:19 < sipa> BlueMatt: thankfully i don't need to
10:19 < cdecker> Same here, I'll have to rework it eventually
10:19 < BlueMatt> I mean I guess its better than the old one...which was based on magicaltux's php half-node and spawned a new process for each node it tested
10:19 < BlueMatt> :p     
10:20 < sipa> i knew the php part
10:20 < BlueMatt> also, mysql
10:20 < sipa> i guess you've learned.
10:20 < BlueMatt> lol, not really, now its in java :p
10:20 < wumpus> at least not javascript...
10:20 < Lightsword> I hear javascript is the new big thing
10:20  * Lightsword *hides*
10:21 < sipa> asmjs is almost a decent object format :p
10:21 < cdecker> Oh yeah we should do crypto in JS :D
10:21 < BlueMatt> Lightsword: no, you're thinking of BASIC
10:22 < cdecker> Visual Basic!
10:22 < BlueMatt> cdecker: no, that was never the new big thing
10:22 < Lightsword> BlueMatt, I suggest COBOL, I hear it’s what all the banks use so it must be good :P
10:22 < sipa> can we please not start a flamewar about programming languages? everybody knows that ALGOL was never beaten
10:22 < cdecker> You're right, it's the rock solid foundation we all built upon
10:22 < BlueMatt> sipa: its called a "religious" war
10:23 < sipa> BlueMatt: that'd be emacs vs vi :)
10:23 < BlueMatt> you forgot the m
10:23 < BlueMatt> in vim
10:23 < BlueMatt> :p     
10:24 < sipa> BlueMatt: pff, vim == vi improved
10:24 < BlueMatt> sipa: ehh, i guess either is better than mcedit :p
10:24 < sipa> that's right.
10:24 < sipa> you misspelled "neither"
10:25 < Lightsword> why not ed? https://www.gnu.org/fun/jokes/ed-msg.en.html
10:25 < BlueMatt> cdecker: which flags do you support?
10:25 < sipa> Lightsword: edlin?
10:25 < cdecker> The 4 least significant bits
10:25 < cdecker> Any combination thereof
10:26 < BlueMatt> argh, you broke my scheme
10:26 < cdecker> So x5 and x13 are included
10:26 < BlueMatt> cdecker: so x1 - x13?
10:26 < sipa> x1-x15
10:26 < cdecker> Yep     
10:26 < BlueMatt> yea, thats what i said
10:26 < BlueMatt> x1-x15
10:27 < GitHub15> [bitcoin] MarcoFalke opened pull request #8942: [doc] 0.13.1: Minor clarification to release notes (0.13...Mf1610-131doc) https://github.com/bitcoin/bitcoin/pull/8942
10:27 < cdecker> Well x0 actually also replies, but is equal to no filter
10:27 < sipa> i always require NODE_NETWORK, so nothing is equivalent to x1
10:28 < cdecker> Hm, haven't found a node without that bit set yet, I'm sure someone broke it somewhere xD
10:28 < BlueMatt> wumpus: ok, merged the two
10:28 < wumpus> thanks!
10:29 < GitHub157> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/06d15fbea6fa...498e950daaf3
10:29 < GitHub157> bitcoin/0.13 fa161e8 MarcoFalke: [doc] 0.13.1: Minor clarification to release notes
10:29 < GitHub96> [bitcoin] laanwj closed pull request #8942: [doc] 0.13.1: Minor clarification to release notes (0.13...Mf1610-131doc) https://github.com/bitcoin/bitcoin/pull/8942
10:29 < GitHub157> bitcoin/0.13 498e950 Wladimir J. van der Laan: Merge #8942: [doc] 0.13.1: Minor clarification to release notes...
10:29 < BlueMatt> cdecker: https://github.com/bitcoin/bitcoin/pull/8940/commits/dc1edd8c93ec5b17f5de9bd48e3b2276866ec2b1
10:29 < GitHub85> [bitcoin] cdecker closed pull request #8941: Marking filter support for cdecker's DNS seed (master...dns-filter) https://github.com/bitcoin/bitcoin/pull/8941
10:30 < wumpus> this leaves MarcoFalke's remark about sipa's seeder - any explanation why it wouldn't respond to x13?
10:30 < sipa> hmm     
10:30 < cdecker> Does it reply to x8?
10:30 < sipa> i just responded
10:30 < sipa> but i'm confused myself
10:30 < sipa> let me check
10:31 < sipa> sigh
10:31 < sipa> 13 would xd.seed.bitcoin.sipa.be
10:31 < sipa> not x13
10:31  * sipa fails at hex
10:32 < sipa> BlueMatt: ^
10:32 < BlueMatt> cdecker: so you reply to 0x1 - 0xf, right?
10:32 < cdecker> Darn, I'm using the decimal representation
10:33 < sipa> cdecker: no worries, it works for x9 :)
10:33 < wumpus> heh, it would have been more clear if we had padded to 64 bits
10:33 < sipa> waste of bandwidth!!!!1
10:33 < cdecker> So wait, which one is the format to implement? Hex or decimal
10:33 < wumpus> hex     
10:33 < cdecker> Ok, give me a minute
10:34 < wumpus> sorry for the confusion, I had forgot too
10:34 < sipa> ^ not a blocker
10:34 < BlueMatt> ok, fixed the text to indicate hex everyhwere
10:35 < cdecker> Fixed and restarted
10:38 < GitHub190> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef3402d9a8cb...763828df499f
10:38 < GitHub190> bitcoin/master 504c72a Matt Corallo: Comment that most dnsseeds only support some service bits combos
10:38 < GitHub190> bitcoin/master ffb4713 Matt Corallo: Add x9 service bit support to dnsseed.bluematt.me
10:38 < GitHub190> bitcoin/master 2449e12 Christian Decker: My DNS seed supports filtering...
10:38 < GitHub161> [bitcoin] laanwj closed pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
10:38 < BlueMatt> phew, back to 100% on 0.13.1
10:43 -!- jnewbery [~jnewbery@176.136.6.51.dyn.plus.net] has quit []     
10:44 < GitHub87> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/498e950daaf3...5b4192bc4c40
10:44 < GitHub87> bitcoin/0.13 9aa0c15 Matt Corallo: Comment that most dnsseeds only support some service bits combos...
10:44 < GitHub87> bitcoin/0.13 3d770a8 Matt Corallo: Add x9 service bit support to dnsseed.bluematt.me...
10:44 < GitHub87> bitcoin/0.13 5b4192b Christian Decker: My DNS seed supports filtering...
10:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
10:50 -!- jdumb1 [~jodie@sydnns0115w-142167034059.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Quit: WeeChat 0.3.8]     
10:51 < GitHub171> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/e1169b052991671db1043f432a85b31f9245a4c2
10:51 < GitHub171> bitcoin/0.13 e1169b0 Wladimir J. van der Laan: doc: Update release notes for last-minute pulls
10:51 < wumpus> time to tag 0.13.0rc1? would be a shame to hold it up on the release notes, those can be updates right until -final anyway
10:52 < wumpus> 0.13.1rc1*
10:52 < btcdrak> do it!
10:52 < btcdrak> I just fired up my gitian VM in anticipation
10:53 < harding> I'll be done it about 5 minutes.
10:54 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
10:54 < wumpus> harding: then we'll wait for you, I need to run pre-release tests anyway
10:54 < MarcoFalke> Oh I should have started caching for gitian yesterday..
10:56 < wumpus> its not a competition :p
10:57 < GitHub18> [bitcoin] harding opened pull request #8943: Release notes: add info about segwit and null dummy soft forks (0.13...notable-change-segwit) https://github.com/bitcoin/bitcoin/pull/8943
11:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:08 < btcdrak> MarcoFalke: for Travis?
11:09 < MarcoFalke> btcdrak: gitian will cache the depends dir, so it will run faster if you do it the day before rc1 :P
11:13 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:20 < achow101> MarcoFalke: doesn't the cache persist across builds? When I run the cacheing command again it doesn't actually do anything since everything is already there
11:24 < MarcoFalke> Yes, it does. But usually some of the depends are bumped, so the compiled and cached ones are no longer valid.
11:24 < achow101> did we bump any depends this time?
11:25 < achow101> nvm, we did with boost for windows waking
11:26 < wumpus> looks like travis is failing on 0.13 brnach
11:27 < wumpus> linux 64 bits, no clear error https://travis-ci.org/bitcoin/bitcoin/jobs/168377467
11:28 < wumpus> "Running test/bitcoin-util-test.py..."
11:28 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:28 < MarcoFalke> Should we backport the "run prevector tests faster"
11:28 < MarcoFalke> ?     
11:28 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:29 < gmaxwell> wumpus: we'll need to do a lot of release note work for 0.13.1 in any case. It would be stupid to hold it now.
11:29 < wumpus> well if it's just a problem with the tests I don't care, can fix that at any time later
11:29 < gmaxwell> wumpus: for example, we need to have a section on miner software compatiblity... and I expect that some of the things we'd list won't be done until after rc1.
11:29 -!- brg444 [415ce2de@gateway/web/freenode/ip.65.92.226.222] has joined #bitcoin-core-dev     
11:29 < MarcoFalke> But we should understand the failure, ideally.
11:30 < wumpus> gmaxwell: agreed
11:30 < wumpus> just going to tag now (before I go to bed), if there's any problems we'll just do another rc...
11:31 < gmaxwell> \O/     
11:31 < gmaxwell> RC's are free, esp when we don't even put up binaries for them. :P
11:31 < wumpus> it will at least get people to actually test
11:31 < wumpus> yep     
11:33 < wumpus>  * [new tag]         v0.13.1rc1 -> v0.13.1rc1
11:34 < achow101> yay!
11:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:37 < gmaxwell> because of the preferential peering, y'all should upgrade your own nodes ASAP, if you're not on a very current master or on 0.13.1rc1
11:39 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
11:40 < wumpus> ah yes good point still need to update my own nodes post-f9c23de
11:42 < btcdrak> upgraded and building
11:44 < achow101> gmaxwell: cobra merged the alert announcement to bitcoin.org. The date for the alert is set to tomorrow. Should that still happen or should it be pushed back a bit?
11:45 < gmaxwell> achow101: with 0.13.1rc1 tagged now, I'd like to push it until after the 0.13.1release.
11:46 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
11:46 < achow101> I'll make another pr for that. Just set the date to "After 0.13.1 is released" instead of a hard date.
11:47 < gmaxwell> sorry for adding delays. :)
11:49 < wumpus> well at least I don't think anyone is waiting for that one :)
11:50 < wumpus> makes sense to prioritize 0.13.1
11:51 < gmaxwell> well I don't want to encourage a wave of updating to 0.13.0 now, since we've seen tolerance effects before (people update slower to a release if its sooner to their last upgrade)
11:58 < BlueMatt> ^ while I get why, this is fucked up...if something comes out really quickly after the last its probably a) an easy, small, update, and b) liekly has security hotfixes
12:03 < btcdrak> achow101: the alert has actually gone live on the bitcoin.org RSS feeds....
12:04 < btcdrak> It's just pinged up in Slack for example...
12:04 < achow101> yes, it has
12:04 < achow101> that happens when it goes live on bitcoin.org.
12:10 < sipa> gmaxwell: yup, already upgraded my node, and seen it appear on my fikteree seed
12:10 < sipa> *filtered
12:14 < gmaxwell> I'm also seeing a lot of my connection slots eaten up by spynodes.  Here is the banlist I've created: http://0bin.net/paste/0Zo6iK2ZFLcryvGp#SQiUU268nld78Z1aMJG4GRwBjXpD4rasRP266adp7-+
12:14 < achow101> given that we don't want people to upgrade yet, it would probably be a good idea to take down the alert post for now, yes?
12:14 < gmaxwell> achow101: ugh. yea, I didn't want that with a banner up on bitcoin.org
12:15 < gmaxwell> achow101: crap.
12:15 < gmaxwell> damnit.
12:16 < achow101> wasn't expecting cobra to be so active today
12:23 < wumpus> gmaxwell: number of connections went from 54 to 14 after applying that banlist :)
12:32 < kanzure> oh crud, he merged because of the ACK probably
12:32 < achow101> he merged probably because of the multiple previous ACKs and then we didn't tell him not to merge today
12:33 -!- whphhg [whphhg@gateway/vpn/mullvad/x-vgzjwmqechajrsry] has quit [Quit: Leaving]     
12:33 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]     
12:34 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
12:34 < achow101> well it's gone now, so that's good (I guess)
12:42 < sipa> who merged what?
12:42 < Lauda> Alert key warning on Bitcoin.org
12:43 < achow101> cobra merged the post about the prefinal alert on bitcoin.org a few minutes after rc1 was tagged
12:43 < sipa> ah     
12:46 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
12:52 < gmaxwell> hm. /r/bitcoin could set the automoderator to automatically hide posts from non verified submitters for moderator approval that contain the string "Bitcoin.*Core.*releas" 
12:54 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]     
12:55 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
12:59 < wumpus> that's kind of smart
13:00 -!- bsm1175321 is now known as bsm117532     
13:00 < wumpus> avoids the most straightforward attack of someone falsely announcing a release, at least
13:03 -!- brg444 [415ce2de@gateway/web/freenode/ip.65.92.226.222] has quit [Ping timeout: 260 seconds]     
13:14 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
13:19 < BlueMatt> aaaaannnndddd segfault with 0.13.1
13:19 < achow101> oh?     
13:20 < BlueMatt> lol, feelers broke addnode
13:20 < BlueMatt> excuse me, not segfault, assert
13:21 < sipa> BlueMatt: which is why we have rcs :)
13:21 < BlueMatt> net.cpp:        assert(nOutbound <= (MAX_OUTBOUND_CONNECTIONS + MAX_FEELER_CONNECTIONS)); is bogus if you use addnode
13:22 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has quit [Ping timeout: 260 seconds]     
13:23 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
13:28 < wumpus> is that just on 0.13.1 or also on master?
13:29 < wumpus> please don't tell me that we have no tests for addnode, and no one tried it since feeler was merged :(
13:29 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:29 < sipa> i have addnodes
13:29 < GitHub67> [bitcoin] TheBlueMatt opened pull request #8944: Remove bogus assert on number of oubound connections. (master...2016-10-bad-assert) https://github.com/bitcoin/bitcoin/pull/8944
13:29 < sipa> and i've been running master for a long time
13:30 < sipa> i see no assert fail
13:30 < BlueMatt> wumpus: I dont know how anyone could have used addnode after their node has been running and not have hit this
13:30 < BlueMatt> if they have addnodes in bitcoin.conf they would likely not have
13:30 < sipa> oh, you mean addnode rpc?
13:30 < BlueMatt> yes     
13:30 < sipa> yeah, i think you're the only user for that :)
13:30 < BlueMatt> or an addnode which was offline and then came up after running
13:31 < BlueMatt> i just wanted to addnode other segwit peers :(
13:31 < achow101> just tried it on master and I don't see a problem
13:31 < achow101> It just returns null
13:31 < BlueMatt> achow101: addnode onetry a few times
13:31 < BlueMatt> to different nodes
13:32 < wumpus> is that assertion new?
13:32 < BlueMatt> yes     
13:32 < BlueMatt> blame on 0.13.1 shows it as from 2611ad79a5d53e2ce1535b342a9b72c2888a6c3f
13:32 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Read error: Connection reset by peer]     
13:32 < BlueMatt> which is feelers
13:32 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:32 < achow101> oh. I think I see now. It just crashed on me after I did it a few times
13:33 < sipa> i don't understand why addnode breaks that assertion
13:33 < sipa> i'd say something is broken with addnode then
13:33 < BlueMatt> because addnode will result in you having $ADDNODE_COUNT + $ORIGINAL_OUTBOUND_COUNT outbound peers
13:33 < BlueMatt> the addnode peers are not marked fInbound (because they are not inbound0
13:33 < BlueMatt> )     
13:33 < wumpus> I think it used to be the case that addnode wouldn't allow you to create more outbound connections than allowed
13:33 < sipa> addnode doesn't respect the max outgoing connection count?
13:34 < BlueMatt> sipa: no it doesnt
13:34 < BlueMatt> why would it
13:34 < wumpus> I don't think an assertion is the right way to enforce that, though
13:34 < sipa> didn't we fix that?
13:34 < BlueMatt> wumpus: im rather confident that is not the case
13:34 < wumpus> BlueMatt: so addnode allowes you to create, say, 100 outgoing connections?
13:34 < BlueMatt> yes     
13:34 < wumpus> blegh
13:34 < BlueMatt> it would be massively surprising behavior for it not to
13:34 < wumpus> that limit exists for a reason
13:34 < BlueMatt> what if I want to peer with the 10 other nodes that I run?
13:35 < sipa> ThreadOpenAddedConnections uses semOutbound
13:35 < sipa> ah, no
13:35 < sipa> it does, but doesn't check the result
13:35 < sipa> i remember
13:36 < wumpus> BlueMatt: yes with that reasoning it makes some sense
13:37 < wumpus> though I don't htink anyone but you was understanding this implication
13:37 < BlueMatt> addnode does, however, result in your node making fewer other outbound connections, which i think is (mostly) reasonable
13:37 < BlueMatt> though it might be nice to lower-bound that (to, say, 2 or 3)
13:37 < BlueMatt> because you might addnode yourself into a sybil
13:37 < BlueMatt> where you only connect outbound to yourself
13:38 < sipa> or always treat the outgoing connections as using a connection slot, unless the peer knows you specifically (whitelist/bip150/...)
13:38 < BlueMatt> hey, my node found a segwit peer of its own volition
13:38 < BlueMatt> well, unless that person addnode'd me
13:39 < sipa> addnode=eu.ng.bitcoinrelaynetwork.org
13:39 < sipa> addnode=nns4r54x3lfbrkq5.onion
13:39 < sipa> addnode=t3x2266jvxpwwwzq.onion
13:39 < sipa> addnode=192.99.46.190
13:39 < sipa> are you any of those?
13:39 < BlueMatt> dig +short public-seed.bluematt.me
13:39 < BlueMatt> 198.251.83.19
13:39 < BlueMatt> no     
13:40 < Lightsword> is there any way to do “bitcoin-cli getblocktemplate” with segwit active?
13:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
13:43 < sipa> Lightsword: you need to pass some extra parameter to indicate the miner supports segwit
13:43 < Lightsword> sipa, how do I do that with bitcoin-cli?
13:45 < sipa> $ ./bitcoin-cli -testnet getblocktemplate '{"rules":["segwit"]}'
13:46 < wumpus> seems that's not documented in the help for the request
13:46 < wumpus> just 'capabilities' and 'mode'; 'rules' is only shown as a reply field
13:46 < sipa> indeed
13:47 < sipa> though the help text does refer to https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes
13:47 < Lightsword> would it make sense to just have bitcoin-cli pass the segwit rules by default?
13:47 < Lightsword> so that scripts don’t get broken
13:47 < Lightsword> since nobody is actually going to mine using bitcoin-cli
13:47 < sipa> Lightsword: it's intended to break things
13:47 < sipa> as clients need to explicitly make changes to support segwit
13:48 < Lightsword> intended to break bitcoin-cli? yes I know it breaks clients intentionally
13:48 < btcdrak> wumpus: I see your asserts in the gitian.sigs repo but not signatures.
13:48 < sipa> well it should equally break those scripts, right? even if they're not used for mining directly, if they're not modified, some things may silently break when segwit activates
13:49 < sipa> but we should update the help output 
13:50 < wumpus> btcdrak: eh yes, added
13:50 < Lightsword> sipa, I assume most would just use it for checking if a transaction is going to be mined next block
13:55 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
14:01 < BlueMatt> I complained about this months ago
14:03 < BlueMatt> well, a month ago
14:04 < wumpus> connected to four witness nodes already
14:04 < BlueMatt> dig +short x9.dnsseed.bluematt.me | wc -l
14:04 < BlueMatt> 7     
14:06 < GitHub170> [bitcoin] Michagogo opened pull request #8947: Add historical release notes for v0.13.0 (0.13...0.13) https://github.com/bitcoin/bitcoin/pull/8947
14:07 < michagogo> Er, wait a sec
14:07 < michagogo> master's historical release notes for 0.13.0 don't match release-notes.md in the v0.13.0 tag
14:08 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
14:08 < michagogo> -- #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (theuni)
14:08 < michagogo> +- #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (MarcoFalke)
14:08 < BlueMatt> heh     
14:09 < wumpus> that happens, some people update the release notes on master
14:09 < wumpus> it's too late to update them on the tag so they update the historical release notes, I also find that curious, but meh
14:10 < BlueMatt> clearly MarcoFalke and cfields_ are in a commit-count feud
14:10 < cfields_> eh?     
14:11 < btcdrak> ha     
14:11 < gmaxwell> Lightsword: there is some risk that some genius is mining using system('bitcoin-cli getblocktemplate'). 
14:11 < gmaxwell> I don't know how great that risk is... but one thing I've learned is to not underestimate the liklyhood of someone doing something crazy, so long as it works.
14:12 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
14:12 < cfields_> gmaxwell: agreed. That sounds like exactly something someone might do as a quick hack, then forgets to clean up and it ends up in production
14:12 < wumpus> also passing arguments automatically from -cli is going to confuse people
14:13 < MarcoFalke> michagogo: The diff should be inversed :P
14:13 < Lightsword> gmaxwell, that sounds very unlikely since most pools are based off of open source software and none does that
14:13 < sipa> Lightsword: how about we add an RPC to just list what txids would be mined?
14:14 < wumpus> the bitcoin-cli API has been kept as close to the RPC API as used by other languages as possible, the only difference is the 'parse this as string or not' bit
14:14 < sipa> BlueMatt: complained about what?
14:14 < gmaxwell> Lightsword: most hashpower has previously been doing things that no open source software does...
14:14 < cfields_> Lightsword: i haven't had a single pool willing to let me poke at their production code...
14:14 < Lightsword> sipa, that would be better since full transactions aren’t needed most of the time when using cli
14:15 < BlueMatt> sipa: lack of getblocktemplate documentation in rpc help
14:15 < wumpus> BlueMatt: you should have created an issue like I just did
14:15 < BlueMatt> this is true
14:15 < gmaxwell> I'd love an RPC that would let me ask for a block of an arbritary weight limit. ... and also only returns the ids, and some extra fields like the total amount of fees.
14:16 < Lightsword> cfields_, kano.is is essentially the open source stock ckpool, mine is a minor patchset(most of my changes are webif related)
14:16 < Lightsword> cfields_, btc.com should be open source
14:16 < Lightsword> https://github.com/btccom/btcpool
14:18 < Lightsword> gmaxwell, btc.com pool software there is a public example of a how the stratum based validationless mining software works
14:18 < Lightsword> https://github.com/btccom/btcpool/tree/master/src/poolwatcher
14:19 < sipa> wumpus, MarcoFalke: ha, 3 identical issues simultabeously
14:19 < MarcoFalke> heh     
14:19 < Lightsword> btw the btc.com pool software is based off of bitcoin core(an old version 0.8.something)
14:20 < wumpus> lol     
14:20 < sipa> Lightsword: wah
14:21 < BlueMatt> whyyyyy
14:21 < Lightsword> very heavially modified of course
14:21 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
14:21 < achow101_> I wonder how that will react to an alert..
14:22 < gmaxwell> achow101_: 0.8 didn't do anything with the alerts except display them and relay them.
14:22 < Lightsword> that part was all stripped out
14:22 < Lightsword> I think it’s mostly just the serialization stuff that was kept
14:22 < sipa> ah, ok
14:23 < Lightsword> by based off of I mean, took lots of code from 0.8 and built a real pool around it
14:25 < michagogo> MarcoFalke: is this better?
14:25 < michagogo> (fixed it myself, then went to the PR page and saw something about you requesting changes... what does that mean?)
14:26 < michagogo> Oh, this is that upgraded review thing GH launched a while back
14:26 < michagogo> I forgot about that, haven't seen it in action yet
14:26 < michagogo> Looks like I broke it with my --amend :-/
14:29  * MarcoFalke Your review was dismissed successfully.
14:30 -!- cdecker [~quassel@2a02:aa16:1105:4a80:6545:7bd0:62a0:613f] has quit [Ping timeout: 260 seconds]     
14:35 -!- knightdk [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
14:38 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds]     
14:41 < michagogo> Can someone remind me: was there a process for trivial PRs?
14:41 < michagogo> Some other branch/fork or something?
14:41 < michagogo> (I feel like there was, but I don't remember where/what)
14:42 < wumpus> there was in the past, but there is no longer
14:42 < sipa> gmaxwell: sounds useful
14:50 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:52 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
14:55 -!- knightdk [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
14:56 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
14:57 < gmaxwell> why is my 0.13.1rc checkout claiming to be Bitcoin version v0.13.0.0-e1169b0  ? did we not bump the version?
15:00 < BlueMatt> yes     
15:02 < gmaxwell> I wonder if we need to add a 'witnessconnections" to getnetworkinfo?
15:02 < gmaxwell> it's going to be a pita to support people who are witness partitioned when right not checking for it requires inspecting all of the getpeerinfo output.
15:06 < michagogo> wumpus: so just a regular PR?
15:06 < wumpus> gmaxwell: if you do, at least add a connection # per service bit, instead of special-casing witness
15:08 < wumpus> michagogo: sure
15:08 < wumpus> yes, we forgot to bump the version
15:09 < gmaxwell> wumpus: okay, though witness is special due to preferential connection and block fetching restrictions.
15:10 < gmaxwell> With segwit active, a node with witness connection 0 is really no less partitioned from the network than one with connections 0.
15:10 < wumpus> yes, many more may be special in the future
15:10 < gmaxwell> True.
15:10 < wumpus> it will look like a bad design decision in the future to special-case anything now, no matter how important it looks, trust me
15:10 < michagogo> Okay, sigs up: https://github.com/bitcoin-core/gitian.sigs/pull/407
15:11 < gmaxwell> uh hm. so another peer that I updated, shows Bitcoin version v0.13.1rc1
15:11 < gmaxwell> s/peer/node/
15:11 < gmaxwell> now I am mystifie.d
15:11 < wumpus> just a map of {version_bit: count} histogram would work, you could leave out those that are 0
15:12 < gmaxwell> alternatively letting getpeerinfo take a mask like the dnsseeds would also work.
15:12 < wumpus> yes     
15:13 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ukgiitiidsxlbptu] has quit [Ping timeout: 245 seconds]     
15:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dhkcqxaijyrsbyaz] has joined #bitcoin-core-dev     
15:17 < GitHub131> [bitcoin] Michagogo opened pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
15:17 < GitHub81> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/a5cef7b0777f13ac83312759ebf576c9d773599f
15:17 < GitHub81> bitcoin/0.13 a5cef7b Wladimir J. van der Laan: Bump version to 0.13.1
15:19 < wumpus> gmaxwell: if it reports v0.13.1rc1 it must hav gotten the tag version from git, there is no other way it can know it is an rc
15:19 < wumpus> (or that it is 0.13.1 without ^)
15:20 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
15:20 < gmaxwell> yea, it must have gotten it from git.
15:21 < michagogo> (Release notes are still in flux, right? I see there are references to it being 0.13.x...)
15:21 < wumpus> michagogo: release notes can be updated until -final
15:21 < wumpus> michagogo: (or, according to some people, even after that as 'historical release notes' in master...)
15:22 < michagogo> Should I assume the .x in the header will be fixed as part of a cleanup before final tag? Or should I PR that myself?
15:22 < wumpus> probably better to not assume anything and just do it yourself
15:23 < wumpus> although you should check harding 's pull, he may have already changed some things
15:25 < michagogo> Ah, yep
15:25 < michagogo> He got it
15:25 < michagogo> Good call
15:25 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
15:26 < gmaxwell> Found another tidbit for SW deployment guide:  do not addnode= or connect= yourself to only non-witness peers...
15:27 < BlueMatt> oh, yea, that'd be bad
15:28 < GitHub152> [bitcoin] laanwj pushed 4 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a5cef7b0777f...c418c0550db3
15:28 < GitHub47> [bitcoin] laanwj closed pull request #8943: Release notes: add info about segwit and null dummy soft forks (0.13...notable-change-segwit) https://github.com/bitcoin/bitcoin/pull/8943
15:28 < GitHub152> bitcoin/0.13 5f9c7b0 David A. Harding: Release notes: add info about segwit and null dummy soft forks...
15:28 < GitHub152> bitcoin/0.13 2de93f0 David A. Harding: Relase notes: correct segwit activation point
15:28 < GitHub152> bitcoin/0.13 bf86073 David A. Harding: Release notes: correct segwit signalling period start conditions...
15:29 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
15:30 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
15:31 < wumpus> would it make sense to add a alert condition when only connected to non-witness peers?
15:31 < BlueMatt> yes     
15:31 < BlueMatt> though this is default for most nodes until the network upgrades
15:32 < BlueMatt> so that would suck :/
15:32 < wumpus> I guess it should only trigger when it actually becomes a concern, e.g. segwit about to activate
15:33 < wumpus> not right after installing 0.13.1
15:33 < BlueMatt> yea, i mean gate it on locked-in state
15:34 < wumpus> though I wonder if it'll still be a common problem at that point
15:34 < wumpus> if people haven't upgraded to 0.13.1+ en masse by then there's another problem
15:34 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
15:41 < BlueMatt> i would not be surprised if we see increasing sybil attacks over the coming month(s)
15:43 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
15:44 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
15:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]     
15:46 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
15:48 < gmaxwell> right now its very easy to end up in this state. I'm going to open a PR to improve it some for discussion.
15:48 < gmaxwell> (just waiting for tests to run before opening it)
15:49 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:52 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
15:53 < michagogo> achow101: Interesting. I have LXC set up and it seems to work for me
15:54 < michagogo> In what way does it fail for you?
15:55 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
16:03 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
16:03 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Ping timeout: 252 seconds]     
16:03 -!- PRab_ is now known as PRab     
16:04 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
16:04 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
16:09 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]     
16:19 < GitHub89> [bitcoin] gmaxwell opened pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
16:21 -!- tulip [uid192128@gateway/web/irccloud.com/x-xigwywvvqrexjthj] has joined #bitcoin-core-dev     
16:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
16:24 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
16:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Client Quit]     
16:33 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
16:33 < tulip> the v0.13.1rc1 tag doesn't have the subver updated, but the 0.13 branch does; confused me for a second. 
16:43 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has joined #bitcoin-core-dev     
16:43 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has quit [Changing host]     
16:43 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:49 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]     
16:52 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
17:05 < achow101> michagogo: I made an issue here https://github.com/devrandom/gitian-builder/issues/128 about it. There is also a corresponding issue about this in lxc/lxc. Also, if you go back to IRC logs around that same time (end of august), you should be able to find some info I said there about the same problem
17:06 < michagogo> tulip: yep, that was missed
17:08 < michagogo> tulip: 01:17:13 <GitHub81> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/a5cef7b0777f13ac83312759ebf576c9d773599f
17:08 < michagogo> 01:17:13 <GitHub81> bitcoin/0.13 a5cef7b Wladimir J. van der Laan: Bump version to 0.13.1
17:09 < michagogo> achow101: hmm. I seem to remember (from quite a while back…) that I tried doing it on Xenial and failed too
17:10 < michagogo> I feel like I might have gotten past the shm thing just to have it fail a different way
17:10 < michagogo> Or maybe I'm misremembering
17:10 < michagogo> Works for me on the Trusty Tahr, though
17:11  * sipa realizes that he never knew what the part after 'Trusty' in the ubuntu version name was
17:11 < achow101> Maybe I'll try it in a VM with trusty then. I've been running 16.04 which is what I do the builds on
17:11 < achow101> it previously worked on 15.10 for a while then broke
17:12 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:12 < achow101> but it would be great if this could be fixed since multiple people have run into the same problem recently
17:15 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
17:18 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]     
17:22 -!- fengling__ [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
17:32 -!- murch [~murch@p4FE383DB.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
17:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dhkcqxaijyrsbyaz] has quit [Quit: Connection closed for inactivity]     
17:37 -!- fengling__ [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
17:50 < achow101> for some reason I can't do the osx build now
17:51 < achow101> it is failing at installing stuff. the install.log says "E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution)."
17:53 < achow101> well, it isn't just osx apparently, something is broken on my gitian
17:54 < achow101> michagogo: 
17:55 < michagogo> But you somehow managed windows and Linux? o_o
17:56 < achow101> I just tried to do windows and linux again and it failed.
17:56 < achow101> I guess it got through them before it broke
17:56 < michagogo> sipa: yep. I wonder if I remember them all
17:56 < michagogo> achow101: odd. I wonder what could have changed
17:58 < achow101> my computer almost crashed during the build since I tried starting a vm. Maybe that corrupted something in memory which corrupted something on disk?
18:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:18 < achow101> wtf. I just redownloaded and setup gitian and now it's asking me for the password for the vm in order to do stuff
18:21 < gmaxwell> My voice is my passport. Verify me.
18:24 < tulip> achow101: you mustn't have had your pentagon configured correctly. 
18:27 < michagogo> achow101: the VM you're running gitian in?
18:27 < michagogo> The same one as before?
18:28 < achow101> the vm that gitian creates
18:28 < michagogo> Hmm.
18:28 < michagogo> It shouldn't be doing that, I think
18:28 < tulip> I managed to find two NODE_SEGWIT peers with #8949 but I don't know if that's luck or not. 
18:28 < michagogo> Did you create the previous one the same way?
18:29 < achow101> yes     
18:29 < michagogo> 🤔
18:30 < achow101> I used my gitian build script with the setup option to setup the gitian environment. the script is in  the repo in contrib/
18:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:41 -!- fengling__ [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
18:42 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-jerfpoprknljetqh] has quit [Read error: Connection reset by peer]     
18:42 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-elhpeqbajllnfshb] has joined #bitcoin-core-dev     
18:47 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-kfpjhdemnmnpdrhx] has quit [Ping timeout: 258 seconds]     
18:48 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-xnnwppeplcyizyex] has joined #bitcoin-core-dev     
18:50 < tulip> 2016-10-18 01:43:35.372446 connect() to [::0.0.255.255]:20720 failed: No route to host (65)
18:50 < tulip> 2016-10-18 01:42:29.613434 connect() to [a586:2a57:100::]:0 failed: Can't assign requested address (49)
18:50 < tulip> 2016-10-18 01:43:18.827390 connect() to [d50e:7f57:100::]:0 failed: Can't assign requested address (49)
18:50 < tulip> gmaxwell: I guess this means there's only junk in addrman with the NODE_WITNESS service? 
18:51 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-lzkpqzhxfiujuwdu] has quit [Ping timeout: 248 seconds]     
18:54 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-nbgrzgpbqrokfpzj] has joined #bitcoin-core-dev     
18:55 < tulip> no wait, there we go. from a very old node state with no sensible peers to 4 NODE_WITNESS peers in about 6 minutes. 
19:02 < gmaxwell> tulip: thats better than I expirenced.
19:03 < gmaxwell> I have one node that after being upgraded, run for three houres, and restart... has no nodewitness peers.
19:03 < gmaxwell> (thus the PR that I opened)
19:04 < tulip> gmaxwell: that's with your patch.
19:04 < gmaxwell> ah okay!
19:04 < tulip> it had no NODE_WITNESS peers beforehand. 
19:04 < gmaxwell> yea, with the patch it will be pretty much guarenteed to find some... often 4. :)
19:05 < tulip> curious why we are even trying to connect to nodes with port zero, is anyone really going to be running a privileged port Bitcoin node?
19:06 < tulip> (I assumed 0-1023 would be masked out entirely) 
19:06 < gmaxwell> well we only try connecting to non-standard ports if we've been failing to connect for a while, but port 0 is braindamaged.
19:06 < gmaxwell> someone might plausably run a bitcoin node on port 80 or port 443 since it's a little more likely to make it through firewalls.
19:08 < gmaxwell> port 0 is just stupid though. We should probably filter out port 0 from ever going into addrman.
19:16 -!- mturquette [sid66043@gateway/web/irccloud.com/x-kwozoarfryepycva] has quit [Ping timeout: 250 seconds]     
19:18 -!- mturquette [sid66043@gateway/web/irccloud.com/x-qapqxnwniusnufxq] has joined #bitcoin-core-dev     
19:25 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
20:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:05 -!- zooko [~user@2601:281:8080:b789:2a14:b0a0:b29f:4ea6] has joined #bitcoin-core-dev     
20:06 -!- alpalp is now known as alpalpwi     
20:07 -!- alpalpwi is now known as alpalp     
20:24 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
20:27 < morcos> gmaxwell: at the risk of beating a dead horse, can you try again to explain to me the logic behind writing down the mempool every 10 mins?
20:28 < gmaxwell> every ten minutes I care less about than at clean shutdown.
20:28 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
20:28 < morcos> i can somewhat reluctantly accept that it might be useful on shutdown, and could see it being beneficial on demand (maybe via rpc)
20:28 < morcos> but writing it every 10 mins just seems like a way to clog up your node doing useless crap
20:28 < gmaxwell> the 10 minute thing is something sipa added that wasn't in my requirements document. :P
20:29 < morcos> and in particular if somehow some bad tx in your mempool crashed your block creation code, maybe you don't want to reload with that mempool (but i guess you could do that manually)
20:29 < gmaxwell> I don't think we disagree.  (The goals in saving it: prevent being utterly cold on newly recieved blocks after you do a simple restart for config changes, to not lose your transaction prioritization, to not reject dependant transactions as orphans which you never recieve, to not needlessly end up mining small blocks for an hour after a boring restart...)
20:30 < gmaxwell> well if you're crashing you can delete the file. I'm not particularly worried about that, and the import path goes through the normal accept logic, it's not just crammed back into the mempool. (meaning a network peer could give you the same garbage)
20:31 < morcos> ok, i guess just making your node to extensive disk access every 10 minutes gives me the heebie jeebies
20:31 < gmaxwell> the lack of the saving/loading also means that all of us spend far too much time messing around with nodes in unrepresentative states, throwing off benchmarking, and risking that we don't see issues that only show up with the mempool nice and fat.
20:32 < morcos> instead of roughly writing 1MB every 10 mins, now you'll write 300
20:32 < gmaxwell> Yea, well, I'm not a fan of the 10 minute thing. I'd be happier if it was on shutdown and had a rpc to trigger, and if you want 10 minutes you can call the rpc yourself. :)
20:32 < morcos> i would be way happier with that
20:33 < gmaxwell> I think the rational for the 10 minute saves is to make it useful across crashes. Which has merit, but-- I'd rather just not crash. :)
20:33 < morcos> looking back at the PR discussion, i think sipa wanted prioritization info to be saved in the event of a crash
20:33 < morcos> but do people actually have nodes that crash?
20:33 < morcos> is that a thing?
20:33 < gmaxwell> horrifyingly, yes. But we don't have to embrace all of reality.
20:34 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
20:34 < gmaxwell> (a main audience for this is miners, some of whom may have custimization that crashes; or be running on mystermeat hardware and not really appricate that it shoud not EVER crash) 
20:35 < morcos> ok.. i'll comment on the PR with my thoughts then since they don't seem too objectionable
20:42 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
20:43 < gmaxwell> I'd love to have some crash detection wrapper around bitcoin core that told people "THIS SHOULD NEVER CRASH. IF IT CRASHES WE WANT TO KNOW _NOW_" .. but unfortunately virtually all crashes I've seen from users are bad hardware, and we don't really want to know. :)
20:44 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
20:47 < morcos> heh, i offered one of the industry exec's a 1 BTC bounty for every non hardware caused crash he had on his bitcoinds because he was complaining bitcoind crashes all the time.
20:47 < morcos> that was like a year ago, no claims yet.
20:47 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
20:48 < gmaxwell> :)     
20:48 < gmaxwell> I've heard those sorts of claims going around, and wasted a lot of time trying to find ways to make it crash.
20:49 < luke-jr> heh     
20:49 < luke-jr> I wonder if the hardware-induced crashes are such that we can detect them with a repeat easily
20:50 < luke-jr> (and then complain to the user that their hardware is certainly faulty)
20:50 < gmaxwell> "Non-determinstic hardware detected (this is bad)"
20:51 < luke-jr> "It's not that we don't like you overclocking, but rather that your overclocking has actually given us the wrong answer to math, which is kinda important to Bitcoin working right."
20:52 < TD-Linux> probably not without crash telemetry, which I think users would be pretty averse to...
20:56 < luke-jr> btw, +1 on RPC trigger to write mempool before exit
20:56 < luke-jr> if someone wants to write every 10 minutes, they can cronjob it
20:56 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
20:58 < TD-Linux> also the existing PR fsync()'s on every write, which is probably fine on exit but is not great for interactive performance, especially on linux
20:58  * luke-jr wonders how much performance gain we'd get by using the file-specific fsync calls
21:00 < TD-Linux> luke-jr, it already does, the problem is on Linux other accesses will be queued behind the gigantic write
21:00 < tulip> TD-Linux: manual telemetry can be a thing, sort of. rather than asking users to dig around for things in a debug.log you can make a cohesive blob and a message that says "report this to your handler if you want to". 
21:10 < luke-jr> TD-Linux: hmm, some filesystems on Linux seem to have another ioctl for fsyncing a specific file; I guess the normal one does it to a specific fd as well.. not sure what the difference is
21:14 < TD-Linux> luke-jr, not sure, but the buffering issue is lower level: https://lwn.net/Articles/682582/
21:16 < TD-Linux> tulip, that would help. here's an example of what a hardware bug looks like on mozilla telemetry: https://crash-stats.mozilla.com/signature/?signature=adapt_probs&date=%3E%3D2016-10-11T04%3A06%3A00.000Z&date=%3C2016-10-18T04%3A06%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#aggregations
21:16 < TD-Linux> (hint: pick the "aggregate on" drop down and choose cpu info)
21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:31 -!- zooko [~user@2601:281:8080:b789:2a14:b0a0:b29f:4ea6] has quit [Ping timeout: 245 seconds]     
21:32 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
21:36 < gmaxwell> morcos: more like 150MB of data, fwiw, ... mempool limit is on the in memory form, saving it out currently uses the p2p serilization.
21:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
21:45 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:50 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
21:53 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
21:58 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:58 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 245 seconds]     
22:00 -!- dermoth [~thomas@dsl-199-102-156-15.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
22:00 -!- dermoth [~thomas@dsl-199-102-156-15.mtl.aei.ca] has joined #bitcoin-core-dev     
22:03 < cfields_> gitian builders: v0.13.1rc1 detached sigs are pushed
22:04 < gmaxwell> wtf. why does sendtoaddress' help have an actual bitcoin address in the example? O_o we worked hard elsewhere to keep real addresses out of examples.
22:05 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
22:09 < gmaxwell> hmph. a long time ago in fact.
22:29 < tulip> TD-Linux: you're right, bitcoin users wouldn't appreciate that much
22:30 < tulip> yuck, the sentoaddress "example" is even a political one. 
22:31 < tulip> well, no political but it's for a "cause" which isn't ideal. 
22:33 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
22:33 < luke-jr> there are probably worse causes it could be
22:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
22:34 < gmaxwell> yea sure. still. obviously it should be my address there
22:34 < luke-jr> ☺     
22:35 < luke-jr> should be a testnet address ☺
22:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wvfgqykannazwbwu] has joined #bitcoin-core-dev     
22:48 < GitHub197> [bitcoin] jl2012 opened pull request #8950: Update gitian signing key of jl2012 (master...patch-18) https://github.com/bitcoin/bitcoin/pull/8950
22:59 -!- fengling__ is now known as fengling     
22:59 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
23:00 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
23:07 < btcdrak> what is si objectionable about writing 150-300MB down every 10 mins? 
23:08 < luke-jr> put it that way and it sounds pretty bad. probably will cause seconds of hanging on my PC
23:08 < btcdrak> the mempool is mostly quite small. sounds like over optimisation worrying about that.
23:09 < btcdrak> oh come on.. even a PI can write that with no sweat. this isnt 1990
23:09 < btcdrak> mempool is usually what 5-10MB at peak?
23:09 < luke-jr> seriously?
23:10 < paveljanik> btcdrak, mempool is usually ~300MB ;-)
23:11 < btcdrak> still doesnt invalidate what I am saying. 300MB flush every 10 mins isnt a big deal. this is 2016
23:11 < luke-jr> 314572800 bytes (315 MB) copied, 2.67949 s, 117 MB/s
23:11 < luke-jr> ok, not so bad I guess
23:28 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
23:31 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
23:32 < TD-Linux> seriously can't tell if that was sarcasm or not...
23:39 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:49 < paveljanik> this was from luke-jr's high-end 64bit workstation...
23:49 < paveljanik> let's wait for the numbers from wumpus' arm small boxes. Still writing...
23:50 < luke-jr> XD     
23:52 < btcdrak> my computer 314572800 bytes (315 MB) copied, 0.629238 s, 500 MB/s
23:52 < luke-jr> SSD?
23:52 < btcdrak> yes     
23:53 < btcdrak> going to check my pine64
23:53 < btcdrak> well my laptop with HDD is 314572800 bytes (315 MB) copied, 0.892623 s, 352 MB/s
23:54 < btcdrak> that's only a 5200rpm thing too
23:54 < luke-jr> I did it on btrfs since I expect poorer performance from it
23:54 < luke-jr> but a relatively new drive, so
23:56 < TD-Linux> btcdrak, that's implausibly high for a spinning disk. you're not syncing afterwards
23:58  * luke-jr also forgot to sync :x
23:59 < luke-jr> real    0m6.677s
23:59 < luke-jr> so 47 MB/s