12016-03-03T00:00:46  *** wallet42 has joined #bitcoin-core-dev
  22016-03-03T00:05:16  *** belcher has quit IRC
  32016-03-03T00:06:36  *** Don_John has joined #bitcoin-core-dev
  42016-03-03T00:17:48  *** Squidicuz has joined #bitcoin-core-dev
  52016-03-03T00:22:44  *** Don_John has quit IRC
  62016-03-03T00:41:02  *** gevs has quit IRC
  72016-03-03T00:48:41  *** frankenmint has joined #bitcoin-core-dev
  82016-03-03T00:49:38  *** randy-waterhouse has joined #bitcoin-core-dev
  92016-03-03T00:53:43  *** frankenmint has quit IRC
 102016-03-03T00:53:44  *** gevs has joined #bitcoin-core-dev
 112016-03-03T01:00:09  *** evoskuil has joined #bitcoin-core-dev
 122016-03-03T01:06:45  *** AaronvanW has quit IRC
 132016-03-03T01:15:04  *** rubensayshi has quit IRC
 142016-03-03T01:15:32  *** tr0nk has joined #bitcoin-core-dev
 152016-03-03T01:16:20  *** wallet42 has quit IRC
 162016-03-03T01:21:34  *** wallet42 has joined #bitcoin-core-dev
 172016-03-03T01:25:11  *** zooko has joined #bitcoin-core-dev
 182016-03-03T01:25:41  *** _alp_ has joined #bitcoin-core-dev
 192016-03-03T01:26:17  *** fengling_ has joined #bitcoin-core-dev
 202016-03-03T01:26:46  *** Don_John has joined #bitcoin-core-dev
 212016-03-03T01:28:28  *** Ylbam has quit IRC
 222016-03-03T01:29:04  *** rubensayshi has joined #bitcoin-core-dev
 232016-03-03T01:33:15  *** wallet42 has quit IRC
 242016-03-03T01:34:29  *** zooko has quit IRC
 252016-03-03T01:38:23  *** windsok has joined #bitcoin-core-dev
 262016-03-03T01:52:32  *** wallet42 has joined #bitcoin-core-dev
 272016-03-03T01:56:31  *** wallet42 has quit IRC
 282016-03-03T01:57:56  *** wallet42 has joined #bitcoin-core-dev
 292016-03-03T02:09:42  *** laurentmt has joined #bitcoin-core-dev
 302016-03-03T02:09:45  *** laurentmt has quit IRC
 312016-03-03T02:10:27  *** wallet42 has quit IRC
 322016-03-03T02:11:01  *** wallet42 has joined #bitcoin-core-dev
 332016-03-03T02:17:20  <gmaxwell> 12:47 < paveljanik> ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels (http://eprint.iacr.org/2016/230.pdf)
 342016-03-03T02:17:56  <gmaxwell> Indeed, we were aware that OpenSSL was vulnerable to this kind of attack (though the pratical exploitation of it is quite interesting) and stopped using it several years ago as a result.
 352016-03-03T02:19:01  *** zibbo has joined #bitcoin-core-dev
 362016-03-03T02:19:22  *** nkuttler_ has joined #bitcoin-core-dev
 372016-03-03T02:22:46  *** xiangfu has joined #bitcoin-core-dev
 382016-03-03T02:22:59  *** justanot1eruser has joined #bitcoin-core-dev
 392016-03-03T02:23:16  *** justanotheruser has quit IRC
 402016-03-03T02:23:49  *** viderizer2 has quit IRC
 412016-03-03T02:23:49  *** zibbo_ has quit IRC
 422016-03-03T02:23:50  *** nkuttler has quit IRC
 432016-03-03T02:23:52  *** nkuttler_ is now known as nkuttler
 442016-03-03T02:24:18  *** viderizer2 has joined #bitcoin-core-dev
 452016-03-03T02:45:44  *** jtimon has quit IRC
 462016-03-03T02:47:10  *** wallet42 has quit IRC
 472016-03-03T03:01:03  *** p15 has quit IRC
 482016-03-03T03:07:41  *** frankenmint has joined #bitcoin-core-dev
 492016-03-03T03:10:34  *** zooko has joined #bitcoin-core-dev
 502016-03-03T03:14:49  *** frankenm_ has joined #bitcoin-core-dev
 512016-03-03T03:15:31  *** zooko has quit IRC
 522016-03-03T03:22:40  *** frankenmint has quit IRC
 532016-03-03T03:25:43  *** kinlo_ has joined #bitcoin-core-dev
 542016-03-03T03:25:45  *** helo_ has joined #bitcoin-core-dev
 552016-03-03T03:25:47  *** adam3us_ has joined #bitcoin-core-dev
 562016-03-03T03:25:47  *** roasbeef_ has joined #bitcoin-core-dev
 572016-03-03T03:25:59  *** nickler_ has joined #bitcoin-core-dev
 582016-03-03T03:26:07  *** nullpt_ has joined #bitcoin-core-dev
 592016-03-03T03:26:14  *** fkhan_ has joined #bitcoin-core-dev
 602016-03-03T03:26:26  *** Bootvis_ has joined #bitcoin-core-dev
 612016-03-03T03:26:29  *** fkhan has quit IRC
 622016-03-03T03:26:29  *** evoskuil has quit IRC
 632016-03-03T03:26:31  *** murr4y has quit IRC
 642016-03-03T03:26:34  *** nanotube has quit IRC
 652016-03-03T03:26:35  *** ebfull has quit IRC
 662016-03-03T03:26:35  *** kinlo has quit IRC
 672016-03-03T03:26:36  *** zxzzt has quit IRC
 682016-03-03T03:26:36  *** nullpt has quit IRC
 692016-03-03T03:26:36  *** roasbeef has quit IRC
 702016-03-03T03:26:36  *** berndj has quit IRC
 712016-03-03T03:26:37  *** nickler has quit IRC
 722016-03-03T03:26:37  *** helo has quit IRC
 732016-03-03T03:26:37  *** Bootvis has quit IRC
 742016-03-03T03:26:38  *** adam3us has quit IRC
 752016-03-03T03:26:38  *** evoskuil has joined #bitcoin-core-dev
 762016-03-03T03:26:53  *** berndj-blackout has joined #bitcoin-core-dev
 772016-03-03T03:27:03  *** kinlo_ is now known as kinlo
 782016-03-03T03:27:50  *** murr4y has joined #bitcoin-core-dev
 792016-03-03T03:30:53  *** nanotube has joined #bitcoin-core-dev
 802016-03-03T03:33:11  *** zxzzt has joined #bitcoin-core-dev
 812016-03-03T03:39:02  *** Alopex has quit IRC
 822016-03-03T03:40:07  *** Alopex has joined #bitcoin-core-dev
 832016-03-03T03:47:45  *** Giszmo has quit IRC
 842016-03-03T04:07:59  *** evoskuil has quit IRC
 852016-03-03T04:22:54  *** evoskuil has joined #bitcoin-core-dev
 862016-03-03T04:41:01  *** Alopex has quit IRC
 872016-03-03T04:42:06  *** Alopex has joined #bitcoin-core-dev
 882016-03-03T04:51:18  *** p15x has joined #bitcoin-core-dev
 892016-03-03T04:57:02  *** Alopex has quit IRC
 902016-03-03T04:58:07  *** Alopex has joined #bitcoin-core-dev
 912016-03-03T05:17:00  *** p15x has quit IRC
 922016-03-03T05:25:03  *** fkhan_ has quit IRC
 932016-03-03T05:38:22  *** fkhan_ has joined #bitcoin-core-dev
 942016-03-03T05:44:02  *** p15x has joined #bitcoin-core-dev
 952016-03-03T05:58:12  *** fengling_ has quit IRC
 962016-03-03T05:58:19  *** xiangfu has quit IRC
 972016-03-03T05:59:02  *** fengling_ has joined #bitcoin-core-dev
 982016-03-03T06:00:06  *** xiangfu has joined #bitcoin-core-dev
 992016-03-03T06:00:36  *** p15x has quit IRC
1002016-03-03T06:04:08  *** pavel_ has quit IRC
1012016-03-03T06:04:17  *** paveljanik has joined #bitcoin-core-dev
1022016-03-03T06:09:52  *** Cheeseo has quit IRC
1032016-03-03T06:13:03  *** Don_John has quit IRC
1042016-03-03T06:39:15  *** Cheeseo has joined #bitcoin-core-dev
1052016-03-03T06:46:26  *** p15 has joined #bitcoin-core-dev
1062016-03-03T06:53:58  *** wallet42 has joined #bitcoin-core-dev
1072016-03-03T07:08:57  *** wallet421 has joined #bitcoin-core-dev
1082016-03-03T07:09:02  *** jarret has quit IRC
1092016-03-03T07:12:23  *** wallet42 has quit IRC
1102016-03-03T07:13:32  *** BitcoinErrorLog has quit IRC
1112016-03-03T07:50:59  *** randy-waterhouse has quit IRC
1122016-03-03T07:54:40  *** BashCo has quit IRC
1132016-03-03T07:58:03  *** Thireus has quit IRC
1142016-03-03T08:03:10  *** schmidty has quit IRC
1152016-03-03T08:09:40  *** Ylbam has joined #bitcoin-core-dev
1162016-03-03T08:20:37  *** Thireus has joined #bitcoin-core-dev
1172016-03-03T08:27:33  *** BashCo has joined #bitcoin-core-dev
1182016-03-03T08:32:42  *** paveljanik has quit IRC
1192016-03-03T08:46:04  *** tr0nk has quit IRC
1202016-03-03T08:47:42  *** p15x has joined #bitcoin-core-dev
1212016-03-03T08:55:49  *** AaronvanW has joined #bitcoin-core-dev
1222016-03-03T09:06:15  *** inaltoasinistra has joined #bitcoin-core-dev
1232016-03-03T09:15:10  *** chris2000 has joined #bitcoin-core-dev
1242016-03-03T09:26:17  *** wallet421 has quit IRC
1252016-03-03T09:26:58  *** paveljanik has joined #bitcoin-core-dev
1262016-03-03T09:39:44  *** jannes has joined #bitcoin-core-dev
1272016-03-03T09:59:25  *** nickler_ is now known as nickler
1282016-03-03T10:08:07  *** randy-waterhouse has joined #bitcoin-core-dev
1292016-03-03T10:35:33  <GitHub33> [bitcoin] elliotolds opened pull request #7635: [Documentation] Add dependency info to test docs (master...docs4) https://github.com/bitcoin/bitcoin/pull/7635
1302016-03-03T10:51:30  <GitHub21> [bitcoin] jtimon closed pull request #7310: MOVEONLY: Move consensus functions out of main (master...consensus-moveonly-0.13.99) https://github.com/bitcoin/bitcoin/pull/7310
1312016-03-03T10:53:00  <GitHub57> [bitcoin] jtimon closed pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
1322016-03-03T10:53:20  <GitHub133> [bitcoin] jtimon closed pull request #7566: WIP: Implement BIP9 and get BIP113 to be ready to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566
1332016-03-03T10:55:16  <GitHub13> [bitcoin] jtimon closed pull request #7565: bip9/bip113/libconsensus-p2a: Deployment preparations forBIP113 + #7552 + Introduce Consensus::VerifyTx() (master...libconsensus-p2a-verifytx-bip113-0.12.99) https://github.com/bitcoin/bitcoin/pull/7565
1342016-03-03T11:01:30  *** inaltoas1nistra has joined #bitcoin-core-dev
1352016-03-03T11:04:37  *** inaltoasinistra has quit IRC
1362016-03-03T11:11:39  <GitHub153> [bitcoin] makevoid opened pull request #7636: Add bitcoin address label to request payment QR code (master...request_payment_qrcode_address_label) https://github.com/bitcoin/bitcoin/pull/7636
1372016-03-03T11:19:12  <jouke> bitcoind -help-debug checks if bitcoin core is running?
1382016-03-03T11:19:24  <jouke> bitcoind -help does not. Intended behaviour?
1392016-03-03T11:22:21  <jouke> oh, --help -help-debug
1402016-03-03T11:22:27  <jouke> never mind
1412016-03-03T11:23:10  *** tr0nk has joined #bitcoin-core-dev
1422016-03-03T11:23:47  *** MarcoFalke has joined #bitcoin-core-dev
1432016-03-03T11:24:14  *** gevs has quit IRC
1442016-03-03T11:43:24  *** randy-waterhouse has left #bitcoin-core-dev
1452016-03-03T11:45:19  *** tr0nk has quit IRC
1462016-03-03T11:45:47  *** jannes_ has joined #bitcoin-core-dev
1472016-03-03T11:46:36  *** jannes has quit IRC
1482016-03-03T11:54:39  <GitHub198> [bitcoin] jtimon closed pull request #7563: libconsensus-p2a: Decouple pow.o from chain.o and move it to the consensus package (master...libconsensus-p2a-chain-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7563
1492016-03-03T11:57:57  <GitHub11> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/409f843f2ed2...1b68de35250e
1502016-03-03T11:57:57  <GitHub11> bitcoin/master fa1b80d MarcoFalke: [travis] Only run check-doc.py once
1512016-03-03T11:57:58  <GitHub11> bitcoin/master 1b68de3 Wladimir J. van der Laan: Merge #7620: [travis] Only run check-doc.py once...
1522016-03-03T11:58:07  <GitHub17> [bitcoin] laanwj closed pull request #7620: [travis] Only run check-doc.py once (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7620
1532016-03-03T12:17:13  *** inaltoas1nistra has quit IRC
1542016-03-03T12:19:14  *** inaltoasinistra has joined #bitcoin-core-dev
1552016-03-03T12:31:52  <GitHub58> [bitcoin] laanwj opened pull request #7637: Fix memleak in TorController [rework] (master...2016_03_torcontrol_leak) https://github.com/bitcoin/bitcoin/pull/7637
1562016-03-03T12:32:07  <GitHub143> [bitcoin] laanwj closed pull request #7610: Fix memleak in TorController (master...2016/02/torctrl_memleak) https://github.com/bitcoin/bitcoin/pull/7610
1572016-03-03T12:37:08  *** xiangfu has quit IRC
1582016-03-03T12:43:33  *** rubensayshi has quit IRC
1592016-03-03T12:56:16  <GitHub137> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b68de35250e...7f001bdf641d
1602016-03-03T12:56:17  <GitHub137> bitcoin/master 5ecfa36 Jonas Schnelli: Remove openssl info from init/log and from Qt debug window
1612016-03-03T12:56:17  <GitHub137> bitcoin/master 7f001bd Wladimir J. van der Laan: Merge #7605: Remove openssl info from init/log and from Qt debug window...
1622016-03-03T12:56:21  <GitHub45> [bitcoin] laanwj closed pull request #7605: Remove openssl info from init/log and from Qt debug window (master...2016/02/rm_openssl_log) https://github.com/bitcoin/bitcoin/pull/7605
1632016-03-03T12:56:31  <GitHub59> [bitcoin] laanwj closed pull request #7586: fixes/refactoring for building against LibreSSL (master...2016/02/fix_openssl_libressl) https://github.com/bitcoin/bitcoin/pull/7586
1642016-03-03T12:57:10  *** rubensayshi has joined #bitcoin-core-dev
1652016-03-03T12:58:53  *** Giszmo has joined #bitcoin-core-dev
1662016-03-03T13:06:06  *** gevs has joined #bitcoin-core-dev
1672016-03-03T13:06:07  *** gevs has joined #bitcoin-core-dev
1682016-03-03T13:20:03  *** berndj-blackout is now known as berndj
1692016-03-03T13:32:44  <GitHub83> [bitcoin] laanwj reopened pull request #7517: test: script_error checking in script_invalid tests (master...2016_02_test_script_errors) https://github.com/bitcoin/bitcoin/pull/7517
1702016-03-03T13:41:03  *** Ylbam has quit IRC
1712016-03-03T13:43:11  *** jl2012 has quit IRC
1722016-03-03T13:52:03  *** jl2012 has joined #bitcoin-core-dev
1732016-03-03T13:52:45  *** Ylbam has joined #bitcoin-core-dev
1742016-03-03T13:59:41  *** jarret has joined #bitcoin-core-dev
1752016-03-03T14:10:26  <GitHub6> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7f001bdf641d...3368895c3b94
1762016-03-03T14:10:26  <GitHub6> bitcoin/master 5a2b1c0 Alex Morcos: Don't resend wallet txs that aren't in our own mempool
1772016-03-03T14:10:27  <GitHub6> bitcoin/master 3368895 Wladimir J. van der Laan: Merge #7521: Don't resend wallet txs that aren't in our own mempool...
1782016-03-03T14:10:31  <GitHub64> [bitcoin] laanwj closed pull request #7521: Don't resend wallet txs that aren't in our own mempool (master...testBeforeRelay) https://github.com/bitcoin/bitcoin/pull/7521
1792016-03-03T14:20:31  *** helo_ is now known as helo
1802016-03-03T14:21:52  *** mesmer_ has quit IRC
1812016-03-03T14:25:06  *** chris2000 has quit IRC
1822016-03-03T14:29:25  *** paveljanik has quit IRC
1832016-03-03T14:43:10  <jouke> wallet config has spendzeroconfchange=0, but with 0.12 it does create transactions with inputs that were not confirmed yet.
1842016-03-03T14:59:09  *** Guyver2 has joined #bitcoin-core-dev
1852016-03-03T15:00:00  *** zooko has joined #bitcoin-core-dev
1862016-03-03T15:04:18  <wumpus> jouke: ugh! can you open an issue?
1872016-03-03T15:06:04  <wumpus> strange, I wonder what changed in that code, looking at CWalletTx::IsTrusted() it still returns false when depth is not >=1 and that option isn't set
1882016-03-03T15:07:21  <wumpus> so is it spending outputs that aren't IsTrusted?
1892016-03-03T15:08:12  <wumpus> shouldn't be, AvailableCoins is always called with fOnlyConfirmed, and it skips coins that aren't trusted if that is set
1902016-03-03T15:08:17  <wumpus> no, I don't see how this could happen :/
1912016-03-03T15:08:44  <wumpus> maybe there was a reorg, and a transaction went from 1 to 0 confirms?
1922016-03-03T15:12:18  <jonasschnelli> jouke, wumpus: interesting... testing local
1932016-03-03T15:17:03  <jonasschnelli> Can't reproduce in a local test.
1942016-03-03T15:17:19  <jonasschnelli> -spendzeroconfchange=0 worked for me
1952016-03-03T15:17:27  <jonasschnelli> maybe a reorg thing.. yes.
1962016-03-03T15:18:13  *** frankenm_ has quit IRC
1972016-03-03T15:19:55  *** ebfull has joined #bitcoin-core-dev
1982016-03-03T15:27:10  <GitHub120> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3368895c3b94...7f966713a413
1992016-03-03T15:27:10  <GitHub120> bitcoin/master fa5f193 MarcoFalke: [travis] Exit early when check-doc.py fails
2002016-03-03T15:27:11  <GitHub120> bitcoin/master 7f96671 Wladimir J. van der Laan: Merge #7455: [travis] Exit early when check-doc.py fails...
2012016-03-03T15:27:15  <GitHub163> [bitcoin] laanwj closed pull request #7455: [travis] Exit early when check-doc.py fails (master...Mf1601-travisCheckDoc) https://github.com/bitcoin/bitcoin/pull/7455
2022016-03-03T15:32:56  *** TZander has quit IRC
2032016-03-03T15:46:46  *** paveljanik has joined #bitcoin-core-dev
2042016-03-03T15:50:06  *** wumpus has quit IRC
2052016-03-03T15:50:49  *** wumpus has joined #bitcoin-core-dev
2062016-03-03T15:51:28  *** CyrusV has quit IRC
2072016-03-03T16:04:38  *** CyrusV has joined #bitcoin-core-dev
2082016-03-03T16:08:41  *** laurentmt has joined #bitcoin-core-dev
2092016-03-03T16:11:21  *** jtimon has joined #bitcoin-core-dev
2102016-03-03T16:14:34  *** Thireus has quit IRC
2112016-03-03T16:14:48  *** zooko has quit IRC
2122016-03-03T16:31:39  *** laurentmt has quit IRC
2132016-03-03T16:31:44  *** davec_ has quit IRC
2142016-03-03T16:32:17  *** BashCo has quit IRC
2152016-03-03T16:32:23  *** davec has joined #bitcoin-core-dev
2162016-03-03T16:33:35  *** Cheeseo has quit IRC
2172016-03-03T16:34:25  *** inaltoasinistra has quit IRC
2182016-03-03T17:00:09  *** BashCo has joined #bitcoin-core-dev
2192016-03-03T17:10:44  *** Cheeseo has joined #bitcoin-core-dev
2202016-03-03T17:10:44  *** Cheeseo has joined #bitcoin-core-dev
2212016-03-03T17:27:35  *** zooko has joined #bitcoin-core-dev
2222016-03-03T17:29:17  *** droark has quit IRC
2232016-03-03T17:38:12  *** gevs has quit IRC
2242016-03-03T17:39:20  *** Cheeseo has quit IRC
2252016-03-03T17:42:01  *** Thireus has joined #bitcoin-core-dev
2262016-03-03T18:06:08  *** Cheeseo has joined #bitcoin-core-dev
2272016-03-03T18:06:08  *** Cheeseo has joined #bitcoin-core-dev
2282016-03-03T18:33:17  *** chris2000 has joined #bitcoin-core-dev
2292016-03-03T18:46:25  *** tr0nk has joined #bitcoin-core-dev
2302016-03-03T18:57:18  *** tr0nk has quit IRC
2312016-03-03T18:59:53  *** MarcoFalke has quit IRC
2322016-03-03T19:00:00  <gmaxwell> Meeting time?
2332016-03-03T19:00:08  <Luke-Jr> yep
2342016-03-03T19:01:01  <gmaxwell> jonasschnelli: wumpus: phantomcircuit: petertodd: sipa: paveljanik: sdaftuar: morcos: BlueMatt:
2352016-03-03T19:02:23  <petertodd> hi
2362016-03-03T19:03:01  <gmaxwell> petertodd: I figured we should wait for some more people to show to start.
2372016-03-03T19:03:28  <sdaftuar> present
2382016-03-03T19:04:11  <sipa> present
2392016-03-03T19:05:31  <CodeShark> Hello
2402016-03-03T19:05:49  <gmaxwell> cfields: btcdrak: CodeShark:
2412016-03-03T19:06:04  *** zooko has quit IRC
2422016-03-03T19:06:26  <gmaxwell> #startmeeting
2432016-03-03T19:06:26  <lightningbot> Meeting started Thu Mar  3 19:06:26 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
2442016-03-03T19:06:26  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2452016-03-03T19:06:33  <gmaxwell> #topic Agenda
2462016-03-03T19:06:52  <gmaxwell> What things need to be discussed today?
2472016-03-03T19:07:21  <CodeShark> Versionbits, segwit status
2482016-03-03T19:08:06  <gmaxwell> okay lets start on versionbits for now and we'll see what else gets raised?
2492016-03-03T19:08:12  <gmaxwell> #topic Versionbits (BIP9)
2502016-03-03T19:08:21  <btcdrak> hi
2512016-03-03T19:08:42  <sipa> i'm about to push a few changes to 7575 (non semantic ones), and it should be ready for review
2522016-03-03T19:08:49  <gmaxwell> Sipa has been working on refining the proposal and has made some recent changes which I think are pretty good-- eliminate some corner cases around start/stop.
2532016-03-03T19:09:12  <btcdrak> The BIP update is looking nice.
2542016-03-03T19:09:15  <CodeShark> Yes, I like the latest changes
2552016-03-03T19:09:16  <sipa> so BIP9 currently guarantees that as long as the start/end times of deployments are non-overlapping, the bits are never ambiguous
2562016-03-03T19:09:44  <sipa> so no need for dependency tracking between different deployments, just choose start/end times sanely
2572016-03-03T19:10:28  <CodeShark> Yes, that's what I had in mind in my implementation but sipa did it better :)
2582016-03-03T19:10:38  <sipa> 7575 currently implements that, and has tests (for the low-level logic, not for the integration with consensus logic)
2592016-03-03T19:11:05  <gmaxwell> I continue to be a little concerned that the activation threshold may be too high considering the low variance triggering mechenism, and activation delay. But I see nothing to do about that except try it and see if our first versionbits fork attempt fails to activate in a reasonable time.
2602016-03-03T19:11:29  <sipa> we can reduce the threshold if needed
2612016-03-03T19:11:49  <sipa> increasing is harder, as it may cause warning to not fire
2622016-03-03T19:12:08  <sdaftuar> sipa: is 7575 going to eventually include deployment code for BIP68/112/113, or are you going to remove the last commit for a different PR?
2632016-03-03T19:12:27  <sipa> sdaftuar: going to remove the last commit, and replace with whatever is agreed
2642016-03-03T19:12:29  <gmaxwell> Thats a good argument. (that it's easier to reduce the threshold)
2652016-03-03T19:12:47  <btcdrak> sdaftuar: I have the deployment code done for VB
2662016-03-03T19:13:07  <morcos> sipa: should the regtest window be smaller than 2016?
2672016-03-03T19:13:19  <sdaftuar> btcdrak: ok great.  i was just going to say that saving the deployment for a subsequent PR might be easier for reviewing tests, etc
2682016-03-03T19:13:49  <morcos> just seems like it'll make the tests less cumbersome if you want to watch what happens as you go up and down through a couple different windows
2692016-03-03T19:13:50  <btcdrak> I was going to say, regtest with 2016 retarget is cumbersome
2702016-03-03T19:13:55  <gmaxwell> we need to fix regtest to not fall over at retargeting.
2712016-03-03T19:14:01  <sdaftuar> i think that is fixed
2722016-03-03T19:14:03  <morcos> didn't we do that
2732016-03-03T19:14:08  <gmaxwell> oh sorry! :)
2742016-03-03T19:14:10  <sdaftuar> but it still might be cumbersome to generate long chains
2752016-03-03T19:14:18  <sipa> yes, regtest just never changes difficulty now
2762016-03-03T19:14:27  <btcdrak> it's cumbersome to generate long chains, since there are two retarget windows required.
2772016-03-03T19:14:40  <sipa> but good point; i can set the regtest window/threshold lower
2782016-03-03T19:14:49  <cfields> whoops, present. thanks gmaxwell.
2792016-03-03T19:14:51  <btcdrak> sipa: +1
2802016-03-03T19:14:52  <gmaxwell> why is typing setgenerate 4032 a problem?
2812016-03-03T19:15:01  <sdaftuar> however i also worry that we're no longer testing mainnet parameters, and the consensus parameters are duplicated for each chain
2822016-03-03T19:15:07  <sipa> gmaxwell: you want generate 4032
2832016-03-03T19:15:16  <btcdrak> gmaxwell: it's too much for RPC tests
2842016-03-03T19:15:24  <sipa> gmaxwell: setgenerate starts the internal miner with the specified number of cores; it no longer has special casing for regtest
2852016-03-03T19:15:28  <morcos> it just takes a little longer...
2862016-03-03T19:15:39  <gmaxwell> I do like to avoid avoidable differences between regtest and mainnet.
2872016-03-03T19:16:16  <gmaxwell> perhaps the answer if it's taking to long is to make regtest even faster?
2882016-03-03T19:16:36  <sipa> reintroduce SSE mining code? :p
2892016-03-03T19:16:44  <btcdrak> :p
2902016-03-03T19:16:52  <gmaxwell> I meant lower the difficulty. :)
2912016-03-03T19:17:07  <morcos> 12 secs
2922016-03-03T19:17:08  <sipa> the regtest difficulty is 1/2000000000
2932016-03-03T19:17:25  <sipa> you can at most get a 2x speedup
2942016-03-03T19:17:38  <morcos> i think it would make the rpc test for this pretty slow as i imagine you'd need to do that many times
2952016-03-03T19:17:50  <gmaxwell> OK, suggestion withdrawn.
2962016-03-03T19:18:08  * paveljanik is late, sorry
2972016-03-03T19:18:23  <sdaftuar> i worry more that a typo in the mainnet chain's deployment bitmask might go unnoticed/untested
2982016-03-03T19:18:40  <gmaxwell> (why is it so slow? 6 seconds for 4k blocks seems like a lot)
2992016-03-03T19:19:13  <sdaftuar> would anything catch that?
3002016-03-03T19:19:17  <sipa> i'm still fine with lower window for regtest
3012016-03-03T19:19:41  <gmaxwell> sdaftuar: review; I guess. (hahaha)
3022016-03-03T19:20:02  *** zooko has joined #bitcoin-core-dev
3032016-03-03T19:20:06  <btcdrak> gmaxwell: it's much slower on RPC tests
3042016-03-03T19:20:40  <sdaftuar> especially if there's stuff in your mempool right?
3052016-03-03T19:21:08  <sdaftuar> blockindex consistency checks and mempool consistency checks both add up i guess
3062016-03-03T19:21:21  <morcos> maybe we didn't fix everything...  blocks 4k -> 8k = 32 secs,   blocks 8k -> 12k = 53 secs
3072016-03-03T19:21:22  <sdaftuar> i'd guess*
3082016-03-03T19:21:30  <btcdrak> yeah it's like 45 seconds for me
3092016-03-03T19:21:32  <sdaftuar> blockindex checks are n^2 no?
3102016-03-03T19:21:38  <sdaftuar> er
3112016-03-03T19:21:45  <morcos> i suppose..  i think we're in the weeds
3122016-03-03T19:21:48  <sdaftuar> yeah sorry
3132016-03-03T19:22:20  <gmaxwell> So, sipa what do you need now for versionbits?
3142016-03-03T19:23:09  <sipa> let me push a few changes, and then review
3152016-03-03T19:23:18  <sipa> and tests are welcome
3162016-03-03T19:23:43  <gmaxwell> #action after sipa pushes a few changes; reivew/test 7575, review BIP9
3172016-03-03T19:24:11  <gmaxwell> Move on to segwit status? anyone have other agenda items to add?
3182016-03-03T19:24:24  <paveljanik> feefilter review etc. please
3192016-03-03T19:24:36  <morcos> and i hae a quick comment on tx backlog
3202016-03-03T19:24:39  <paveljanik> BIP113
3212016-03-03T19:24:58  <gmaxwell> k, lets do txbacklog right now.
3222016-03-03T19:24:58  <Luke-Jr> I still think feefilter should be a little more flexible.
3232016-03-03T19:25:02  <gmaxwell> #topic txbacklog
3242016-03-03T19:25:30  <Luke-Jr> is there one?
3252016-03-03T19:25:33  <morcos> i was wondering what kind of improvements are acceptable for minor releases
3262016-03-03T19:25:37  <paveljanik> s/113/133/
3272016-03-03T19:25:51  <sdaftuar> CPFP mining! :)
3282016-03-03T19:25:56  <sipa> morcos: in response to an urgent problem, i'd say "anything"
3292016-03-03T19:26:03  <morcos> i've noticed block validation seems to have slowed down significantly..  my theory is this is due to the daily cache flush and now many txs in blocks are older than that
3302016-03-03T19:26:09  <morcos> this isn't urgent for sure
3312016-03-03T19:26:12  <sipa> ok
3322016-03-03T19:26:32  <gmaxwell> Right now there has been an increase in tx with fees over 1 satoshi per byte. The months standing background spam load of a around a gigabyte below that seems largely unchanged to me.
3332016-03-03T19:26:36  <morcos> but it seems to me if we can correctly fix the "write but don't flush" aspect of the coinsviewcache, then that should be a significant performance boost
3342016-03-03T19:27:08  <morcos> i guess it depends on whether we think validation times are a significant bottleneck for anything
3352016-03-03T19:27:08  <sipa> morcos: yes...
3362016-03-03T19:27:19  <gmaxwell> morcos: I've noticed the startup checks being much slower and was wondering if we'd made some regression someplace. Haven't tried bisecting.
3372016-03-03T19:27:27  <petertodd> morcos: until we change to sending blocks before validating them they do add up
3382016-03-03T19:27:44  <Luke-Jr> has anyone looked into whether the new txs are real or spam?
3392016-03-03T19:28:05  <gmaxwell> Luke-Jr: some people have, petertodd was tweeting some analysis that strongly supported the latter.
3402016-03-03T19:28:08  <petertodd> Luke-Jr: yeah, they look like long chains where eventually everything goes back to the sender, apaprently
3412016-03-03T19:28:15  <petertodd> Luke-Jr: but no formal writeups exist yet
3422016-03-03T19:28:15  <Luke-Jr> hmm
3432016-03-03T19:28:21  <morcos> heh, you mean short chains..  woo hoo for chain limits!
3442016-03-03T19:28:40  <Luke-Jr> any patterns to identify it with?
3452016-03-03T19:28:40  <petertodd> morcos: no, they're long chains - once the txs confirm the chain is extended further
3462016-03-03T19:29:29  <gmaxwell> in general most wallets are responding well (hurray! big improvement from 6 months ago) though not all.
3472016-03-03T19:29:53  <petertodd> gmaxwell: speaking of, I noticed greenaddress has rbf code in their github repo
3482016-03-03T19:29:57  <morcos> it looks to me like the backlog is diminishing as well
3492016-03-03T19:29:57  <petertodd> gmaxwell: (for sending)
3502016-03-03T19:30:56  <gmaxwell> petertodd: interesting, yes.. gait has been working on that; I think he was off in a design rathole on how to best support updating with additional outputs.
3512016-03-03T19:31:23  <petertodd> gmaxwell: yeah, lots of possible ways wallets can do that, some of them quite different from how wallets work right now
3522016-03-03T19:31:24  <gmaxwell> FWIW, with the new proposal for schnorr aggregate signatures, updating for more outputs will be much more attractive.
3532016-03-03T19:31:38  <cfields> gmaxwell: speaking of, the -mintxfee behavior change may be worth a quick discussion.
3542016-03-03T19:32:06  <sipa> cfields: the -paytxfee change you mean? :)
3552016-03-03T19:32:12  <sipa> (too many fee parameters...)
3562016-03-03T19:32:19  <petertodd> gmaxwell: oh! that's a good point!
3572016-03-03T19:33:03  <cfields> sipa: er yes
3582016-03-03T19:33:06  <morcos> i think we just bungled not more clearly announcing the change in semantics for paytxfee
3592016-03-03T19:33:52  <morcos> surprising none of us flagged that as important at the time of the PR...  which does raise another issue, we should have a checklist of things to revisit before release
3602016-03-03T19:34:00  <gmaxwell> Did we know we really changed them? my view on the history was that it was changed to not round a long time ago, but another bug covered it up. That bug was fixed, and no one realized an announcement was needed.
3612016-03-03T19:34:10  <morcos> multiple times now we've said, ok we'll just need to fix that before release, and then forgotten or almost so
3622016-03-03T19:34:24  <morcos> gmaxwell: oh perhaps?
3632016-03-03T19:34:27  <Luke-Jr> morcos: well, the change in behaviour is definitely correct
3642016-03-03T19:34:43  <gmaxwell> I'm not sure that even if I realized it was a change I would have put "fee computation more accurate" as high importance-- since mining priority was changed to be precise a really long time ago. (0.6?)
3652016-03-03T19:35:01  <sipa> morcos: when i saw that discussion, i remembered the "fPayAtLeastCustomFee" global and associated problems, but I don't think I ever realized that that global and its default value equal to true was ever released
3662016-03-03T19:35:42  *** Don_John has joined #bitcoin-core-dev
3672016-03-03T19:35:45  <gmaxwell> yea, I saw that fix but don't think I realized that it was ever in a release. When sipa asked me about paytxfee yesturday I told him it was changed to be accurate forever ago.
3682016-03-03T19:35:56  <gmaxwell> So I think thats the sequence of errors here.
3692016-03-03T19:36:13  <gmaxwell> A checklist would be useful, though I don't know if it would have saved us here.
3702016-03-03T19:36:31  <sipa> so what i think happened is that at some point we switched the mining code to be per byte instead of per kb, later that global was introduced which implicitly retained the behaviour of "rounding up to 1000 bytes for fee calculation" even though the rest of the code was updated to be per byte, and only now, with the global going away, we actually get the accurate change
3712016-03-03T19:36:34  <gmaxwell> asking people to document if a bug being fixed was ever released might have helped.
3722016-03-03T19:36:36  <morcos> yeah , a checklist on changing behavior of any options or rpc calls being properly documented
3732016-03-03T19:36:58  <morcos> another example is -maxsigcachesize
3742016-03-03T19:37:04  <sipa> and i expect that people who made these changes were aware of it, as they updated the rpc tests accordingly, but not review
3752016-03-03T19:37:08  <morcos> i pity the poor fool who has that set to 100000
3762016-03-03T19:37:50  <gmaxwell> you don't have 100 gb ram?
3772016-03-03T19:37:52  <Luke-Jr> ideally we should probably do the release notes in the PR itself
3782016-03-03T19:37:59  <morcos> i'm not sure how many people would catch all these warnings in the 2 foot think binder of release notes, but its still good to have them
3792016-03-03T19:38:37  <gmaxwell> I don't think it was a big deal here, but it could have been one.
3802016-03-03T19:38:37  <sipa> well if we'd have warning for unknown options, we can just switch to a practice of renaming them whenever their meaning changes
3812016-03-03T19:38:41  <CodeShark> make sure to say "WARNING" first so it's searchable :)
3822016-03-03T19:38:57  <btcdrak> yeah I've been meaning to suggest we add at least brief release note documentation in PRs
3832016-03-03T19:39:14  <sipa> btcdrak: i always do (or try to...)
3842016-03-03T19:39:23  <gmaxwell> okay, we're going on a tangent.
3852016-03-03T19:39:36  <sipa> going on a tangent is a sin
3862016-03-03T19:39:41  <gmaxwell> Anything more to say about backlog before we move to talk fee filter?
3872016-03-03T19:39:43  <morcos> oh no
3882016-03-03T19:39:48  <CodeShark> no trig puns
3892016-03-03T19:39:58  <sipa> CodeShark: i co-sign that
3902016-03-03T19:39:58  <gmaxwell> My sides hurt.
3912016-03-03T19:40:00  <btcdrak> sipa: can you cosign this?
3922016-03-03T19:40:12  <Luke-Jr> lol
3932016-03-03T19:40:23  <Luke-Jr> ♥ sipa
3942016-03-03T19:40:26  <sdaftuar> so how about that fee filter
3952016-03-03T19:40:33  <gmaxwell> #topic feefilter
3962016-03-03T19:40:45  <morcos> it seems to work pretty well
3972016-03-03T19:40:49  <gmaxwell> Feefilter is awesome. I have not yet run it.
3982016-03-03T19:41:00  <Luke-Jr> sorry, I need to run.. I think feefilter at least needs some kind of "mode" for things like "how do we measure size" etc, but not a huge deal
3992016-03-03T19:41:05  <morcos> i mentioned in another context, it reduces tx send and rx bandwidth by around 40+%
4002016-03-03T19:41:28  <gmaxwell> thats fantastic.
4012016-03-03T19:41:28  <morcos> Luke-Jr: I'm basically of the mindset that we don't introduce complication until we need it
4022016-03-03T19:41:47  <morcos> its totally optional, so no reason not to replace it later with a more generic one if we ever bother implementing
4032016-03-03T19:42:02  <gmaxwell> We will not run out of message types, so we could introduce a modefilter later. I support that thinking.
4042016-03-03T19:42:11  <morcos> it seems to me the message type is the version, yep
4052016-03-03T19:42:19  <gmaxwell> I expect the way relay works to change substantially in the next couple years; so we should probably not overdesign here.
4062016-03-03T19:43:09  <morcos> i need to do a trivial pr rebase, but i guess it just needs more review
4072016-03-03T19:43:10  *** tr0nk has joined #bitcoin-core-dev
4082016-03-03T19:43:23  <morcos> i'm not sure what there is to discuss
4092016-03-03T19:43:38  <gmaxwell> Okay, I will test and review. Thanks for working on this.
4102016-03-03T19:43:50  <morcos> sure
4112016-03-03T19:43:58  <gmaxwell> #action Test and review fee filter. Morcos reports unicorns and rainbows result.
4122016-03-03T19:44:09  <paveljanik> great!
4132016-03-03T19:44:14  <morcos> well all depends on your test setup i guess.. :)
4142016-03-03T19:44:20  <gmaxwell> #topic CPFP mining
4152016-03-03T19:44:31  <gmaxwell> sdaftuar: hows it going?
4162016-03-03T19:44:33  <sdaftuar> it's awesome.
4172016-03-03T19:44:53  <sdaftuar> i've been running live for the last two days
4182016-03-03T19:45:16  <btcdrak> The PR number is #7600
4192016-03-03T19:45:20  <sdaftuar> comparing existing mining algorithm to new one
4202016-03-03T19:45:25  <sdaftuar> every ~128 tx's or so
4212016-03-03T19:45:57  <sdaftuar> looking at the last call to CNB before a block is found, i see a 72% increase in fee/block on the last 144 data points
4222016-03-03T19:45:58  <gmaxwell> I believe it should be making some pretty significant differences in selection from what I've seen. A number of users of OTHERBRAND wallet that has no fee estimation and always spends unconfirmed change seem to frequently produce chains of very low fee, very high fee (after realizing they needed more fee from the first tx).
4232016-03-03T19:46:08  <morcos> 72% ?!?!??!
4242016-03-03T19:46:15  <sdaftuar> that could obviously be due to a small number of tx's that aren't getting mined for extended periods
4252016-03-03T19:46:26  <sdaftuar> but geez we need this deployed, i think
4262016-03-03T19:46:41  <btcdrak> amazing
4272016-03-03T19:46:42  <sipa> sdaftuar: i believe that test would result in an exaggerated result
4282016-03-03T19:46:48  <gmaxwell> the effect is likely exagerated due to the pattern I just described: the human controlled fees are exagerating the needed increase.
4292016-03-03T19:47:06  <sipa> sdaftuar: as you're not actually creating blocks on the network with the new CPFP algorithm, i guess?
4302016-03-03T19:47:09  <sdaftuar> yep
4312016-03-03T19:47:10  <sdaftuar> correct
4322016-03-03T19:47:21  <sdaftuar> so if a tx stays around for a day, and isn't selected by the old code, you'd count it over and over
4332016-03-03T19:47:33  <sipa> sdaftuar: meaning that in a real setting, those "better" transactions would be mined once and cleaned up, reducing the effect for later blocks
4342016-03-03T19:47:37  <sipa> right,
4352016-03-03T19:47:37  <sdaftuar> correct
4362016-03-03T19:47:47  <sipa> sdaftuar: how about performance?
4372016-03-03T19:48:01  <sdaftuar> so there are three areas of performance to consider
4382016-03-03T19:48:11  <sdaftuar> one is the additional work of the mempool to keep the index
4392016-03-03T19:48:19  <sdaftuar> another is the part of CNB before TestBlockValidity is called
4402016-03-03T19:48:38  <sdaftuar> and the last is the time TestBlockValidity takes (much larger than the rest of CNB, which is why i think it makes sense to split it out)
4412016-03-03T19:48:58  <gmaxwell> (whom ever makes the lay summary, please don't report 72% increase as what CPFP does; in consideration of sipa's above point about N-fold counting)
4422016-03-03T19:49:19  <sdaftuar> the mempool work isn't really a steady state increase, the concern i think is in what happens when a block is connected
4432016-03-03T19:49:29  <sdaftuar> because then we have to update all the scores for every in-block transaction's descendants
4442016-03-03T19:49:54  <morcos> gmaxwell: also the previous number he reported to me was 1%.. :)
4452016-03-03T19:50:08  <sdaftuar> (when you add a tx to the mempool, you statically count its ancestors once, so that's basically negligible additional work)
4462016-03-03T19:50:40  <sdaftuar> so i timed that extra delay in mempool.removeForBlock
4472016-03-03T19:50:44  <morcos> but i think it is a good point, that if the increase is sometimes very big, its important for miners to take it...  presumably the average increase wouldn't ever be much different from 0, as we don't see txs permantely residing in mempool
4482016-03-03T19:50:46  <sdaftuar> and reported some numbers in #7594
4492016-03-03T19:51:14  <sdaftuar> looks like what i saw was an increase from an average of 10.9ms to 11.2ms
4502016-03-03T19:51:26  <sdaftuar> that was on half a month's data from october
4512016-03-03T19:51:32  <sdaftuar> er 10 days i guess actually
4522016-03-03T19:52:04  <sdaftuar> so i figure that's negligible enough to not really worry about, especially because if we really cared, we could make block relay happen while the mempool was still being updated, though it'd take some work
4532016-03-03T19:52:13  <gmaxwell> do we worry that CPFP's utility is compromised without package relay? -- I guess these measurements suggest its not.
4542016-03-03T19:52:22  <sdaftuar> moving on to CreateNewBlock's performance:
4552016-03-03T19:52:36  <sdaftuar> vast majority of CNB's total time is taken up by TestBlockValidity
4562016-03-03T19:53:06  <CodeShark> sorry to interrupt - we only have 8 minutes and I wanted to discuss segwit
4572016-03-03T19:53:16  <sdaftuar> somehow, TBV is slightly faster using the new code than the old one.  i haven't dived into it, but my guess is that maybe it's faster to look up mempool inputs than pcoinsTip inputs?
4582016-03-03T19:53:43  <sdaftuar> that speed increase is actually larger than the small hit to performance on the rest of CNB, so it's actually faster in total.  anyway numbers are in the PR #7600
4592016-03-03T19:53:45  <morcos> gmaxwell: i don't see that as a big concern...  i think it'll likely become common practice to avoid fees so small that they get evicted unless its actual spam.  and CPFP will be useful for when you guess wrong on getting confirmed quickly
4602016-03-03T19:53:46  <sdaftuar> i think this is a clear win
4612016-03-03T19:54:06  <gmaxwell> sdaftuar: it sounds great, what now do you think we need to do to move forward?
4622016-03-03T19:54:27  <sdaftuar> review! i broke the work into 3 PR's for review.  one just adds the ancestor feerate index to the mempool (7594)
4632016-03-03T19:54:29  <gmaxwell> morcos: I guess thats one upside over the overly large mempool default size.
4642016-03-03T19:54:38  <sdaftuar> another is by morcos, which refactors CNB
4652016-03-03T19:54:49  <sdaftuar> and then 7600 builds on both with the change to CNB
4662016-03-03T19:55:13  <morcos> #7598
4672016-03-03T19:55:30  <gmaxwell> #action whip people into wroking on review for CFPF 7594 / 7598 / 7600  it's nicely broken up.
4682016-03-03T19:55:39  <gmaxwell> Can we segwit for CodeShark?
4692016-03-03T19:55:43  <CodeShark> lol
4702016-03-03T19:55:44  <gmaxwell> #topic segwit status
4712016-03-03T19:55:52  <CodeShark> we had a fork a few days ago
4722016-03-03T19:56:05  <sipa> i haven't had time to investigate
4732016-03-03T19:56:19  <sipa> my hope is that it is caused by miners running older versions of the code
4742016-03-03T19:56:23  <sipa> and not something else
4752016-03-03T19:56:27  <gmaxwell> Time for science then.
4762016-03-03T19:56:43  <CodeShark> that's most probable - but we haven't narrowed down the conditional that actually caused it
4772016-03-03T19:56:48  <sipa> i was planning on doing a segnet4 very soon, but we'd need to understand what's causing this first
4782016-03-03T19:56:59  <morcos> well is there anyone stuck on the short fork?
4792016-03-03T19:57:13  <CodeShark> I think there might still be a few
4802016-03-03T19:57:26  <morcos> seems like would be helpful to know what errors they have and what code they are running
4812016-03-03T19:57:36  <cfields> hmm, i'd be interested in taking a look there. sipa: any helpful references/context ?
4822016-03-03T19:57:45  <gmaxwell> might be useful if regtest networks put their git build info in their version numbers. awful for privacy... but would be useful here.
4832016-03-03T19:57:50  <sipa> cfields: CodeShark probably knows more
4842016-03-03T19:58:10  <gmaxwell> (e.g. a chainparam to put that info in the subver)
4852016-03-03T19:58:11  <cfields> ok. will ping CodeShark after
4862016-03-03T19:58:22  <CodeShark> I think the offending block was something like 22130
4872016-03-03T19:58:26  <CodeShark> or 22132
4882016-03-03T19:58:29  <CodeShark> or somewhere around there
4892016-03-03T19:59:12  <gmaxwell> okay So-- sounds good, a fleet of flying monkies will contemplate the segnet fork.  Posting forked IPs in the segwit IRC channel might get someone's attention.
4902016-03-03T19:59:18  <btcdrak> it's in the logs of #segwit-dev
4912016-03-03T19:59:22  <cfields> ok, thanks
4922016-03-03T19:59:24  <morcos> whats the actual block we're on now?
4932016-03-03T19:59:40  <CodeShark> 22769
4942016-03-03T20:00:06  <CodeShark> https://segnet.smartbit.com.au/ is still stuck on 22153
4952016-03-03T20:00:09  <gmaxwell> okay any emergencies worth going over?
4962016-03-03T20:00:11  <CodeShark> so it's still running he old code
4972016-03-03T20:00:31  <gmaxwell> #endmeeting
4982016-03-03T20:00:31  <lightningbot> Meeting ended Thu Mar  3 20:00:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4992016-03-03T20:00:31  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.html
5002016-03-03T20:00:31  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.txt
5012016-03-03T20:00:31  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.log.html
5022016-03-03T20:00:44  <gmaxwell> Thanks everyone (of course feel free to keep discussing!)
5032016-03-03T20:01:57  <gmaxwell> Sorry we didn't get to all the topics.
5042016-03-03T20:01:58  <morcos> we still need tests for the soft fork BIPS right
5052016-03-03T20:02:15  *** chris2000 has quit IRC
5062016-03-03T20:02:21  <morcos> and 7187 still needs to be merged as well..
5072016-03-03T20:02:59  <btcdrak> morcos: I'm waiting on the python tests from sdaftuar for #7187
5082016-03-03T20:03:36  *** chris200_ has joined #bitcoin-core-dev
5092016-03-03T20:03:57  <gmaxwell> sdaftuar: if CPFP appears to be moderately stable, we might consider asking a moderately large miner to run it (in parallel to other stuff);  it would have most of it's usability benefit for the network if only one moderately large miner was running it.
5102016-03-03T20:05:18  <sdaftuar> gmaxwell: yeah i was wondering if any miners might be set up to test the new code using their production parameters at least?  so that we can measure performance in production settings and know we haven't missed anything
5112016-03-03T20:05:45  <sdaftuar> i thought it might make sense to wait until it was merged into master to ask someone to do that
5122016-03-03T20:11:33  *** treehug88 has joined #bitcoin-core-dev
5132016-03-03T20:21:14  <gmaxwell> sdaftuar: assuming that the surrounding enviroment is sufficently fail safe, even if it's a crash problem then it should be safe to try. but also no harm in getting some more maturity under its belt first.
5142016-03-03T20:21:32  <gmaxwell> The only reason I suggested it is because there are at least a few users whos delays could be avoided by it.
5152016-03-03T20:24:39  <sdaftuar> gmaxwell: that sounds reasonable to me.  do you have someone in mind to reach out to, or should i send out an email to the -dev list?
5162016-03-03T20:32:45  *** fredrin has quit IRC
5172016-03-03T20:35:04  *** fredrin has joined #bitcoin-core-dev
5182016-03-03T20:37:30  <gmaxwell> sdaftuar: I have someone in mind.
5192016-03-03T20:39:33  *** fredrin has quit IRC
5202016-03-03T20:41:30  *** fredrin has joined #bitcoin-core-dev
5212016-03-03T20:46:18  *** fredrin has quit IRC
5222016-03-03T20:46:46  <sdaftuar> gmaxwell: cool, feel free to put them in touch with me
5232016-03-03T20:46:57  *** fredrin has joined #bitcoin-core-dev
5242016-03-03T20:52:34  *** Guest66849 has joined #bitcoin-core-dev
5252016-03-03T20:52:41  *** Guest66849 has joined #bitcoin-core-dev
5262016-03-03T20:52:42  *** Guest66849 is now known as schmidty
5272016-03-03T21:02:44  *** jannes_ has quit IRC
5282016-03-03T21:04:57  *** tr0nk has quit IRC
5292016-03-03T21:24:00  *** xabbix has joined #bitcoin-core-dev
5302016-03-03T21:41:27  *** chiwawa_ has joined #bitcoin-core-dev
5312016-03-03T21:47:32  *** treehug88 has quit IRC
5322016-03-03T21:56:06  *** tr0nk has joined #bitcoin-core-dev
5332016-03-03T22:07:45  *** tr0nk has quit IRC
5342016-03-03T22:14:40  *** tr0nk has joined #bitcoin-core-dev
5352016-03-03T22:16:32  *** gevs has joined #bitcoin-core-dev
5362016-03-03T22:26:45  *** Guyver2 has quit IRC
5372016-03-03T22:32:45  *** laurentmt has joined #bitcoin-core-dev
5382016-03-03T22:55:44  *** laurentmt has quit IRC
5392016-03-03T22:57:56  *** chiwawa_ has quit IRC
5402016-03-03T23:22:08  *** justanot1eruser is now known as justanotheruser