--- Day changed Thu Nov 03 2016
00:09 < GitHub46> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed0cc50afed1...508404de98a8
00:09 < GitHub46> bitcoin/master fd46136 Gregory Maxwell: IBD check uses minimumchain work instead of checkpoints....
00:09 < GitHub46> bitcoin/master 2082b55 Gregory Maxwell: Remove GetTotalBlocksEstimate and checkpoint tests that test nothing....
00:09 < GitHub46> bitcoin/master e141beb Gregory Maxwell: IsInitialBlockDownload no longer uses header-only timestamps....
00:09 < GitHub127> [bitcoin] sipa closed pull request #9053: IBD using chainwork instead of height and not using header timestamps (master...no_checkpoint_for_ibd) https://github.com/bitcoin/bitcoin/pull/9053
00:24 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
00:31 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
00:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zdopouejucqqtdta] has joined #bitcoin-core-dev     
00:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
01:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
01:35 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:38 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 256 seconds]     
01:47 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
02:14 < GitHub156> [bitcoin] laanwj closed pull request #9061: Ignore getheaders prior to passing all checkpoints. (master...FixGetheadersResponseWhenSyncing) https://github.com/bitcoin/bitcoin/pull/9061
02:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
02:22 < luke-jr> lol 2016-11-03 08:34:25 Flushed 65607 addresses to peers.dat  13896962ms
02:22 < GitHub127> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/508404de98a8...d1871da7fe63
02:22 < GitHub127> bitcoin/master 2ca882a Pieter Wuille: Declare wallet.h functions inline
02:22 < GitHub127> bitcoin/master d1871da Wladimir J. van der Laan: Merge #9071: Declare wallet.h functions inline...
02:22 < GitHub139> [bitcoin] laanwj closed pull request #9071: Declare wallet.h functions inline (master...walletinline) https://github.com/bitcoin/bitcoin/pull/9071
02:32 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]     
02:45 < GitHub52> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d1871da7fe63...fcf61b80fa2c
02:45 < GitHub52> bitcoin/master aff6584 Cory Fields: net: constify a few CNode vars to indicate that they're threadsafe
02:45 < GitHub52> bitcoin/master 59ac5c5 Cory Fields: net: Use deterministic randomness for CNode's nonce, and make it const
02:45 < GitHub52> bitcoin/master fcf61b8 Wladimir J. van der Laan: Merge #9050: net: make a few values immutable, and use deterministic randomness for the localnonce...
02:45 < GitHub54> [bitcoin] laanwj closed pull request #9050: net: make a few values immutable, and use deterministic randomness for the localnonce (master...connman-const) https://github.com/bitcoin/bitcoin/pull/9050
02:46 -!- laurentmt [~Thunderbi@80.215.178.187] has joined #bitcoin-core-dev     
02:46 -!- laurentmt [~Thunderbi@80.215.178.187] has quit [Client Quit]     
02:53 -!- murch [~murch@p4FE3A3AE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:02 -!- Tiraspol [~Tiraspol@unaffiliated/tiraspol] has quit [Ping timeout: 260 seconds]     
03:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
03:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
03:12 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
03:27 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev     
03:28 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
04:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
04:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
04:13 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:31 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
04:33 -!- laurentmt [~Thunderbi@80.215.178.187] has joined #bitcoin-core-dev     
04:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:46 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
04:52 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
05:09 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
05:16 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
05:27 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
05:35 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
05:36 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
05:40 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds]     
05:41 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
05:47 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
05:52 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
05:53 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye]     
05:53 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
05:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
06:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:03 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
06:09 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
06:09 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
06:19 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
06:20 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
06:24 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 250 seconds]     
06:48 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
06:54 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
06:58 < GitHub2> [bitcoin] instagibbs opened pull request #9073: Trivial: Add common failure cases for rpc server connection failure (master...rpcnoconnectstring) https://github.com/bitcoin/bitcoin/pull/9073
07:01 -!- abpa [~abpa@199.87.86.217] has quit [Read error: Connection reset by peer]     
07:14 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit []     
07:20 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
07:23 -!- xinxi [~xinxi@116.87.187.139] has quit [Client Quit]     
07:30 < BlueMatt> wumpus: any update on #8969? Should I solicit more review?
07:30 < gribble> https://github.com/bitcoin/bitcoin/issues/8969 | Decouple peer-processing-logic from block-connection-logic (#2) by TheBlueMatt · Pull Request #8969 · bitcoin/bitcoin · GitHub
07:30 < BlueMatt> thanks gribble!
07:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
07:33 <@wumpus> seems ok to me
07:41 -!- eenoch [~eenoch@unaffiliated/eenoch] has quit [Quit: leaving]     
07:46 < BlueMatt> lol, go to test some latency issues i was observing on fibre network....realize i cant because all the chinese peering in tokyo is currently entirely fucked
07:46 < BlueMatt> oh well, good thing i have other routes....
07:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:50 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
07:52 < instagibbs> where is the rpc test cache directory by default?
07:52 < sdaftuar> qa/     
07:53 < sdaftuar> qa/cache, i guess
07:53 <@wumpus> yes     
07:54 < BlueMatt>  /tmp/${shit}
07:54 < BlueMatt> oh, cache, yea, qa/
07:54 < BlueMatt> test runs are /tmp/thing
07:54 < instagibbs> ok, looking thanks
07:55 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
07:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
07:59 < instagibbs> actually it appears to be top level directory
07:59 < instagibbs> bitcoin/cache
08:02 < sdaftuar> actually i think it depends on where you run the tests from, there are relative paths used in test_framework.py
08:03 < instagibbs> Ah, I'm running individually from top-level
08:04 < instagibbs> My cache somehow got corrupted and tests were failing due to this
08:04 < instagibbs> and if it finds all the nodeX's directories, it never tries to rebuilt it
08:07 <@wumpus> sdaftuar: I'm fairly sure that was made consistent recently
08:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
08:32 < GitHub173> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/fcf61b80fa2c...3665483be7be
08:32 < GitHub173> bitcoin/master 65f35eb Matt Corallo: Move FlushStateToDisk call out of ProcessMessages::TX into ATMP
08:32 < GitHub173> bitcoin/master fc0c24f Matt Corallo: Move MarkBlockAsReceived out of ProcessNewMessage
08:32 < GitHub173> bitcoin/master d6ea737 Matt Corallo: Remove network state wipe from UnloadBlockIndex....
08:32 < GitHub146> [bitcoin] laanwj closed pull request #8969: Decouple peer-processing-logic from block-connection-logic (#2) (master...net_processing_2) https://github.com/bitcoin/bitcoin/pull/8969
08:33 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
08:42 -!- eenoch [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev     
08:51 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
08:56 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
09:18 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
09:27 -!- notmike [~notmike@unaffiliated/notmike] has joined #bitcoin-core-dev     
09:33 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:40 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
09:40 -!- echonaut6 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
09:41 -!- notmike [~notmike@unaffiliated/notmike] has quit [Quit: This computer has gone to sleep]     
09:46 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:52 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
09:54 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
09:54 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev     
09:54 -!- laurentmt [~Thunderbi@80.215.178.187] has quit [Quit: laurentmt]     
09:58 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
09:58 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]     
10:01 < jtimon> the meeting is in 2 hours, right?
10:01 < Chris_Stewart_5> Yes     
10:01 < jtimon> thanks
10:01 < sipa> indeed
10:08 < cfields_> I won't make the meeting today, boarding a flight now
10:14 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
10:14 -!- laurentmt [~Thunderbi@80.215.178.187] has joined #bitcoin-core-dev     
10:14 <@wumpus> cfields_: no problem, have a good flight
10:16 -!- laurentmt [~Thunderbi@80.215.178.187] has quit [Client Quit]     
10:25 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
10:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
10:45 < instagibbs> any tricks on attaching gdb to an rpc node instance?
10:45 < instagibbs> rpc test*
10:47 < jonasschnelli> instagibbs: i do that often... let me check...
10:49 < jonasschnelli> instagibbs: this is my snipped:
10:49 < jonasschnelli> http://0bin.net/paste/jZuj8LLRSDoQdNkJ#XXGoCkylN0Cjy3v1iDov9l6dzT-eaaQ/6xFz+gKmMBV
10:50 < jonasschnelli> I start a node with my local IDE&debugger(lldb) and add it via self.nodes.append(proxy)
10:50 < jonasschnelli> I guess you could also add a sleep or a readline and attach gdb and continue after a successfull attach
10:51 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]     
10:53 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
10:57 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
11:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:05 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 250 seconds]     
11:06 < instagibbs> (after digging solution) I just set_trace like normal in python, then used gdb attach. Thanks jonasschnelli 
11:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
11:13 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
11:20 < GitHub83> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3665483be7be...82077ef6e49a
11:20 < GitHub83> bitcoin/master 8f329f9 instagibbs: Add common failure cases for rpc server connection failure
11:20 < GitHub83> bitcoin/master 82077ef Wladimir J. van der Laan: Merge #9073: Trivial: Add common failure cases for rpc server connection failure...
11:20 < GitHub32> [bitcoin] laanwj closed pull request #9073: Trivial: Add common failure cases for rpc server connection failure (master...rpcnoconnectstring) https://github.com/bitcoin/bitcoin/pull/9073
11:21 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:27 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 265 seconds]     
11:39 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:48 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:53 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
11:58 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
11:59 < luke-jr> morning :p
12:00 < achow101> meeting?
12:00 < instagibbs> i believe so
12:00 < Chris_Stewart_5> ding?
12:00 <@wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Nov  3 19:00:39 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < sipa> meeting!
12:00 <@wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012
12:01 < gmaxwell> hi     
12:01 < jonasschnelli> here
12:01 < jtimon> hello
12:01 < GitHub136> [bitcoin] TheBlueMatt opened pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (master...net_processing_4) https://github.com/bitcoin/bitcoin/pull/9075
12:01 < BlueMatt> second to last one ^
12:01 <@wumpus> BlueMatt: you just keep reopening it after we merge it, isn't it :)
12:01 <@wumpus> proposed topics?
12:02 < BlueMatt> wumpus: E_NO_PARSE, but, yes, all this stuff is pretty much queued up, once one gets merged another gets pr'd
12:02 <@wumpus> no topics at all for this meeting?
12:03 <@wumpus> did the pre-final alert go out gmaxwell?
12:03 < achow101> it did
12:03 <@wumpus> ok, great
12:03 < sipa> did anyone see it?
12:03 < btcdrak> hi     
12:03 < sdaftuar> i did
12:03 < achow101> I caught it on a 0.12.0 node I fired up just for it
12:04 < sipa> gmaxwell and i were talking recently about some improvements to the block/header fetch logic
12:04 <@wumpus> #topic block header/fetch logic
12:05 < sipa> there are a bunch of related points there
12:05 < sipa> one is that we don't have a timeout for headers requests
12:05 < jtimon> BlueMatt: is there a long branch where I can see the code movements you're planning?
12:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 265 seconds]     
12:05 < sipa> and that we don't respond to headers requests while in IBD, which can cause stalls if nodes mistakenly believe they are in IBD
12:06 < sipa> bit it goes even further... the block fetch logic only disconnects peers who slow down the process
12:06 < sipa> we may just have a peer who has no blocks we can fetch at all from, and we never try, and we never disconnect them
12:06 < arubi> I have it on onlynet=onion
12:06 < BlueMatt> jtimon: working on an updated version now
12:07 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:07 < sdaftuar> sipa: eg non-NODE_WITNESS nodes?
12:07 < jtimon> BlueMatt: cool
12:07 < sipa> sdaftuar: or nodes who are legitimately behind
12:07 < sdaftuar> ah, right
12:07 < sipa> so it seems there is a simple solution: disconnect outgoing connections you're not downloading from while in IBD
12:07 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 250 seconds]     
12:08 < sipa> but remove the non-response to getheaders in IBD
12:08 < jonasschnelli> sipa: ack
12:08 < sipa> if the peer actually is behind, we won't fetch from them, and we'll disconnect them instead of stalling yhem
12:09 < sipa> gmaxwell suggested something even stronger: ever minute, disconnect the peer that is slowest to give you blocks overall (during IBD)
12:09 < sdaftuar> if we remove the non-response to getheaders in IBD, mightn't we disconnect people who are downloading from us?
12:09 < jonasschnelli> During IBD?
12:10 < sipa> sdaftuar: note that this is only for outgoing connections
12:10 < sdaftuar> ah     
12:10 < sipa> i think serving blocks to someone who is even more behind than us, whike we are in IBD, is perfectly fine
12:10 < gmaxwell> I believe my suggestion went further, if you have MAX outbound, and it's been a minute since you disconnected anyone, and you're downloading blocks, disconnect the outbound peer you recieved the fewest blocks from in the last minute. (or, least recently recieved a block from). Presumably excempting -connect peers.
12:11 < gmaxwell> (ah pieter just said some of that)
12:11 < jonasschnelli> What about prioritize peers that can server "faster" (don't know if it's really measurable)
12:12 < sdaftuar> sipa: one complication with serving headers during IBD is that we might be on a bogus chain
12:12 < sipa> jonasschnelli: that's what we already do... the slowest ones get disconnected if they slow your overall sync speed down
12:12 < jonasschnelli> sipa: ah
12:12 < sipa> sdaftuar: that's something better IBD/chainpoint replacement is for, i guess?
12:13 < sipa> *checkpoint
12:13 < jonasschnelli> during my SPV work I encountered some stalling because of peers serving blocks each in a ~5min rhythm. 
12:13 < sdaftuar> i thought gmaxwell's PR to replcae the checkpointed-height with a checkpointed work as a way to determine if you're in IBD makes sense
12:14 < sdaftuar> so if we eliminate the IBD restriction on serving headers, we'd still want to keep some version of that checkpointed-work requirement i think
12:15 < sdaftuar> which i guess would be fine?
12:15 < sdaftuar> and an improvement over the current situation
12:15 < sdaftuar> ?     
12:15 < kanzure> hi.     
12:15 < sipa> i think so
12:15 < sipa> it's hard to reason about this. if you're truly sybilled during IBD, none of this will have an effect
12:16 < sipa> if not, you'll quickly learn about the real chain anyway
12:16 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 252 seconds]     
12:17 < Chris_St1> sipa: So that pull request does not help if you are fully sybilled? Won't you at least be able to determine if there was a lot of work expended in the sybil attack? (not sure how reassuring that is)
12:17 < gmaxwell> this is going offtopic. :)
12:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
12:18 < gmaxwell> sipa: sdaftuar is pointing out that if we're on a checkpoint invalid chain, and serve headers for it, our peers will ban us. So thats a complication with serving headers while below the top checkpoint.
12:18 < sipa> ah.     
12:19 < sdaftuar> right, so assuming we are keeping the checkpoint-work-requirement (or some version of it) as a gate on responding to a getheaders, then which of the IBD checks are we trying to eliminate?
12:19 < sdaftuar> from past conversations i think the concern is that we might have some long headers chain that we can't access/download blocks towards, like on testnet or something
12:19 < sdaftuar> is that basicalyl right?
12:20 < gmaxwell> We'd like to eliminate all cases where we simply ignore a getheaders request (potentially replace it with hanging up on the peer)-- because it DOS attacks peers unlucky enough to select us for their initial headers fetch.
12:20 < sipa> we only serve headers for blocks in our main chain, no?
12:20 < sdaftuar> sipa: yes
12:20 < sipa> which indeed may contains dummy low difficulty blocks
12:21 < gmaxwell> In any case, the download part of this can be done first before any change to how we respond to getheaders.
12:21 < sipa> right
12:21 < morcos> gmaxwell: thanks, i think it was important to clearly delineate the problem.  i didn't know what we were trying to accomplish.  it doesn't seem that having a bunch of IBD nodes able to serve each other as much as they have is _that_ beneficial
12:22 < morcos> however freeing them up to ask someone else for headers withotu waiting for a long timeout seems valuable
12:22 < GitHub84> [bitcoin] TheBlueMatt closed pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930
12:22 < gmaxwell> morcos: yes, thats mostly irrelevant, the concern is primarily that we cause harm to peers by not responding.
12:22 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
12:22 < gmaxwell> morcos: My recollection is that currently we don't even have a timeout for the initial headers fetch! the 'timeout' is a new block being offered by some other peer.
12:23 < sdaftuar> so step 1: #9068?
12:23 < sipa> morcos: right... i think by using a "kick peers that aren't useful for sync" generic approach, we won't need the "don't serve headers while in IBD" anyway... less comllexity
12:23 < sipa> *complexity
12:24 < luke-jr> (suggested topic: when to halt changes to BIPs; 0.13.1 is no longer BIP 152-compatible I think)
12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9068 | Timeout for headers fetch · Issue #9068 · bitcoin/bitcoin · GitHub
12:24 < gmaxwell> That should be fixed as well, but even with it fixed it would be rude to make them wait.
12:28 <@wumpus> 0.13.1 is no longer BIP 152 compatible?
12:28 < sdaftuar> well, it seems to have some bugs
12:28 < sipa> switch topic?
12:28 <@wumpus> #topic BIP 152 changes
12:29 < sipa> 0.13.1 does not relayever before validating, right?
12:29 <@wumpus> but if it has bugs, was it ever BIP 152 compatible?
12:29 <@wumpus> or were the bugsin the BIP
12:29 < sdaftuar> sipa: correct
12:29 < BlueMatt> 0.13.1 is bip 152 compatible after sdaftuar's proposed changes
12:29 < BlueMatt> which was merged
12:29 < BlueMatt> sipa: yes, but it can ban in response to a peer doing that
12:29 < BlueMatt> sipa: the bip has been updated to say that you may no longer pre-relay unless there was a version bump
12:29 < BlueMatt> which is #9026
12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar · Pull Request #9026 · bitcoin/bitcoin · GitHub
12:30 < sipa> so the issue is only when potential other bip152 implementations are oresent on the network
12:30 < sdaftuar> right
12:30 < BlueMatt> sipa: yes, but no such implementations exist, and if they do it now they must wait for the protocol version
12:30 < sipa> so i believe 0.13.1 is compliant with the updated bip152
12:30 < BlueMatt> yes     
12:30 < sdaftuar> yes, i think so as well.
12:30 < gmaxwell> sipa: unfortunately because of the checkpoint stupidity we may still. :(
12:30 < gmaxwell> but lets think about that outside of the meeting.
12:30 < gmaxwell> 0.13.0 did too.
12:30 < gmaxwell> But I think what luke was referring to is that BIP152 didn't originally document version 2 compact blocks that use the wtxid instead.
12:30 < luke-jr> wumpus: people are changing BIP 152 still
12:31 < gmaxwell> Luke's question was really about when should someone be told 'write a new BIP' rather than changing an existing one.
12:31 < sipa> yes, this is a good question
12:32 < luke-jr> I may be wrong about the current status of v0.13.1 and BIP 152, but yes, the general principle is what I think needs to be discussed
12:32 < gmaxwell> Not really much of a question for this meeting though, perhaps solicit input on the mailing list?
12:32 < luke-jr> I didn't realise v0.13.1 bumped the protocol version-number
12:32 < sdaftuar> it didn't
12:32 < luke-jr> hmm, ok
12:33 < morcos> i don't think its realistic to think we're going to not want to make small tweaks to complicated BIP's like this after releasing implementations of it.  and it seems much clearer in the future to just edit the original bip to reflect the fully thought out final design
12:33 < luke-jr> sdaftuar: then how is it BIP 152 compatible iwth your change?
12:33 < sdaftuar> luke-jr: it imposes a restriction on code to not do something (which no one is currently doing) unless the recipient is at-or-above the bumped version number
12:33 < sdaftuar> in this case, relay before full validation
12:35 < gmaxwell> luke-jr: for the specifics here, 0.13.1 is compatible with BIP152 because it implements a new version number that the original bip152 was just silent on. 
12:35 < luke-jr> it says "nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header" unconditionally, and says nodes should bump the version number
12:36 < gmaxwell> and BIP152 already explained how versions were to be handled in a compatible way.
12:36 < gmaxwell> luke-jr: re banning it's just a bug that all prior versions have as well.
12:37 < BlueMatt> oh, well that is a language mistake
12:37 < BlueMatt> by that language, indeed, 0.13.1 violates a SHOULD NOT
12:37 < BlueMatt> however, this wont effect functionality, as we're a) fixing this as if it were a bug, b) we say you SHOULD NOT announce without validation if the number is below
12:37 < luke-jr> ok     
12:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:39 < luke-jr> BlueMatt: with this change, as the author are you comfortable with a freeze to the BIP so we can move it forward to Final status?
12:39 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
12:40 < gmaxwell> is there a reason to rush?
12:40 <@wumpus> is this about https://github.com/bitcoin/bitcoin/pull/9058? there was also talk of a protocol change there
12:40 < BlueMatt> luke-jr: after https://github.com/bitcoin/bips/pull/469, yea, probably
12:40 < BlueMatt> but need to review tht
12:40 < BlueMatt> at     
12:41 <@wumpus> I thought it mentioned a BIP change, but doesn't seem to mention that anymore
12:41 < luke-jr> BlueMatt: how will existing nodes react if they get a full block message there?
12:41 < morcos> i don't see why we should Finalize it at all until we've stopped changing it for 6-12 mos
12:42 <@wumpus> morcos: makes sense to not finalize too soon, it's unrealistic to expect a bip to come into being completely perfect
12:42 < sipa> i think it depends
12:42 < gmaxwell> Agreed with Morcos. Though for things like consensus code, really being widely active on the network defines final.
12:42 < sipa> there shouldn't be material changes to ideas
12:42 < luke-jr> no particular reason to rush, I guess, just feels like a moving goal for anyone who wanted to be compatible with it
12:43 < gmaxwell> luke-jr: at least they are minor alterations.
12:43 <@wumpus> that's always the case. Others could also report problems encountered during implementing it
12:43 < sipa> but clarifications and elaborating on edge cases is something else
12:43 < morcos> gmaxwell: heh, even there, its a matter of whether we are confident that we've really understood what the consensus is.   but yeah i agree it shoudl depend on the changes we want to make.
12:43 < luke-jr> sipa: sure, we still make clarifications to Final BIPs even now I think
12:43 < BlueMatt> luke-jr: agreed, it sucks that its still moving, but currently there are no other implementors (except XT, which I believe is still moving as well)
12:43 <@wumpus> it could also move because of problems other implementors find
12:44 < luke-jr> since it's being used live on the network, changes also should probably address backwards compatibility, which they aren't in this case
12:45 <@wumpus> it's just unrealsitic to expect not even small issues in wording/clarity/definitions, although I guess if it is in a release there should not be substantial incompatible changes anymore
12:45 < gmaxwell> morcos: so interesting point, say we discovered that BIP30 was implemented differently from the BIP tomorrow. What should we do?   IETF way would be to attach an erratum to the document right away. But I find that this often confuses people who manage to read the document without an erratum. Then later a new document is published that reflects reality.  Though this has a problem that people reme
12:45 < gmaxwell> mber the original number. 
12:45 < gmaxwell> If no one of consequence actually implemented BIP30 as specified in the doc, what use does keeping the old doc around (except in the git history) serve?
12:45 <@wumpus> yes, those at least will need to address backwards compatibilty
12:46 < luke-jr> gmaxwell: I *think* we've fixed such issues in Final BIPs already
12:46 < BlueMatt> gmaxwell: we're not plaintext, lets highlight it in red! :p
12:46 < luke-jr> >_<     
12:46 < morcos> yes, BIP 34 for example
12:47 < morcos> ehh, i guess that was just wrong explanation
12:47 < luke-jr> BIP 16
12:48 < luke-jr> https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size
12:48 < gmaxwell> BlueMatt: the erratum link on the ietf website is red, https://tools.ietf.org/html/rfc6716
12:48 < gribble> https://github.com/bitcoin/bitcoin/issues/520 | log low-level network messages only when fDebug is set by tcatm · Pull Request #520 · bitcoin/bitcoin · GitHub
12:48  * luke-jr looks at gribble
12:49 < gmaxwell> I warned about that!
12:49 < gmaxwell> In any case, I still think that the BIP discussion belongs elsewhere. :)
12:50 < morcos> well you come up with something else to talk about for 11 more minutes then!
12:51 < gmaxwell> wumpus: sipa: thanks for merging lots of stuff!
12:51 < BlueMatt> <3     
12:51 < sdaftuar> +1     
12:51 <@wumpus> I think there was some pull where we wondered whether to backport to 0.13.2
12:51 <@wumpus> np :)
12:51 < BlueMatt> making 0.14 great again!
12:51 <@wumpus> https://github.com/bitcoin/bitcoin/pull/9053
12:51 < jtimon> topic potential backports to 0.13.2 ?
12:52 <@wumpus> I don't think there's time enough to discuss all potential backports to 0.13.2, but that one would do
12:53 < gmaxwell> I think it would be harmless to backport, and helpful for testnet nodes.  But I don't have a strong opinion. 
12:53 < gmaxwell> oh I see sipa mentioned testnet.
12:54 <@wumpus> so I guess in practice it fixes testnet issues only on 0.13.2, so the question would be is that worth it to potential regressions?
12:54 < sdaftuar> it's not that much of a fix for testnet right, it just allows you to reorg out the non-segwit chain?
12:55 < gmaxwell> it does actually fix a misbehavior that we see on testnet. <famous last words>I can't see it causing a regression.</famous last words>
12:55 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]     
12:55 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
12:55 < gmaxwell> sdaftuar: because of the 20 minute rule in general it's very easy to get testnet nodes into a state where they just stop mining. Trivial vulnerablity, the active issue is that the non-segwit chain there unintentionally triggers it from time to time.
12:56 < gmaxwell> ('stop mining' is ambigious, they won't mine after they're restarted)
12:56 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
12:56 < sdaftuar> fwiw i have a few bridges of my own back up now that i hope will keep that from happening again
12:56 < sdaftuar> can you elaborate on the 20 minute rule though?
12:57 < sdaftuar> oh     
12:57 <@wumpus> I think personally I'd prefer to keep it for 0.14, so the new rule/logic can prove itself a while
12:57 < gmaxwell> sdaftuar: the issue is that if anyone produces a lot of headers beyond your current tip which you accept (made computationally easy by the diff1 blocks) then you'll not leave IBD. 
12:58 < sdaftuar> got it
12:58 < gmaxwell> sdaftuar: the non-segwit chain does this by accident through a confluence of other behaviors (the not fetching blocks from non-witness peers). But the real bug is just using forward header count to cause you to not leave ibd.
12:58 < gmaxwell> which that PR fixes.
12:58 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
12:58 -!- LeMiner2 is now known as LeMiner     
12:58 < sipa> wumpus: ok, we can of course later decide to backport to whatever 0.13.x at that time
12:59 <@wumpus> sipa: yes
12:59 < gmaxwell> sounds fine to me.
12:59 <@wumpus> that doesn't prohibit backporting it later
12:59 < gmaxwell> because of the latching in IBD this code is pretty robust against mistbehavior to begin with.
12:59 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
13:00 < sipa> $-+(#(_+$+ PC LOAD LETTER
13:00 <@wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Nov  3 20:00:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.log.html
13:00 < gmaxwell> Thanks all!
13:02 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has joined #bitcoin-core-dev     
13:03 < BakSAj> hi     
13:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:03 < BakSAj> meeting in progress?
13:04 < BlueMatt> over :/
13:04 < jtimon> BakSAj: no, it just finished
13:04 < GitHub16> [bitcoin] jonasschnelli opened pull request #9076: [WIP][Experimental] Add Hybrid full block SPV mode (master...2016/10/spv) https://github.com/bitcoin/bitcoin/pull/9076
13:05 < BakSAj> oh, moved to 8pm or ...smth to do with daylight saving change?
13:05 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
13:05 < jtimon> BakSAj: it's fixed to UTC, so yes its because your time zone changed
13:06 < gmaxwell> The meeting time is in GMT, otherwise it moves 6 times a year (for different people).
13:06 < BakSAj> makes sense :-)
13:06 < BakSAj> i will reread the log
13:06 <@wumpus> you should put it in your calendar in Reykjavik time, which is a city in an awesome country in UTC+0 that has no DST nonsense
13:07 < BakSAj> btw, do we have feature list for 0.14 yet?
13:07 < sipa> BakSAj: whatever makes it before the feature freeze :)
13:07 <@wumpus> master is always the most up to date branch, everything in there will make it into 0.14
13:07 < jtimon> wumpus: I heard the country is governed by pirates
13:07 < BlueMatt> BakSAj: rainbows and unicorns and ponies and shit
13:07 <@wumpus> unless reverted ofcourse but that's rare
13:07 < BakSAj> :-D     
13:08 < sipa> wumpus: they have no need for DST... they either have 24 hour daylight or 24 hiur darkness :p
13:08 < BakSAj> even my wife laughts at this :-)
13:08 <@wumpus> of the 125 PRs currently open, a few will likely make it too, you can help by testing and reviewing and posting your results
13:08 <@wumpus> sipa: hehe, good point :p
13:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
13:09 < GitHub96> [bitcoin] ryanofsky opened pull request #9077: [qa] Increase wallet-dump RPC timeout (master...fix-wallet-dump-timeout) https://github.com/bitcoin/bitcoin/pull/9077
13:09 < BakSAj> can I get just one feature which 0.14 will be remembered for? like 0.13 was for compact blocks, 0.13.1 segwit etc..
13:10  * BlueMatt is still hopeful that main.cpp gets split and compact block announcements in the background happen for 0.14
13:10 < BlueMatt> happen at process-time, that is
13:10 <@wumpus> I wonder if we have any contributors from Iceland
13:10 < BakSAj> polar bears?
13:11 < sipa> BakSAj: seems there is a lot of focus on refactorings and performance imorovememts... so not necessarily user visiable changes
13:11  * jtimon dreams of one or even 2 more functions exposed in libconsensus
13:11 < sipa> BakSAj: i prefer cartesian bears
13:11 < BakSAj> i will have to google that :-)
13:11 <@wumpus> polar bears don't live in iceland
13:12 < sipa> iceland isn't even above the polar circle
13:12 < BakSAj> not even in the zoo?
13:13 < BakSAj> http://i.imgur.com/z0Sl2XP.jpg
13:14 < BakSAj> sipa: ok thanks, thats also good, i guess schnorr is longrun task
13:14 < BlueMatt> BakSAj: 0.14 has been a lot of fixes/refactoring/cleanups/optimizations/etc/etc...due to a focus on segwit some of these things got put off and/or big features werent something that was a major focus for lots of people
13:15 < luke-jr> BakSAj: does that one on the right really exist? :O
13:15 < sipa> luke-jr: no, it's a math joke
13:16 < BakSAj> luke-jr: only after you forget your bear in the box for some time
13:16 < luke-jr> someone made a fake bear for a math joke? XD
13:16 < jtimon> luke-jr: photoshop or something, yeah
13:17 < luke-jr> o.o     
13:17 < BlueMatt> oh, sipa said that
13:17 < BlueMatt> BakSAj: bumpfee might make it in though, so that would be cool
13:17 < jtimon> luke-jr: I'm actually surprised that you are surprised
13:18 < luke-jr> jtimon: I would have tried to get bear skin and paste it on a set of boxes :p
13:18 < luke-jr> didn't even occur to me to try to make such an image with a computer
13:19 < jtimon> not an expert, but I would bet that one is actually not that hard
13:19 < BakSAj> yeah like segwit :-)
13:19 < BakSAj> btw i really wonder how ecosystem will change once sw activates and LN will come to existence
13:21 < BakSAj> lol rereading the log: this is really a good one :-)) BlueMatt making 0.14 great again!
13:22 < BakSAj> i vote it for comic relief
13:26 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev     
13:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
13:34 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]     
13:43 < luke-jr> hum, after taking forever to start in valgrind, I got a segfault. fun
13:44 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has quit [Quit: Page closed]     
13:45 < luke-jr> not sure how to interpret the stack trace however
13:45 < luke-jr> http://0bin.net/paste/-EkiuN3jdVtwRd0v#3NfjE9HJqmxNwuiil0FZXv+9QgmQr0Fv+VAp9Qzrd3H
13:46 < gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
13:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:47 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds]     
13:47 < sipa> nanotube: ^ gribble is a bit too trigger happy... maybe make the regexp only work when it's not surrounded by alphanumeric characters?
13:48 < gmaxwell> I was suggesting before that it only do PR#[0-9]+
13:48 < sipa> that sounds good as well
13:48 <@wumpus> though that wouldn't handle issues
13:49 < gmaxwell> hm.  \w[PIG]#[0-9]+\w  ?
13:50 < gmaxwell> (PR, Issue, 'github' for when you don't know/care)
13:55 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
13:56 <@wumpus> PIG#1234 sgtm :p
13:56 < gribble> https://github.com/bitcoin/bitcoin/issues/1234 | During initial sync, chain download pauses if peer goes away · Issue #1234 · bitcoin/bitcoin · GitHub
13:58 < luke-jr> gmaxwell: that won't work for PR# :P
14:01 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
14:03 < nanotube> heh well, so let's go over this... you want PR#\d+\W to go to github pr, I#\d+\W to go to github issues, and just #\d+\W to just assume issue?
14:06 < luke-jr> (^|\s)(PR|I)#\d+\b I think
14:06 < luke-jr> explicitly *not* #\d+
14:06 < BlueMatt> lol     
14:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
14:11 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
14:18 < BlueMatt> jtimon: the main.cpp split is my net_processing_file branch, which includes #9026, #9075, #8930 in rebased form, 4 more commits to form a future pr, and then -2990 +3085 LOC in a single code-move commit
14:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar · Pull Request #9026 · bitcoin/bitcoin · GitHub
14:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
14:18 < gribble> https://github.com/bitcoin/bitcoin/issues/8930 | Move orphan processing to ActivateBestChain by TheBlueMatt · Pull Request #8930 · bitcoin/bitcoin · GitHub
14:20 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]     
14:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
14:21 < jtimon> BlueMatt: awesome thanks!
14:22 -!- cryptapus_afk is now known as cryptapus     
14:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:39 < jouke> What does it mean when a wallet says: "Transaction commit failed" I blieve it's a .12 wallet
14:45 < jouke> Hmm, corrupt /win 109
14:45 < jouke> whoops
14:47 < jouke> Hmm, but the specific transaction seems to be broadcasted though?
14:49 < sipa> i believe it means it wasn't accepted by your own mempool, but still broadcast
14:49 < sipa> that shouldn't happen
14:50 < sipa> if it confirms, it will show up in the wallet fine, though
14:50 < jouke> Hmm, rpc doesn't give a tx-id back, so I am not sure if it's absolutely the same
14:50 < jouke> but the outputs match, so I guess so
14:51 < jouke> Other transaction from the same wallet: "Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."
14:51 < jouke> also broadcasted
14:51 < jouke> and confirmed
14:54 < jouke> gettransaction shows the account
14:56 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
14:58 -!- murr4y [~murr4y@17.57.211.130.bc.googleusercontent.com] has quit [Remote host closed the connection]     
14:59 < jtimon> rebased https://github.com/bitcoin/bitcoin/pull/8855
15:02 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
15:07 < jouke> sipa: that wallet node is connected to an other node on the same host via 127.0.0.1. Could that be a reason why it's broadcasted even though the wallet itself says it's not valid?
15:08 < sipa> i don't think so
15:15 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]     
15:16 -!- justanother|CHI is now known as justanother|DJT     
15:25 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
15:35 -!- cryptapus is now known as cryptapus_afk     
15:41 < jtimon> rebased #8994 and jtimon/0.13-blocksign branch too for the curious (the latter still needs more work)
15:41 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
15:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:57 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
16:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 250 seconds]     
16:02 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
16:24 -!- Anduck [~Anduck@unaffiliated/anduck] has quit [Ping timeout: 252 seconds]     
16:24 -!- Anduck [~Anduck@unaffiliated/anduck] has joined #bitcoin-core-dev     
16:24 -!- Eliel [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has quit [Ping timeout: 256 seconds]     
16:25 -!- Eliel [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has joined #bitcoin-core-dev     
16:58 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
17:03 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
17:32 < murch> Does signaling start with the epoch time listed in the Deployment on BIP141 or with the first difficulty retarget after the epoch time listed in deployment?
17:37 < murch> Nevermind, reading BIP0009 now. :p
17:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
17:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
17:49 < murch> Answer is only with the next retarget, if anyone is interested. ;)
17:54 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:59 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev     
18:00 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
18:00 -!- echonaut6 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
18:00 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
18:04 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]     
18:04 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
18:07 < sipa> murch: indeed :)
18:08 < murch> sipa: So, did you have a chance to take a glimpse at my thesis? :)
18:08 < sipa> murch: i haven't
18:08 < murch> Ah, I'm really curious what you'll think.
18:09 < murch> (if you have time)
18:16 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
18:16 < phantomcircuit> wumpus: can you take another look at #8831 ?
18:16 < gribble> https://github.com/bitcoin/bitcoin/issues/8831 | Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue by pstratem · Pull Request #8831 · bitcoin/bitcoin · GitHub
18:17 < phantomcircuit> (i'm going to rebase now)
18:17 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]     
18:18 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
18:42 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
18:43 -!- pigeons [~pigeons@94.242.209.214] has quit [Quit: leaving]     
18:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 250 seconds]     
18:57 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
19:01 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:05 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
19:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
19:07 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Remote host closed the connection]     
19:17 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-salhegiybjoqgylo] has quit [Quit: Connection closed for inactivity]     
19:17 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev     
19:18 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev     
19:18 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:18 -!- murch [~murch@p4FE3A3AE.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]     
19:20 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zdopouejucqqtdta] has quit [Quit: Connection closed for inactivity]     
19:23 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
19:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
19:28 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:41 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
19:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
19:58 -!- abpa [~abpa@2604:5500:16:6:895:9cdc:2e44:cdc4] has joined #bitcoin-core-dev     
20:38 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
20:40 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Client Quit]     
20:48 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
20:50 < GitHub47> [bitcoin] rebroad opened pull request #9082: Fix peer selection so that non-Witness peers are still connected to (master...FixPeerSelection) https://github.com/bitcoin/bitcoin/pull/9082
20:58 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:690f:de64:957d:87df] has quit [Quit: .]     
20:58 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b074:f626:8684:3aed] has joined #bitcoin-core-dev     
21:18 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
21:19 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Ping timeout: 244 seconds]     
21:19 -!- PRab_ is now known as PRab     
21:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]     
21:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:51 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-idigxjbhlxwczzpd] has joined #bitcoin-core-dev     
21:51 -!- rebroad [~rebroad@175.145.246.181] has joined #bitcoin-core-dev     
21:55 < rebroad> gmaxwell, in response to your comment to #9061 - it's already ignoring getheaders - this pull make it ignore less of them
21:55 < gribble> https://github.com/bitcoin/bitcoin/issues/9061 | Ignore getheaders prior to passing all checkpoints. by rebroad · Pull Request #9061 · bitcoin/bitcoin · GitHub
22:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:42 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds]     
22:46 -!- rebroad [~rebroad@175.145.246.181] has quit [Ping timeout: 260 seconds]     
22:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:02 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds]     
23:03 -!- owowo [ovovo@gateway/vpn/mullvad/x-fxzjytlupubuqbba] has quit [Ping timeout: 244 seconds]     
23:13 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 252 seconds]     
23:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
23:29 -!- rebroad [~rebroad@175.145.234.89] has joined #bitcoin-core-dev     
23:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qyskawhqdybigtqr] has joined #bitcoin-core-dev     
23:47 -!- rebroad [~rebroad@175.145.234.89] has quit [Ping timeout: 250 seconds]     
23:50 -!- DigiByteDev [~JT2@124.217.188.144] has joined #bitcoin-core-dev     
23:50 -!- DigiByteDev [~JT2@124.217.188.144] has quit [Client Quit]     
23:59 -!- rebroad [~rebroad@115.133.231.241] has joined #bitcoin-core-dev