12016-03-31T00:16:24  *** jtimon has quit IRC
  22016-03-31T00:30:46  *** fengling has joined #bitcoin-core-dev
  32016-03-31T00:35:16  *** fengling has quit IRC
  42016-03-31T01:00:09  *** p15 has joined #bitcoin-core-dev
  52016-03-31T01:01:02  *** Ylbam has quit IRC
  62016-03-31T01:09:04  *** zooko has joined #bitcoin-core-dev
  72016-03-31T01:16:06  *** ghtdak has joined #bitcoin-core-dev
  82016-03-31T01:37:03  *** fengling has joined #bitcoin-core-dev
  92016-03-31T02:31:09  *** Chris_Stewart_5 has quit IRC
 102016-03-31T02:53:48  <GitHub72> [bitcoin] maneotrix opened pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
 112016-03-31T02:56:36  *** Thireus1 has quit IRC
 122016-03-31T02:57:38  *** Thireus has joined #bitcoin-core-dev
 132016-03-31T03:09:48  *** achow101 has quit IRC
 142016-03-31T03:15:36  *** fengling has quit IRC
 152016-03-31T03:24:02  *** Alopex has quit IRC
 162016-03-31T03:25:07  *** Alopex has joined #bitcoin-core-dev
 172016-03-31T03:32:05  *** CodeShark_ has joined #bitcoin-core-dev
 182016-03-31T03:32:50  *** baldur has quit IRC
 192016-03-31T03:32:56  *** da2ce7_mobile has quit IRC
 202016-03-31T03:32:56  *** CodeShark has quit IRC
 212016-03-31T03:33:27  *** Bootvis has quit IRC
 222016-03-31T03:33:30  *** CodeShark_ is now known as CodeShark
 232016-03-31T03:33:30  *** supasonic has quit IRC
 242016-03-31T03:34:09  *** devrandom has quit IRC
 252016-03-31T03:34:09  *** jron has quit IRC
 262016-03-31T03:34:16  *** Bootvis has joined #bitcoin-core-dev
 272016-03-31T03:34:27  *** jron has joined #bitcoin-core-dev
 282016-03-31T03:34:30  *** devrandom has joined #bitcoin-core-dev
 292016-03-31T03:34:35  *** da2ce7_mobile has joined #bitcoin-core-dev
 302016-03-31T03:34:52  *** baldur has joined #bitcoin-core-dev
 312016-03-31T03:35:26  *** zooko has quit IRC
 322016-03-31T03:38:38  *** xiangfu has joined #bitcoin-core-dev
 332016-03-31T03:48:01  *** Alopex has quit IRC
 342016-03-31T03:49:06  *** Alopex has joined #bitcoin-core-dev
 352016-03-31T03:51:56  *** Giszmo has quit IRC
 362016-03-31T04:13:02  *** Alopex has quit IRC
 372016-03-31T04:14:07  *** Alopex has joined #bitcoin-core-dev
 382016-03-31T04:21:50  *** xiangfu has quit IRC
 392016-03-31T04:23:44  *** xiangfu has joined #bitcoin-core-dev
 402016-03-31T04:26:36  *** fengling has joined #bitcoin-core-dev
 412016-03-31T04:44:03  *** afk11 has quit IRC
 422016-03-31T04:46:59  *** afk11 has joined #bitcoin-core-dev
 432016-03-31T05:03:02  *** Alopex has quit IRC
 442016-03-31T05:04:07  *** Alopex has joined #bitcoin-core-dev
 452016-03-31T05:09:20  *** d_t has joined #bitcoin-core-dev
 462016-03-31T05:19:01  *** Alopex has quit IRC
 472016-03-31T05:20:06  *** Alopex has joined #bitcoin-core-dev
 482016-03-31T05:34:05  *** frankenmint has joined #bitcoin-core-dev
 492016-03-31T06:14:05  <GitHub136> [bitcoin] laanwj closed pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
 502016-03-31T06:15:02  *** Don_John has quit IRC
 512016-03-31T06:18:04  *** PRab has quit IRC
 522016-03-31T06:45:42  *** Ylbam has joined #bitcoin-core-dev
 532016-03-31T06:54:35  *** PRab has joined #bitcoin-core-dev
 542016-03-31T06:56:16  *** Thireus has quit IRC
 552016-03-31T07:21:38  *** abritoid has joined #bitcoin-core-dev
 562016-03-31T07:22:15  *** frankenmint has quit IRC
 572016-03-31T07:38:38  *** xiangfu has quit IRC
 582016-03-31T07:39:20  *** xiangfu has joined #bitcoin-core-dev
 592016-03-31T07:43:26  *** frankenmint has joined #bitcoin-core-dev
 602016-03-31T07:52:33  *** xiangfu has quit IRC
 612016-03-31T08:04:01  *** Alopex has quit IRC
 622016-03-31T08:05:06  *** Alopex has joined #bitcoin-core-dev
 632016-03-31T08:07:18  *** jannes has joined #bitcoin-core-dev
 642016-03-31T08:16:00  <wumpus> <gmaxwell> We're destroying the future utility by producing false positives now.  <- exactly
 652016-03-31T08:16:38  <wumpus> that's why I said "in any case let's say that if we can unequivocably decide that  7568 is an improvement that makes it worth keeping the system in the next 24 hours then we'll merge and backport that, otherwise we'll disable it in 0.12 for now" ... we should consider the utility now, even if that temporarily means disabling it
 662016-03-31T08:18:59  <wumpus> anyhow let's discuss at the meeting
 672016-03-31T08:20:08  *** Bootvis has quit IRC
 682016-03-31T08:24:20  *** PaulCapestany has joined #bitcoin-core-dev
 692016-03-31T08:27:04  *** PaulCape_ has quit IRC
 702016-03-31T08:39:15  *** frankenmint has quit IRC
 712016-03-31T08:51:07  *** PaulCape_ has joined #bitcoin-core-dev
 722016-03-31T08:52:40  *** AaronvanW has joined #bitcoin-core-dev
 732016-03-31T08:53:55  *** PaulCapestany has quit IRC
 742016-03-31T08:55:44  <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8a8f3d4b22b...16555b658f5b
 752016-03-31T08:55:45  <GitHub33> bitcoin/master fb8a8cf Wladimir J. van der Laan: rpc: Register calls where they are defined...
 762016-03-31T08:55:45  <GitHub33> bitcoin/master 16555b6 Wladimir J. van der Laan: Merge #7766: rpc: Register calls where they are defined...
 772016-03-31T08:55:51  <GitHub45> [bitcoin] laanwj closed pull request #7766: rpc: Register calls where they are defined (master...2016_03_separate_rpc_registration) https://github.com/bitcoin/bitcoin/pull/7766
 782016-03-31T08:56:20  *** Thireus has joined #bitcoin-core-dev
 792016-03-31T09:08:40  <GitHub195> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/16555b658f5b...7c80e720402d
 802016-03-31T09:08:40  <GitHub195> bitcoin/master 40234ba BtcDrak: Fix comments in tests
 812016-03-31T09:08:41  <GitHub195> bitcoin/master 7c80e72 Wladimir J. van der Laan: Merge #7773: Fix comments in tests...
 822016-03-31T09:08:50  <GitHub51> [bitcoin] laanwj closed pull request #7773: Fix comments in tests (master...csv-comments) https://github.com/bitcoin/bitcoin/pull/7773
 832016-03-31T09:16:43  *** PaulCapestany has joined #bitcoin-core-dev
 842016-03-31T09:19:38  *** PaulCape_ has quit IRC
 852016-03-31T09:40:06  *** frankenmint has joined #bitcoin-core-dev
 862016-03-31T09:47:03  *** frankenmint has quit IRC
 872016-03-31T09:55:53  *** jtimon has joined #bitcoin-core-dev
 882016-03-31T10:09:30  *** PaulCape_ has joined #bitcoin-core-dev
 892016-03-31T10:12:23  *** PaulCapestany has quit IRC
 902016-03-31T10:23:38  *** randy-waterhouse has left #bitcoin-core-dev
 912016-03-31T10:43:21  *** frankenmint has joined #bitcoin-core-dev
 922016-03-31T10:49:20  *** frankenmint has quit IRC
 932016-03-31T11:22:40  *** gijensen has quit IRC
 942016-03-31T11:22:40  *** da2ce7 has quit IRC
 952016-03-31T11:22:51  *** p15 has quit IRC
 962016-03-31T11:22:51  *** justanotheruser has quit IRC
 972016-03-31T11:22:51  *** Squidicc has quit IRC
 982016-03-31T11:22:53  *** da2ce7 has joined #bitcoin-core-dev
 992016-03-31T11:23:07  *** justanot1eruser has joined #bitcoin-core-dev
1002016-03-31T11:23:28  *** gijensen has joined #bitcoin-core-dev
1012016-03-31T11:25:19  <GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c80e720402d...3081fb9a3105
1022016-03-31T11:25:19  <GitHub59> bitcoin/master eff736e Pieter Wuille: Reformat version in UpdateTip and other messages...
1032016-03-31T11:25:20  <GitHub59> bitcoin/master 3081fb9 Wladimir J. van der Laan: Merge #7763: Put hex-encoded version in UpdateTip...
1042016-03-31T11:25:22  <GitHub95> [bitcoin] laanwj closed pull request #7763: Put hex-encoded version in UpdateTip (master...hexver) https://github.com/bitcoin/bitcoin/pull/7763
1052016-03-31T11:25:54  <GitHub99> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3081fb9a3105...209dbeb05f88
1062016-03-31T11:25:54  <GitHub99> bitcoin/master 3e55b3a accraze: [doc] added depends cross compile info
1072016-03-31T11:25:55  <GitHub99> bitcoin/master 209dbeb Wladimir J. van der Laan: Merge #7747: [docs] added depends cross compile info...
1082016-03-31T11:26:02  <GitHub89> [bitcoin] laanwj closed pull request #7747: [docs] added depends cross compile info (master...depends-build-docs) https://github.com/bitcoin/bitcoin/pull/7747
1092016-03-31T11:27:36  *** fengling has quit IRC
1102016-03-31T11:33:37  *** cryptapus has joined #bitcoin-core-dev
1112016-03-31T11:33:39  *** cryptapus has joined #bitcoin-core-dev
1122016-03-31T11:45:16  *** frankenmint has joined #bitcoin-core-dev
1132016-03-31T11:49:50  *** frankenmint has quit IRC
1142016-03-31T11:50:25  <GitHub59> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4d035bcc9aa3388dc7f37cf81451e55f0b6270ee
1152016-03-31T11:50:26  <GitHub59> bitcoin/0.12 4d035bc accraze: [doc] added depends cross compile info...
1162016-03-31T11:57:00  *** chris2000 has joined #bitcoin-core-dev
1172016-03-31T12:14:23  <GitHub125> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/209dbeb05f88...63832688939f
1182016-03-31T12:14:23  <GitHub125> bitcoin/master ae2156f Pavel Janík: Clear the input line after activating autocomplete
1192016-03-31T12:14:24  <GitHub125> bitcoin/master 6383268 Jonas Schnelli: Merge #7772: Clear the input line after activating autocomplete...
1202016-03-31T12:14:32  <GitHub14> [bitcoin] jonasschnelli closed pull request #7772: Clear the input line after activating autocomplete (master...20160330_completer_clean_input_line) https://github.com/bitcoin/bitcoin/pull/7772
1212016-03-31T12:29:17  <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63832688939f...28ad4d9fc2be
1222016-03-31T12:29:18  <GitHub124> bitcoin/master 72fd008 Daniel Kraft: Fix quoting of copyright holders in configure.ac....
1232016-03-31T12:29:18  <GitHub124> bitcoin/master 28ad4d9 Wladimir J. van der Laan: Merge #7477: Fix quoting of copyright holders in configure.ac....
1242016-03-31T12:29:24  <GitHub97> [bitcoin] laanwj closed pull request #7477: Fix quoting of copyright holders in configure.ac. (master...configure-quoting) https://github.com/bitcoin/bitcoin/pull/7477
1252016-03-31T12:45:51  <GitHub199> [bitcoin] laanwj closed pull request #7511: [WIP] New ax_pthread.m4 from upstream - draft 3 (not final), for testing on all platforms (master...20160211_WIP_test_new_ax_pthread) https://github.com/bitcoin/bitcoin/pull/7511
1262016-03-31T12:46:00  *** frankenmint has joined #bitcoin-core-dev
1272016-03-31T12:50:38  *** frankenmint has quit IRC
1282016-03-31T12:56:31  <GitHub104> [bitcoin] laanwj opened pull request #7776: build: Remove unnecessary executables from gitian release (master...2016_03_gitian_release_cleanup) https://github.com/bitcoin/bitcoin/pull/7776
1292016-03-31T13:12:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1302016-03-31T13:22:30  *** Chris_Stewart_5 has quit IRC
1312016-03-31T13:29:25  *** Giszmo has joined #bitcoin-core-dev
1322016-03-31T13:36:01  <GitHub57> [bitcoin] jtimon closed pull request #7731: Discussion: By "more precision", I don't mean using rational numbers in CFeeRate (master...0.12.99-feerate) https://github.com/bitcoin/bitcoin/pull/7731
1332016-03-31T13:36:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1342016-03-31T13:43:25  *** MarcoFalke has joined #bitcoin-core-dev
1352016-03-31T13:46:46  *** frankenmint has joined #bitcoin-core-dev
1362016-03-31T13:51:24  *** frankenmint has quit IRC
1372016-03-31T13:57:04  *** fengling has joined #bitcoin-core-dev
1382016-03-31T14:01:56  *** fengling has quit IRC
1392016-03-31T14:20:46  <GitHub142> [bitcoin] laanwj pushed 5 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/c251f46bea8f...ecaa178a235a
1402016-03-31T14:20:46  <GitHub25> [bitcoin] laanwj closed pull request #7743: [0.11] Important backports for 0.11.3 (updated to v0.12.0) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7743
1412016-03-31T14:20:47  <GitHub142> bitcoin/0.11 90de0e1 Cory Fields: build: Split hardening/fPIE options out...
1422016-03-31T14:20:47  <GitHub142> bitcoin/0.11 5c0b357 Cory Fields: build: Use fPIC rather than fPIE for qt objects....
1432016-03-31T14:20:48  <GitHub142> bitcoin/0.11 d626faa Luke Dashjr: Merge commit '5c0b357' into backports-for-0.11.3
1442016-03-31T14:31:30  *** trippysalmon has joined #bitcoin-core-dev
1452016-03-31T14:46:14  *** zooko has joined #bitcoin-core-dev
1462016-03-31T14:46:29  <MarcoFalke> Anything holding back 7691?
1472016-03-31T15:17:32  *** frankenmint has joined #bitcoin-core-dev
1482016-03-31T15:22:01  *** frankenmint has quit IRC
1492016-03-31T15:27:29  *** zooko` has joined #bitcoin-core-dev
1502016-03-31T15:29:18  *** zooko has quit IRC
1512016-03-31T15:35:47  *** abritoid has quit IRC
1522016-03-31T16:00:15  *** fengling has joined #bitcoin-core-dev
1532016-03-31T16:04:56  *** fengling has quit IRC
1542016-03-31T16:06:13  *** chris2000 has quit IRC
1552016-03-31T16:09:52  *** zooko` has quit IRC
1562016-03-31T16:10:48  *** Bootvis has joined #bitcoin-core-dev
1572016-03-31T16:13:18  *** Don_John has joined #bitcoin-core-dev
1582016-03-31T16:21:56  <sdaftuar> wumpus: can you explain the infinite loop in EncodeDecimal that #7751 addressed?
1592016-03-31T16:22:27  *** JeromeLegoupil has joined #bitcoin-core-dev
1602016-03-31T16:27:14  <morcos> wumpus: in particular, encoding amounts as strings for json now make it so that current rpc tests can't be run against pre 0.12 binaries
1612016-03-31T16:28:03  <morcos> we discovered this when sdaftuar couldn't reproduce the same testing of the CSV soft fork backport I and btcdrak did without removing all the calls to Decimal
1622016-03-31T16:28:45  <morcos> Also it would make it hard to use our rpc tests to test against other implementations which might not handle JSON numbers as strings since thats not really proper json
1632016-03-31T16:29:02  <morcos> it seems better if our rpc tests dont' encode them that way?
1642016-03-31T16:35:32  *** abritoid has joined #bitcoin-core-dev
1652016-03-31T16:37:20  <GitHub136> [bitcoin] MarcoFalke opened pull request #7778: [qa] Bug fixes and refactor (master...Mf1604-qaFixesRefactor) https://github.com/bitcoin/bitcoin/pull/7778
1662016-03-31T16:47:55  *** zooko has joined #bitcoin-core-dev
1672016-03-31T16:51:30  <GitHub176> [bitcoin] MarcoFalke closed pull request #7722: [qa] Refactor python2 syntax (master...Mf1603-qaPy2/3) https://github.com/bitcoin/bitcoin/pull/7722
1682016-03-31T16:52:34  *** zooko` has joined #bitcoin-core-dev
1692016-03-31T16:53:48  *** zooko has quit IRC
1702016-03-31T16:54:39  <GitHub32> [bitcoin] jtimon opened pull request #7779: Discussion: Consensus: There's only one type of consensus flags (master...0.12.99-consensus-unify-flags) https://github.com/bitcoin/bitcoin/pull/7779
1712016-03-31T17:02:04  *** Cheeseo has quit IRC
1722016-03-31T17:10:39  <MarcoFalke> NicolasDorier, I can still see it
1732016-03-31T17:10:41  <MarcoFalke> +        if (!CheckFinalTx(tx, flags)
1742016-03-31T17:11:06  <NicolasDorier> ?? one second
1752016-03-31T17:11:41  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/R9q9fyfu/
1762016-03-31T17:11:47  <NicolasDorier> I removed the flags
1772016-03-31T17:11:54  <NicolasDorier> and it compiles on travis
1782016-03-31T17:12:49  <NicolasDorier> MarcoFalke: you see the like with flags as "add" ?
1792016-03-31T17:12:58  <NicolasDorier> the line
1802016-03-31T17:13:18  <MarcoFalke> travis is all red
1812016-03-31T17:13:54  <MarcoFalke> check char 25 in this line
1822016-03-31T17:13:56  <NicolasDorier> nop, only two build which are red because I pushed too fast, if can again should work fine
1832016-03-31T17:14:10  <NicolasDorier> hu are we on same commit ?
1842016-03-31T17:14:25  <NicolasDorier> ad930cdab3b23801f8a415cc4e900a182a6f8bc6 ?
1852016-03-31T17:15:12  <wumpus> sdaftuar: in python 3.4, round(Decimal) no longer converts the decimal to a float
1862016-03-31T17:15:26  <MarcoFalke> git grep 'if (!CheckFinalTx(tx, flags)'
1872016-03-31T17:15:34  <wumpus> sdaftuar: so EncodeDecimal returns a (rounded) Decimal, which is again passed to EncodeDecimal
1882016-03-31T17:15:36  <MarcoFalke> on the commit you posted
1892016-03-31T17:15:43  <MarcoFalke> what is the result?
1902016-03-31T17:16:13  <NicolasDorier> ooooooh
1912016-03-31T17:16:16  <wumpus> sdaftuar: (e.g. if the 'default' function returns an object that is not json encodable, it will call the function on it, just as long as necessary)
1922016-03-31T17:16:34  <NicolasDorier> omg sorry, wtf did it compiled on several conf in travis and on my machine
1932016-03-31T17:16:40  <sdaftuar> wumpus: ah okay
1942016-03-31T17:16:52  <wumpus> sdaftuar: that shouldn't be backported to pre-0.12, no
1952016-03-31T17:17:09  <MarcoFalke> I think there is an issue with travis if you push faster than it can start the build.
1962016-03-31T17:17:24  <MarcoFalke> It will just compile the current ref instad of the commit you pushed
1972016-03-31T17:17:28  <wumpus> MarcoFalke: yes, it will try to fetch the pull then fails
1982016-03-31T17:17:44  <wumpus> oh okay
1992016-03-31T17:18:03  <wumpus> sdaftuar: you can still use the old authproxy.py if yo udon't care about python 3 compat
2002016-03-31T17:18:22  <sdaftuar> wumpus: right, yeah i figured out how to workaround the issue for now
2012016-03-31T17:18:45  <sdaftuar> wumpus: but i do wonder if the fix in master makes sense, we're outside the JSON spec when we deliver numeric values as strings, right?
2022016-03-31T17:18:50  <sdaftuar> i know bitcoind supports it
2032016-03-31T17:19:42  <NicolasDorier> MarcoFalke: Just repushed, sorry for the myopa :D
2042016-03-31T17:20:29  <MarcoFalke> np
2052016-03-31T17:20:48  *** Tasoshi_ has joined #bitcoin-core-dev
2062016-03-31T17:22:48  *** cguida has quit IRC
2072016-03-31T17:23:05  *** cguida has joined #bitcoin-core-dev
2082016-03-31T17:24:28  <wumpus> sdaftuar: how is passing strings 'outside the json spec'?
2092016-03-31T17:24:30  *** Tasoshi has quit IRC
2102016-03-31T17:24:44  <sdaftuar> for numeric values i mean
2112016-03-31T17:24:49  <wumpus> what it sends it 100% valid json
2122016-03-31T17:25:12  <wumpus> well the underlying problem is that python has no way to send-this-string-unquoted
2132016-03-31T17:25:12  <sdaftuar> hm, so i guess the rpc calls themselves now support numeric or string?  i suppose that makes sense.
2142016-03-31T17:25:25  *** MarcoFalke has quit IRC
2152016-03-31T17:25:27  <wumpus> casting to float defeats the purpose of using decimal in the first place
2162016-03-31T17:25:46  <wumpus> so I think this is better
2172016-03-31T17:26:20  <wumpus> besides reimplementing the json module to support arbitrary number formats, like univalue
2182016-03-31T17:28:38  <wumpus> but yes the reason we implement strings for monetary values is that this is easier to use for software that uses decimals, no need to insert another type into the json stream just wrap it as string
2192016-03-31T17:29:03  <wumpus> indeed, this is implemented in AmountFromValue
2202016-03-31T17:30:46  <instagibbs> has anyone charted out the various major function calls for accepting/creating new blocks? I don't find the function call names very helpful :)
2212016-03-31T17:31:06  <instagibbs> and comments tend to have lingo I don't really grok
2222016-03-31T17:31:08  <wumpus> the doxygen docs have a call tree
2232016-03-31T17:31:14  <instagibbs> hmm ill check that
2242016-03-31T17:32:36  <morcos> sipa: gmaxwell: i was just trying to do a quick review of #7568 and i'm very confused
2252016-03-31T17:32:37  <wumpus> https://dev.visucore.com/bitcoin/doxygen/
2262016-03-31T17:32:58  <instagibbs> yeah found it, thanks. Just need to find the "tip" of the flow I'm looking for now :)
2272016-03-31T17:33:16  <morcos> isn't it doomed to have way too many false positives due to its use of GetBlockTime().  I mean that could kind of be anything.
2282016-03-31T17:33:32  <morcos> We have to measure when the block was actually found, not the time on the block right?
2292016-03-31T17:33:49  <instagibbs> wumpus, oh this is actually really useful, it has callee & caller graph
2302016-03-31T17:34:21  <morcos> It's not clear to me that 7568 would meaningfully reduce the number of false positives, so i might now be leaning towards removal for 0.12.1, but i'd like to make sure i'm not missing something
2312016-03-31T17:42:50  *** frankenmint has joined #bitcoin-core-dev
2322016-03-31T17:49:03  <NicolasDorier> morcos: for #7574 you say it is premature to remove, why ? this code is not used at all anymore, why keeping it around ?
2332016-03-31T17:49:59  <morcos> NicolasDorier: We don't even know if these soft forks are going to activate.  We should not lock ourselves into only using MTP for mempool acceptance until they do.
2342016-03-31T17:50:50  <NicolasDorier> so you mean in case we need to revert it would be easier ?
2352016-03-31T17:50:55  <morcos> I'd even argue that after they activate, its still better to preserve the ability to pass in different flags to the mempool.  If for instance trying to analyze something that happend on the chain before the soft fork triggered, or starting a new chain where the fork hasn't triggered yet
2362016-03-31T17:51:07  <wumpus> I tend to agree it may be too early to remove it
2372016-03-31T17:51:20  <NicolasDorier> ok I close the pr for now or keep around ?
2382016-03-31T17:51:22  <wumpus> and for future softforks there may be other, new, flags to pass around
2392016-03-31T17:51:22  <morcos> I like #7779 as the right approach
2402016-03-31T17:51:35  <morcos> OR a step in the right direction
2412016-03-31T17:52:00  <NicolasDorier> ok let's do that then, I close the PR ?
2422016-03-31T17:52:01  <morcos> If you see in the segwit code I actually introduce some ways to accept non-standard stuff to the mempool (At least for testnet/regtest)
2432016-03-31T17:52:14  <morcos> I think that its better to abstract ways to do that for better testing
2442016-03-31T17:52:30  <morcos> That would be my recommendation (close the PR)
2452016-03-31T17:52:58  <NicolasDorier> ok did it
2462016-03-31T17:53:00  <wumpus> NicolasDorier: yes I think so, we can always bring it back when it's time
2472016-03-31T17:53:02  <morcos> NicolasDorier: I actually thought until today that we shouldn't even have the LOCKTIME_VERIFY_SEQUENCE flag at all
2482016-03-31T17:53:06  <GitHub28> [bitcoin] NicolasDorier closed pull request #7574: Remove STANDARD_LOCKTIME_VERIFY_FLAGS and mempool policy's flags (master...removeFlag) https://github.com/bitcoin/bitcoin/pull/7574
2492016-03-31T17:53:34  <NicolasDorier> morcos, I think there is case where we need it
2502016-03-31T17:53:36  <morcos> but now I think by my own argument we should have that, so that we have a way to specify for the mempool whether it should enforce that or not
2512016-03-31T17:53:54  <NicolasDorier> if the fork is not activated, the flag is off
2522016-03-31T17:54:05  <morcos> For consensus its not needed, because you can just check for the CSV soft fork activation and then not even call SequenceLocks if it isn't activated
2532016-03-31T17:54:35  <morcos> No reason to call it with no flag and have it just short circuit
2542016-03-31T17:55:36  <NicolasDorier> ah yes I see what you mean
2552016-03-31T17:55:38  <morcos> I think we properly abstract a set of rules and a way to determine whether they are active (and this can be consensus or standardness) its possible that just the flags bitfield is the right way to do this, i'm not sure
2562016-03-31T17:56:58  <morcos> It seems like what you really want is a way to do that for the mempool.  What is active now
2572016-03-31T17:57:08  <morcos> For blocks you recreate that set of flags each block
2582016-03-31T17:57:20  <morcos> but for the mempool, you want to know what was active as of the last block
2592016-03-31T17:57:43  <morcos> maybe thats somethign we should just save as a global from connectBlock or maybe there is a better way
2602016-03-31T17:57:45  <wumpus> well not exactly that, I think
2612016-03-31T17:57:53  <wumpus> usually we start enforcing things for the mempool first
2622016-03-31T17:57:59  <morcos> wumpus: well you want AT LEAST that
2632016-03-31T17:58:10  <wumpus> I think for the mempool you want to do *everything*
2642016-03-31T17:58:29  <wumpus> there's generally no point in merging a softfork and not enforcing it for the mempool
2652016-03-31T17:58:45  <morcos> wumpus: I don't like it that in the mempool you are separately constructing that list of rules for the mempool via the STANDARD_FLAGS
2662016-03-31T17:59:11  <morcos> I think somehow you should have the STANDARD_FLAGS and the currently active consensus flags
2672016-03-31T17:59:27  <morcos> instead we have STANDARD_FLAGS and sort of original consensus flags
2682016-03-31T17:59:34  <wumpus> well sure, the standard flags need to be stricter than anything that is currently active
2692016-03-31T18:00:22  <wumpus> I'm sure that could be implemented with more clarity, but effectively I think it's doing the right thing. Standard has alwasy been "be as strict as possible, above and beyond what consensus requires"
2702016-03-31T18:00:51  <wumpus> there's nothing wrong with having a mechanism that checks and makes sure that that is the case, of course
2712016-03-31T18:01:51  <wumpus> another thing is that the rules for the mempool should be invariant over a run, otherwise there may be old transactions in the mempool from earlier (before catching up) before some new rules were added
2722016-03-31T18:02:41  <morcos> yeah i keep getting concerned around mempool issues during a soft fork activation
2732016-03-31T18:02:47  <morcos> but i don't think there are any current problems
2742016-03-31T18:03:22  <morcos> wumpus: did you see my prior comment on alert chain triggering.  i'm not pro removal
2752016-03-31T18:03:31  <morcos> i'm NOW pro removal i mean
2762016-03-31T18:03:51  <morcos> bad-chain alert triggering, ugh, i can't type today
2772016-03-31T18:04:15  <wumpus> well as long as the mempool already enforces a rule *before* the softfork triggers, something we always make sure, there should be no problem
2782016-03-31T18:04:36  <wumpus> morcos: yes I saw, I think we should discuss it at the meeting but the prevailing sentiment seems to be to remove it for 0.12.1
2792016-03-31T18:06:27  <morcos> ok, i'll be back for that
2802016-03-31T18:12:56  <gmaxwell> morcos: Just comining into the discussion but we prefer a behavior change be throughly non-standard on the whole network before a soft-fork activates so that unupgraded software does not get itself orphaned. Generally a soft-fork should not be invalidating any transactions honest users are actually making. (MTP is special in my view because the 'invalidation' is merely a short delay, and there w
2812016-03-31T18:13:02  <gmaxwell> ere very few timelocked transactions being made)
2822016-03-31T18:13:32  <gmaxwell> and so since we'd want to make that transistion a version or two ahead, there really isn't a reason to make sure we re-filter the mempool.
2832016-03-31T18:19:40  <NicolasDorier> not enforcing a sf in mempool before activation may also be an attack. For example MTP, if it was not pushed in mempool for 0.11, when it would have been enforced by miners, someone can flood the network of old nodes by making replacement transaction whci never can confirm but can still be propagated.
2842016-03-31T18:20:04  <zooko`> The Zcash project has an issue ticket to track "hard-fork detection", which I currently think is the same thing or
2852016-03-31T18:20:20  <zooko`> at least closely related to the bad-chain-alert-triggering that you're talking about
2862016-03-31T18:20:24  <zooko`> disabling: https://github.com/zcash/zcash/issues/131#issuecomment-204063197
2872016-03-31T18:20:45  *** zooko` is now known as zooko
2882016-03-31T18:21:23  <sipa> zooko: no, this is about partition detection; hard forks are much easier to detect: you see a longer but invalid chain
2892016-03-31T18:21:37  <zooko> sipa: oh, thanks.
2902016-03-31T18:21:48  *** frankenmint has quit IRC
2912016-03-31T18:22:13  *** d_t has joined #bitcoin-core-dev
2922016-03-31T18:24:40  <sipa> morcos: see my comments on the PR
2932016-03-31T18:25:02  <sipa> morcos: i don't know what the reason is for the actual false firing we frequently see now
2942016-03-31T18:33:32  <sipa> morcos: i actually have no idea how much block timestamps are off
2952016-03-31T18:35:31  <gmaxwell> I doubt it's block timestamps.
2962016-03-31T18:36:42  <gmaxwell> one cause of false firing is correct but uninteresting firing. E.g. not enough blocks shows up on my laptop when I leave the office and go to dinner and such on the way home, then for the next week until I restart I'm left with this stupid not enough blocks warning.
2972016-03-31T18:37:37  <gmaxwell> It's unfortunate that this was constructed without a clear model of the kinds of true positives it was trying to detect.
2982016-03-31T18:37:40  <helo> should it be bother-until-dismissed?
2992016-03-31T18:39:43  <helo> in -qt, that is
3002016-03-31T18:39:54  <gmaxwell> thats obnoxious too, what is the threat you hope to solve by telling people their network connection _used_ to be down?
3012016-03-31T18:40:56  <gmaxwell> without an argument, that just sounds like another kind of false positive: we commanded the users attention where no action was actually required on their part.  Creating more reason to ignore any further warnings.
3022016-03-31T18:47:20  <morcos> gmaxwell: i'm surprised you don't think its the block time stamps
3032016-03-31T18:47:40  <morcos> as soon as the current tip is over 130 mins old by its own time stamp, that'll cause an alert
3042016-03-31T18:48:02  <helo> potentially bad (but probably not) might warrant getting someone's attention... -paranoialevel=N
3052016-03-31T18:48:10  <morcos> that seems likely to happen, if say it was mined with a time an hour in the past and it was another 70 mins before the next block was found
3062016-03-31T18:48:16  <dgenr8> sipa: you can get a quick idea from tac debug.log | grep UpdateTip | awk '{printf("%s %s\n", $2, $10);}
3072016-03-31T18:50:33  <dgenr8> '
3082016-03-31T18:56:01  <morcos> and even if that isn't the cause, it allows any miner to make a false alert more likely by just using an old timestamp
3092016-03-31T18:56:17  *** kangx has joined #bitcoin-core-dev
3102016-03-31T18:56:34  <sipa> in the short term i am mostly concernes with fixing the spurious alerts
3112016-03-31T18:56:56  <sipa> longer term, we should think hard about what the cases are to detect
3122016-03-31T18:57:29  <sipa> for example, if miners would intentionally keep timestamps low, isn't that something to alert about as well?
3132016-03-31T18:58:27  <jonasschnelli> Right? The meeting is now +1 on GMT?
3142016-03-31T18:58:28  <dgenr8> time warp
3152016-03-31T18:58:36  <wumpus> yes I think so
3162016-03-31T18:59:05  <wumpus> no, I mean meeting is +0 UTC, but that's now isn't it?
3172016-03-31T18:59:05  <Luke-Jr> ?
3182016-03-31T18:59:16  <Luke-Jr> my calendar says it should start right now
3192016-03-31T18:59:20  <paveljanik> yup
3202016-03-31T18:59:21  <petertodd> Luke-Jr: ack
3212016-03-31T18:59:39  <wumpus> meeting is in Reykjavik time, they don't have DST
3222016-03-31T18:59:45  <wumpus> #startmeeting
3232016-03-31T18:59:45  <lightningbot> Meeting started Thu Mar 31 18:59:45 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3242016-03-31T18:59:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3252016-03-31T19:00:16  <wumpus> action points from last meeting: ACTION: review more at https://github.com/bitcoin/bitcoin/pull/7648 (wumpus, 19:05:42)    done and merged
3262016-03-31T19:00:27  <jonasschnelli> topic proposal (short): p2p layer encryption
3272016-03-31T19:00:35  <wumpus> ACTION: hunt down miners that mine MTP violations <- don't know about this one
3282016-03-31T19:00:50  <wumpus> main topic is the softfork backports I think
3292016-03-31T19:01:16  <sipa> topic: short update on segwit and segnet4
3302016-03-31T19:01:29  <wumpus> cool
3312016-03-31T19:01:43  <wumpus> #topic short update on segwit and segnet4
3322016-03-31T19:02:00  <cfields> topic suggestion: net-refactor update
3332016-03-31T19:02:33  <sipa> segwit code progressed a lot the past few days; it now passes all preexisting rpc tests and unit tests, and many bugs were fixed in the process
3342016-03-31T19:02:45  *** frankenmint has joined #bitcoin-core-dev
3352016-03-31T19:02:49  <jonasschnelli> Nice!
3362016-03-31T19:02:51  <wumpus> good to hear!
3372016-03-31T19:02:52  <petertodd> sipa: +1
3382016-03-31T19:03:00  <jonasschnelli> also had no crash on my segnet4 node.. :)
3392016-03-31T19:03:27  <sipa> it's also rebased on top of the bip68/112/113 backport, and a new segnet (segnet4) is up and running with bip9 activation logic
3402016-03-31T19:03:53  <gmaxwell> morcos: my uncertanty comes from looking at some incidents and it not being obvious what the cause was in them.
3412016-03-31T19:04:01  <gmaxwell> it's not well founded uncertanty.
3422016-03-31T19:04:12  <gmaxwell> oops. [sorry for OT]
3432016-03-31T19:04:24  <sipa> lastly, i have significantly reorganized the commits in the branch to 1) define segnet 2) add consensus/node logic 3) add wallet logic 4) add tests
3442016-03-31T19:04:48  <sipa> so that upgrade tests from pre-segwit code post fork can be tested
3452016-03-31T19:04:58  <sipa> and so that the consensus critical part can be reviewed separately
3462016-03-31T19:05:16  <morcos> sipa: i think it would be hugely beneficial if you could come up with a list of things you'd like other people to work on to move this forward
3472016-03-31T19:05:26  <sipa> ack, will do
3482016-03-31T19:05:49  <cfields> yes, that would be great
3492016-03-31T19:06:07  <petertodd> I should add segwit to python-bitcoinlib...
3502016-03-31T19:06:07  <sipa> the next thing i will do myself is write script unit tests, as we are not testing all possible witness validation failures
3512016-03-31T19:06:50  <gmaxwell> As far as the MTP huntdown, sdaftuar checked to see if there were violations already, and there weren't. I need to start generating mtp violating transactions, but haven't done this yet.
3522016-03-31T19:07:07  <petertodd> sipa: ah cool - are you going to do that with the existing script_(in)valid.json framework?
3532016-03-31T19:07:42  <sipa> there are some unusual things to test that are not typivally needed for softforks, such as the preferential peering (oh, that's implemented too; on top of the service bits enforcement logic), rewind testing, ...
3542016-03-31T19:07:46  <sipa> petertodd: yes
3552016-03-31T19:08:18  <btcdrak> #link https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit
3562016-03-31T19:08:21  <wumpus> #action start generating mtp violating transactions (gmaxwell)
3572016-03-31T19:08:29  <petertodd> sipa: how are you going to add segwit support to it? (I was just updating python-bitcoinlib's script unit tests yesterday along those lines)
3582016-03-31T19:08:51  <sipa> petertodd: tbd, i'm sure i'll find a way
3592016-03-31T19:09:00  <sipa> but i haven't looked into it deeply
3602016-03-31T19:09:56  <sipa> EOT? (end of topic)
3612016-03-31T19:10:20  <sipa> btcdrak: no, use segwit-base...segwit
3622016-03-31T19:10:34  <sipa> (so you don't see the backports before segwit)
3632016-03-31T19:10:57  <wumpus> ok
3642016-03-31T19:11:21  <wumpus> #topic net-refactor update
3652016-03-31T19:11:52  <wumpus> @cfields
3662016-03-31T19:11:56  <cfields> ok. I've pushed an up-to-date version to my net-refactor10 branch...
3672016-03-31T19:12:13  <cfields> at this point, it's ready for testing and review, but i'm not entirely sure how to proceed
3682016-03-31T19:12:30  <wumpus> ohh I'm two branches behind
3692016-03-31T19:13:01  <wumpus> what is unclear?
3702016-03-31T19:13:04  <cfields> atm it's just 2 huge commits. I'm not sure how much it's worth going in and splitting into logical chunks, because it's really one big change...
3712016-03-31T19:13:14  <btcdrak> sipa: this then? https://github.com/sipa/bitcoin/compare/segwit-base...sipa:segwit
3722016-03-31T19:13:20  <sipa> btcdrak: ack
3732016-03-31T19:13:33  <wumpus> well if it is one big change it should be one commit
3742016-03-31T19:13:49  <wumpus> splitting makes sense if there are atomic changes
3752016-03-31T19:14:13  <wumpus> especially if they're somewhat independent
3762016-03-31T19:14:24  <cfields> also, it needs a bunch of unit tests, which I'm still working on a framework for. For catching stupid things like max connections, etc
3772016-03-31T19:15:06  <cfields> wumpus: sure. what I'm not clear on is if I should try to refactor current master to make it easier to slide in the other changes, or just plan to do it all in one go
3782016-03-31T19:15:37  <cfields> s/refactor/PR small refactoring chunks/
3792016-03-31T19:15:50  <wumpus> I don't know. I'd try it first in one go, if people complain about it being to much you can always decide to do it in multiple phases.
3802016-03-31T19:16:33  <cfields> ok. Well, next steps are adding tons of docs and tests. But at this point, I'm happy to have people test and point out any brokenness
3812016-03-31T19:17:30  <wumpus> congrats :)
3822016-03-31T19:17:40  <cfields> I suppose that's it for now
3832016-03-31T19:18:12  <wumpus> unfortunately this comes at a time that people are really busy, so I hope they can spare enough review cycles, to get this in for 0.13
3842016-03-31T19:18:42  <cfields> wumpus: understood. I'm starting to doubt whether it makes sense for .13.
3852016-03-31T19:18:59  <sipa> when is the feature freeze for 0.13?
3862016-03-31T19:18:59  <wumpus> #topic softfork backports
3872016-03-31T19:19:00  <jonasschnelli> I have already started reviewing it but need to read myself more into libevent first.
3882016-03-31T19:19:14  <petertodd> cfields: well, keep in mind that what's keeping everyone busy is stuff that'll be backported
3892016-03-31T19:19:18  <jtimon> NicolasDorier:
3902016-03-31T19:19:20  <btcdrak> backports are #7543 and #7716
3912016-03-31T19:19:24  <cfields> jonasschnelli: for the sake of review, I'd say you can do it in 2 main chunks
3922016-03-31T19:19:41  <cfields> first, libbtcnet can be considered to be a black box that works as intended
3932016-03-31T19:19:53  <jtimon> what? it was a suggestion for extension, I think you got simplifications I missed'
3942016-03-31T19:19:57  <cfields> then, reviewing libbtcnet itself
3952016-03-31T19:20:04  <wumpus> sipa: 2016-05-15 https://github.com/bitcoin/bitcoin/issues/7679
3962016-03-31T19:20:11  <btcdrak> so #7543 is a straight up cherry-pick from master, easy peasy.
3972016-03-31T19:20:30  <btcdrak> #7716 needs a bit more review, but the tests, as per the comments make it quite easy to verify.
3982016-03-31T19:20:40  <sipa> i gave a command line for easy mechanical review of 7543 :)
3992016-03-31T19:20:51  <morcos> "easy"
4002016-03-31T19:21:13  <btcdrak> #7543 has 5 tested ACKs so far. It should be ready for merge.
4012016-03-31T19:21:38  <jtimon> NicolasDorier: seriously if someone else could do it I think we could be much more objective combined (I'm probably too biased with my consensus branch)
4022016-03-31T19:22:04  <phantomcircuit> cfields: link to current net refactor work?
4032016-03-31T19:22:37  <wumpus> agree on the 0.12 backport btcdrak
4042016-03-31T19:22:47  <cfields> phantomcircuit: https://github.com/theuni/bitcoin/tree/net-refactor10
4052016-03-31T19:22:52  <wumpus> #action #7543 has 5 tested ACKs so far. It should be ready for merge
4062016-03-31T19:23:28  <btcdrak> wumpus: I'll go round bugging more people for review of #7716 this week.
4072016-03-31T19:24:15  <morcos> I know this may be controversial, but I'd argue that it is worse to provide backports for 0.11 than not
4082016-03-31T19:24:19  <wumpus> #link  https://github.com/theuni/bitcoin/tree/net-refactor10
4092016-03-31T19:24:40  <cfields> btcdrak: you bugged me last week but i didn't get to them. Will review both right after the meeting.
4102016-03-31T19:25:06  <wumpus> what would be the effect of not backporting to 0.11?
4112016-03-31T19:25:11  <morcos> It's very difficult to provide sufficient enough review.  You could have backported those soft forks to 0.11 in a way that passed both the existing unit tests and was broken if you didn't know you needed to change both
4122016-03-31T19:25:39  <morcos> I think we are doing our "customers" a better service by not putting our stamp of approval on something we can't give as high a degree of safety to
4132016-03-31T19:25:57  <morcos> Just a though, given that segwit will also likely be difficult to get properly tested in 0.11
4142016-03-31T19:26:25  <gmaxwell> I've had this thought too. Unfortunately none of the users of these things will give us any feedback.
4152016-03-31T19:26:26  <petertodd> morcos: ack - and also, esp. from miners, do we have a clear request to do a backport?
4162016-03-31T19:26:33  <wumpus> do miners use 0.11?
4172016-03-31T19:26:58  <wumpus> if not, backporting softfork to 0.11 is not *that* important
4182016-03-31T19:27:06  <phantomcircuit> wumpus: miners use git master...
4192016-03-31T19:27:09  <morcos> This is an opensource project anyway, nothing stopping other people from backporting to 0.11 themselves
4202016-03-31T19:27:21  <wumpus> sure, but we have a PR open for 0.11
4212016-03-31T19:27:23  <morcos> We should concentrate our efforts where they will be most effective
4222016-03-31T19:27:24  <sdaftuar> hah - low probability of getting that right
4232016-03-31T19:27:29  <wumpus> people that want it can review it
4242016-03-31T19:27:31  <sdaftuar> but agree that it's difficult to review
4252016-03-31T19:27:46  *** Guyver2 has joined #bitcoin-core-dev
4262016-03-31T19:27:55  <wumpus> if no one wants it, no one should review it
4272016-03-31T19:28:04  <wumpus> so the decision would be more 'backport to 0.11 should block 0.12 deployment'
4282016-03-31T19:28:14  <btcdrak> wumpus: I know of some miners who are still on 0.11.2 but plan to upgrade, but instead are waiting for 0.12.1 now.
4292016-03-31T19:28:18  <petertodd> how about we mention that we haven't done a backport in the release notes for 0.12.x, and make it clear that if people do what that they should let us know?
4302016-03-31T19:28:21  <morcos> wumpus: But what I'm saying is we seem to have set a requirement for ourselves that we will backport 2 major versions, and so we waste a lot of development resources doing that for a questionable quality product
4312016-03-31T19:28:29  <Luke-Jr> wumpus: yes, miners still use 0.11
4322016-03-31T19:28:38  <wumpus> morcos: well the plan was to release 0.11.3 and 0.12.1 at the same time
4332016-03-31T19:28:48  <Luke-Jr> wumpus: and that is likely to remain the case for some time
4342016-03-31T19:28:52  <wumpus> that means that 0.11.3 will block 0.12.1
4352016-03-31T19:29:10  <morcos> Yes thats what i'm objecting to!
4362016-03-31T19:29:22  <btcdrak> I disagree with morcos that 0.11 is so difficult. We do have a pretty decent set of functional tests, and the 0.11 backport passes those.
4372016-03-31T19:29:30  <jonasschnelli> cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.11." | wc -l    ---> 1581
4382016-03-31T19:29:34  <jonasschnelli> cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.12." | wc -l --> 1276
4392016-03-31T19:29:47  <jonasschnelli> I think a BP for 0.11 would be good.
4402016-03-31T19:30:14  <wumpus> mind that 0.12 isn't very old yet, and it's still at .0, lots of people wait for .1 releases to deploy it
4412016-03-31T19:30:22  <morcos> btcdrak: i think the 0.11 backport is correct.  but it would have been easy to get wrong and still could be
4422016-03-31T19:30:24  <btcdrak> morcos: so far 3 people have tested #7716.
4432016-03-31T19:30:32  <Luke-Jr> wumpus: it also has no well-tested CPFP yet ;)
4442016-03-31T19:30:34  <morcos> yes and 2 of them think it was a waste of time
4452016-03-31T19:31:01  <wumpus> so can we get people that use 0.11.x involved in testing it?
4462016-03-31T19:31:01  <btcdrak> For the record, I am fine not to backport to 0.11
4472016-03-31T19:31:12  <morcos> anyway, this is potentially off topic, but i think its more important that this project spend its resources getting segwit deployed
4482016-03-31T19:31:16  <wumpus> this is an open source project, so at some point it's scratch your own itch
4492016-03-31T19:31:18  <morcos> than deploying CSV to 0.11
4502016-03-31T19:31:22  <jonasschnelli> morcos : +1
4512016-03-31T19:31:29  <morcos> wumpus: sure, so lets not delay 0.12.1
4522016-03-31T19:31:30  <paveljanik> +1
4532016-03-31T19:31:31  <jl2012> Anyway, I think it's unlikely to backport segwit to 0.11, so I don't think we really need to backport CSV to 0.11
4542016-03-31T19:31:38  <btcdrak> +1
4552016-03-31T19:31:39  <morcos> jl2012: thanks
4562016-03-31T19:31:41  <wumpus> but what if bbackporting to 0.11.x helps segwit deployment, by making sure miners use it?
4572016-03-31T19:31:46  <gmaxwell> 0.11 is also so low in performance relative to 0.12 that there are many reasons not to run it.
4582016-03-31T19:31:50  <wumpus> ok
4592016-03-31T19:31:52  <btcdrak> please can we merge 7543 and start the RC phase.
4602016-03-31T19:31:58  <jonasschnelli> Agree with wumpus: 0.12 is relatively new. The time will also works towers 0.12 adaptation.
4612016-03-31T19:32:04  <jonasschnelli> towards
4622016-03-31T19:32:06  <morcos> btcdrak: well that brings us to next topic, bad-chain alerts
4632016-03-31T19:32:07  <Luke-Jr> it may be easier to get morcos's new CPFP stuff tested well
4642016-03-31T19:32:10  <gmaxwell> it is premature to RC on 0.12 at this second. (maybe in a couple days)
4652016-03-31T19:32:19  <wumpus> it'd be better if we would have first done a bugfix release for 0.12
4662016-03-31T19:32:20  <morcos> Luke-Jr: heh, thanks but sdaftuar's
4672016-03-31T19:32:24  <Luke-Jr> oh, oops
4682016-03-31T19:32:37  <btcdrak> morcos: this is my answer to back chain alerts for 0.12.1 https://github.com/bitcoin/bitcoin/compare/0.12...btcdrak:spurious
4692016-03-31T19:32:48  *** achow101 has joined #bitcoin-core-dev
4702016-03-31T19:32:48  <wumpus> then again I know of no *serious* bugs in 0.12
4712016-03-31T19:32:51  <btcdrak> disable them for 0.12.1 and if we get them fixed, we can add back to 0.12.2
4722016-03-31T19:33:05  <wumpus> new topic bad chain alerts?
4732016-03-31T19:33:06  <morcos> btcdrak: i think i mostly agree with that
4742016-03-31T19:33:11  <wumpus> #topic bad chain alerts
4752016-03-31T19:33:59  <gmaxwell> is that bad "chain alerts" or "bad chain" alerts? :)
4762016-03-31T19:34:14  <jonasschnelli> second.
4772016-03-31T19:34:23  <wumpus> hehe both
4782016-03-31T19:34:27  <sipa> (bad ((bad chain) alerts))
4792016-03-31T19:34:29  <gmaxwell> I think it's actually more the first.
4802016-03-31T19:34:36  <btcdrak> sipa: groan
4812016-03-31T19:34:43  <morcos> wumpus: i think the proper thing to do here is properly research what was causing the false positives.
4822016-03-31T19:34:53  <wumpus> so, disable for now, then try to fix in master, if that succeeds backport to 0.12.2?
4832016-03-31T19:35:01  <morcos> that would be my vote
4842016-03-31T19:35:01  <btcdrak> wumpus: +1
4852016-03-31T19:35:04  <gmaxwell> +1
4862016-03-31T19:35:06  <sdaftuar> ack
4872016-03-31T19:35:20  <gmaxwell> We urgently must stop the false positives or the facility becomes completely useless.
4882016-03-31T19:35:29  <wumpus> morcos: I agree, hurriedly backporting an improvement that isn't even merged in master yet is probably a bad idea
4892016-03-31T19:35:32  <morcos> wasn't MeniRosenfelds calculation that the existing code should be generating an alert once every 3 years, well i think something is off
4902016-03-31T19:35:40  <wumpus> gmaxwell: right
4912016-03-31T19:35:44  <gmaxwell> I think the work that Tom has done improving it is valuable and welcome, but clearly not enough yet.
4922016-03-31T19:36:05  <morcos> gmaxwell: or it might be enough, but we're not sure yet
4932016-03-31T19:36:07  <wumpus> gmaxwell: it makes sense to merge that for master
4942016-03-31T19:36:12  <sipa> morcos: under assumptions of constant hash rate,nodes that are up 100% of the time, and correct block timestamps
4952016-03-31T19:36:33  <petertodd> I recently spoke to a very confused user who thought the alerts meant bitcoin was fending off attack :/
4962016-03-31T19:36:33  <sipa> morcos: if any of those assumptions are wrong, it will fail more
4972016-03-31T19:36:46  <wumpus> ah a bad-weather check that only works under good-weather conditions :)
4982016-03-31T19:36:49  <morcos> sipa: yes so we don't have a sense of what false positive rate we'll have with 7568 b/c those assumptions are still equally poorly met
4992016-03-31T19:37:03  <dgenr8> sipa: why do you think it will fail more?
5002016-03-31T19:37:16  <wumpus> petertodd: yes, it confuses users
5012016-03-31T19:37:21  <gmaxwell> dgenr8: fail more than meni's calculation.
5022016-03-31T19:37:25  <wumpus> petertodd: especially because the alert just won't go away
5032016-03-31T19:37:33  <morcos> dgenr8: i think its very likely that 7568 will fail less often than master, but maybe not rarely enough compared to just disabling
5042016-03-31T19:37:50  <morcos> and it obscures other alerts
5052016-03-31T19:37:51  <dgenr8> morcos: hard to argue with that ;)
5062016-03-31T19:38:01  <morcos> "maybe" :)
5072016-03-31T19:38:12  <gmaxwell> it will still falsely alert after a temporary disconnection, that alone shows its insufficent to avoid many of the reported FPs.
5082016-03-31T19:38:13  <dgenr8> bad weather check that never detects bad weather
5092016-03-31T19:38:15  <petertodd> wumpus: when we fix them, probably worthwhile to hide the alerts in the gui for the first release
5102016-03-31T19:38:39  <wumpus> #action disable bad-chain alert for 0.12.1
5112016-03-31T19:38:57  <sipa> dgenr8: anyway, i want to be clear here: i really think you changes should go in, but perhaps only once we're sure no further imorovements are needed to make them reliable
5122016-03-31T19:38:59  <wumpus> who's going to make a PR?
5132016-03-31T19:39:19  <morcos> yes i agree with sipa
5142016-03-31T19:39:27  <dgenr8> sipa: re your comment.  coordinated check times would not actually solve anything.  they would just ensure everyone agreed on the sample error.
5152016-03-31T19:39:32  <petertodd> wumpus: I'll do it
5162016-03-31T19:39:32  <gmaxwell> dgenr8: I think the mental model you should use is that any important looking warning that turns out to be false and not require use action seen by a user has a 90% chance of making that use forever ignore any similar looking warning. So it's critical that FPs be basically 0.
5172016-03-31T19:39:33  <morcos> this is just about backporting to 0.12
5182016-03-31T19:39:37  <wumpus> dgenr8: your changes should go into master. If it turns out to be enough, they'll make 0.13, it's too late for 0.12.1
5192016-03-31T19:40:02  <wumpus> right.
5202016-03-31T19:40:05  <dgenr8> wumpus: that's great
5212016-03-31T19:40:14  <petertodd> wumpus: what branch would be best to do it against?
5222016-03-31T19:40:20  <wumpus> petertodd: 0.12
5232016-03-31T19:40:30  <wumpus> only 0.12
5242016-03-31T19:40:33  <petertodd> wumpus: ack
5252016-03-31T19:40:42  <btcdrak> oh
5262016-03-31T19:40:47  <GitHub123> [bitcoin] btcdrak opened pull request #7780: [0.12] Disable bad-chain alert (0.12...spurious) https://github.com/bitcoin/bitcoin/pull/7780
5272016-03-31T19:40:47  <gmaxwell> dgenr8: I don't agree with your view on coordinated check times.  When we want there to be no FP _anywhere_ except very rarely, the lack of sync means that this will happen much more often.  It's the multiple comparisons problem.
5282016-03-31T19:40:49  <btcdrak> I just submitted
5292016-03-31T19:40:59  <jonasschnelli> ^^ :-)
5302016-03-31T19:41:01  <sipa> i think disabling should go in master
5312016-03-31T19:41:09  <gmaxwell> dgenr8: FPs are also less harmful when everyone gets one, since at least then "I got a warning and no one else did" is a good warning sign.
5322016-03-31T19:41:28  <dgenr8> gmaxwell: ah I forgot the "exclude false positives" code
5332016-03-31T19:41:30  <sipa> so that if no appropriate imorovement is found for 0.13, we don't need a separate "fix" there
5342016-03-31T19:41:36  <btcdrak> sipa: we're likely to fix it before then surely?
5352016-03-31T19:41:40  <wumpus> sipa: I don't agree, we should aim for improvement in master
5362016-03-31T19:41:44  <morcos> wumpus: I agree with sipa, otherwise we forget and have the broken one back for 0.13
5372016-03-31T19:41:49  <morcos> wumpus: yes AIM
5382016-03-31T19:41:53  <wumpus> sipa: if it itsn't fixed by 0.13 then we can easily disable it
5392016-03-31T19:42:05  <sipa> wumpus: disabling is considered an improvement, it should in master and be backported
5402016-03-31T19:42:09  <btcdrak> morcos: we wont forget. If it's not ready by 0.13 we can just disbale it
5412016-03-31T19:42:10  <wumpus> sigh
5422016-03-31T19:42:13  <sipa> but i don't care strongly
5432016-03-31T19:42:15  <sipa> :)
5442016-03-31T19:42:17  <morcos> we always forget!
5452016-03-31T19:42:19  <wumpus> I don't care
5462016-03-31T19:42:42  <wumpus> I just thought we had a plan and it's completely different now, but just do whatever you think makes sense
5472016-03-31T19:42:43  <btcdrak> well how about we merge 7780 the cherry-pick it into master. same diff
5482016-03-31T19:42:48  <morcos> if it makes it on a task list somewhere, thats good enough
5492016-03-31T19:42:56  <morcos> but just saying it here is a mistake
5502016-03-31T19:43:11  <gmaxwell> we've already wasted too much time on this really minor feature. If this loops too much more my view is going to change to abandon it completely.
5512016-03-31T19:43:25  <wumpus> if you disable it that means there is effectgively no testing for the improved code
5522016-03-31T19:43:29  <sipa> ok, let's fix in master
5532016-03-31T19:43:34  <sipa> i retract my comment
5542016-03-31T19:43:57  <gmaxwell> wumpus: already people have stopped reporting false postives. :(
5552016-03-31T19:43:58  <wumpus> gmaxwell: sure, if no one is going to improve the code further, that's fine too, wel'll disable it, just be honest about it :)
5562016-03-31T19:44:00  <morcos> i withdraw comment due to fear of the wrath of maxwell  (kidding trolls, kidding)
5572016-03-31T19:44:32  <sipa> morcos: you should fear maxwell's demon indeed
5582016-03-31T19:44:42  <wumpus> hah
5592016-03-31T19:45:02  * petertodd shakes head
5602016-03-31T19:45:15  <petertodd> (thereby increasing entropy slightly)
5612016-03-31T19:45:20  <morcos> wumpus: you should do what you think is best, just don't let us forget if you leave it in... make an issue and milestone it or milestone dgenr8's PR
5622016-03-31T19:45:31  <morcos> next topic
5632016-03-31T19:45:35  <wumpus> morcos: right
5642016-03-31T19:46:05  <wumpus> I don't think 'we always forget', if we really want to remember something for the release there are ways to do so, but if no one feels it's worth the trouble well then it's not :)
5652016-03-31T19:46:23  <morcos> i am prone to hyperbole on the rare occasion
5662016-03-31T19:46:24  <wumpus> any other topics?
5672016-03-31T19:46:26  <sdaftuar> topic suggestion: CPFP mining
5682016-03-31T19:46:32  <wumpus> #topic CPFP mining
5692016-03-31T19:46:33  <sipa> sdaftuar: answer is yes
5702016-03-31T19:46:53  <sdaftuar> mostly i just want to bug people for review
5712016-03-31T19:47:04  <sipa> sorry, i wanted to review again now that the base tracking is merged, but haven't gotten around to it
5722016-03-31T19:47:06  <morcos> first step is for people to give concept feedback for 7598, refactor of CreateNewBlock
5732016-03-31T19:47:19  <sdaftuar> ^ yes that's what i was going to say
5742016-03-31T19:47:20  <morcos> its a kind of large change, and lets get it to a design we all like better
5752016-03-31T19:47:38  <morcos> sdaftuar and i can rebuild the CPFP on whatever the design is people like best
5762016-03-31T19:48:31  <morcos> the original goal of the design was to separate priority filling from feerate filling, but i think the overall goal should be to make it more modular to figure out how to assemble a block
5772016-03-31T19:48:33  <wumpus> #action disable bad-alert detection in master if it doesn't improve enough by 0.13 (and don't forget!)
5782016-03-31T19:49:09  <sipa> morcos: ok
5792016-03-31T19:50:22  <morcos> hmm
5802016-03-31T19:51:20  <jonasschnelli> 5mins for p2p enc/auth?
5812016-03-31T19:51:22  <morcos> i'm just trying to think about itming of all these things
5822016-03-31T19:51:28  <morcos> 5/15 isn't that far away
5832016-03-31T19:51:41  <morcos> and some changes on top of segwit will be necessary
5842016-03-31T19:51:53  <morcos> do we punt on these other things for now and try to get segwit merged
5852016-03-31T19:51:57  <morcos> or continue in parallel or what
5862016-03-31T19:52:25  <morcos> i'm not sure i know the answer...
5872016-03-31T19:52:28  <wumpus> jonasschnelli: sure
5882016-03-31T19:52:36  <jonasschnelli> I just wanted to get a feeling if it's worth to continue work on the p2p encryption and authentication BIP.
5892016-03-31T19:52:36  <jonasschnelli> IMO there are clear benefits. Question is more if we need our own solution (including all the risks) of if we should adapt stuff like stunnel, DJB's curveCP, etc. are already available.
5902016-03-31T19:52:36  <jonasschnelli> Continuing makes probably only sense if most of us prefere a own/custom solution.
5912016-03-31T19:52:53  <wumpus> #topic p2p encryption/authentication
5922016-03-31T19:53:16  <petertodd> jonasschnelli: fwiw, note that .onion addresses do work pretty well for p2p encryption and authentication
5932016-03-31T19:53:19  <sipa> jonasschnelli: you can literally copy the crypto code from openssh; it's 300 lines for chacha20-poly1305
5942016-03-31T19:53:25  <wumpus> I'm all for adapting something that already exists as long as it's not openssl
5952016-03-31T19:53:31  *** MarcoFa has joined #bitcoin-core-dev
5962016-03-31T19:53:32  <sipa> and ecdh and signing we already have
5972016-03-31T19:54:29  <jonasschnelli> I think it would allow extremely simple setups for wallet nodes (spv) to increase privacy.
5982016-03-31T19:54:33  <petertodd> sipa: copying ssh sounds pretty reasonable to me
5992016-03-31T19:54:34  <Luke-Jr> jonasschnelli: ready for BIP #s yet?
6002016-03-31T19:54:36  <btcdrak> jonasschnelli: continuing to work on those BIPs is a clear win
6012016-03-31T19:54:55  <jonasschnelli> tor is an alternative, but not preferred by everyone and probably consequences on performance.
6022016-03-31T19:55:06  <sipa> jonasschnelli: i don't think we should rush this (implementation should not start until cfields's refaactor is in, i think)
6032016-03-31T19:55:09  <jonasschnelli> Luke-Jr: BIP is _not_ ready yet.
6042016-03-31T19:55:18  <sipa> but thinking about it can continur
6052016-03-31T19:55:26  * wumpus also likes chacha20-poly1305
6062016-03-31T19:55:30  <jonasschnelli> Right. No rush. Can take 1-2 years. I just want to keep it moving.
6072016-03-31T19:55:51  <sipa> chacha20-poly1305 is faster than sha256 ;)
6082016-03-31T19:56:08  <warren> Are folks thinking this would be optional, not default?
6092016-03-31T19:56:11  <cfields> sipa / jonasschnelli: note that you can easily test with libbtcnet, so it'll be familiar after the net refactor
6102016-03-31T19:56:11  <petertodd> jonasschnelli: fwiw, this will improve privacy for non-spv as well if widely deployed; one of the interesting things that the network monitoring services like chainalysis are doing is MITMing nodes by simply faking the address info for both sides of the connection
6112016-03-31T19:56:16  <jonasschnelli> Okay. Will continue finish the BIP and seek out for funding for cryptanalysis, etc.
6122016-03-31T19:56:36  <petertodd> jonasschnelli: obviously encryption isn't a total solution, but the authentication is a good first step to anti-sybil techniques
6132016-03-31T19:56:36  <cfields> sipa / jonasschnelli: i added support for chunked reads as suggested, in case i forgot to mention
6142016-03-31T19:56:54  <wumpus> and indeed, .onion does fairly well as a p2p encryption and authentication for now, but that doesn't mean it's not worth looking for something that can be integrated
6152016-03-31T19:57:02  <gmaxwell> jonasschnelli: please don't ask for external cryptanalysis until it passes pieter's review. Otherwise it just risks embarassing our team and wasting money. :)
6162016-03-31T19:57:07  <sipa> related topic: shameless plug for https://github.com/sipa/ctaes (since it was a topic last week)
6172016-03-31T19:57:13  <petertodd> sipa: thanks!
6182016-03-31T19:57:21  <jonasschnelli> gmaxwell: Agree!
6192016-03-31T19:57:26  <cfields> jonasschnelli: i suspect there would be some MIT folks interested in analyzing/researching. I could ask around if you'd like.
6202016-03-31T19:57:31  <wumpus> #link https://github.com/sipa/ctaes
6212016-03-31T19:57:41  <jonasschnelli> cfields: good idea.
6222016-03-31T19:57:50  <gmaxwell> please not yet.
6232016-03-31T19:57:52  <cfields> heh, offer retracted after gmaxwell's plea :)
6242016-03-31T19:58:14  <jonasschnelli> Yes. Not now. First we need an implementation and clear review from maxwell and sipa.
6252016-03-31T19:58:26  <gmaxwell> I'm happy to help refining it, though.
6262016-03-31T19:58:33  <jonasschnelli> (after the BIP is "stable").
6272016-03-31T19:58:47  <jonasschnelli> gmaxwell: yes. Will bother you soon with tons of q.
6282016-03-31T19:58:53  <gmaxwell> jonasschnelli: Thank you!
6292016-03-31T19:59:43  <jonasschnelli> </p2pencauth>
6302016-03-31T19:59:47  * sipa afk
6312016-03-31T19:59:56  <wumpus> #endmeeting
6322016-03-31T19:59:56  <lightningbot> Meeting ended Thu Mar 31 19:59:56 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6332016-03-31T19:59:56  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.html
6342016-03-31T19:59:56  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.txt
6352016-03-31T19:59:56  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-31-18.59.log.html
6362016-03-31T20:00:06  <morcos> wait sorry if i zoned out
6372016-03-31T20:00:15  <morcos> did we agree not to hold up 0.12.1 for 0.11.3 ?
6382016-03-31T20:00:24  <jonasschnelli> I think so.
6392016-03-31T20:00:48  <wumpus> I don't think we agreed in anything in that regard, then again meetings are not for making decisions :)
6402016-03-31T20:00:51  <jonasschnelli> But it was not a clear obvious decision I guess.
6412016-03-31T20:01:07  <jonasschnelli> ok.
6422016-03-31T20:01:08  <instagibbs> in Core unit tests how do I pass in a chainparam string argument? Can't find examples and looking up Boost docs is failing me.
6432016-03-31T20:01:52  <jtimon> wait, how can this be endmeeting? wasn't the meeting starting at 8 pm? I was supposed to have missed the meeting 2 hours ago. Bad job communicating the hour changes ;)
6442016-03-31T20:02:16  <wumpus> jtimon: meeting is +0 UTC, or Reykjavik time
6452016-03-31T20:02:17  <morcos> wumpus: well, given that we are so close with 0.11.3, i think we should continue for CSV, but no reason to hold up 0.12.1, thats what i think
6462016-03-31T20:02:46  <morcos> the timeframe is set by the startdate in BIP9 anyway, so no reason not to let 0.12.1 penetrate for a little bit longer if we can
6472016-03-31T20:02:52  <wumpus> according to my calendar it just ended
6482016-03-31T20:03:11  <morcos> jtimon: you are funny, you were chatting offtopic during hte meeting, yet you didn't notice it was happening? :)
6492016-03-31T20:03:23  <wumpus> morcos: I personally tend to agree though, dependencies between releaases just inhibit flexibilty
6502016-03-31T20:04:01  <wumpus> then again even if we merged the softfork backport right now 0.12.1 wouldn't be ready yet, I think there's still an timeout issue to deal with
6512016-03-31T20:04:19  <morcos> wumpus: yes, but lets let worry about its own blockers only.
6522016-03-31T20:04:29  <morcos> wait
6532016-03-31T20:04:45  <jtimon> wumpus: oh, right, no more hour changes anymore that's better. If we were open to bike-shedding I would propose GMT forever everywhere without "time savings" and that would be it
6542016-03-31T20:05:17  <wumpus> jtimon: that's what it is already
6552016-03-31T20:05:29  <paveljanik> jtimon, then am and pm can change its meaning ;-)
6562016-03-31T20:05:44  <wumpus> jtimon: it's planned in UTC+0 which has no time savings
6572016-03-31T20:05:55  *** fengling has joined #bitcoin-core-dev
6582016-03-31T20:06:01  <jtimon> morcos: yeah, sorry about that, I was answering on IRC not to disrupt gihub :(
6592016-03-31T20:06:30  *** cryptapus has quit IRC
6602016-03-31T20:06:47  <wumpus> meeting is always: 19:00 to 20:00 (GMT+00:00) Reykjavik
6612016-03-31T20:06:48  <jtimon> wumpus: yeah, it's perfect, sorry, I was just kidding about more radical "clock regimes" and I would ACK
6622016-03-31T20:06:55  <wumpus> jtimon: ohh okay
6632016-03-31T20:06:59  <wumpus> jtimon: sorry :)
6642016-03-31T20:07:08  <jtimon> no worries, my fault
6652016-03-31T20:07:18  <btcdrak> morcos: yes we agreed not to hold up 0.12.1
6662016-03-31T20:07:30  <wumpus> yes I'd prefer to get rid of DST in my country as well, it's an artifact of the past
6672016-03-31T20:07:35  <petertodd> jtimon: heh, I keep meaning to switch my computers to display time in UTC because a) I travel constantly anyway, so they're wrong half the time, and b) privacy!
6682016-03-31T20:07:56  <petertodd> jtimon: (also c) my brother is a pilot and does that already - sibling rivalry!)
6692016-03-31T20:08:02  <jtimon> petertodd: mhmm, never thought about privacy...
6702016-03-31T20:08:17  <petertodd> jtimon: _lots_ of stuff leaks where you are by leaking your local TZ
6712016-03-31T20:08:41  <wumpus> yes, it does, e.g. git
6722016-03-31T20:08:59  <petertodd> jtimon: e.g you can pretty easily figure out the last time I was in Newfoundland based on a well timed git commit (er, well, I was in Newfoundland's airspace...)
6732016-03-31T20:09:57  *** JeromeLegoupil has quit IRC
6742016-03-31T20:10:14  <wumpus> I don't really understand that, why protocols don't just use UTC timestamps or dates
6752016-03-31T20:10:16  *** fengling has quit IRC
6762016-03-31T20:10:16  <jtimon> trust me: as non-native english speaker tryting to full my OS installer that I am, I always have problems
6772016-03-31T20:10:32  <petertodd> wumpus: nsa conspiracy obvs :)
6782016-03-31T20:10:39  <wumpus> hehe
6792016-03-31T20:10:40  <instagibbs> for boost unit tests how does one pass an argument to the fixture, in order to test other chainparams? anyone?
6802016-03-31T20:11:11  <petertodd> wumpus: along those lines, I'm surprised even privacy oriented stuff doesn't let you fuzz timestamps - day-level resolution is pretty revealing, let alone down to the second
6812016-03-31T20:11:12  <jtimon> well, notalways, debian seems to listen, ubuntu doesn't
6822016-03-31T20:11:41  <jtimon> wumpus: UTC is still flawed
6832016-03-31T20:12:53  <sipa> instagibbs: you don't; individual tests specify what chain they run it
6842016-03-31T20:13:10  <instagibbs> sipa, the default string parameter is MAIN
6852016-03-31T20:13:14  <wumpus> petertodd: sure, a different issue, but timestamps in itself are always a fingerprinting angle, I was kind of shocked to read there are even some in TCP
6862016-03-31T20:13:24  <instagibbs> maybe I'm not looking at the right examples, but I don't see it being changed?
6872016-03-31T20:14:17  <wumpus> instagibbs: it's a matter of passing the right chainparams to the appropriate functions, let me see
6882016-03-31T20:14:31  <jtimon> let me expain, if you throw 2 UTC clocks in perpendicular directions, you may be deceived into thinking that either the earth is not moving or you have to grow a withe mustache to undesrstand the universe: it's neither of them, you just have to use median time, see BIP113
6892016-03-31T20:14:53  <sipa> instagibbs: i guess almost all unit tests run in main (maybe actually all)
6902016-03-31T20:14:58  <instagibbs> i need to learn the right incantation
6912016-03-31T20:15:15  <sipa> instagibbs: there is no incantation, it's not supposed to be configurable
6922016-03-31T20:15:34  <instagibbs> well... it's odd it has a parameter then
6932016-03-31T20:15:35  <wumpus> we're trying to erfactor away from having a global chainparams, so as many functions as possible just need it passed in
6942016-03-31T20:15:55  <instagibbs> I see
6952016-03-31T20:15:55  <sipa> instagibbs: wait, you mean in the code or on the command line?
6962016-03-31T20:16:07  <wumpus> but the right incantation is: SelectParams(CBaseChainParams::TESTNET);
6972016-03-31T20:16:19  <wumpus> see eg base58_tests.cpp
6982016-03-31T20:17:15  <instagibbs> ok that makes sense, the constructor calls it for chainName, which is always MAIN, so calling it myself may work
6992016-03-31T20:17:51  <wumpus> but in general that's not necessary, and you can just do const CChainParams& chainparams = Params(CBaseChainParams::TESTNET); then use that and pass it to the appropriate functions
7002016-03-31T20:18:12  <wumpus> unless you are testing something that uses the globally configured params
7012016-03-31T20:18:14  <instagibbs> wumpus, it's yelling at me about coinbase stuff
7022016-03-31T20:18:36  <instagibbs> anyhoo, one sec
7032016-03-31T20:21:20  <jtimon> so, given that there's people congregated I feel tempted to ask about my latest too crazy ideas
7042016-03-31T20:21:42  <petertodd> jtimon: heh
7052016-03-31T20:22:29  <jtimon> 1) do we need more feerate precision? ok, but not now, right? if so, we have much to disrupt and I'm looking for voluntaries, promise reivew
7062016-03-31T20:22:47  <jtimon> 2) are we coing to unify consensus flags or what?
7072016-03-31T20:23:16  <Luke-Jr> I don't know that it makes sense to release 0.12.1 without 0.11 being ready
7082016-03-31T20:23:37  <Luke-Jr> since 0.12 is not ready for mining
7092016-03-31T20:24:33  <jtimon> 1) #7731 2) #7779 please feel free to comment on the PRs and/or take/modify/resethead any commits as it may fit
7102016-03-31T20:24:43  <instagibbs> wumpus, SelectParams did the trick +1
7112016-03-31T20:25:02  <jtimon> do we still have selectparams? facepalm
7122016-03-31T20:25:29  <instagibbs> unit tests use it <_<
7132016-03-31T20:25:50  <sipa> Luke-Jr: increasing precision: i don't think we need it (it's less needed the larger fees are)
7142016-03-31T20:25:54  <sipa> eh, jtimon
7152016-03-31T20:26:03  <sipa> Luke-Jr: why is 0.12 not ready for mining?
7162016-03-31T20:26:08  <Luke-Jr> sipa: no CPFP
7172016-03-31T20:26:14  <sipa> Luke-Jr: neither did 0.11
7182016-03-31T20:26:17  <Luke-Jr> yes it does
7192016-03-31T20:26:25  <Luke-Jr> just not in Core
7202016-03-31T20:26:43  <jtimon> yeah, we don't have a factory for tests yet, #6907 sigh
7212016-03-31T20:26:57  <gmaxwell> Luke-Jr: analysis run by sdaftuar showed that it appeared no one was CFPF mining a couple months ago.
7222016-03-31T20:27:15  <Luke-Jr> gmaxwell: that can't be right, considering people are *using* CPFP on a regular basis
7232016-03-31T20:27:32  <Luke-Jr> and I know for certain a number of miners are
7242016-03-31T20:27:46  <gmaxwell> but do they solve more than a block per week?
7252016-03-31T20:28:21  <Luke-Jr> yes
7262016-03-31T20:28:35  <jtimon> btw, Luke-Jr morcos and I want more policy encapsulation and we're not doing it for lack of communication
7272016-03-31T20:29:23  <petertodd> the most convincing move towards policy encapsulation would be to get an alternate way of getting txs to miners - txs over bitmessage comes to mind
7282016-03-31T20:29:53  <Luke-Jr> …
7292016-03-31T20:29:55  <jtimon> oh CFPF...<lurker mode>
7302016-03-31T20:30:19  <jtimon> CPFP
7312016-03-31T20:30:26  <morcos> jtimon: i think it makes more sense for you to take over policy encapsulation PR's and i can help review
7322016-03-31T20:33:57  *** MarcoFa has quit IRC
7332016-03-31T20:36:57  <jtimon> morcos: I have things I could easily rebase to set up an easy base to continue (based on a base from look, but I hipe luke can agree we have more since my first policy PR which started just as nit to his) but in my best policy encapsulation dreams, at some point const CPolicy& was just a parameter to AcceptToMemorypoolWorker. And now it has many more parameters I don't know about
7342016-03-31T20:37:26  <jtimon> so I'm kind of worried of committing to a work I won't finish
7352016-03-31T20:37:53  <morcos> jtimon: ok. no problem.  i think i will close my two open PR's though for now..
7362016-03-31T20:38:11  <morcos> i feel a lot of other stuff happening, unless you tihnk either of them is worth pursuing
7372016-03-31T20:38:23  <jtimon> I mean, I believe little steps cannot be bad, but if you're reviwieing maybe with the thought of having to continue the work, that would be very helpful indeed
7382016-03-31T20:39:32  <jtimon> I mean, probably not just you, once it's started many people can help, but having someone committed to "finish it" (if we find a common definition of "finish") it's great
7392016-03-31T20:39:53  <jtimon> nah, I don't think this is urgent
7402016-03-31T20:40:35  *** JeromeLegoupil has joined #bitcoin-core-dev
7412016-03-31T20:42:20  *** laurentmt has joined #bitcoin-core-dev
7422016-03-31T20:42:59  <jtimon> I will resurrect 6068 and friends just to take feerate out of primitives/transaction (which is the only thing that really makes me sigh) and hopefully create an abstract CPolicy policy parameter and a CDefaultPolicy to put new options in
7432016-03-31T20:43:43  <jtimon> morcos: did I got this right? you mostly care about encapsulating the minRealyFee global first
7442016-03-31T20:44:46  <morcos> jtimon: i think at the time i wrote that what i cared about was yes, being able to access that global from other codes rather than passing it in on construction which is broken b/c it hasn't been set by command line argument yet
7452016-03-31T20:45:08  <morcos> s/other codes/other classes/files/
7462016-03-31T20:48:25  <jtimon> ok, I now wonder how many of them we need though
7472016-03-31T20:48:58  <jtimon> once I wrote a version in which you had a dynamic one based on your feeestimator and a static one for dust
7482016-03-31T20:49:25  <jtimon> policy/policy depends on the dust one
7492016-03-31T20:50:24  <jtimon> which is the one I'm most interested in touching now for moving it out of primitives/transaction and amount.o, but maybe we need to
7502016-03-31T20:50:27  <jtimon> 2
7512016-03-31T20:51:07  <jtimon> morcos: does that make sense to you? You know that code better than me
7522016-03-31T20:54:50  <jtimon> anyway, I should show you some code before asking
7532016-03-31T20:56:04  *** justanot1eruser has quit IRC
7542016-03-31T20:59:25  *** BCBot_ has quit IRC
7552016-03-31T20:59:25  *** BCBot has quit IRC
7562016-03-31T21:00:29  <morcos> jtimon: we need the existing one and we need the minIncrementalRate, they can be the same thing for now.   i
7572016-03-31T21:01:10  *** BCBot has joined #bitcoin-core-dev
7582016-03-31T21:01:16  *** cryptapus_afk is now known as cryptapus
7592016-03-31T21:08:51  *** laurentmt has quit IRC
7602016-03-31T21:12:35  <jtimon> morcos: ok that's the kind of thing I don't have criterion to decide and someone else has to do (but whoever does it should be interested in my stuff to suppoosedly make that easy [and I'm very interested on comments of the sort "I don't think this will make my life easier", which is why I thought of you for review on my "preparations" {MarcoFalke is never here and NicolasDorier I would like to look too, I mean the more people
7612016-03-31T21:12:35  <jtimon> look the better, but you guys first please if you are available whenever}]);
7622016-03-31T21:13:09  <morcos> so is there a specific PR you want me to review now
7632016-03-31T21:18:17  <jtimon> I'll open a PR and ping you for review, knowing that feerate is your prioriy is great, the functions in policy/policy were just examples for the interface containing globals that would become encapsulated in globalPolicy (in main, althout I would prefer globals/server, never got to the poinst to explain that without great disruption), but GetDefaultFee() is as good as an example as any other. If you're goint to use it directly,
7642016-03-31T21:18:17  <jtimon> all the better.
7652016-03-31T21:21:26  <jtimon> too many words and too little code, when I open the PR, you're gonna ask why I need to mention satoshi so many times for such a simple no-change commit but as said I should talk to the compiler first, thanks for bringing this up again
7662016-03-31T21:34:59  *** xabbix has quit IRC
7672016-03-31T21:36:30  *** xabbix has joined #bitcoin-core-dev
7682016-03-31T21:36:31  *** xabbix has joined #bitcoin-core-dev
7692016-03-31T21:39:16  *** droark has joined #bitcoin-core-dev
7702016-03-31T21:47:40  *** JeromeLegoupil has quit IRC
7712016-03-31T21:52:27  *** brg444 has joined #bitcoin-core-dev
7722016-03-31T21:54:23  *** brg444 has left #bitcoin-core-dev
7732016-03-31T22:06:03  *** Guyver2 has quit IRC
7742016-03-31T22:08:13  *** fengling has joined #bitcoin-core-dev
7752016-03-31T22:12:21  *** Thireus has quit IRC
7762016-03-31T22:12:40  *** Thireus has joined #bitcoin-core-dev
7772016-03-31T22:13:16  *** fengling has quit IRC
7782016-03-31T22:28:40  *** justanotheruser has joined #bitcoin-core-dev
7792016-03-31T22:32:41  *** cryptapus is now known as cryptapus_afk
7802016-03-31T22:35:15  *** droark has quit IRC
7812016-03-31T22:38:04  *** zooko has quit IRC
7822016-03-31T22:45:04  *** gevs has quit IRC
7832016-03-31T22:50:39  *** AaronvanW has quit IRC
7842016-03-31T22:55:40  *** lolwut has joined #bitcoin-core-dev
7852016-03-31T22:58:28  *** gevs has joined #bitcoin-core-dev
7862016-03-31T22:58:28  *** gevs has joined #bitcoin-core-dev
7872016-03-31T23:00:47  *** lolwut has quit IRC
7882016-03-31T23:39:32  *** PRab has quit IRC
7892016-03-31T23:59:01  *** frankenmint has quit IRC