12016-06-16T00:01:19  *** molz has joined #bitcoin-core-dev
  22016-06-16T00:04:15  *** moli has quit IRC
  32016-06-16T00:05:45  *** kadoban has quit IRC
  42016-06-16T00:22:39  *** wumpus has quit IRC
  52016-06-16T00:24:01  *** wumpus has joined #bitcoin-core-dev
  62016-06-16T00:29:06  *** go1111111 has joined #bitcoin-core-dev
  72016-06-16T00:30:34  *** Chris_Stewart_5 has quit IRC
  82016-06-16T00:31:59  *** Squidicuz has joined #bitcoin-core-dev
  92016-06-16T00:34:33  *** Squidicc has quit IRC
 102016-06-16T00:35:28  *** frankenmint has joined #bitcoin-core-dev
 112016-06-16T00:40:01  *** frankenmint has quit IRC
 122016-06-16T00:41:18  *** Ylbam has quit IRC
 132016-06-16T00:42:23  *** nets1n has joined #bitcoin-core-dev
 142016-06-16T00:44:57  *** Giszmo has quit IRC
 152016-06-16T01:03:35  *** nets1n has quit IRC
 162016-06-16T01:08:13  *** jiggalator has joined #bitcoin-core-dev
 172016-06-16T01:11:26  *** jiggalator has quit IRC
 182016-06-16T01:13:32  *** lesderid_ has quit IRC
 192016-06-16T01:13:39  *** lesderid has joined #bitcoin-core-dev
 202016-06-16T01:17:44  *** achow101 has quit IRC
 212016-06-16T01:29:21  *** adnn has joined #bitcoin-core-dev
 222016-06-16T01:33:49  *** achow101 has joined #bitcoin-core-dev
 232016-06-16T01:36:16  *** frankenmint has joined #bitcoin-core-dev
 242016-06-16T01:39:20  *** Cory has quit IRC
 252016-06-16T01:39:53  *** PRab has joined #bitcoin-core-dev
 262016-06-16T01:41:03  *** Pasha has joined #bitcoin-core-dev
 272016-06-16T01:41:52  *** frankenmint has quit IRC
 282016-06-16T01:47:57  *** Pasha is now known as Cory
 292016-06-16T01:58:02  *** phantomcircuit_ is now known as phantomcircuit
 302016-06-16T01:58:07  *** kadoban has joined #bitcoin-core-dev
 312016-06-16T01:58:51  <phantomcircuit> jonasschnelli, can you review 8152? i'd like to move onto the next step which is moving things that aren't called externally to private and having them use a cached CWalletDB*
 322016-06-16T02:02:43  *** fengling has quit IRC
 332016-06-16T02:22:53  *** xiangfu has quit IRC
 342016-06-16T02:31:36  *** justanotheruser has quit IRC
 352016-06-16T02:37:23  *** justanotheruser has joined #bitcoin-core-dev
 362016-06-16T02:38:25  *** frankenmint has joined #bitcoin-core-dev
 372016-06-16T02:40:31  *** adnn_ has joined #bitcoin-core-dev
 382016-06-16T02:43:04  *** adnn has quit IRC
 392016-06-16T02:43:10  *** frankenmint has quit IRC
 402016-06-16T03:09:51  *** [b__b] has quit IRC
 412016-06-16T03:25:58  *** adnn has joined #bitcoin-core-dev
 422016-06-16T03:28:59  *** adnn_ has quit IRC
 432016-06-16T03:30:58  *** [b__b] has joined #bitcoin-core-dev
 442016-06-16T03:41:04  *** frankenmint has joined #bitcoin-core-dev
 452016-06-16T03:46:24  *** frankenmint has quit IRC
 462016-06-16T03:53:10  *** raedah2 has quit IRC
 472016-06-16T03:54:47  *** raedah2 has joined #bitcoin-core-dev
 482016-06-16T03:55:36  *** [b__b] has quit IRC
 492016-06-16T04:18:08  *** adnn_ has joined #bitcoin-core-dev
 502016-06-16T04:19:01  *** adnn has quit IRC
 512016-06-16T04:25:46  *** [b__b] has joined #bitcoin-core-dev
 522016-06-16T04:26:45  *** adnn_ has quit IRC
 532016-06-16T04:50:47  *** warren_ is now known as warren
 542016-06-16T05:11:30  *** larrysalibra has joined #bitcoin-core-dev
 552016-06-16T05:11:49  *** larrysalibra has quit IRC
 562016-06-16T05:13:44  *** larrysalibra has joined #bitcoin-core-dev
 572016-06-16T05:17:12  *** larrysalibra has quit IRC
 582016-06-16T05:24:32  *** [b__b] has quit IRC
 592016-06-16T05:24:54  *** [b__b] has joined #bitcoin-core-dev
 602016-06-16T05:30:34  *** TomMc has quit IRC
 612016-06-16T05:37:52  *** so has joined #bitcoin-core-dev
 622016-06-16T05:39:53  *** Giszmo has joined #bitcoin-core-dev
 632016-06-16T05:41:51  *** haakonn has joined #bitcoin-core-dev
 642016-06-16T05:48:32  *** spudowiar has quit IRC
 652016-06-16T05:51:32  *** spudowiar has joined #bitcoin-core-dev
 662016-06-16T05:52:46  *** pedrobranco has joined #bitcoin-core-dev
 672016-06-16T05:52:58  *** haakonn has quit IRC
 682016-06-16T05:52:58  *** so has quit IRC
 692016-06-16T05:55:20  *** Ylbam has joined #bitcoin-core-dev
 702016-06-16T05:57:03  *** pedrobranco has quit IRC
 712016-06-16T05:58:37  *** so has joined #bitcoin-core-dev
 722016-06-16T06:00:21  *** haakonn has joined #bitcoin-core-dev
 732016-06-16T06:03:26  <paveljanik> I'd like to be able to save mempool snapshot at shutdown so it could be "loaded" back on startup...
 742016-06-16T06:36:06  *** frankenmint has joined #bitcoin-core-dev
 752016-06-16T06:41:12  *** frankenmint has quit IRC
 762016-06-16T06:52:13  *** kadoban has quit IRC
 772016-06-16T06:53:22  <jonasschnelli> phantomcircuit: 8152 has a large diff now... but I'll try to review it.
 782016-06-16T06:54:49  <jonasschnelli> ?w=1 helps though
 792016-06-16T06:58:25  <phantomcircuit> jonasschnelli: there's very little changed only things moved
 802016-06-16T06:58:34  <jonasschnelli> Yes. Will test now.
 812016-06-16T06:58:43  <phantomcircuit> (there is some changed, but most of the lines are just moving stuff and changing the indentation)
 822016-06-16T07:20:52  <jonasschnelli> paveljanik MarcoFalke: https://github.com/bitcoin/bitcoin/pull/8207 is this ready?
 832016-06-16T07:36:50  *** frankenmint has joined #bitcoin-core-dev
 842016-06-16T07:37:09  <paveljanik> yes, we can fix the URL later
 852016-06-16T07:41:26  *** frankenmint has quit IRC
 862016-06-16T07:43:55  *** Giszmo has quit IRC
 872016-06-16T08:06:48  *** tripleslash has joined #bitcoin-core-dev
 882016-06-16T08:10:26  *** MarcoFalke has joined #bitcoin-core-dev
 892016-06-16T08:37:36  *** frankenmint has joined #bitcoin-core-dev
 902016-06-16T08:42:15  *** frankenmint has quit IRC
 912016-06-16T08:49:43  *** Guyver2 has joined #bitcoin-core-dev
 922016-06-16T08:51:36  *** frankenmint has joined #bitcoin-core-dev
 932016-06-16T08:53:37  *** tripleslash has quit IRC
 942016-06-16T08:56:53  <GitHub163> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb0ac482eee7...f7a403b4cf22
 952016-06-16T08:56:53  <GitHub163> bitcoin/master fa58e5e MarcoFalke: [doc] Add website links to about dialog
 962016-06-16T08:56:54  <GitHub163> bitcoin/master f7a403b Wladimir J. van der Laan: Merge #8207: [trivial] Add a link to the Bitcoin-Core repository and website to the About Dialog...
 972016-06-16T08:57:03  <GitHub19> [bitcoin] laanwj closed pull request #8207: [trivial] Add a link to the Bitcoin-Core repository and website to the About Dialog (master...Mf1606-LicInfo) https://github.com/bitcoin/bitcoin/pull/8207
 982016-06-16T08:57:35  *** CubicEarth has joined #bitcoin-core-dev
 992016-06-16T08:58:21  <GitHub171> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7a403b4cf22...0a64777b909e
1002016-06-16T08:58:21  <GitHub171> bitcoin/master bc0a895 Pieter Wuille: Do not set extra flags for unfiltered DNS seed results
1012016-06-16T08:58:22  <GitHub171> bitcoin/master 0a64777 Wladimir J. van der Laan: Merge #8208: Do not set extra flags for unfiltered DNS seed results...
1022016-06-16T08:58:33  <GitHub118> [bitcoin] laanwj closed pull request #8208: Do not set extra flags for unfiltered DNS seed results (master...simplerservices) https://github.com/bitcoin/bitcoin/pull/8208
1032016-06-16T09:00:43  *** fengling has joined #bitcoin-core-dev
1042016-06-16T09:04:11  <GitHub95> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a64777b909e...e4bb4a85a551
1052016-06-16T09:04:12  <GitHub95> bitcoin/master 5d0ca81 Gregory Maxwell: Add recently accepted blocks and txn to AttemptToEvictConnection....
1062016-06-16T09:04:12  <GitHub95> bitcoin/master 6ee7f05 Gregory Maxwell: Allow disconnecting a netgroup with only one member in eviction....
1072016-06-16T09:04:13  <GitHub95> bitcoin/master e4bb4a8 Wladimir J. van der Laan: Merge #8084: Add recently accepted blocks and txn to AttemptToEvictConnection....
1082016-06-16T09:04:21  <GitHub166> [bitcoin] laanwj closed pull request #8084: Add recently accepted blocks and txn to AttemptToEvictConnection. (master...protect_recent_blocks) https://github.com/bitcoin/bitcoin/pull/8084
1092016-06-16T09:05:36  *** AtashiCon has quit IRC
1102016-06-16T09:07:12  <GitHub112> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4bb4a85a551...62fcf27bd8d7
1112016-06-16T09:07:12  <GitHub112> bitcoin/master 6fa950a Jonas Schnelli: [RPC] Fix createrawtx sequence number unsigned int parsing
1122016-06-16T09:07:13  <GitHub112> bitcoin/master 62fcf27 Wladimir J. van der Laan: Merge #8171: [RPC] Fix createrawtx sequence number unsigned int parsing...
1132016-06-16T09:07:22  <GitHub191> [bitcoin] laanwj closed pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (master...2016/06/fix_crt) https://github.com/bitcoin/bitcoin/pull/8171
1142016-06-16T09:07:35  <jonasschnelli> cfields_: I'm working on Qt5.6.1 fix... I can compile it.. but had to restore two .pc files. Any idea why Qt.5.6.1 does not come with Qt5XcbQpa.pc and Qt5PlatformSupport.pc?
1152016-06-16T09:12:43  *** ennui has joined #bitcoin-core-dev
1162016-06-16T09:16:24  *** Anduck_ is now known as Anduck
1172016-06-16T09:22:23  <wumpus> I don't think cfields_ is back yet :)
1182016-06-16T09:23:39  *** pedrobranco has joined #bitcoin-core-dev
1192016-06-16T09:28:35  <paveljanik> interesting, I'll again try new dmg installer on OS X
1202016-06-16T09:30:38  *** kcud_dab is now known as bad_duck
1212016-06-16T09:31:45  *** ws2k3 has joined #bitcoin-core-dev
1222016-06-16T09:32:05  <wumpus> jonasschnelli: that's curious! maybe qt git history will tell us something
1232016-06-16T09:32:13  <ws2k3> hello, my bitcoin core says no source for block available how can i fix this?
1242016-06-16T09:32:32  <jonasschnelli> Ah right. cfields_ is not here...
1252016-06-16T09:32:47  <jonasschnelli> wumpus: I looked into it and could not figure it out... but maybe need to look closer.
1262016-06-16T09:32:54  <wumpus> ws2k3: fix your internet connection, usually :)
1272016-06-16T09:33:20  <wumpus> usually means it cannot connect to other nodes (on port 8333)
1282016-06-16T09:34:54  <paveljanik> jonasschnelli, https://bugreports.qt.io/browse/QTBUG-50073
1292016-06-16T09:35:09  <ws2k3> wumpus it does say 8 connection to the bitcoin network
1302016-06-16T09:35:20  <ws2k3> but in the left bottum it still says no source for blocks available
1312016-06-16T09:35:27  <wumpus> how long has it been showing that there is no source for blocks available?
1322016-06-16T09:35:45  <ws2k3> wumpus sinds i started using it(15 min ago)
1332016-06-16T09:36:07  <ws2k3> wumpus i already restarted it a few times
1342016-06-16T09:36:27  <wumpus> ok, no idea then
1352016-06-16T09:36:55  <wumpus> anything strange in debug.log?
1362016-06-16T09:42:55  <ws2k3> wumpus no nothing strange there i now have connection with 8 nodes it says. but it still does not download data
1372016-06-16T09:43:45  <wumpus> what is the output of 'getpeerinfo'?
1382016-06-16T09:44:24  <ws2k3> wumpus it shows a huge list i can pastebin if you want?
1392016-06-16T09:44:30  <wumpus> yes
1402016-06-16T09:44:58  <jonasschnelli> paveljanik: thanks!
1412016-06-16T09:46:42  <wumpus> also the output of getblockchaininfo would be useful
1422016-06-16T09:48:21  <ws2k3> wumpus i sended you a link
1432016-06-16T09:49:12  <wumpus> hm apparently the node is at block 136572 - which means it did download some blocks earlier on
1442016-06-16T09:49:44  <wumpus> but it isn't requesting any new blocks
1452016-06-16T09:50:41  *** Arnavion has quit IRC
1462016-06-16T09:50:46  *** Arnavion3 has joined #bitcoin-core-dev
1472016-06-16T09:50:49  *** Arnavion3 is now known as Arnavion
1482016-06-16T09:51:23  <wumpus> can you try: getblockheader 00000000000003ba98accad570d9b74fff1287508cbabb0955b54f0dc18ef64e  (that's the block after it)
1492016-06-16T09:52:45  <wumpus> ok this makes no sense, it is supposed to return BLOCK_SOURCE_NETWORK in every case that there is more than one network connection
1502016-06-16T09:53:04  <wumpus> so with those peers it certainly shouldn't be showing no block source available
1512016-06-16T09:53:16  <ws2k3> wumpus i runned the command and it gave me some output
1522016-06-16T09:53:30  <wumpus> looks like the GUI is stuck but it is actually doing something in the background?
1532016-06-16T09:53:39  <ws2k3> wumpus should i pastebin it
1542016-06-16T09:53:46  <ws2k3> wumpus it does not seem to do anything atm
1552016-06-16T09:54:00  <wumpus> if you call getblockchaininfo multiple times in a row does the number of blocks increase?
1562016-06-16T09:54:06  <wumpus> nah, not necessary
1572016-06-16T09:54:51  <ws2k3> wumpus no the block number does not raise
1582016-06-16T09:55:32  <ws2k3> wumpus but the network graph shows it does around 50 kbps
1592016-06-16T09:55:33  <wumpus> can you try reconsiderblock 00000000000003ba98accad570d9b74fff1287508cbabb0955b54f0dc18ef64e
1602016-06-16T09:56:20  <ws2k3> wumpus i runned the command output is emty
1612016-06-16T09:56:36  <wumpus> anything in debug.log?
1622016-06-16T09:57:36  <ws2k3> wumpus check link i pastebinned
1632016-06-16T09:58:04  <wumpus> 2016-06-16 09:50:28 ProcessMessages(headers, 162003 bytes) FAILED peer=2
1642016-06-16T09:58:04  <wumpus> 2016-06-16 09:55:51 ERROR: ConnectBlock(): tried to overwrite transaction
1652016-06-16T09:58:08  <wumpus> ouch, your database is broken
1662016-06-16T09:58:18  <wumpus> restart with the -reindex flag
1672016-06-16T09:59:04  <ws2k3> wumpus i did its not reindexing
1682016-06-16T09:59:41  <wumpus> ok then backup wallet.dat, remove the entire data directory
1692016-06-16T09:59:54  <wumpus> and restart
1702016-06-16T10:00:37  <ws2k3> wumpus sorry i made a typo. it is reindexing now
1712016-06-16T10:00:53  <ws2k3> 5 years 2 weeks and counting down
1722016-06-16T10:04:21  *** [b__b] has quit IRC
1732016-06-16T10:05:25  *** [b__b] has joined #bitcoin-core-dev
1742016-06-16T10:07:14  <GitHub161> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/62fcf27bd8d7...3f89a534acfe
1752016-06-16T10:07:15  <GitHub161> bitcoin/master 1111b80 Pieter Wuille: Rework addnode behaviour...
1762016-06-16T10:07:15  <GitHub161> bitcoin/master f9f5cfc Pieter Wuille: Prevent duplicate connections where one is by name and another by ip
1772016-06-16T10:07:16  <GitHub161> bitcoin/master 1a5a4e6 Pieter Wuille: Randomize name lookup result in ConnectSocketByName
1782016-06-16T10:07:18  <GitHub63> [bitcoin] laanwj closed pull request #8113: Rework addnode behaviour (master...saneaddednode) https://github.com/bitcoin/bitcoin/pull/8113
1792016-06-16T10:08:33  *** laurentmt has joined #bitcoin-core-dev
1802016-06-16T10:08:40  *** murch has joined #bitcoin-core-dev
1812016-06-16T10:08:53  <GitHub188> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f89a534acfe...9c3d0fab3623
1822016-06-16T10:08:54  <GitHub188> bitcoin/master 60ab9b2 Wladimir J. van der Laan: Squashed 'src/univalue/' changes from 2740c4f..f32df99...
1832016-06-16T10:08:54  <GitHub188> bitcoin/master 6315152 Wladimir J. van der Laan: Merge commit '60ab9b200654ef0914459711cf2b22be16be3dc2'
1842016-06-16T10:08:55  <GitHub188> bitcoin/master a406fcb Wladimir J. van der Laan: test: add ensure_ascii setting to AuthServiceProxy...
1852016-06-16T10:08:58  <GitHub4> [bitcoin] laanwj closed pull request #7892: Add full UTF-8 support to RPC (master...2016_04_i18n_unicode_rpc) https://github.com/bitcoin/bitcoin/pull/7892
1862016-06-16T10:09:48  *** pedrobranco has quit IRC
1872016-06-16T10:11:19  *** [b__b] has quit IRC
1882016-06-16T10:12:31  *** laurentmt has quit IRC
1892016-06-16T10:17:35  <wumpus> PSA: it looks like the build system doesn't detect changes to univalue source files and will not automatically rebuild the library: **if you get RPC test failures concerning unicode, please build from a clean tree**
1902016-06-16T10:18:38  *** G1lius has joined #bitcoin-core-dev
1912016-06-16T10:21:34  *** molz has quit IRC
1922016-06-16T10:22:54  *** gevs has quit IRC
1932016-06-16T10:23:25  *** pedrobranco has joined #bitcoin-core-dev
1942016-06-16T10:24:03  *** [b__b] has joined #bitcoin-core-dev
1952016-06-16T10:26:45  *** pedrobranco has quit IRC
1962016-06-16T10:30:07  *** CubicEarth has quit IRC
1972016-06-16T10:34:47  *** gevs has joined #bitcoin-core-dev
1982016-06-16T10:34:48  *** gevs has joined #bitcoin-core-dev
1992016-06-16T10:36:52  *** pedrobranco has joined #bitcoin-core-dev
2002016-06-16T10:41:08  *** pedrobranco has quit IRC
2012016-06-16T10:41:36  *** pedrobranco has joined #bitcoin-core-dev
2022016-06-16T11:17:19  *** pedrobranco has quit IRC
2032016-06-16T11:18:02  *** pedrobranco has joined #bitcoin-core-dev
2042016-06-16T11:21:17  *** mkarrer has quit IRC
2052016-06-16T11:21:25  *** mkarrer has joined #bitcoin-core-dev
2062016-06-16T11:25:13  *** pedrobranco has quit IRC
2072016-06-16T11:26:34  *** pedrobranco has joined #bitcoin-core-dev
2082016-06-16T11:27:09  *** AtashiCon has joined #bitcoin-core-dev
2092016-06-16T11:27:15  *** mkarrer has quit IRC
2102016-06-16T11:29:20  *** mkarrer has joined #bitcoin-core-dev
2112016-06-16T11:29:20  *** pedrobranco has quit IRC
2122016-06-16T11:30:55  *** Arnavion has quit IRC
2132016-06-16T11:31:00  *** Arnavion has joined #bitcoin-core-dev
2142016-06-16T11:35:04  *** pedrobranco has joined #bitcoin-core-dev
2152016-06-16T11:36:30  *** cryptapus has joined #bitcoin-core-dev
2162016-06-16T11:41:08  *** frankenmint has quit IRC
2172016-06-16T11:43:25  *** pedrobranco has quit IRC
2182016-06-16T11:44:45  *** pedrobranco has joined #bitcoin-core-dev
2192016-06-16T11:45:49  *** mkarrer has quit IRC
2202016-06-16T11:46:11  *** mkarrer has joined #bitcoin-core-dev
2212016-06-16T11:52:12  *** kadoban has joined #bitcoin-core-dev
2222016-06-16T11:57:48  *** pedrobranco has quit IRC
2232016-06-16T12:01:44  *** pedrobranco has joined #bitcoin-core-dev
2242016-06-16T12:11:19  *** mkarrer has quit IRC
2252016-06-16T12:15:35  *** mkarrer has joined #bitcoin-core-dev
2262016-06-16T12:22:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2272016-06-16T12:26:42  *** mkarrer has quit IRC
2282016-06-16T12:27:00  *** mkarrer has joined #bitcoin-core-dev
2292016-06-16T12:28:06  *** pedrobranco has quit IRC
2302016-06-16T12:31:29  *** Humanity has joined #bitcoin-core-dev
2312016-06-16T12:33:52  *** pedrobranco has joined #bitcoin-core-dev
2322016-06-16T12:41:52  *** frankenmint has joined #bitcoin-core-dev
2332016-06-16T12:47:54  *** frankenmint has quit IRC
2342016-06-16T12:58:22  *** pedrobranco has quit IRC
2352016-06-16T13:03:40  *** kadoban has quit IRC
2362016-06-16T13:03:44  *** pedrobranco has joined #bitcoin-core-dev
2372016-06-16T13:25:26  *** Sosumi has joined #bitcoin-core-dev
2382016-06-16T13:28:13  *** Humanity has left #bitcoin-core-dev
2392016-06-16T13:38:57  *** TomMc has joined #bitcoin-core-dev
2402016-06-16T13:44:10  *** frankenmint has joined #bitcoin-core-dev
2412016-06-16T13:48:51  *** frankenmint has quit IRC
2422016-06-16T14:00:10  *** MarcoFalke has left #bitcoin-core-dev
2432016-06-16T14:06:06  *** pedrobranco has quit IRC
2442016-06-16T14:08:13  *** JackH has joined #bitcoin-core-dev
2452016-06-16T14:09:50  *** molz has joined #bitcoin-core-dev
2462016-06-16T14:13:45  *** pedrobranco has joined #bitcoin-core-dev
2472016-06-16T14:16:34  *** CubicEarth has joined #bitcoin-core-dev
2482016-06-16T14:18:34  *** CubicEarth has quit IRC
2492016-06-16T14:24:33  *** Giszmo has joined #bitcoin-core-dev
2502016-06-16T14:31:31  *** pedrobranco has quit IRC
2512016-06-16T14:32:02  *** pedrobranco has joined #bitcoin-core-dev
2522016-06-16T14:39:15  *** mkarrer has quit IRC
2532016-06-16T14:39:40  *** mkarrer has joined #bitcoin-core-dev
2542016-06-16T14:46:16  *** Chris_Stewart_5 has quit IRC
2552016-06-16T14:53:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2562016-06-16T14:59:08  *** slackircbridge has quit IRC
2572016-06-16T14:59:19  *** slackircbridge1 has joined #bitcoin-core-dev
2582016-06-16T15:16:28  *** TomMc has quit IRC
2592016-06-16T15:20:05  *** Chris_Stewart_5 has quit IRC
2602016-06-16T15:36:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2612016-06-16T15:40:43  *** Chris_Stewart_5 has quit IRC
2622016-06-16T15:54:42  *** Giszmo has quit IRC
2632016-06-16T16:06:45  *** Frederic94500 has joined #bitcoin-core-dev
2642016-06-16T16:08:30  *** Giszmo has joined #bitcoin-core-dev
2652016-06-16T16:10:05  *** Yv7trNY has joined #bitcoin-core-dev
2662016-06-16T16:13:42  *** frankenmint has joined #bitcoin-core-dev
2672016-06-16T16:29:04  *** Yv7trNY has quit IRC
2682016-06-16T16:52:09  *** Chris_St1 has joined #bitcoin-core-dev
2692016-06-16T17:01:14  *** raedah2 is now known as raedah
2702016-06-16T17:03:43  *** G1lius has quit IRC
2712016-06-16T17:21:18  <GitHub98> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9c3d0fab3623...66db2d62d598
2722016-06-16T17:21:19  <GitHub98> bitcoin/master c82a4e9 Suhas Daftuar: Use ancestor-feerate based transaction selection for mining...
2732016-06-16T17:21:19  <GitHub98> bitcoin/master 29fac19 Suhas Daftuar: Add unit tests for ancestor feerate mining
2742016-06-16T17:21:20  <GitHub98> bitcoin/master 66db2d6 Pieter Wuille: Merge #7600: Mining: Select transactions using feerate-with-ancestors...
2752016-06-16T17:21:23  <GitHub152> [bitcoin] sipa closed pull request #7600: Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
2762016-06-16T17:22:40  *** CubicEarth has joined #bitcoin-core-dev
2772016-06-16T17:25:00  <sdaftuar> woot!
2782016-06-16T17:25:18  <gmaxwell> Woot.
2792016-06-16T17:25:46  <Chris_St1> woot?
2802016-06-16T17:28:58  <sdaftuar> Chris_St1: i'm just glad ancestor feerate mining ("child pays for parent") was merged, is all.
2812016-06-16T17:49:57  <GitHub121> [bitcoin] jl2012 opened pull request #8209: Showing "not_applicable" if BIP9 timeout is 0 (master...patch-13) https://github.com/bitcoin/bitcoin/pull/8209
2822016-06-16T17:50:38  *** Chris_St1 has quit IRC
2832016-06-16T18:06:43  *** Chris_St1 has joined #bitcoin-core-dev
2842016-06-16T18:19:03  <btcdrak> sdaftuar: congratz
2852016-06-16T18:25:26  *** Ylbam has quit IRC
2862016-06-16T18:27:39  <jonasschnelli> sdaftuar: I haven't fully read myself through the CPFP PR. But how would this affect the wallet regarding fee bumps, etc.?
2872016-06-16T18:27:59  *** Ylbam has joined #bitcoin-core-dev
2882016-06-16T18:28:14  <jonasschnelli> Usecase: how could you "unstuck" a tx with CPFP... just use your unconfirmed/stuck input in a new transaction paying higher fees?
2892016-06-16T18:29:53  <sipa> yes
2902016-06-16T18:30:12  <sipa> (though that's less efficient than RBF, as you'll need to pay for inclusion of two transactions)
2912016-06-16T18:30:41  <jonasschnelli> Okay. Thanks... but..
2922016-06-16T18:30:53  *** CubicEarth has quit IRC
2932016-06-16T18:31:00  <jonasschnelli> Could the enduser usecases be identical for RBF and CPFP?
2942016-06-16T18:31:17  <jonasschnelli> Something like the "bumpfee" API?
2952016-06-16T18:32:54  <Chris_St1> Has there been any effort to introduce property based testing? From what I can tell there isn't any in the code base yet
2962016-06-16T18:34:19  *** Guyver2 has quit IRC
2972016-06-16T18:34:21  *** Guyver2_ has joined #bitcoin-core-dev
2982016-06-16T18:43:31  *** go1111111 has quit IRC
2992016-06-16T18:50:42  <GitHub157> [bitcoin] jonasschnelli opened pull request #8210: [Qt] Bump to Qt5.6.1 (master...2016/06/qt_561) https://github.com/bitcoin/bitcoin/pull/8210
3002016-06-16T18:54:48  *** BakSAj has joined #bitcoin-core-dev
3012016-06-16T18:56:12  *** raedah has quit IRC
3022016-06-16T18:56:13  *** e4xit has joined #bitcoin-core-dev
3032016-06-16T18:57:17  <Frederic94500> When Segwit update is available and when he is activate?
3042016-06-16T18:57:21  *** go1111111 has joined #bitcoin-core-dev
3052016-06-16T18:58:11  *** raedah has joined #bitcoin-core-dev
3062016-06-16T19:00:41  <wumpus> meeting time?
3072016-06-16T19:00:49  <petertodd> yup
3082016-06-16T19:00:52  <btcdrak> yup
3092016-06-16T19:00:53  <wumpus> #startmeeting
3102016-06-16T19:00:53  <lightningbot> Meeting started Thu Jun 16 19:00:53 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3112016-06-16T19:00:53  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3122016-06-16T19:00:59  <Frederic94500> Okay
3132016-06-16T19:01:14  <BakSAj> hi
3142016-06-16T19:01:16  <wumpus> topic suggestion: merge compactblocks for 0.13
3152016-06-16T19:01:21  <btcdrak> ack
3162016-06-16T19:01:29  <gmaxwell> I like topics.
3172016-06-16T19:02:04  <jonasschnelli> replacements (RBF/bumpfee) in 0.13
3182016-06-16T19:02:30  <btcdrak> segwit status
3192016-06-16T19:02:32  <jonasschnelli> ack for compactblocks topic
3202016-06-16T19:02:35  <sipa> topic: i propose pushing the feature freeze one week further for CB and segwit to stabilize
3212016-06-16T19:02:42  <gmaxwell> sipa: morcos: sdaftuar: jonasschnelli: btcdrak: phantomcircuit: paveljanik:
3222016-06-16T19:02:48  <wumpus> I really don't like that\
3232016-06-16T19:02:53  <wumpus> we already pushed it back a month
3242016-06-16T19:02:56  <gmaxwell> sipa: hm. so feature freeze doesn't mean the software is done.
3252016-06-16T19:03:04  <wumpus> I really want to feature freeze this week
3262016-06-16T19:03:06  <gmaxwell> it's not like we're waiting for new features for these things.
3272016-06-16T19:03:20  <gmaxwell> Is the issue just that we're worred about destablizing master a bit?
3282016-06-16T19:03:28  <wumpus> note that it's okay to merge something that still needs some work given that it can be done before rc1
3292016-06-16T19:03:35  <btcdrak> CB is mergeable. any bug fixes woudl be minor and can be merged afterwards.
3302016-06-16T19:03:36  <wumpus> but we really want to merge things now
3312016-06-16T19:03:43  <sdaftuar> CB is not mergeable imo
3322016-06-16T19:03:52  <sipa> well CB and segwit cannot be merged both
3332016-06-16T19:03:55  <wumpus> of course it shouldn't leave master in broken state
3342016-06-16T19:03:56  <sdaftuar> also true
3352016-06-16T19:04:04  <sipa> not right now
3362016-06-16T19:04:12  *** moli has joined #bitcoin-core-dev
3372016-06-16T19:04:27  <gmaxwell> sdaftuar: do you think it's mergable with the outstanding raised issues resolved?
3382016-06-16T19:04:36  <luke-jr> we can merge segwit+CB+CPFP and let them stabilise in master?
3392016-06-16T19:04:43  <wumpus> sdaftuar: you realize that means it misses the merge window for 0.13?
3402016-06-16T19:04:44  <sdaftuar> i haven't finished my review, but i raised some issues last night that i think need to be addressed
3412016-06-16T19:04:45  <gmaxwell> luke-jr: CPFP is merged now.
3422016-06-16T19:04:49  <btcdrak> luke-jr: CPFP merged
3432016-06-16T19:04:51  <luke-jr> oh, missed that, k
3442016-06-16T19:05:13  <sdaftuar> actually
3452016-06-16T19:05:25  <sdaftuar> bluematt hasn't updated yet to remove the work limit
3462016-06-16T19:05:26  <sdaftuar> that has to go
3472016-06-16T19:05:54  <sdaftuar> i hadn't bothered commenting because i was under the impression he's working on it
3482016-06-16T19:05:54  <gmaxwell> the criteria for merging isn't bugfree, its free of major architectural flaws or so full of issues we're not confident that it can be believed bugfree by rc1.
3492016-06-16T19:06:04  <wumpus> what about merging it and putting it behind an experimental option?
3502016-06-16T19:06:23  <btcdrak> sdaftuar: agreed, but it can be removed post merge in a separate PR.
3512016-06-16T19:06:29  <gmaxwell> sdaftuar: I presume he'll remove it as soon as he's back on.
3522016-06-16T19:06:33  *** molz has quit IRC
3532016-06-16T19:06:36  <luke-jr> which topic are we on now? CB?
3542016-06-16T19:06:42  <btcdrak> yes CB
3552016-06-16T19:06:43  <jeremyrubin> luke-jr: yes
3562016-06-16T19:06:45  <luke-jr> #topic Compact block relay
3572016-06-16T19:07:06  <gmaxwell> (thats why I asked if you'd think it would be mergable if the outstanding identified issues were resolved)
3582016-06-16T19:07:39  <btcdrak> CB is clearly working as it's being live tested in the wild by major pools.
3592016-06-16T19:07:49  <sdaftuar> there's DoS risk that has not been analyzed at all
3602016-06-16T19:07:55  <gmaxwell> btcdrak: that doesn't mean that there aren't outstanding issues.
3612016-06-16T19:08:05  <wumpus> what about merging it experimentally for 0.13.0
3622016-06-16T19:08:06  <luke-jr> btcdrak: well, so is X-thin.. working in practice doesn't mean reliable
3632016-06-16T19:08:08  <phantomcircuit> gmaxwell: present
3642016-06-16T19:08:15  <sdaftuar> wumpus: that sounds fine to me
3652016-06-16T19:08:25  <wumpus> put itbehind an option, then when the outstanding issues are fixed, remove that in 0.13.1 or so
3662016-06-16T19:08:27  <sdaftuar> and we can use the time between now and the release candidates to make it more stable/reliable?
3672016-06-16T19:08:35  <instagibbs> here as well
3682016-06-16T19:08:37  <jeremyrubin> I'd like to see more limit options to address sdaftuar's concerns
3692016-06-16T19:08:46  <btcdrak> the point of the feature freeze is that the main bulk of the master branch enters a stabalisation phase.
3702016-06-16T19:08:50  <sipa> wumpus: i can live with that
3712016-06-16T19:09:10  <wumpus> the other option is to move compactblocks to 0.14
3722016-06-16T19:09:11  <luke-jr> wumpus: 0.13.1 shouldn't remove features IMO, but maybe changing the default would make sense
3732016-06-16T19:09:20  <luke-jr> I don't think CB can wait for 0.14, unfortunately
3742016-06-16T19:09:24  <jeremyrubin> I would also like to see more analysis on how CB would affect miner's txn selection
3752016-06-16T19:09:34  <wumpus> luke-jr: this would be adding features, not removing them, and yes it's cheating of a sort
3762016-06-16T19:09:38  <petertodd> jeremyrubin: I don't think that's a barrier to merging though
3772016-06-16T19:09:53  <sipa> jeremyrubin: without work limit, there shouldn't be any
3782016-06-16T19:10:05  <instagibbs> sipa, sorry what's the "work limit" here?
3792016-06-16T19:10:05  <wumpus> seems there are still a lot of concerns for CB. why so last minute?
3802016-06-16T19:10:09  <wumpus> why didn't this come up weeks ago?
3812016-06-16T19:10:19  <sipa> instagibbs: not checking the entire mempool
3822016-06-16T19:10:22  <instagibbs> oh ok
3832016-06-16T19:10:29  <sdaftuar> i've been reviewing segwit :P
3842016-06-16T19:10:45  <instagibbs> sdaftuar, why aren't you doing both simultaneously?
3852016-06-16T19:10:49  <gmaxwell> wumpus: these are implementation details and people have been reviewing other things, some are driven out of last minute opimizations matt added that he didn't need to add.
3862016-06-16T19:10:59  <wumpus> wasns't talking about you specifically sdaftuar :)
3872016-06-16T19:11:06  <jonasschnelli> we could delay 0.13 once again. There are no urgent features and the release due date is artificial. Right?
3882016-06-16T19:11:08  <wumpus> I know you focused on segwit, that's good
3892016-06-16T19:11:18  <wumpus> I don't want to delay 0.13 again
3902016-06-16T19:11:18  <jeremyrubin> sipa: without work limit there is also DOS concern (although limited by needing to re-connect)
3912016-06-16T19:11:31  <gmaxwell> jeremyrubin: thats not true.
3922016-06-16T19:11:37  <wumpus> too much slip and we can just forget 0.14
3932016-06-16T19:11:39  <gmaxwell> jeremyrubin: please, this isn't helpful.
3942016-06-16T19:12:00  <wumpus> 0.13 is good enough for a release right now
3952016-06-16T19:12:29  <luke-jr> release 0.13 without segwit+CB then, and merge those immediately for 0.14?
3962016-06-16T19:12:32  <jonasschnelli> I agree with wumpus: CB 0.13 as experimental (for our own protection) and non-exp in 0.13.1
3972016-06-16T19:12:35  <wumpus> it would be nice to merge CB, and i think we should, but it's not a requiremnt
3982016-06-16T19:12:37  <gmaxwell> lets take a step back there are two categories of remaining issue on CB,  one if the work limit stuff matt added recently. This was driven purely out of his unrelated UDP forwarding that is based on CB, which sent him into microsecond shaving mode.
3992016-06-16T19:12:42  <sipa> i don't want (1) keep rebasing segwit (2) wait until february 2017 for CB
4002016-06-16T19:12:59  <wumpus> sipa: me neither
4012016-06-16T19:13:12  <jeremyrubin> I think that segwit should take priority in merging.
4022016-06-16T19:13:14  <luke-jr> wumpus: 1 MB blocks is already killing; segwit without CB is likely to be a disaster
4032016-06-16T19:13:20  <sipa> i am fine with making CB experimental in 0.13
4042016-06-16T19:13:28  <petertodd> sipa: ack
4052016-06-16T19:13:31  <sipa> if there are a few days to work out the kinks
4062016-06-16T19:13:31  <jeremyrubin> sipa: experimental sounds fine
4072016-06-16T19:13:39  <gmaxwell> We cannot have SW deployed with no prospect of CB live nad in use.
4082016-06-16T19:13:44  <petertodd> gmaxwell: also ack
4092016-06-16T19:13:45  <wumpus> sipa: there's still until july 7 for the planned rc1
4102016-06-16T19:13:57  <sipa> wumpus: that should be plenty
4112016-06-16T19:14:14  <wumpus> but the point is we want to merge feaatures *now*, exactly so that the next weeks can be fixing the remaining issues
4122016-06-16T19:14:18  <BakSAj> guys, please dont delay segwit, whole community is watching you and we need capacity increase soon :-(
4132016-06-16T19:14:24  <gmaxwell> yes, the concerns there appear small. And indeed, we SW activation not set we don't need to have CB requesting enabled.
4142016-06-16T19:14:37  <sipa> BakSAj: this has no effect on segwit's activation time
4152016-06-16T19:14:57  <sdaftuar> must we merge CB now though?  i feel like the bug fixes are more likely to happen in the initial PR, than trying to clean up post merge to meet the feature freeze deadline
4162016-06-16T19:15:04  <BakSAj> oh ok then
4172016-06-16T19:15:12  <luke-jr> oh, we're leaving SW undefined on mainnet?
4182016-06-16T19:15:17  <sipa> luke-jr: yes
4192016-06-16T19:15:24  <sipa> luke-jr: until a backport to 0.12 is ready
4202016-06-16T19:15:30  <wumpus> sdaftuar: if we don't merge CB this week it misses the merge window for 0.13, and will be merged for 0.14
4212016-06-16T19:15:32  <luke-jr> ok
4222016-06-16T19:15:49  <gmaxwell> sdaftuar: I assumed the outstanding issues raised last night will be fixed before its merged.
4232016-06-16T19:15:52  <wumpus> sdaftuar: bug fixes do not need to be done before the feature freeze
4242016-06-16T19:16:01  <wumpus> it's a feature freeze, not a bug fix freeze, that would be silly
4252016-06-16T19:16:23  <btcdrak> sdaftuar: it alows master to stabalise. Then we know there wont be hugely disruptive things getting merged post freeze.
4262016-06-16T19:16:26  <BakSAj> sipa: how hard is it to backport segwit to 0.12.2 ?
4272016-06-16T19:16:30  <wumpus> integration testing
4282016-06-16T19:16:40  <jeremyrubin> wumpus: can we keep the feature freeze date and alloc an addtl week for bug fix now?
4292016-06-16T19:16:53  <phantomcircuit> BakSAj: after the meeting?
4302016-06-16T19:16:57  <gmaxwell> jeremyrubin: we have until july 7th for that.
4312016-06-16T19:16:58  <petertodd> jeremyrubin: bug fix time isn't "allocated"
4322016-06-16T19:17:04  <wumpus> jeremyrubin: do you need an additional week for bug fixing? rc1 is planned for july 7, according to sipa that was good
4332016-06-16T19:17:19  <gmaxwell> the whole reason for feature freeze ahead of rc1 is to allow time for fixing and testing. :)
4342016-06-16T19:17:23  <sipa> i think 3 weeks to work out the problems in CB is sufficient
4352016-06-16T19:17:27  <sipa> they are details
4362016-06-16T19:17:31  *** cryptapus has quit IRC
4372016-06-16T19:17:36  <BakSAj> phantomcircuit: yeah, sure
4382016-06-16T19:17:40  <jonasschnelli> sipa: ack
4392016-06-16T19:17:41  <sipa> my concern with merging is that the code has been in flux the past days
4402016-06-16T19:17:43  <wumpus> and that's only rc1, I'm sure there will be bugs in rc1, and we'll need rc2 rc3
4412016-06-16T19:17:50  <sdaftuar> i think so too, but it seems silly that we're merging a PR that we otherwise wouldn't merge to get around a self-imposed deadline
4422016-06-16T19:18:13  <gmaxwell> sdaftuar: I know it seems stupid, but long time expirence with creep shows that deadlines have value.
4432016-06-16T19:18:15  <wumpus> sdaftuar: you don't think the release schedule is important?
4442016-06-16T19:18:40  <gmaxwell> Or another way to look at it, it's fine that some well known important features get fixes and evolution, but we need a bar against other creep.
4452016-06-16T19:18:41  <sdaftuar> wumpus: probably no point in arguing further.  i'll be happy to help work the bugs out...
4462016-06-16T19:18:54  <wumpus> sdaftuar: no, there is really no point in arguing this
4472016-06-16T19:18:56  <gmaxwell> (you don't want me submitting the n-th fold relay improvement or whatnot in the next couple weeks)
4482016-06-16T19:19:04  <petertodd> sdaftuar: well, I think gmaxwell has a good point that CB is very important to get in to be ready for segwit
4492016-06-16T19:19:04  <wumpus> and I'm kind of tired having to argue the value of having deadlines for every release
4502016-06-16T19:20:05  <gmaxwell> With a big team, bright lines are helpful. Even if they're sometimes objectively dumb.
4512016-06-16T19:20:15  <btcdrak> wumpus: well I for one appreciate the scheduling. It's more productive.
4522016-06-16T19:20:31  <Chris_St1> ^^^
4532016-06-16T19:20:50  <luke-jr> scheduled releases IMO are great; the only problem I think we're hitting is outside pressure to get specific things in sooner
4542016-06-16T19:20:57  <wumpus> I do agree CB is still a lot in flux
4552016-06-16T19:21:12  *** cryptapus has joined #bitcoin-core-dev
4562016-06-16T19:21:21  <wumpus> which is why I brought up this topic in the first place instead of just merging it
4572016-06-16T19:22:03  <wumpus> so, ok, let's decide that CB still gets a week to be ready
4582016-06-16T19:22:15  <gmaxwell> Thank you.
4592016-06-16T19:22:24  <sdaftuar> sounds good to me.
4602016-06-16T19:22:25  <btcdrak> great.
4612016-06-16T19:22:37  <jeremyrubin> wumpus: can you clarify "gets a week" meaning
4622016-06-16T19:22:42  <sipa> wumpus: ack
4632016-06-16T19:22:50  <jeremyrubin> i think I am interpreting it as 1 more week till merge
4642016-06-16T19:22:55  <btcdrak> jeremyrubin: it get's merged next week.
4652016-06-16T19:22:55  <wumpus> jeremyrubin: can you clarify what is unclear about it?
4662016-06-16T19:23:11  <achow101> is segwit ready for merging?
4672016-06-16T19:23:44  <sipa> segwit is ready for merging, though i'd like to get review on the changes made the past few days
4682016-06-16T19:23:58  <luke-jr> I think it should increase the pkh length limit to 75 bytes, but not important
4692016-06-16T19:24:01  <wumpus> segwit is also still very much in flux
4702016-06-16T19:24:03  <jeremyrubin> wumpus: not too much... just a little unclear what the week is for etc
4712016-06-16T19:24:08  <gmaxwell> the changes were just related to merging it without an activation date, right?
4722016-06-16T19:24:14  <Frederic94500> Because the last night, there are 40K+ unconfirmed transaction
4732016-06-16T19:24:15  <wumpus> jeremyrubin: to finish up the pull request so that it can be merged
4742016-06-16T19:24:18  <sipa> they're mostly making segwit p2p deal correctly with having no activation date
4752016-06-16T19:24:27  <jeremyrubin> wumpus: but all ok now (I think you missed my second msg)
4762016-06-16T19:24:29  <sipa> and tests/nots
4772016-06-16T19:24:32  <luke-jr> Frederic94500: #bitcoin
4782016-06-16T19:24:33  <sipa> *nits
4792016-06-16T19:25:00  <btcdrak> and ticks
4802016-06-16T19:25:02  <gmaxwell> Okay can we move to the next topic?
4812016-06-16T19:25:07  <wumpus> #topic segwit
4822016-06-16T19:25:09  <instagibbs> luke-jr, noted, but I think that ship has sailed
4832016-06-16T19:25:30  <sipa> i don't think there will be any further changes to segwit necessary, apart from potentially making it cooperate with CB
4842016-06-16T19:26:15  *** raedah has quit IRC
4852016-06-16T19:26:21  <sipa> we may find some edge cases in the transition between activation date unset and set, which i plan to actively help testing he next few days
4862016-06-16T19:26:38  <sipa> that is, assuming people find the review and testing it has had so far sufficient
4872016-06-16T19:26:54  <wumpus> so it would be better to merge segwit *before* CB?
4882016-06-16T19:27:03  <sipa> i don't care
4892016-06-16T19:27:15  <sipa> i'll help rebase either one on top of the other
4902016-06-16T19:27:33  <sipa> sdaftuar: opinion?
4912016-06-16T19:27:34  <instagibbs> sdaftuar, any outstanding concerns re testing?
4922016-06-16T19:27:36  *** raedah has joined #bitcoin-core-dev
4932016-06-16T19:27:40  <wumpus> at the least we need to make sure one of them is merged asap
4942016-06-16T19:27:44  <wumpus> so the other one can be integrated into it
4952016-06-16T19:27:46  <instagibbs> wumpus, ACK
4962016-06-16T19:27:51  <gmaxwell> sipa: if you were to do the rebase which do you think would be less work?  I have a pref for merging segwit first due to review things.  (though I believe we can't set an activation for it without CB)
4972016-06-16T19:28:10  <sdaftuar> instagibbs: i'm doing testing now for the activation date unset -> set scenario
4982016-06-16T19:28:19  <sdaftuar> i'd like more eyes on that issue, as it only just came up
4992016-06-16T19:28:20  <Chris_St1> 'activation' is wrt BIP9 right?
5002016-06-16T19:28:22  <wumpus> otherwise we'll keep this 'we need to rebase it over X' problem, and integration (and fixing bugs in integration) always causes unexpected issues
5012016-06-16T19:28:28  <gmaxwell> basically CB is less to review, and fewer have reviewed it, disrupting review with a rebase there is less of an issue.
5022016-06-16T19:28:33  <luke-jr> merging CB first makes it potentially easier to backport if people want to
5032016-06-16T19:28:43  <btcdrak> Chris_St1: yes, the parameters for activation on mainnet (starttime, timeout, bit)
5042016-06-16T19:28:44  <gmaxwell> Chris_St1: BIP9 starting date, yes.
5052016-06-16T19:28:55  <luke-jr> but if CB needs a week of revisions, merging segwit first might just make more sense
5062016-06-16T19:28:57  <wumpus> the thing is though: CB is bound by the feature freeze, segwit is not
5072016-06-16T19:29:03  <luke-jr> especially since segwit needs backports anyway
5082016-06-16T19:29:03  <gmaxwell> luke-jr: a backport of CB without segwit wouldn't be very interesting in any case.
5092016-06-16T19:29:17  <jonasschnelli> good point wumpus
5102016-06-16T19:29:35  <luke-jr> wumpus: it's less important so long as segwit has no mainnet activation params set
5112016-06-16T19:29:40  <luke-jr> IMO
5122016-06-16T19:30:09  <wumpus> luke-jr: just need to get the code into master, it's been reviewed and tested so extensively
5132016-06-16T19:30:45  <gmaxwell> yes the merge there is about code maintance.
5142016-06-16T19:30:49  <sdaftuar> wumpus: fyi the issue that came up this week about merging with no mainnet activation was a surprise to all of us
5152016-06-16T19:30:52  <BakSAj> isnt segwit the most reviewed btc code ever?
5162016-06-16T19:30:53  <instagibbs> sdaftuar, I can take a look too.
5172016-06-16T19:30:54  <Frederic94500> Actually, there are 13K+ unconfirmed transaction and we need segwit
5182016-06-16T19:30:57  <sdaftuar> wumpus: i think that particular issue should be thought abou tmore
5192016-06-16T19:31:01  <sdaftuar> to make sure we haven't missed anything
5202016-06-16T19:31:02  <sipa> Frederic94500: #bitcoin
5212016-06-16T19:31:15  <Frederic94500> #bitcoin
5222016-06-16T19:31:18  *** ChanServ sets mode: +o wumpus
5232016-06-16T19:31:22  <sdaftuar> sipa: but to answer your question about my opinion, i think i agree it should be fine to merge
5242016-06-16T19:31:43  <jeremyrubin> Frederic94500: it means move your conversation to that channel as it is off topic here.
5252016-06-16T19:31:58  <sdaftuar> i will finish my testing/review of the latest changes, and then hopefully ack this week
5262016-06-16T19:32:02  <sdaftuar> ie today/tomorrow
5272016-06-16T19:32:26  <Chris_St1> sdaftuar: So BIP9 parameters need to be set in the pull request before being merged into master correct?
5282016-06-16T19:32:39  <gmaxwell> Chris_St1: no, it can be merged with no starting date set.
5292016-06-16T19:32:40  <sipa> wumpus: segwit is merged this week or not at all, CB thursday or not at all.
5302016-06-16T19:32:51  <btcdrak> no. they will bet set later in a seprate pull
5312016-06-16T19:32:52  <sipa> wumpus: is that acceptable?
5322016-06-16T19:32:56  <gmaxwell> Which is what will happen for master.
5332016-06-16T19:33:01  <luke-jr> sipa: next thursday*
5342016-06-16T19:33:08  <wumpus> sipa: CB needs to be merged before (or on) next week thursday
5352016-06-16T19:33:14  <wumpus> sipa: segwit doesn't really have  a constraint
5362016-06-16T19:33:23  <sipa> wumpus: ok
5372016-06-16T19:33:45  <wumpus> I just thought merging it first was preferable, so that maintenance and testing of it can happen on master
5382016-06-16T19:33:55  <sipa> yes, i agree
5392016-06-16T19:34:04  <gmaxwell> I'm really tired of not being able to work on some things due to avoiding disrupting segwit, it'll be good to have it merged.
5402016-06-16T19:34:07  <gmaxwell> :)
5412016-06-16T19:34:11  <jonasschnelli> Yes. Merging it before 0.13 would make things more testable/tested
5422016-06-16T19:34:12  <wumpus> right
5432016-06-16T19:34:13  <instagibbs> Only a few ACKs so far, start cracking the whip!
5442016-06-16T19:34:39  <gmaxwell> all my focus is on things that were freeze gated.
5452016-06-16T19:34:42  <btcdrak> instagibbs: this meeting is one huge ACK :-p
5462016-06-16T19:34:47  <gmaxwell> (in the last week)
5472016-06-16T19:34:49  <jonasschnelli> I have reviewed SW for serval hours but I don't feel myself in a position to give a it a utACK (or more)
5482016-06-16T19:34:58  <sipa> i would also like to point to #8149 for review, where i've reorganized the commits per BIP
5492016-06-16T19:35:19  <sipa> it may make sense for people to just ack certain sections of it, as it touches many relatively unrelated things
5502016-06-16T19:35:23  <btcdrak> sipa: is #8149 the version to merge?
5512016-06-16T19:35:39  <sipa> (testing, wallet, p2p, consensus, script)
5522016-06-16T19:35:44  <sipa> btcdrak: yes
5532016-06-16T19:35:52  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8149 for review with reorganized commits per BIP
5542016-06-16T19:35:56  <gmaxwell> I really like the ordering of 8149, FWIW.
5552016-06-16T19:36:06  <instagibbs> jonasschnelli, just pick a part you can review comfortably
5562016-06-16T19:36:28  <sipa> and don't look at the commit by github; there is a summary comment with a list of all commits organized per section
5572016-06-16T19:36:32  <sipa> which i keep up to date
5582016-06-16T19:36:46  <jeremyrubin> sipa: thank you it's much easier to review
5592016-06-16T19:37:41  <sipa> ok, any other topics?
5602016-06-16T19:37:52  <jeremyrubin> yes
5612016-06-16T19:38:02  <wumpus> jonasschnelli had one
5622016-06-16T19:38:06  <jeremyrubin> I'd like to briefly call for more review on cory's cconman
5632016-06-16T19:38:08  <jeremyrubin> refctor
5642016-06-16T19:38:17  <sipa> jeremyrubin: i will, but after 0.13
5652016-06-16T19:38:18  <jonasschnelli> I think we should have a replacement option for the wallet in 0.13
5662016-06-16T19:38:21  <wumpus> #topic replacements (RBF/bumpfee) in 0.13
5672016-06-16T19:38:29  <sipa> ack topic
5682016-06-16T19:38:34  <wumpus> jeremyrubin: when Cory is back
5692016-06-16T19:38:54  <instagibbs> cory is answering pr stuff now, but I think he's not supposed to be :)
5702016-06-16T19:38:56  <jonasschnelli> Also,... what happens if users start up a node and immediately send a tx?
5712016-06-16T19:39:01  <gmaxwell> am I missing something in thinking thats post 0.13 work now?
5722016-06-16T19:39:04  <wumpus> oh, more review, yes that's always good, although peopel are very busy with pre-0.13 issues now
5732016-06-16T19:39:06  <luke-jr> cfields_:
5742016-06-16T19:39:08  <gmaxwell> (the conman stuff)
5752016-06-16T19:39:10  <wumpus> gmaxwell: yes
5762016-06-16T19:39:21  <wumpus> gmaxwell: I mena, no, you're not missing anything
5772016-06-16T19:39:25  <gmaxwell> Thanks. whew.
5782016-06-16T19:39:34  <sipa> i'd to see conman go in right after 0.13 branch off
5792016-06-16T19:39:42  <sdaftuar> jonasschnelli: are you talking about how fee estimation should work in that case?
5802016-06-16T19:39:46  <sipa> *conmann
5812016-06-16T19:39:47  <gmaxwell> jeremyrubin: thats why there isn't attention on it right at this second (also because cory is out)
5822016-06-16T19:39:47  <jonasschnelli> Review of https://github.com/bitcoin/bitcoin/pull/8182 would be nice. Its a bumpfee command for GUI only.
5832016-06-16T19:39:51  <wumpus> sipa: +1
5842016-06-16T19:39:54  <jonasschnelli> sdaftuar: yes
5852016-06-16T19:39:57  <jeremyrubin> gmaxwell: he's been responsive
5862016-06-16T19:40:09  <jeremyrubin> gmaxwell: but maybe let him relax a bit
5872016-06-16T19:40:11  <petertodd> jonasschnelli: yeah, my apologies for not having already looked at that!
5882016-06-16T19:40:14  <sipa> doesn't matter, there is no benefit in merging conman before the branch
5892016-06-16T19:40:16  <gmaxwell> jeremyrubin: I want that too. Well, I really want the sequence setting parts and fee even on the bump parts.
5902016-06-16T19:40:27  <luke-jr> jonasschnelli: I don't think "signals replaceability" is very useful
5912016-06-16T19:40:46  <luke-jr> "Enable fee bumping" would make more sense
5922016-06-16T19:40:52  <gmaxwell> er s/fee even/feel 50/50 on the bump parts/
5932016-06-16T19:40:59  <jeremyrubin> I brought it up not for the 0.13 but because it seemed like we were out of topics so I raised it, no need to address further.
5942016-06-16T19:41:06  <sipa> ok
5952016-06-16T19:41:12  <jonasschnelli> luke-jr: you mean the text comment in the transaction details? Whats wrong with it. IMO we agreed on that term in a recent meeting.
5962016-06-16T19:41:17  <luke-jr> right
5972016-06-16T19:41:31  <gmaxwell> thats nits, can be worked out on the PR or out of meeting.
5982016-06-16T19:41:42  <gmaxwell> please don't go into field naming details here. :)
5992016-06-16T19:41:42  <luke-jr> k
6002016-06-16T19:41:48  <phantomcircuit> jonasschnelli, maybe this is just me, but i generally much prefer that things be added to the cli before the gui
6012016-06-16T19:41:50  <wumpus> nits shouldn't be a reason to hold up the feature merge
6022016-06-16T19:41:52  <jonasschnelli> Agree. The question is do we want a feebump option in 0.13...
6032016-06-16T19:41:58  <jonasschnelli> if so,.. its extermly late. :)
6042016-06-16T19:42:01  <phantomcircuit> makes the initial review much easier for the feature itself
6052016-06-16T19:42:18  <gmaxwell> So I think we really should have the sequence setting stuff, I kept trying to ack the prior PRs but they've been closed for new prs several times.
6062016-06-16T19:42:20  <jonasschnelli> phantomcircuit: there is also a CLI PR. :)
6072016-06-16T19:42:26  <wumpus> jonasschnelli: especially for the GUI isn't [retty much too late
6082016-06-16T19:42:33  <wumpus> jonasschnelli: as it adds new translation strings
6092016-06-16T19:42:45  <wumpus> translation for 0.13 already started a few weeks ago
6102016-06-16T19:42:57  <sipa> that's sad, but understandable
6112016-06-16T19:42:58  <jonasschnelli> Yes. I agree. But I just think option to increase fees for 0.14 is to late..
6122016-06-16T19:43:01  <achow101> I think the fee bump stuff should definitely be in 0.13
6132016-06-16T19:43:03  <wumpus> having the CLI option would make sense though
6142016-06-16T19:43:06  <gmaxwell> jonasschnelli: where did we land with bumping interacting with the changs outputs already having been spent?
6152016-06-16T19:43:11  *** Sosumi has quit IRC
6162016-06-16T19:43:20  <gmaxwell> achow101: I want a pony.
6172016-06-16T19:43:36  <wumpus> achow101: 'should', but there's preactical issues with timing and planning we're trying to cope with here
6182016-06-16T19:43:36  * btcdrak gives gmaxwell a pony
6192016-06-16T19:43:38  <phantomcircuit> jonasschnelli, 0.13.1 ?
6202016-06-16T19:43:38  <sipa> achow101: i think we all like that, but we can't bypass safe practices for review and testing because we want it
6212016-06-16T19:43:42  <phantomcircuit> it's a minor feature
6222016-06-16T19:43:56  <jonasschnelli> Not sure if we want BP a bumpfeature...
6232016-06-16T19:44:14  <sipa> BP?
6242016-06-16T19:44:17  <jonasschnelli> backport
6252016-06-16T19:44:22  <wumpus> to be honest I think getting CB and segwit is enough worry for next week
6262016-06-16T19:44:36  <jonasschnelli> yes... agree.
6272016-06-16T19:44:58  <jonasschnelli> Although it's a triangle. CB <-> SW <-> RBF
6282016-06-16T19:45:00  *** Chris_St1 has quit IRC
6292016-06-16T19:45:16  <petertodd> so, I'd strongly suggest we at least get in my global optin setting, so that people who need RBF can easily use external scripts to do so: https://github.com/bitcoin/bitcoin/pull/7132
6302016-06-16T19:45:18  <wumpus> it's unfortunate that your PRs with feebump got little attention, but it's kind of late now, we can't just cram everything in last minute
6312016-06-16T19:45:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6322016-06-16T19:45:32  <jonasschnelli> wumpus: Agree.
6332016-06-16T19:45:48  <wumpus> in any case: RPC functionality must be in before the GUI
6342016-06-16T19:45:50  <Chris_Stewart_5> Did we figure the ordering for those merges?
6352016-06-16T19:45:50  <jonasschnelli> My feeling is that it is too late for 0.13 and I just wanted to make this clear. :)
6362016-06-16T19:45:55  <instagibbs> petertodd, I agree with this
6372016-06-16T19:45:56  <sipa> i will focus on reviewing RPC bumpfee
6382016-06-16T19:45:56  <wumpus> that's always how we work
6392016-06-16T19:46:00  <gmaxwell> wumpus: could we split the sequence setting parts and do those? I think they're simple and not risky and have been reviewed under several PRs.
6402016-06-16T19:46:08  <Chris_Stewart_5> segwit -> CB or CB -> segwit?
6412016-06-16T19:46:13  <gmaxwell> The issue for them is that those PRs kept getting closed with changing scope.
6422016-06-16T19:46:19  <wumpus> gmaxwell: sounds good to me
6432016-06-16T19:47:01  <gmaxwell> Chris_Stewart_5: we'll see how it goes with the actual timing of the changes.
6442016-06-16T19:47:02  <luke-jr> suggested topic: how should GBT react to pre-segwit miners, once segwit activates?
6452016-06-16T19:47:04  <wumpus> make sure the API is extensible enough to add the other things so we don't need to deprecate it already next version
6462016-06-16T19:47:07  <gmaxwell> Chris_Stewart_5: we don't need to decide that now.
6472016-06-16T19:47:15  <wumpus> but that's arguably a minor concern
6482016-06-16T19:47:37  <gmaxwell> luke-jr: what does it do in the current implementation?
6492016-06-16T19:47:44  <Chris_Stewart_5> gmaxwell: Also, these are BOTH to be included before the feature freeze, correct? Or is that tbd
6502016-06-16T19:47:50  <Chris_Stewart_5> to be determined*
6512016-06-16T19:48:02  <wumpus> Chris_Stewart_5: no, CB needs to be in before the feature freeze, softforks can in principle go in any time
6522016-06-16T19:48:17  <gmaxwell> Chris_Stewart_5: SW is freeze unrelated, CB has another week to mature.
6532016-06-16T19:48:17  <luke-jr> gmaxwell: just errors
6542016-06-16T19:48:30  <sipa> luke-jr: what is the alternative?
6552016-06-16T19:48:32  <luke-jr> gmaxwell: the RPC call errors, that is. so the miner will failover or stop
6562016-06-16T19:48:42  <luke-jr> sipa: mine blocks without any witness transactions
6572016-06-16T19:49:02  <gmaxwell> Chris_Stewart_5: question might suggest a misunderstanding, SW merge for master is not tightly coupled to deployment; it's mostly a discussion of code management.
6582016-06-16T19:49:18  <sipa> luke-jr: that means mining on top of a chain they have not fully validated
6592016-06-16T19:49:23  <sipa> oh, no, they have
6602016-06-16T19:49:24  <sipa> sorry
6612016-06-16T19:49:28  <luke-jr> sipa: no, the bitcoind is updated, just not the miner
6622016-06-16T19:49:30  <sipa> i'm confusing client and server
6632016-06-16T19:49:48  <gmaxwell> luke-jr: might be better to return an empty block, if the implementation would be simple.
6642016-06-16T19:50:08  <gmaxwell> the failover might just cause it to fail over to something even stupider.
6652016-06-16T19:50:16  <btcdrak> Chris_Stewart_5: the lifecycle page got updated to clarify some of this https://bitcoincore.org/en/lifecycle/
6662016-06-16T19:50:17  <sdaftuar> presumably this is not a feature that there can possibly be a lot of demand for.  is it relaly worth the trouble?
6672016-06-16T19:50:17  <luke-jr> I guess that's another option, but empty block is :<
6682016-06-16T19:50:23  <wumpus> consensus changes are not on bitcoin core's major release schedule, the first release introducing segwit would ideally be 0.12.x
6692016-06-16T19:50:44  <Chris_Stewart_5> gmaxwell: I guess it seems CB from my understanding isn't tightly coupled to deployment either since I'm assuming old block relay code will still be in core? I'll ask more questions after meeting..
6702016-06-16T19:50:46  <wumpus> but that doesn't mean segwit code can't be merged (just not activated) in 0.13
6712016-06-16T19:50:59  <luke-jr> gmaxwell: concern with non-witness template being code complexity, I guess?
6722016-06-16T19:51:20  <sipa> i prefer empty block
6732016-06-16T19:51:21  <luke-jr> I suppose empty blocks are also more likely to get noticed and upgraded
6742016-06-16T19:51:30  <gmaxwell> luke-jr: just more features to test when hopefully thats just an emergency fallback.
6752016-06-16T19:51:34  <sdaftuar> throwing an error should get noticed very fast
6762016-06-16T19:51:42  <wumpus> Chris_Stewart_5: the old relay code will still be used in most cases, like with peers that don't support CB
6772016-06-16T19:51:54  <gmaxwell> sdaftuar: error will result in failover to another daemon, perhaps without segwit support, which is somewhat less desirable. :)
6782016-06-16T19:51:58  <Chris_Stewart_5> btcdrak: Thanks
6792016-06-16T19:52:15  <sdaftuar> little known fact: those blocks will be orphaned,  that should also get noticed!
6802016-06-16T19:52:17  <petertodd> ack empty blocks - that's a reasonable failsafe in a lot of conditions in general
6812016-06-16T19:52:23  <luke-jr> sdaftuar: they won't, though
6822016-06-16T19:52:26  <gmaxwell> I think error and empty are both acceptable, with a small preference for empty that would be overridden if i find out the implementation is more than about 4 lines of code.
6832016-06-16T19:52:28  <sdaftuar> they won't relay
6842016-06-16T19:52:32  <luke-jr> sdaftuar: they're valid
6852016-06-16T19:52:34  <sdaftuar> yes
6862016-06-16T19:52:36  <sdaftuar> but they won't relay
6872016-06-16T19:52:38  <luke-jr> …
6882016-06-16T19:52:41  <luke-jr> why not?
6892016-06-16T19:52:41  <sdaftuar> hence, little known fact
6902016-06-16T19:52:57  <gmaxwell> ah, well if they won't realy, okay, well no reason to not error then.
6912016-06-16T19:53:03  <sipa> why would they not relay?
6922016-06-16T19:53:05  <sdaftuar> segwit nodes will try to download blocks from WITNESS peers
6932016-06-16T19:53:13  <sdaftuar> after activation
6942016-06-16T19:53:14  <sipa> so, this is a witness peer
6952016-06-16T19:53:17  <luke-jr> ^
6962016-06-16T19:53:19  <sdaftuar> not if it fails over
6972016-06-16T19:53:19  <sipa> just not a witness miner
6982016-06-16T19:53:24  <luke-jr> hm
6992016-06-16T19:53:38  <sipa> oh, i see what you're saying
7002016-06-16T19:53:39  <sdaftuar> sorry i was responding to gmaxwell's failover to an old daemon
7012016-06-16T19:53:44  <sipa> so, failover seems sufficient
7022016-06-16T19:53:45  <gmaxwell> sdaftuar: this is a witness node, but asking what happens when a non-sw hasher connects.
7032016-06-16T19:53:52  <gmaxwell> sdaftuar: OH!
7042016-06-16T19:54:00  <gmaxwell> well okay, that would get noticed too.
7052016-06-16T19:54:08  <luke-jr> yeah, I think this makes error the better behaviour
7062016-06-16T19:54:18  <gmaxwell> still, the crap blocks produced would be noise to non-upgraded nodes.
7072016-06-16T19:54:19  <petertodd> wait, did or didn't we remove the code that used to push new blocks to peers?
7082016-06-16T19:54:42  <sdaftuar> technically, mining a non-witness block on an upgraded peer would relay, as per sipa's suggestion to mine an empty block
7092016-06-16T19:54:48  <sdaftuar> i just don't think it's worth the trouble to code that up
7102016-06-16T19:55:03  <luke-jr> oh
7112016-06-16T19:55:20  <sdaftuar> code up/test/review
7122016-06-16T19:55:21  <sdaftuar> etc
7132016-06-16T19:55:31  <luke-jr> BFGMiner at least WILL submit blocks to local bitcoind regardless of what pool mined them, BUT it can only do that with GBT pools, and frankly nobody uses that
7142016-06-16T19:55:48  <luke-jr> so probably not worth considering IMO
7152016-06-16T19:55:58  <sipa> i think we're good
7162016-06-16T19:56:06  <gmaxwell> K
7172016-06-16T19:56:08  <sipa> unless miners complain about the behaviour
7182016-06-16T19:56:13  <sipa> then wr can reconsider
7192016-06-16T19:56:16  <sdaftuar> sounds good
7202016-06-16T19:56:43  <wumpus> three minutes to go!
7212016-06-16T19:56:48  <gmaxwell> jonasschnelli: if you split that PR I will go ack the non-bump part super fast.
7222016-06-16T19:56:53  <petertodd> also, if a block is relayed to non-witness peers, we only need one node on the network to bridge that gap...
7232016-06-16T19:57:07  <sipa> agree
7242016-06-16T19:57:15  <jonasschnelli> gmaxwell: which one?
7252016-06-16T19:57:23  <sipa> which their private infrastructure may do unknowlingly
7262016-06-16T19:57:27  <gmaxwell> jonasschnelli: the bump fee PR.
7272016-06-16T19:57:39  <luke-jr> petertodd: we don't *want* to bridge that gap, but I guess that's your point
7282016-06-16T19:57:44  <luke-jr> any malicious actor could do it
7292016-06-16T19:57:56  *** cryptapus has quit IRC
7302016-06-16T19:58:09  <petertodd> luke-jr: having consensus depend on nuances of network behavior is icky...
7312016-06-16T19:58:15  <luke-jr> but on the other hand, these blocks are only defective in being not fully verified parents, which won't affect full nodes
7322016-06-16T19:58:20  <gmaxwell> jonasschnelli: the actual bumping reqiures review and testing for that I don't think we have time for pre-freeze regretable, but the rest (setting the sequence numbers and what not) is fine, and I've already reviewed it and tested it.
7332016-06-16T19:58:27  <luke-jr> so this can only be done for valid blocks anyway
7342016-06-16T19:58:45  <jonasschnelli> gmaxwell: okay. I'll try to factor this out in an independent PR
7352016-06-16T19:59:08  <instagibbs> 1 minute
7362016-06-16T19:59:30  <petertodd> instagibbs: hopefully we land on the drone ship this time
7372016-06-16T19:59:34  <luke-jr> petertodd: consensus doesn't depend on it, just a slightly higher risk miners don't upgrade their nodes
7382016-06-16T19:59:36  <phantomcircuit> sdaftuar, it should be only a few lines of code to simply not include any transactions which have witness data
7392016-06-16T19:59:39  <gmaxwell> (also, in general, layering in seperate PRs RPC and GUI is useful, since we're usually more eager about merging rpc features-- easier to test, more sophicated users)
7402016-06-16T19:59:59  * wumpus turns off thel lights
7412016-06-16T20:00:03  <wumpus> #endmeeting
7422016-06-16T20:00:03  <lightningbot> Meeting ended Thu Jun 16 20:00:03 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7432016-06-16T20:00:03  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.html
7442016-06-16T20:00:03  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.txt
7452016-06-16T20:00:03  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.log.html
7462016-06-16T20:00:05  <sipa> phantomcircuit: there are 3 transaction selection algorithms now
7472016-06-16T20:00:23  <sdaftuar> phantomcircuit: i agree, but this should not be anyone's priority
7482016-06-16T20:00:51  <Chris_Stewart_5> wumpus: CB needs to be merged in before 0.13 because the protocol version in the version message indicates nodes need to talk using CB?
7492016-06-16T20:00:57  <luke-jr> petertodd: I do think you've convinced me that maybe the empty-block behaviour is better again though.
7502016-06-16T20:01:00  <petertodd> luke-jr: by "depends" I just mean the outcome of the consensus protocol is strongly affected by that nuance, in that case
7512016-06-16T20:01:29  <petertodd> luke-jr: so in general, we're better off having an empty blockchain with everyone's funds frozen than other possible failure modes
7522016-06-16T20:01:41  <gmaxwell> Chris_Stewart_5: hm? no unrelated. The issue is that if it isn't merged it would slip by something like a half year, which would be kinda dumb because the protocol is dumb.
7532016-06-16T20:01:59  <BakSAj> what is the meeting result on merging segwit? tnx
7542016-06-16T20:02:07  <petertodd> luke-jr: empty blocks work towards that goal
7552016-06-16T20:02:46  <Chris_Stewart_5> gmaxwell: Is this because of the release policy we have come up with or something inherent to the protocol itself? I guess I'm missing the limitation for not being able to put this out in a minor..
7562016-06-16T20:02:57  <wumpus> Chris_Stewart_5: it doesn't *need* to be merged before 0.13, we could postpone it to 0.14
7572016-06-16T20:03:15  <wumpus> Chris_Stewart_5: but because it is such a useful feature everyone really wants it in 0.13
7582016-06-16T20:03:22  <petertodd> though systems like Lightning are an annoying counterexample to the "empty blocks are safe" assumption...
7592016-06-16T20:03:35  <gmaxwell> Chris_Stewart_5: there is nothing about the protocol being discussed today, this is all project management.
7602016-06-16T20:03:48  <Chris_Stewart_5> gotcha.
7612016-06-16T20:04:12  <wumpus> Chris_Stewart_5: also, because of bandwidth reasons people want CB with segwit
7622016-06-16T20:04:37  <luke-jr> does segwit currently fetch the whole block in one chunk, or stripped + witness separately?
7632016-06-16T20:05:03  <sipa> the whole block
7642016-06-16T20:05:14  <gmaxwell> luke-jr: there is no seperate thing, it's just a block and you seralize it with or without the witness.
7652016-06-16T20:05:33  <wumpus> also CB is pretty much ready, it hasbeen tested extensively, and reviewed quite well, as I see it there are just some last nits
7662016-06-16T20:05:40  <GreenIsMyPepper> petertodd: w/r/t Lightning, i think with CSV, should be OK. transactions in-flight should be biased towards smaller values in the near term for the hard CLTV deadlines so impact for straight payments with empty blocks should be minimal but i'm not 100% sure
7672016-06-16T20:05:43  <luke-jr> gmaxwell: oh, it's not even supported to fetch just the witness data? :/  would be nice for nodes that skip it and go back and check later
7682016-06-16T20:05:47  <luke-jr> oh well, future improvements
7692016-06-16T20:06:11  <sipa> luke-jr: indeed, that may be something useful to add at some point
7702016-06-16T20:06:20  <wumpus> no scope creep please :)
7712016-06-16T20:06:30  <instagibbs> action item: creep the scope
7722016-06-16T20:06:37  <luke-jr> CB changes things too much to consider it now anyway
7732016-06-16T20:06:45  <gmaxwell> fortunately the meeting is over so we don't have to take instagibbs' action.
7742016-06-16T20:07:26  <luke-jr> I think for L1 consensus, we probably want to bridge the old-node valid blocks to the main network :/  which means we might want GBT to do empty blocks for old miners
7752016-06-16T20:07:28  <wumpus> topic for next meeting :p
7762016-06-16T20:07:31  <gmaxwell> luke-jr: really that kind of multistage sync is something independant of SW; it's just that it could be more efficient with segwit.
7772016-06-16T20:07:38  <luke-jr> gmaxwell: right
7782016-06-16T20:08:57  <petertodd> GreenIsMyPepper: it's ok for a bit, but given a sufficiently long period of empty blocks being mined eventually lightning users are really screwed over; that's not true for other ways of using Bitcoin
7792016-06-16T20:09:13  <petertodd> GreenIsMyPepper: not necessarily a problem in practice, but it's worth considering
7802016-06-16T20:09:35  *** BakSAj has quit IRC
7812016-06-16T20:09:57  <luke-jr> sipa: is it trivial to configure a node to fetch and process blocks from old nodes?
7822016-06-16T20:10:01  <gmaxwell> Chris_Stewart_5: going back to your earlier comments, per the lifecycle, changes for network consensus exist outside of the bitcoin core release cycle,  the reason we're talking about segwit merge in master here is not so much related to deploying segwit in the network, but related to managing the code implementing segwit in core as part of master. This is important to us because of the overhead
7832016-06-16T20:10:07  <gmaxwell> s related to keeping it as a patch in flight.
7842016-06-16T20:10:10  <GreenIsMyPepper> petertodd: yes, i agree, esp for time-dependent aspects during the switchover from mining->empty
7852016-06-16T20:10:29  <gmaxwell> Chris_Stewart_5: generally a consensus rule change will show up in a point release, not in a new major release (though it might also be in the new major release in parallel)
7862016-06-16T20:10:37  <sipa> luke-jr: what do you mean?
7872016-06-16T20:11:00  <luke-jr> sipa: get a new node which downloads blocks from pre-segwit nodes, and relays them to the main/segwit nodes.
7882016-06-16T20:11:07  <petertodd> GreenIsMyPepper: yeah, the tl;dr: is Lightning means if Bitcoin breaks, we have deadlines to fix it or all hell breaks loose
7892016-06-16T20:11:10  <luke-jr> provided the block is valid without witness data
7902016-06-16T20:11:39  <gmaxwell> Chris_Stewart_5: also consenus changes in core are often merged without any activation. (or in some cases with no nearterm plans to activate.. like the low-S signature stuff.)
7912016-06-16T20:11:45  <luke-jr> petertodd: softfork sequence stuff to skip empty blocks
7922016-06-16T20:11:59  <sipa> luke-jr: sounds trivial, just disable that check
7932016-06-16T20:12:00  <petertodd> luke-jr: that's not a crazy idea
7942016-06-16T20:12:13  <luke-jr> petertodd: it's not a new idea either :P:
7952016-06-16T20:12:24  <luke-jr> empty blocks are just full blocks with a soft size limit of 0
7962016-06-16T20:12:27  <petertodd> luke-jr: it's so not crazy, multiple people have proposed it :)
7972016-06-16T20:12:37  <GreenIsMyPepper> petertodd: additionally, i think the 2016-block mining retargeting point is an interesting factor to consider with second-order effects/drivers
7982016-06-16T20:12:51  <GreenIsMyPepper> when talking about stopping vs. empty
7992016-06-16T20:12:56  <petertodd> GreenIsMyPepper: how so?
8002016-06-16T20:13:59  <GreenIsMyPepper> in the sense that if the default was to stop, to encourage time for development, there's still a hard deadline of block retarget from part of the hashpower still mining
8012016-06-16T20:14:17  <GreenIsMyPepper> still mining for one reason or another
8022016-06-16T20:14:22  <sipa> luke-jr: all you need is one witness-capable node that attempts to download from its non-witness peers
8032016-06-16T20:14:37  <luke-jr> sipa: what's the segwit branch I should work on top of, for adding GBT old-miner empty block stuff?
8042016-06-16T20:14:47  <petertodd> GreenIsMyPepper: oh, nah, I was only talking about cases where ~all miners are mining empty blocks due to some kind of failure mode
8052016-06-16T20:14:57  <GreenIsMyPepper> which I suspect may affect default selection of CSV timeouts
8062016-06-16T20:15:05  <sipa> luke-jr: segwit-master or segwit-master2 (they are identical apart from commit structure)
8072016-06-16T20:15:19  <GreenIsMyPepper> ah, i see, i was thinking of different problems. yeah in that case, if you presume that as a "backup feature" then yes that would be impacted, that's a very good point!
8082016-06-16T20:15:25  <gmaxwell> GreenIsMyPepper: BIP-68 was setup so there could be other kinds of CSV counters in the future pretty easily.
8092016-06-16T20:16:36  <GreenIsMyPepper> yeah, not sure whether you could sufficiently punt the problem via only "don't count if the blocks are empty", but this is veering into -wizards territory :P
8102016-06-16T20:16:44  <gmaxwell> (so, e.g. when it's clear thats whats wanted, one that counted in terms of confirmed transactions could be done.)
8112016-06-16T20:17:02  *** laurentmt has joined #bitcoin-core-dev
8122016-06-16T20:17:32  <luke-jr> gmaxwell: empty block mining will be more than 4 lines.
8132016-06-16T20:18:28  <luke-jr> possibly quite a lot, due to code movement (we populate "transactions" before checking deployments)
8142016-06-16T20:19:01  *** raedah has quit IRC
8152016-06-16T20:20:30  *** raedah has joined #bitcoin-core-dev
8162016-06-16T20:20:59  <Chris_Stewart_5> gmaxwell: Thanks for the explanation
8172016-06-16T20:22:32  <phantomcircuit> luke-jr, select them and... dont use them
8182016-06-16T20:22:34  *** frankenmint has quit IRC
8192016-06-16T20:26:37  <luke-jr> http://codepad.org/t97X9nU3 is a bit ugly, but *might* work   1 file changed, 9 insertions(+), 2 deletions(-)
8202016-06-16T20:27:06  *** frankenmint has joined #bitcoin-core-dev
8212016-06-16T20:27:31  <luke-jr> note that we cannot modify the value inside pblock, as it is cached for (potentially segwit) future GBT calls
8222016-06-16T20:28:16  <luke-jr> thoughts?
8232016-06-16T20:28:36  *** Frederic94500 has quit IRC
8242016-06-16T20:30:05  <sipa> luke-jr: why do you need to do that?
8252016-06-16T20:30:41  <luke-jr> sipa: this would avoid old miners failing over to possibly pre-segwit pools.
8262016-06-16T20:31:11  <sipa> just give a new on-the-fly constructed empty result
8272016-06-16T20:31:18  <sipa> instead of using the cached value
8282016-06-16T20:31:32  <gmaxwell> thats what phantomcircuit was saying.
8292016-06-16T20:31:38  <luke-jr> that's essentially what this is doing?
8302016-06-16T20:32:04  <luke-jr> just adds a few lines of code to add a variable and use it
8312016-06-16T20:32:04  <sipa> then why do you need to modify the cached value?
8322016-06-16T20:32:12  <luke-jr> I don't, I'm explaining why not.
8332016-06-16T20:33:46  <sipa> oh, i missed part of the conversation
8342016-06-16T20:33:48  <sipa> apologies
8352016-06-16T20:34:01  <phantomcircuit> sipa, i don't believe this is modifying the cached value
8362016-06-16T20:34:04  <phantomcircuit> it seems reasonable
8372016-06-16T20:34:14  <luke-jr> np
8382016-06-16T20:34:58  <sipa> luke-jr: can't this be generically applied to all non-force deployments?
8392016-06-16T20:35:33  <luke-jr> depends on the deployment.
8402016-06-16T20:35:42  <luke-jr> I don't see any reason we can assume it will be.
8412016-06-16T20:35:45  <sipa> or make the force field a tristate "no you can't use this without understanding", "you can make empty blocks without understanding", "yes you can always use this"
8422016-06-16T20:36:02  <luke-jr> not sure it's worth that until we have both kinds
8432016-06-16T20:38:48  <sipa> we only have two kinds now
8442016-06-16T20:39:06  <luke-jr> shall I remove the segwit conditional?
8452016-06-16T20:43:56  <luke-jr> eg http://codepad.org/gxEaJQpi
8462016-06-16T20:44:10  <sipa> sounds good; you probably want to add a comment to the force field to explain that it implies an empty block will be produced
8472016-06-16T20:44:48  *** laurentmt has quit IRC
8482016-06-16T20:44:55  <sipa> what is the "unsupported" you report?
8492016-06-16T20:45:33  *** cryptapus has joined #bitcoin-core-dev
8502016-06-16T20:46:02  <luke-jr> http://codepad.org/QSnQQRD6
8512016-06-16T20:46:18  <luke-jr> sipa: something to trigger BIP9-aware clients not to try merging the template
8522016-06-16T20:46:47  <luke-jr> ie, "rules":["unsupported","csv"]
8532016-06-16T20:47:23  <sipa> he, ok
8542016-06-16T20:47:29  <luke-jr> (how do I improve the comments on this?)
8552016-06-16T20:47:44  <sipa> is there any software in the real world that actually does such merging?
8562016-06-16T20:47:48  <sipa> anyway, does not hurt
8572016-06-16T20:48:24  <luke-jr> sipa: there is a fork of libblkmaker, not merged with BIP 9 code; but nothing uses it AFAIK
8582016-06-16T21:04:16  *** cryptapus has quit IRC
8592016-06-16T21:06:25  *** jannes has quit IRC
8602016-06-16T21:08:36  *** cryptapus has joined #bitcoin-core-dev
8612016-06-16T21:11:26  *** zooko has joined #bitcoin-core-dev
8622016-06-16T21:13:35  *** Chris_Stewart_5 has quit IRC
8632016-06-16T21:20:05  *** cryptapus has quit IRC
8642016-06-16T21:22:24  *** cryptapus has joined #bitcoin-core-dev
8652016-06-16T21:25:42  *** cryptapus has quit IRC
8662016-06-16T21:29:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8672016-06-16T21:41:17  *** frankenmint has quit IRC
8682016-06-16T22:11:13  *** frankenmint has joined #bitcoin-core-dev
8692016-06-16T22:24:36  *** frankenmint has quit IRC
8702016-06-16T22:26:04  *** JackH has quit IRC
8712016-06-16T22:30:34  *** frankenmint has joined #bitcoin-core-dev
8722016-06-16T22:32:08  *** zooko has quit IRC
8732016-06-16T22:44:27  *** Kexkey has joined #bitcoin-core-dev
8742016-06-16T22:44:43  *** cryptapus has joined #bitcoin-core-dev
8752016-06-16T22:44:43  *** cryptapus has joined #bitcoin-core-dev
8762016-06-16T22:45:52  *** ennui has quit IRC
8772016-06-16T22:46:11  *** cryptapus has quit IRC
8782016-06-16T22:46:38  *** cryptapus has joined #bitcoin-core-dev
8792016-06-16T22:52:50  *** cryptapus has quit IRC
8802016-06-16T22:53:27  *** cryptapus has joined #bitcoin-core-dev
8812016-06-16T22:58:26  *** cryptapus has quit IRC
8822016-06-16T23:02:00  *** frankenmint has quit IRC
8832016-06-16T23:03:38  *** frankenmint has joined #bitcoin-core-dev
8842016-06-16T23:19:11  *** skyraider has joined #bitcoin-core-dev
8852016-06-16T23:25:01  *** Kexkey has quit IRC
8862016-06-16T23:25:51  *** go111111111 has joined #bitcoin-core-dev
8872016-06-16T23:37:19  *** murch has quit IRC
8882016-06-16T23:37:58  *** xiangfu has joined #bitcoin-core-dev