12016-11-03T00:09:13  *** Chris_Stewart_5 has quit IRC
  22016-11-03T00:12:03  *** zooko has joined #bitcoin-core-dev
  32016-11-03T00:13:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  42016-11-03T00:13:15  *** fengling has joined #bitcoin-core-dev
  52016-11-03T00:18:09  *** fengling has quit IRC
  62016-11-03T00:21:47  *** waxwing has quit IRC
  72016-11-03T00:22:32  *** waxwing has joined #bitcoin-core-dev
  82016-11-03T00:30:26  <GitHub32> [bitcoin] sipa opened pull request #9071: Declare wallet.h functions inline (master...walletinline) https://github.com/bitcoin/bitcoin/pull/9071
  92016-11-03T00:47:54  *** btcdrak has quit IRC
 102016-11-03T00:56:05  *** abpa has quit IRC
 112016-11-03T01:06:18  *** Chris_Stewart_5 has quit IRC
 122016-11-03T01:11:55  <luke-jr> hmm, CAddrMan::Unserialize is insane slow in valgrind
 132016-11-03T01:14:17  *** fengling has joined #bitcoin-core-dev
 142016-11-03T01:16:47  *** zooko has quit IRC
 152016-11-03T01:19:12  *** fengling has quit IRC
 162016-11-03T01:20:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 172016-11-03T01:25:45  *** zooko has joined #bitcoin-core-dev
 182016-11-03T01:30:10  *** Ylbam has quit IRC
 192016-11-03T01:31:00  *** zooko has quit IRC
 202016-11-03T01:37:45  *** zooko has joined #bitcoin-core-dev
 212016-11-03T01:53:47  *** echonaut5 has quit IRC
 222016-11-03T01:53:55  *** echonaut has joined #bitcoin-core-dev
 232016-11-03T01:58:17  *** tunafizz has quit IRC
 242016-11-03T01:59:50  *** Chris_Stewart_5 has quit IRC
 252016-11-03T02:03:05  *** zooko has quit IRC
 262016-11-03T02:15:08  *** fengling has joined #bitcoin-core-dev
 272016-11-03T02:16:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 282016-11-03T02:36:03  *** Chris_Stewart_5 has quit IRC
 292016-11-03T02:42:46  *** jtimon has quit IRC
 302016-11-03T02:49:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 312016-11-03T03:06:34  *** Chris_Stewart_5 has quit IRC
 322016-11-03T03:12:11  *** abpa has joined #bitcoin-core-dev
 332016-11-03T03:22:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 342016-11-03T03:36:28  *** Arnavion has quit IRC
 352016-11-03T03:37:52  *** Arnavion has joined #bitcoin-core-dev
 362016-11-03T03:40:55  *** rebroad has joined #bitcoin-core-dev
 372016-11-03T03:41:26  <rebroad> I've enabled debugging and I'm seeing POTENTIAL DEADLOCK DETECTED messages... are these bad?
 382016-11-03T03:51:13  *** Giszmo has quit IRC
 392016-11-03T03:57:12  *** To7 has quit IRC
 402016-11-03T04:07:24  *** rebroad has quit IRC
 412016-11-03T04:52:07  *** btcdrak has joined #bitcoin-core-dev
 422016-11-03T04:59:30  *** justanotheruser is now known as justanother|CHI
 432016-11-03T05:28:06  *** Alopex has quit IRC
 442016-11-03T05:29:12  *** Alopex has joined #bitcoin-core-dev
 452016-11-03T05:41:17  *** Alopex has quit IRC
 462016-11-03T05:42:22  *** Alopex has joined #bitcoin-core-dev
 472016-11-03T05:55:02  *** juscamarena has joined #bitcoin-core-dev
 482016-11-03T06:29:30  *** juscamarena has quit IRC
 492016-11-03T06:36:46  <GitHub5> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9bdf9a75f9f...ed0cc50afed1
 502016-11-03T06:36:47  <GitHub5> bitcoin/master 0fdf810 Wladimir J. van der Laan: wallet: Change default confirm target from 2 to 6...
 512016-11-03T06:36:47  <GitHub5> bitcoin/master ed0cc50 Pieter Wuille: Merge #9036: wallet: Change default confirm target from 2 to 6...
 522016-11-03T06:37:00  <GitHub44> [bitcoin] sipa closed pull request #9036: wallet: Change default confirm target from 2 to 6 (master...2016_10_txconfirmtarget) https://github.com/bitcoin/bitcoin/pull/9036
 532016-11-03T07:09:21  <GitHub46> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed0cc50afed1...508404de98a8
 542016-11-03T07:09:21  <GitHub46> bitcoin/master fd46136 Gregory Maxwell: IBD check uses minimumchain work instead of checkpoints....
 552016-11-03T07:09:22  <GitHub46> bitcoin/master 2082b55 Gregory Maxwell: Remove GetTotalBlocksEstimate and checkpoint tests that test nothing....
 562016-11-03T07:09:22  <GitHub46> bitcoin/master e141beb Gregory Maxwell: IsInitialBlockDownload no longer uses header-only timestamps....
 572016-11-03T07:09:29  <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
 582016-11-03T07:24:38  *** Cheeseo has quit IRC
 592016-11-03T07:31:44  *** kadoban has quit IRC
 602016-11-03T07:40:46  *** Ylbam has joined #bitcoin-core-dev
 612016-11-03T07:51:53  *** BashCo has quit IRC
 622016-11-03T08:16:29  *** BashCo has joined #bitcoin-core-dev
 632016-11-03T08:35:12  *** Guyver2 has joined #bitcoin-core-dev
 642016-11-03T08:38:38  *** atroxes has quit IRC
 652016-11-03T08:47:10  *** atroxes has joined #bitcoin-core-dev
 662016-11-03T09:14:50  <GitHub156> [bitcoin] laanwj closed pull request #9061: Ignore getheaders prior to passing all checkpoints. (master...FixGetheadersResponseWhenSyncing) https://github.com/bitcoin/bitcoin/pull/9061
 672016-11-03T09:19:25  *** Guyver2 has quit IRC
 682016-11-03T09:22:38  <luke-jr> lol 2016-11-03 08:34:25 Flushed 65607 addresses to peers.dat  13896962ms
 692016-11-03T09:22:41  <GitHub127> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/508404de98a8...d1871da7fe63
 702016-11-03T09:22:41  <GitHub127> bitcoin/master 2ca882a Pieter Wuille: Declare wallet.h functions inline
 712016-11-03T09:22:42  <GitHub127> bitcoin/master d1871da Wladimir J. van der Laan: Merge #9071: Declare wallet.h functions inline...
 722016-11-03T09:22:50  <GitHub139> [bitcoin] laanwj closed pull request #9071: Declare wallet.h functions inline (master...walletinline) https://github.com/bitcoin/bitcoin/pull/9071
 732016-11-03T09:32:41  *** Sosumi has quit IRC
 742016-11-03T09:45:43  <GitHub52> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d1871da7fe63...fcf61b80fa2c
 752016-11-03T09:45:44  <GitHub52> bitcoin/master aff6584 Cory Fields: net: constify a few CNode vars to indicate that they're threadsafe
 762016-11-03T09:45:44  <GitHub52> bitcoin/master 59ac5c5 Cory Fields: net: Use deterministic randomness for CNode's nonce, and make it const
 772016-11-03T09:45: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...
 782016-11-03T09:45:53  <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
 792016-11-03T09:46:16  *** laurentmt has joined #bitcoin-core-dev
 802016-11-03T09:46:54  *** laurentmt has quit IRC
 812016-11-03T09:53:49  *** murch has joined #bitcoin-core-dev
 822016-11-03T10:02:49  *** Tiraspol has quit IRC
 832016-11-03T10:05:55  *** Chris_Stewart_5 has quit IRC
 842016-11-03T10:07:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 852016-11-03T10:12:20  *** jannes has joined #bitcoin-core-dev
 862016-11-03T10:27:03  *** pedrobranco has joined #bitcoin-core-dev
 872016-11-03T10:28:34  *** xinxi has joined #bitcoin-core-dev
 882016-11-03T11:05:21  *** Chris_Stewart_5 has quit IRC
 892016-11-03T11:09:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 902016-11-03T11:13:03  *** fengling has quit IRC
 912016-11-03T11:31:26  *** DigiByteDev has joined #bitcoin-core-dev
 922016-11-03T11:33:52  *** laurentmt has joined #bitcoin-core-dev
 932016-11-03T11:34:28  *** cryptapus has joined #bitcoin-core-dev
 942016-11-03T11:46:48  *** fengling has joined #bitcoin-core-dev
 952016-11-03T11:51:54  *** fengling has quit IRC
 962016-11-03T12:09:34  *** Giszmo has joined #bitcoin-core-dev
 972016-11-03T12:16:58  *** BashCo_ has joined #bitcoin-core-dev
 982016-11-03T12:19:52  *** BashCo has quit IRC
 992016-11-03T12:27:39  *** DigiByteDev has quit IRC
1002016-11-03T12:35:52  *** xinxi has quit IRC
1012016-11-03T12:36:19  *** xinxi has joined #bitcoin-core-dev
1022016-11-03T12:40:44  *** xinxi has quit IRC
1032016-11-03T12:41:20  *** To7 has joined #bitcoin-core-dev
1042016-11-03T12:47:49  *** fengling has joined #bitcoin-core-dev
1052016-11-03T12:52:57  *** fengling has quit IRC
1062016-11-03T12:53:06  *** atroxes has quit IRC
1072016-11-03T12:53:23  *** atroxes has joined #bitcoin-core-dev
1082016-11-03T12:59:52  *** Chris_Stewart_5 has quit IRC
1092016-11-03T13:00:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1102016-11-03T13:03:05  *** Cheeseo has joined #bitcoin-core-dev
1112016-11-03T13:09:16  *** jtimon has joined #bitcoin-core-dev
1122016-11-03T13:09:38  *** xinxi has joined #bitcoin-core-dev
1132016-11-03T13:19:59  *** xinxi has quit IRC
1142016-11-03T13:20:26  *** xinxi has joined #bitcoin-core-dev
1152016-11-03T13:24:56  *** xinxi has quit IRC
1162016-11-03T13:48:49  *** fengling has joined #bitcoin-core-dev
1172016-11-03T13:54:00  *** fengling has quit IRC
1182016-11-03T13:58:02  <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
1192016-11-03T14:01:47  *** abpa has quit IRC
1202016-11-03T14:14:42  *** pedrobranco has quit IRC
1212016-11-03T14:20:02  *** xinxi has joined #bitcoin-core-dev
1222016-11-03T14:23:09  *** xinxi has quit IRC
1232016-11-03T14:30:02  <BlueMatt> wumpus: any update on #8969? Should I solicit more review?
1242016-11-03T14:30:03  <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
1252016-11-03T14:30:12  <BlueMatt> thanks gribble!
1262016-11-03T14:31:06  *** Chris_Stewart_5 has quit IRC
1272016-11-03T14:33:45  <wumpus> seems ok to me
1282016-11-03T14:41:07  *** eenoch has quit IRC
1292016-11-03T14:46:14  <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
1302016-11-03T14:46:22  <BlueMatt> oh well, good thing i have other routes....
1312016-11-03T14:47:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1322016-11-03T14:49:58  *** fengling has joined #bitcoin-core-dev
1332016-11-03T14:52:20  <instagibbs> where is the rpc test cache directory by default?
1342016-11-03T14:52:41  <BlueMatt>  /tmp/${shit}
1352016-11-03T14:52:48  <sdaftuar> qa/
1362016-11-03T14:52:56  <BlueMatt> oh, cache, yea, qa/
1372016-11-03T14:53:00  <BlueMatt> test runs are /tmp/thing
1382016-11-03T14:53:01  <sdaftuar> qa/cache, i guess
1392016-11-03T14:53:31  <wumpus> yes
1402016-11-03T14:54:45  <instagibbs> ok, looking thanks
1412016-11-03T14:55:03  *** fengling has quit IRC
1422016-11-03T14:57:58  *** Chris_Stewart_5 has quit IRC
1432016-11-03T14:59:46  <instagibbs> actually it appears to be top level directory
1442016-11-03T14:59:50  <instagibbs> bitcoin/cache
1452016-11-03T15:02:03  <sdaftuar> actually i think it depends on where you run the tests from, there are relative paths used in test_framework.py
1462016-11-03T15:03:46  <instagibbs> Ah, I'm running individually from top-level
1472016-11-03T15:04:10  <instagibbs> My cache somehow got corrupted and tests were failing due to this
1482016-11-03T15:04:36  <instagibbs> and if it finds all the nodeX's directories, it never tries to rebuilt it
1492016-11-03T15:07:41  <wumpus> sdaftuar: I'm fairly sure that was made consistent recently
1502016-11-03T15:12:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1512016-11-03T15:32:05  <GitHub173> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/fcf61b80fa2c...3665483be7be
1522016-11-03T15:32:07  <GitHub173> bitcoin/master 65f35eb Matt Corallo: Move FlushStateToDisk call out of ProcessMessages::TX into ATMP
1532016-11-03T15:32:07  <GitHub173> bitcoin/master fc0c24f Matt Corallo: Move MarkBlockAsReceived out of ProcessNewMessage
1542016-11-03T15:32:07  <GitHub173> bitcoin/master d6ea737 Matt Corallo: Remove network state wipe from UnloadBlockIndex....
1552016-11-03T15:32:20  <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
1562016-11-03T15:33:10  *** Victorsueca has joined #bitcoin-core-dev
1572016-11-03T15:42:23  *** eenoch has joined #bitcoin-core-dev
1582016-11-03T15:50:58  *** fengling has joined #bitcoin-core-dev
1592016-11-03T15:56:06  *** fengling has quit IRC
1602016-11-03T16:18:13  *** Sosumi has joined #bitcoin-core-dev
1612016-11-03T16:26:55  *** notmike has joined #bitcoin-core-dev
1622016-11-03T16:27:10  *** notmike has joined #bitcoin-core-dev
1632016-11-03T16:33:15  *** BashCo_ has quit IRC
1642016-11-03T16:40:06  *** echonaut has quit IRC
1652016-11-03T16:40:10  *** echonaut6 has joined #bitcoin-core-dev
1662016-11-03T16:41:39  *** notmike has quit IRC
1672016-11-03T16:46:22  *** abpa has joined #bitcoin-core-dev
1682016-11-03T16:52:00  *** fengling has joined #bitcoin-core-dev
1692016-11-03T16:54:07  *** roidster has joined #bitcoin-core-dev
1702016-11-03T16:54:25  *** droark has joined #bitcoin-core-dev
1712016-11-03T16:54:46  *** laurentmt has quit IRC
1722016-11-03T16:57:09  *** fengling has quit IRC
1732016-11-03T16:58:12  *** ryanofsky has quit IRC
1742016-11-03T17:01:17  <jtimon> the meeting is in 2 hours, right?
1752016-11-03T17:01:24  <Chris_Stewart_5> Yes
1762016-11-03T17:01:30  <jtimon> thanks
1772016-11-03T17:01:37  <sipa> indeed
1782016-11-03T17:08:45  <cfields_> I won't make the meeting today, boarding a flight now
1792016-11-03T17:10:41  *** ryanofsky has joined #bitcoin-core-dev
1802016-11-03T17:12:20  *** laurentmt has joined #bitcoin-core-dev
1812016-11-03T17:14:53  <wumpus> cfields_: no problem, have a good flight
1822016-11-03T17:16:23  *** laurentmt has quit IRC
1832016-11-03T17:25:44  *** kadoban has joined #bitcoin-core-dev
1842016-11-03T17:41:11  *** BashCo has joined #bitcoin-core-dev
1852016-11-03T17:44:13  *** Chris_Stewart_5 has quit IRC
1862016-11-03T17:45:25  <instagibbs> any tricks on attaching gdb to an rpc node instance?
1872016-11-03T17:45:34  <instagibbs> rpc test*
1882016-11-03T17:47:42  <jonasschnelli> instagibbs: i do that often... let me check...
1892016-11-03T17:49:34  <jonasschnelli> instagibbs: this is my snipped:
1902016-11-03T17:49:35  <jonasschnelli> http://0bin.net/paste/jZuj8LLRSDoQdNkJ#XXGoCkylN0Cjy3v1iDov9l6dzT-eaaQ/6xFz+gKmMBV
1912016-11-03T17:50:06  <jonasschnelli> I start a node with my local IDE&debugger(lldb) and add it via self.nodes.append(proxy)
1922016-11-03T17:50:32  <jonasschnelli> I guess you could also add a sleep or a readline and attach gdb and continue after a successfull attach
1932016-11-03T17:51:30  *** jtimon has quit IRC
1942016-11-03T17:52:46  *** fengling has joined #bitcoin-core-dev
1952016-11-03T17:57:35  *** fengling has quit IRC
1962016-11-03T18:01:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1972016-11-03T18:05:44  *** atroxes has quit IRC
1982016-11-03T18:06:17  <instagibbs> (after digging solution) I just set_trace like normal in python, then used gdb attach. Thanks jonasschnelli
1992016-11-03T18:07:24  *** Chris_Stewart_5 has quit IRC
2002016-11-03T18:13:53  *** atroxes has joined #bitcoin-core-dev
2012016-11-03T18:20:34  <GitHub83> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3665483be7be...82077ef6e49a
2022016-11-03T18:20:34  <GitHub83> bitcoin/master 8f329f9 instagibbs: Add common failure cases for rpc server connection failure
2032016-11-03T18:20:35  <GitHub83> bitcoin/master 82077ef Wladimir J. van der Laan: Merge #9073: Trivial: Add common failure cases for rpc server connection failure...
2042016-11-03T18:20:47  <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
2052016-11-03T18:21:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2062016-11-03T18:27:15  *** Chris_Stewart_5 has quit IRC
2072016-11-03T18:39:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2082016-11-03T18:48:28  *** jtimon has joined #bitcoin-core-dev
2092016-11-03T18:53:54  *** fengling has joined #bitcoin-core-dev
2102016-11-03T18:58:38  *** fengling has quit IRC
2112016-11-03T18:59:34  <luke-jr> morning :p
2122016-11-03T19:00:20  <achow101> meeting?
2132016-11-03T19:00:31  <instagibbs> i believe so
2142016-11-03T19:00:33  <Chris_Stewart_5> ding?
2152016-11-03T19:00:39  <wumpus> #startmeeting
2162016-11-03T19:00:39  <lightningbot> Meeting started Thu Nov  3 19:00:39 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2172016-11-03T19:00:39  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2182016-11-03T19:00:44  <sipa> meeting!
2192016-11-03T19:00:53  <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
2202016-11-03T19:01:02  <gmaxwell> hi
2212016-11-03T19:01:03  <jonasschnelli> here
2222016-11-03T19:01:08  <jtimon> hello
2232016-11-03T19:01:17  <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
2242016-11-03T19:01:18  <BlueMatt> second to last one ^
2252016-11-03T19:01:39  <wumpus> BlueMatt: you just keep reopening it after we merge it, isn't it :)
2262016-11-03T19:01:45  <wumpus> proposed topics?
2272016-11-03T19:02:10  <BlueMatt> wumpus: E_NO_PARSE, but, yes, all this stuff is pretty much queued up, once one gets merged another gets pr'd
2282016-11-03T19:02:59  <wumpus> no topics at all for this meeting?
2292016-11-03T19:03:20  <wumpus> did the pre-final alert go out gmaxwell?
2302016-11-03T19:03:24  <achow101> it did
2312016-11-03T19:03:29  <wumpus> ok, great
2322016-11-03T19:03:38  <sipa> did anyone see it?
2332016-11-03T19:03:41  <btcdrak> hi
2342016-11-03T19:03:42  <sdaftuar> i did
2352016-11-03T19:03:50  <achow101> I caught it on a 0.12.0 node I fired up just for it
2362016-11-03T19:04:21  <arubi> I have it on onlynet=onion
2372016-11-03T19:04:25  <sipa> gmaxwell and i were talking recently about some improvements to the block/header fetch logic
2382016-11-03T19:04:50  <wumpus> #topic block header/fetch logic
2392016-11-03T19:05:03  <sipa> there are a bunch of related points there
2402016-11-03T19:05:14  <sipa> one is that we don't have a timeout for headers requests
2412016-11-03T19:05:36  <jtimon> BlueMatt: is there a long branch where I can see the code movements you're planning?
2422016-11-03T19:05:54  <BlueMatt> jtimon: working on an updated version now
2432016-11-03T19:05:55  *** Victorsueca has quit IRC
2442016-11-03T19:05:59  <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
2452016-11-03T19:06:21  <sipa> bit it goes even further... the block fetch logic only disconnects peers who slow down the process
2462016-11-03T19:06:41  <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
2472016-11-03T19:07:01  *** Chris_St1 has joined #bitcoin-core-dev
2482016-11-03T19:07:04  <sdaftuar> sipa: eg non-NODE_WITNESS nodes?
2492016-11-03T19:07:11  <jtimon> BlueMatt: cool
2502016-11-03T19:07:15  <sipa> sdaftuar: or nodes who are legitimately behind
2512016-11-03T19:07:18  <sdaftuar> ah, right
2522016-11-03T19:07:50  <sipa> so it seems there is a simple solution: disconnect outgoing connections you're not downloading from while in IBD
2532016-11-03T19:07:58  *** Chris_Stewart_5 has quit IRC
2542016-11-03T19:08:13  <sipa> but remove the non-response to getheaders in IBD
2552016-11-03T19:08:30  <jonasschnelli> sipa: ack
2562016-11-03T19:08:35  <sipa> if the peer actually is behind, we won't fetch from them, and we'll disconnect them instead of stalling yhem
2572016-11-03T19:09:30  <sipa> gmaxwell suggested something even stronger: ever minute, disconnect the peer that is slowest to give you blocks overall (during IBD)
2582016-11-03T19:09:35  <sdaftuar> if we remove the non-response to getheaders in IBD, mightn't we disconnect people who are downloading from us?
2592016-11-03T19:09:54  <jonasschnelli> During IBD?
2602016-11-03T19:10:05  <sipa> sdaftuar: note that this is only for outgoing connections
2612016-11-03T19:10:14  <sdaftuar> ah
2622016-11-03T19:10:48  <sipa> i think serving blocks to someone who is even more behind than us, whike we are in IBD, is perfectly fine
2632016-11-03T19:10:58  <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.
2642016-11-03T19:11:06  <gmaxwell> (ah pieter just said some of that)
2652016-11-03T19:11:42  <jonasschnelli> What about prioritize peers that can server "faster" (don't know if it's really measurable)
2662016-11-03T19:12:05  <sdaftuar> sipa: one complication with serving headers during IBD is that we might be on a bogus chain
2672016-11-03T19:12:14  <sipa> jonasschnelli: that's what we already do... the slowest ones get disconnected if they slow your overall sync speed down
2682016-11-03T19:12:28  <jonasschnelli> sipa: ah
2692016-11-03T19:12:58  <sipa> sdaftuar: that's something better IBD/chainpoint replacement is for, i guess?
2702016-11-03T19:13:09  <sipa> *checkpoint
2712016-11-03T19:13:23  <jonasschnelli> during my SPV work I encountered some stalling because of peers serving blocks each in a ~5min rhythm.
2722016-11-03T19:13:30  <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
2732016-11-03T19:14:07  <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
2742016-11-03T19:15:09  <sdaftuar> which i guess would be fine?
2752016-11-03T19:15:15  <sdaftuar> and an improvement over the current situation
2762016-11-03T19:15:18  <sdaftuar> ?
2772016-11-03T19:15:20  <kanzure> hi.
2782016-11-03T19:15:22  <sipa> i think so
2792016-11-03T19:15:54  <sipa> it's hard to reason about this. if you're truly sybilled during IBD, none of this will have an effect
2802016-11-03T19:16:07  <sipa> if not, you'll quickly learn about the real chain anyway
2812016-11-03T19:16:24  *** atroxes has quit IRC
2822016-11-03T19:17:22  <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)
2832016-11-03T19:17:41  <gmaxwell> this is going offtopic. :)
2842016-11-03T19:18:17  *** Victorsueca has joined #bitcoin-core-dev
2852016-11-03T19:18:17  <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.
2862016-11-03T19:18:45  <sipa> ah.
2872016-11-03T19:19:17  <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?
2882016-11-03T19:19:42  <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
2892016-11-03T19:19:46  <sdaftuar> is that basicalyl right?
2902016-11-03T19:20:14  <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.
2912016-11-03T19:20:27  <sipa> we only serve headers for blocks in our main chain, no?
2922016-11-03T19:20:35  <sdaftuar> sipa: yes
2932016-11-03T19:20:38  <sipa> which indeed may contains dummy low difficulty blocks
2942016-11-03T19:21:40  <gmaxwell> In any case, the download part of this can be done first before any change to how we respond to getheaders.
2952016-11-03T19:21:51  <sipa> right
2962016-11-03T19:21:59  <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
2972016-11-03T19:22:19  <morcos> however freeing them up to ask someone else for headers withotu waiting for a long timeout seems valuable
2982016-11-03T19:22:29  <GitHub84> [bitcoin] TheBlueMatt closed pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930
2992016-11-03T19:22:33  <gmaxwell> morcos: yes, thats mostly irrelevant, the concern is primarily that we cause harm to peers by not responding.
3002016-11-03T19:22:54  *** atroxes has joined #bitcoin-core-dev
3012016-11-03T19:22:58  <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.
3022016-11-03T19:23:14  <sdaftuar> so step 1: #9068?
3032016-11-03T19:23:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9068 | Timeout for headers fetch · Issue #9068 · bitcoin/bitcoin · GitHub
3042016-11-03T19:23:35  <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
3052016-11-03T19:23:40  <sipa> *complexity
3062016-11-03T19:24:31  <luke-jr> (suggested topic: when to halt changes to BIPs; 0.13.1 is no longer BIP 152-compatible I think)
3072016-11-03T19:24:35  <gmaxwell> That should be fixed as well, but even with it fixed it would be rude to make them wait.
3082016-11-03T19:28:16  <wumpus> 0.13.1 is no longer BIP 152 compatible?
3092016-11-03T19:28:25  <sdaftuar> well, it seems to have some bugs
3102016-11-03T19:28:39  <BlueMatt> 0.13.1 is bip 152 compatible after sdaftuar's proposed changes
3112016-11-03T19:28:52  <sipa> switch topic?
3122016-11-03T19:28:59  <wumpus> #topic BIP 152 changes
3132016-11-03T19:29:10  <BlueMatt> which was merged
3142016-11-03T19:29:18  <sipa> 0.13.1 does not relayever before validating, right?
3152016-11-03T19:29:21  <wumpus> but if it has bugs, was it ever BIP 152 compatible?
3162016-11-03T19:29:29  <BlueMatt> sipa: yes, but it can ban in response to a peer doing that
3172016-11-03T19:29:31  <wumpus> or were the bugsin the BIP
3182016-11-03T19:29:34  <sdaftuar> sipa: correct
3192016-11-03T19:29:42  <BlueMatt> sipa: the bip has been updated to say that you may no longer pre-relay unless there was a version bump
3202016-11-03T19:29:56  <BlueMatt> which is #9026
3212016-11-03T19:29:57  <gribble> https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar · Pull Request #9026 · bitcoin/bitcoin · GitHub
3222016-11-03T19:30:05  <sipa> so the issue is only when potential other bip152 implementations are oresent on the network
3232016-11-03T19:30:11  <sdaftuar> right
3242016-11-03T19:30:27  <BlueMatt> sipa: yes, but no such implementations exist, and if they do it now they must wait for the protocol version
3252016-11-03T19:30:30  <sipa> so i believe 0.13.1 is compliant with the updated bip152
3262016-11-03T19:30:38  <BlueMatt> yes
3272016-11-03T19:30:39  <sdaftuar> yes, i think so as well.
3282016-11-03T19:30:45  <gmaxwell> sipa: unfortunately because of the checkpoint stupidity we may still. :(
3292016-11-03T19:30:46  <gmaxwell> but lets think about that outside of the meeting.
3302016-11-03T19:30:46  <gmaxwell> 0.13.0 did too.
3312016-11-03T19:30:46  <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.
3322016-11-03T19:30:57  <luke-jr> wumpus: people are changing BIP 152 still
3332016-11-03T19:31:14  <gmaxwell> Luke's question was really about when should someone be told 'write a new BIP' rather than changing an existing one.
3342016-11-03T19:31:26  <sipa> yes, this is a good question
3352016-11-03T19:32:04  <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
3362016-11-03T19:32:30  <gmaxwell> Not really much of a question for this meeting though, perhaps solicit input on the mailing list?
3372016-11-03T19:32:42  <luke-jr> I didn't realise v0.13.1 bumped the protocol version-number
3382016-11-03T19:32:47  <sdaftuar> it didn't
3392016-11-03T19:32:49  <luke-jr> hmm, ok
3402016-11-03T19:33:10  <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
3412016-11-03T19:33:14  <luke-jr> sdaftuar: then how is it BIP 152 compatible iwth your change?
3422016-11-03T19:33:42  <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
3432016-11-03T19:33:54  <sdaftuar> in this case, relay before full validation
3442016-11-03T19:35:14  <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.
3452016-11-03T19:35:30  <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
3462016-11-03T19:36:16  <BlueMatt> oh, well that is a language mistake
3472016-11-03T19:36:20  <gmaxwell> and BIP152 already explained how versions were to be handled in a compatible way.
3482016-11-03T19:36:30  <BlueMatt> by that language, indeed, 0.13.1 violates a SHOULD NOT
3492016-11-03T19:36:43  <gmaxwell> luke-jr: re banning it's just a bug that all prior versions have as well.
3502016-11-03T19:37:14  <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
3512016-11-03T19:37:54  <luke-jr> ok
3522016-11-03T19:37:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3532016-11-03T19:39:02  <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?
3542016-11-03T19:39:21  *** Chris_St1 has quit IRC
3552016-11-03T19:40:08  <gmaxwell> is there a reason to rush?
3562016-11-03T19:40:44  <wumpus> is this about https://github.com/bitcoin/bitcoin/pull/9058? there was also talk of a protocol change there
3572016-11-03T19:40:47  <BlueMatt> luke-jr: after https://github.com/bitcoin/bips/pull/469, yea, probably
3582016-11-03T19:40:51  <BlueMatt> but need to review tht
3592016-11-03T19:40:52  <BlueMatt> at
3602016-11-03T19:41:20  <wumpus> I thought it mentioned a BIP change, but doesn't seem to mention that anymore
3612016-11-03T19:41:22  <luke-jr> BlueMatt: how will existing nodes react if they get a full block message there?
3622016-11-03T19:41:45  <morcos> i don't see why we should Finalize it at all until we've stopped changing it for 6-12 mos
3632016-11-03T19:42:28  <wumpus> morcos: makes sense to not finalize too soon, it's unrealistic to expect a bip to come into being completely perfect
3642016-11-03T19:42:31  <sipa> i think it depends
3652016-11-03T19:42:34  <gmaxwell> Agreed with Morcos. Though for things like consensus code, really being widely active on the network defines final.
3662016-11-03T19:42:42  <sipa> there shouldn't be material changes to ideas
3672016-11-03T19:42:47  <luke-jr> no particular reason to rush, I guess, just feels like a moving goal for anyone who wanted to be compatible with it
3682016-11-03T19:43:07  <gmaxwell> luke-jr: at least they are minor alterations.
3692016-11-03T19:43:09  <wumpus> that's always the case. Others could also report problems encountered during implementing it
3702016-11-03T19:43:13  <sipa> but clarifications and elaborating on edge cases is something else
3712016-11-03T19:43:22  <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.
3722016-11-03T19:43:26  <luke-jr> sipa: sure, we still make clarifications to Final BIPs even now I think
3732016-11-03T19:43:29  <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)
3742016-11-03T19:43:53  <wumpus> it could also move because of problems other implementors find
3752016-11-03T19:44:53  <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
3762016-11-03T19:45:05  <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
3772016-11-03T19:45:48  <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
3782016-11-03T19:45:48  <gmaxwell> mber the original number.
3792016-11-03T19:45:48  <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?
3802016-11-03T19:45:48  <wumpus> yes, those at least will need to address backwards compatibilty
3812016-11-03T19:46:28  <luke-jr> gmaxwell: I *think* we've fixed such issues in Final BIPs already
3822016-11-03T19:46:45  <BlueMatt> gmaxwell: we're not plaintext, lets highlight it in red! :p
3832016-11-03T19:46:51  <luke-jr> >_<
3842016-11-03T19:46:53  <morcos> yes, BIP 34 for example
3852016-11-03T19:47:34  <morcos> ehh, i guess that was just wrong explanation
3862016-11-03T19:47:50  <luke-jr> BIP 16
3872016-11-03T19:48:01  <luke-jr> https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size
3882016-11-03T19:48:02  <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
3892016-11-03T19:48:03  <gmaxwell> BlueMatt: the erratum link on the ietf website is red, https://tools.ietf.org/html/rfc6716
3902016-11-03T19:48:35  * luke-jr looks at gribble
3912016-11-03T19:49:20  <gmaxwell> I warned about that!
3922016-11-03T19:49:56  <gmaxwell> In any case, I still think that the BIP discussion belongs elsewhere. :)
3932016-11-03T19:50:47  <morcos> well you come up with something else to talk about for 11 more minutes then!
3942016-11-03T19:51:03  <gmaxwell> wumpus: sipa: thanks for merging lots of stuff!
3952016-11-03T19:51:12  <BlueMatt> <3
3962016-11-03T19:51:13  <sdaftuar> +1
3972016-11-03T19:51:16  <wumpus> I think there was some pull where we wondered whether to backport to 0.13.2
3982016-11-03T19:51:27  <wumpus> np :)
3992016-11-03T19:51:48  <BlueMatt> making 0.14 great again!
4002016-11-03T19:51:50  <wumpus> https://github.com/bitcoin/bitcoin/pull/9053
4012016-11-03T19:51:56  <jtimon> topic potential backports to 0.13.2 ?
4022016-11-03T19:52:38  <wumpus> I don't think there's time enough to discuss all potential backports to 0.13.2, but that one would do
4032016-11-03T19:53:18  <gmaxwell> I think it would be harmless to backport, and helpful for testnet nodes.  But I don't have a strong opinion.
4042016-11-03T19:53:23  <gmaxwell> oh I see sipa mentioned testnet.
4052016-11-03T19:54:12  *** Victorsueca has quit IRC
4062016-11-03T19:54:14  <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?
4072016-11-03T19:54:41  <sdaftuar> it's not that much of a fix for testnet right, it just allows you to reorg out the non-segwit chain?
4082016-11-03T19:54:55  *** fengling has joined #bitcoin-core-dev
4092016-11-03T19:55:09  <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>
4102016-11-03T19:55:50  <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.
4112016-11-03T19:56:16  <gmaxwell> ('stop mining' is ambigious, they won't mine after they're restarted)
4122016-11-03T19:56:31  *** LeMiner2 has joined #bitcoin-core-dev
4132016-11-03T19:56:48  <sdaftuar> fwiw i have a few bridges of my own back up now that i hope will keep that from happening again
4142016-11-03T19:56:58  <sdaftuar> can you elaborate on the 20 minute rule though?
4152016-11-03T19:57:08  <sdaftuar> oh
4162016-11-03T19:57:23  <wumpus> I think personally I'd prefer to keep it for 0.14, so the new rule/logic can prove itself a while
4172016-11-03T19:57:44  <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.
4182016-11-03T19:58:29  <sdaftuar> got it
4192016-11-03T19:58:40  <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.
4202016-11-03T19:58:49  <gmaxwell> which that PR fixes.
4212016-11-03T19:58:52  *** LeMiner has quit IRC
4222016-11-03T19:58:52  *** LeMiner2 is now known as LeMiner
4232016-11-03T19:58:58  <sipa> wumpus: ok, we can of course later decide to backport to whatever 0.13.x at that time
4242016-11-03T19:59:07  <wumpus> sipa: yes
4252016-11-03T19:59:16  <gmaxwell> sounds fine to me.
4262016-11-03T19:59:19  <wumpus> that doesn't prohibit backporting it later
4272016-11-03T19:59:36  <gmaxwell> because of the latching in IBD this code is pretty robust against mistbehavior to begin with.
4282016-11-03T19:59:41  *** fengling has quit IRC
4292016-11-03T20:00:05  <sipa> $-+(#(_+$+ PC LOAD LETTER
4302016-11-03T20:00:22  <wumpus> #endmeeting
4312016-11-03T20:00:22  <lightningbot> Meeting ended Thu Nov  3 20:00:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4322016-11-03T20:00:22  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.html
4332016-11-03T20:00:22  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.txt
4342016-11-03T20:00:22  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-03-19.00.log.html
4352016-11-03T20:00:45  <gmaxwell> Thanks all!
4362016-11-03T20:02:58  *** BakSAj has joined #bitcoin-core-dev
4372016-11-03T20:03:03  <BakSAj> hi
4382016-11-03T20:03:14  *** Victorsueca has joined #bitcoin-core-dev
4392016-11-03T20:03:48  <BakSAj> meeting in progress?
4402016-11-03T20:04:05  <BlueMatt> over :/
4412016-11-03T20:04:06  <jtimon> BakSAj: no, it just finished
4422016-11-03T20:04:08  <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
4432016-11-03T20:05:10  <BakSAj> oh, moved to 8pm or ...smth to do with daylight saving change?
4442016-11-03T20:05:28  *** cryptapus has quit IRC
4452016-11-03T20:05:51  <jtimon> BakSAj: it's fixed to UTC, so yes its because your time zone changed
4462016-11-03T20:06:01  <gmaxwell> The meeting time is in GMT, otherwise it moves 6 times a year (for different people).
4472016-11-03T20:06:43  <BakSAj> makes sense :-)
4482016-11-03T20:06:51  <BakSAj> i will reread the log
4492016-11-03T20:06:53  <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
4502016-11-03T20:07:05  <BakSAj> btw, do we have feature list for 0.14 yet?
4512016-11-03T20:07:26  <sipa> BakSAj: whatever makes it before the feature freeze :)
4522016-11-03T20:07:30  <wumpus> master is always the most up to date branch, everything in there will make it into 0.14
4532016-11-03T20:07:33  <jtimon> wumpus: I heard the country is governed by pirates
4542016-11-03T20:07:35  <BlueMatt> BakSAj: rainbows and unicorns and ponies and shit
4552016-11-03T20:07:38  <wumpus> unless reverted ofcourse but that's rare
4562016-11-03T20:07:45  <BakSAj> :-D
4572016-11-03T20:08:04  <sipa> wumpus: they have no need for DST... they either have 24 hour daylight or 24 hiur darkness :p
4582016-11-03T20:08:13  <BakSAj> even my wife laughts at this :-)
4592016-11-03T20:08:25  <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
4602016-11-03T20:08:32  <wumpus> sipa: hehe, good point :p
4612016-11-03T20:08:49  *** Guyver2 has joined #bitcoin-core-dev
4622016-11-03T20:09:18  <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
4632016-11-03T20:09:35  * BlueMatt is still hopeful that main.cpp gets split and compact block announcements in the background happen for 0.14
4642016-11-03T20:09:40  <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..
4652016-11-03T20:09:41  <BlueMatt> happen at process-time, that is
4662016-11-03T20:10:40  <wumpus> I wonder if we have any contributors from Iceland
4672016-11-03T20:10:56  <BakSAj> polar bears?
4682016-11-03T20:11:11  <sipa> BakSAj: seems there is a lot of focus on refactorings and performance imorovememts... so not necessarily user visiable changes
4692016-11-03T20:11:11  * jtimon dreams of one or even 2 more functions exposed in libconsensus
4702016-11-03T20:11:26  <sipa> BakSAj: i prefer cartesian bears
4712016-11-03T20:11:51  <BakSAj> i will have to google that :-)
4722016-11-03T20:11:55  <wumpus> polar bears don't live in iceland
4732016-11-03T20:12:11  <sipa> iceland isn't even above the polar circle
4742016-11-03T20:12:12  <BakSAj> not even in the zoo?
4752016-11-03T20:13:02  <BakSAj> http://i.imgur.com/z0Sl2XP.jpg
4762016-11-03T20:14:14  <BakSAj> sipa: ok thanks, thats also good, i guess schnorr is longrun task
4772016-11-03T20:14:37  <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
4782016-11-03T20:14:43  <BlueMatt> oh, sipa said that
4792016-11-03T20:15:01  <luke-jr> BakSAj: does that one on the right really exist? :O
4802016-11-03T20:15:12  <sipa> luke-jr: no, it's a math joke
4812016-11-03T20:16:11  <BakSAj> luke-jr: only after you forget your bear in the box for some time
4822016-11-03T20:16:15  <luke-jr> someone made a fake bear for a math joke? XD
4832016-11-03T20:16:44  <BlueMatt> BakSAj: bumpfee might make it in though, so that would be cool
4842016-11-03T20:16:59  <jtimon> luke-jr: photoshop or something, yeah
4852016-11-03T20:17:13  <luke-jr> o.o
4862016-11-03T20:17:35  <jtimon> luke-jr: I'm actually surprised that you are surprised
4872016-11-03T20:18:04  <luke-jr> jtimon: I would have tried to get bear skin and paste it on a set of boxes :p
4882016-11-03T20:18:16  <luke-jr> didn't even occur to me to try to make such an image with a computer
4892016-11-03T20:19:02  <jtimon> not an expert, but I would bet that one is actually not that hard
4902016-11-03T20:19:29  <BakSAj> yeah like segwit :-)
4912016-11-03T20:19:55  <BakSAj> btw i really wonder how ecosystem will change once sw activates and LN will come to existence
4922016-11-03T20:21:55  <BakSAj> lol rereading the log: this is really a good one :-)) BlueMatt making 0.14 great again!
4932016-11-03T20:22:03  <BakSAj> i vote it for comic relief
4942016-11-03T20:26:29  *** dcousens has joined #bitcoin-core-dev
4952016-11-03T20:30:03  *** Chris_Stewart_5 has quit IRC
4962016-11-03T20:34:52  *** dcousens has quit IRC
4972016-11-03T20:43:35  <luke-jr> hum, after taking forever to start in valgrind, I got a segfault. fun
4982016-11-03T20:44:22  *** BakSAj has quit IRC
4992016-11-03T20:45:13  <luke-jr> not sure how to interpret the stack trace however
5002016-11-03T20:45:31  <luke-jr> http://0bin.net/paste/-EkiuN3jdVtwRd0v#3NfjE9HJqmxNwuiil0FZXv+9QgmQr0Fv+VAp9Qzrd3H
5012016-11-03T20:45:36  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
5022016-11-03T20:47:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5032016-11-03T20:47:15  *** roidster has quit IRC
5042016-11-03T20:47:16  <sipa> nanotube: ^ gribble is a bit too trigger happy... maybe make the regexp only work when it's not surrounded by alphanumeric characters?
5052016-11-03T20:48:04  <gmaxwell> I was suggesting before that it only do PR#[0-9]+
5062016-11-03T20:48:19  <sipa> that sounds good as well
5072016-11-03T20:48:41  <wumpus> though that wouldn't handle issues
5082016-11-03T20:49:38  <gmaxwell> hm.  \w[PIG]#[0-9]+\w  ?
5092016-11-03T20:50:19  <gmaxwell> (PR, Issue, 'github' for when you don't know/care)
5102016-11-03T20:55:56  *** fengling has joined #bitcoin-core-dev
5112016-11-03T20:56:28  <wumpus> PIG#1234 sgtm :p
5122016-11-03T20:56:30  <gribble> https://github.com/bitcoin/bitcoin/issues/1234 | During initial sync, chain download pauses if peer goes away · Issue #1234 · bitcoin/bitcoin · GitHub
5132016-11-03T20:58:26  <luke-jr> gmaxwell: that won't work for PR# :P
5142016-11-03T21:00:44  *** fengling has quit IRC
5152016-11-03T21:03:59  <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?
5162016-11-03T21:06:14  <luke-jr> (^|\s)(PR|I)#\d+\b I think
5172016-11-03T21:06:28  <luke-jr> explicitly *not* #\d+
5182016-11-03T21:06:33  <BlueMatt> lol
5192016-11-03T21:11:22  *** Chris_Stewart_5 has quit IRC
5202016-11-03T21:11:23  *** jannes has quit IRC
5212016-11-03T21:18:03  <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
5222016-11-03T21:18:05  <gribble> https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar · Pull Request #9026 · bitcoin/bitcoin · GitHub
5232016-11-03T21:18:06  <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
5242016-11-03T21:18:07  <gribble> https://github.com/bitcoin/bitcoin/issues/8930 | Move orphan processing to ActivateBestChain by TheBlueMatt · Pull Request #8930 · bitcoin/bitcoin · GitHub
5252016-11-03T21:20:48  *** Victorsueca has quit IRC
5262016-11-03T21:21:43  *** Victorsueca has joined #bitcoin-core-dev
5272016-11-03T21:21:45  <jtimon> BlueMatt: awesome thanks!
5282016-11-03T21:22:45  *** cryptapus_afk is now known as cryptapus
5292016-11-03T21:27:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5302016-11-03T21:39:54  <jouke> What does it mean when a wallet says: "Transaction commit failed" I blieve it's a .12 wallet
5312016-11-03T21:45:39  <jouke> Hmm, corrupt /win 109
5322016-11-03T21:45:41  <jouke> whoops
5332016-11-03T21:47:11  <jouke> Hmm, but the specific transaction seems to be broadcasted though?
5342016-11-03T21:49:38  <sipa> i believe it means it wasn't accepted by your own mempool, but still broadcast
5352016-11-03T21:49:44  <sipa> that shouldn't happen
5362016-11-03T21:50:03  <sipa> if it confirms, it will show up in the wallet fine, though
5372016-11-03T21:50:34  <jouke> Hmm, rpc doesn't give a tx-id back, so I am not sure if it's absolutely the same
5382016-11-03T21:50:54  <jouke> but the outputs match, so I guess so
5392016-11-03T21:51:44  <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."
5402016-11-03T21:51:48  <jouke> also broadcasted
5412016-11-03T21:51:53  <jouke> and confirmed
5422016-11-03T21:54:22  <jouke> gettransaction shows the account
5432016-11-03T21:56:58  *** fengling has joined #bitcoin-core-dev
5442016-11-03T21:58:05  *** murr4y has quit IRC
5452016-11-03T21:59:30  <jtimon> rebased https://github.com/bitcoin/bitcoin/pull/8855
5462016-11-03T22:01:47  *** fengling has quit IRC
5472016-11-03T22:07:28  <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?
5482016-11-03T22:08:17  <sipa> i don't think so
5492016-11-03T22:15:46  *** Victorsueca has quit IRC
5502016-11-03T22:16:59  *** justanother|CHI is now known as justanother|DJT
5512016-11-03T22:25:42  *** Victorsueca has joined #bitcoin-core-dev
5522016-11-03T22:35:10  *** cryptapus is now known as cryptapus_afk
5532016-11-03T22:41:08  <jtimon> rebased #8994 and jtimon/0.13-blocksign branch too for the curious (the latter still needs more work)
5542016-11-03T22:41:10  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
5552016-11-03T22:42:35  *** Guyver2 has quit IRC
5562016-11-03T22:57:48  *** fengling has joined #bitcoin-core-dev
5572016-11-03T23:01:42  *** Victorsueca has quit IRC
5582016-11-03T23:02:50  *** fengling has quit IRC
5592016-11-03T23:24:16  *** Anduck has quit IRC
5602016-11-03T23:24:27  *** Anduck has joined #bitcoin-core-dev
5612016-11-03T23:24:28  *** Eliel has quit IRC
5622016-11-03T23:25:19  *** Eliel has joined #bitcoin-core-dev
5632016-11-03T23:58:58  *** fengling has joined #bitcoin-core-dev