1 2016-03-31T00:16:24  *** jtimon has quit IRC
  2 2016-03-31T00:30:46  *** fengling has joined #bitcoin-core-dev
  3 2016-03-31T00:35:16  *** fengling has quit IRC
  4 2016-03-31T01:00:09  *** p15 has joined #bitcoin-core-dev
  5 2016-03-31T01:01:02  *** Ylbam has quit IRC
  6 2016-03-31T01:09:04  *** zooko has joined #bitcoin-core-dev
  7 2016-03-31T01:16:06  *** ghtdak has joined #bitcoin-core-dev
  8 2016-03-31T01:37:03  *** fengling has joined #bitcoin-core-dev
  9 2016-03-31T02:31:09  *** Chris_Stewart_5 has quit IRC
 10 2016-03-31T02:53:48  <GitHub72> [bitcoin] maneotrix opened pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
 11 2016-03-31T02:56:36  *** Thireus1 has quit IRC
 12 2016-03-31T02:57:38  *** Thireus has joined #bitcoin-core-dev
 13 2016-03-31T03:09:48  *** achow101 has quit IRC
 14 2016-03-31T03:15:36  *** fengling has quit IRC
 15 2016-03-31T03:24:02  *** Alopex has quit IRC
 16 2016-03-31T03:25:07  *** Alopex has joined #bitcoin-core-dev
 17 2016-03-31T03:32:05  *** CodeShark_ has joined #bitcoin-core-dev
 18 2016-03-31T03:32:50  *** baldur has quit IRC
 19 2016-03-31T03:32:56  *** da2ce7_mobile has quit IRC
 20 2016-03-31T03:32:56  *** CodeShark has quit IRC
 21 2016-03-31T03:33:27  *** Bootvis has quit IRC
 22 2016-03-31T03:33:30  *** CodeShark_ is now known as CodeShark
 23 2016-03-31T03:33:30  *** supasonic has quit IRC
 24 2016-03-31T03:34:09  *** devrandom has quit IRC
 25 2016-03-31T03:34:09  *** jron has quit IRC
 26 2016-03-31T03:34:16  *** Bootvis has joined #bitcoin-core-dev
 27 2016-03-31T03:34:27  *** jron has joined #bitcoin-core-dev
 28 2016-03-31T03:34:30  *** devrandom has joined #bitcoin-core-dev
 29 2016-03-31T03:34:35  *** da2ce7_mobile has joined #bitcoin-core-dev
 30 2016-03-31T03:34:52  *** baldur has joined #bitcoin-core-dev
 31 2016-03-31T03:35:26  *** zooko has quit IRC
 32 2016-03-31T03:38:38  *** xiangfu has joined #bitcoin-core-dev
 33 2016-03-31T03:48:01  *** Alopex has quit IRC
 34 2016-03-31T03:49:06  *** Alopex has joined #bitcoin-core-dev
 35 2016-03-31T03:51:56  *** Giszmo has quit IRC
 36 2016-03-31T04:13:02  *** Alopex has quit IRC
 37 2016-03-31T04:14:07  *** Alopex has joined #bitcoin-core-dev
 38 2016-03-31T04:21:50  *** xiangfu has quit IRC
 39 2016-03-31T04:23:44  *** xiangfu has joined #bitcoin-core-dev
 40 2016-03-31T04:26:36  *** fengling has joined #bitcoin-core-dev
 41 2016-03-31T04:44:03  *** afk11 has quit IRC
 42 2016-03-31T04:46:59  *** afk11 has joined #bitcoin-core-dev
 43 2016-03-31T05:03:02  *** Alopex has quit IRC
 44 2016-03-31T05:04:07  *** Alopex has joined #bitcoin-core-dev
 45 2016-03-31T05:09:20  *** d_t has joined #bitcoin-core-dev
 46 2016-03-31T05:19:01  *** Alopex has quit IRC
 47 2016-03-31T05:20:06  *** Alopex has joined #bitcoin-core-dev
 48 2016-03-31T05:34:05  *** frankenmint has joined #bitcoin-core-dev
 49 2016-03-31T06:14:05  <GitHub136> [bitcoin] laanwj closed pull request #7775: 0.12 (master...0.12) https://github.com/bitcoin/bitcoin/pull/7775
 50 2016-03-31T06:15:02  *** Don_John has quit IRC
 51 2016-03-31T06:18:04  *** PRab has quit IRC
 52 2016-03-31T06:45:42  *** Ylbam has joined #bitcoin-core-dev
 53 2016-03-31T06:54:35  *** PRab has joined #bitcoin-core-dev
 54 2016-03-31T06:56:16  *** Thireus has quit IRC
 55 2016-03-31T07:21:38  *** abritoid has joined #bitcoin-core-dev
 56 2016-03-31T07:22:15  *** frankenmint has quit IRC
 57 2016-03-31T07:38:38  *** xiangfu has quit IRC
 58 2016-03-31T07:39:20  *** xiangfu has joined #bitcoin-core-dev
 59 2016-03-31T07:43:26  *** frankenmint has joined #bitcoin-core-dev
 60 2016-03-31T07:52:33  *** xiangfu has quit IRC
 61 2016-03-31T08:04:01  *** Alopex has quit IRC
 62 2016-03-31T08:05:06  *** Alopex has joined #bitcoin-core-dev
 63 2016-03-31T08:07:18  *** jannes has joined #bitcoin-core-dev
 64 2016-03-31T08:16:00  <wumpus> <gmaxwell> We're destroying the future utility by producing false positives now.  <- exactly
 65 2016-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
 66 2016-03-31T08:18:59  <wumpus> anyhow let's discuss at the meeting
 67 2016-03-31T08:20:08  *** Bootvis has quit IRC
 68 2016-03-31T08:24:20  *** PaulCapestany has joined #bitcoin-core-dev
 69 2016-03-31T08:27:04  *** PaulCape_ has quit IRC
 70 2016-03-31T08:39:15  *** frankenmint has quit IRC
 71 2016-03-31T08:51:07  *** PaulCape_ has joined #bitcoin-core-dev
 72 2016-03-31T08:52:40  *** AaronvanW has joined #bitcoin-core-dev
 73 2016-03-31T08:53:55  *** PaulCapestany has quit IRC
 74 2016-03-31T08:55:44  <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8a8f3d4b22b...16555b658f5b
 75 2016-03-31T08:55:45  <GitHub33> bitcoin/master fb8a8cf Wladimir J. van der Laan: rpc: Register calls where they are defined...
 76 2016-03-31T08:55:45  <GitHub33> bitcoin/master 16555b6 Wladimir J. van der Laan: Merge #7766: rpc: Register calls where they are defined...
 77 2016-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
 78 2016-03-31T08:56:20  *** Thireus has joined #bitcoin-core-dev
 79 2016-03-31T09:08:40  <GitHub195> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/16555b658f5b...7c80e720402d
 80 2016-03-31T09:08:40  <GitHub195> bitcoin/master 40234ba BtcDrak: Fix comments in tests
 81 2016-03-31T09:08:41  <GitHub195> bitcoin/master 7c80e72 Wladimir J. van der Laan: Merge #7773: Fix comments in tests...
 82 2016-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
 83 2016-03-31T09:16:43  *** PaulCapestany has joined #bitcoin-core-dev
 84 2016-03-31T09:19:38  *** PaulCape_ has quit IRC
 85 2016-03-31T09:40:06  *** frankenmint has joined #bitcoin-core-dev
 86 2016-03-31T09:47:03  *** frankenmint has quit IRC
 87 2016-03-31T09:55:53  *** jtimon has joined #bitcoin-core-dev
 88 2016-03-31T10:09:30  *** PaulCape_ has joined #bitcoin-core-dev
 89 2016-03-31T10:12:23  *** PaulCapestany has quit IRC
 90 2016-03-31T10:23:38  *** randy-waterhouse has left #bitcoin-core-dev
 91 2016-03-31T10:43:21  *** frankenmint has joined #bitcoin-core-dev
 92 2016-03-31T10:49:20  *** frankenmint has quit IRC
 93 2016-03-31T11:22:40  *** gijensen has quit IRC
 94 2016-03-31T11:22:40  *** da2ce7 has quit IRC
 95 2016-03-31T11:22:51  *** p15 has quit IRC
 96 2016-03-31T11:22:51  *** justanotheruser has quit IRC
 97 2016-03-31T11:22:51  *** Squidicc has quit IRC
 98 2016-03-31T11:22:53  *** da2ce7 has joined #bitcoin-core-dev
 99 2016-03-31T11:23:07  *** justanot1eruser has joined #bitcoin-core-dev
100 2016-03-31T11:23:28  *** gijensen has joined #bitcoin-core-dev
101 2016-03-31T11:25:19  <GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c80e720402d...3081fb9a3105
102 2016-03-31T11:25:19  <GitHub59> bitcoin/master eff736e Pieter Wuille: Reformat version in UpdateTip and other messages...
103 2016-03-31T11:25:20  <GitHub59> bitcoin/master 3081fb9 Wladimir J. van der Laan: Merge #7763: Put hex-encoded version in UpdateTip...
104 2016-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
105 2016-03-31T11:25:54  <GitHub99> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3081fb9a3105...209dbeb05f88
106 2016-03-31T11:25:54  <GitHub99> bitcoin/master 3e55b3a accraze: [doc] added depends cross compile info
107 2016-03-31T11:25:55  <GitHub99> bitcoin/master 209dbeb Wladimir J. van der Laan: Merge #7747: [docs] added depends cross compile info...
108 2016-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
109 2016-03-31T11:27:36  *** fengling has quit IRC
110 2016-03-31T11:33:37  *** cryptapus has joined #bitcoin-core-dev
111 2016-03-31T11:33:39  *** cryptapus has joined #bitcoin-core-dev
112 2016-03-31T11:45:16  *** frankenmint has joined #bitcoin-core-dev
113 2016-03-31T11:49:50  *** frankenmint has quit IRC
114 2016-03-31T11:50:25  <GitHub59> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4d035bcc9aa3388dc7f37cf81451e55f0b6270ee
115 2016-03-31T11:50:26  <GitHub59> bitcoin/0.12 4d035bc accraze: [doc] added depends cross compile info...
116 2016-03-31T11:57:00  *** chris2000 has joined #bitcoin-core-dev
117 2016-03-31T12:14:23  <GitHub125> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/209dbeb05f88...63832688939f
118 2016-03-31T12:14:23  <GitHub125> bitcoin/master ae2156f Pavel Janík: Clear the input line after activating autocomplete
119 2016-03-31T12:14:24  <GitHub125> bitcoin/master 6383268 Jonas Schnelli: Merge #7772: Clear the input line after activating autocomplete...
120 2016-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
121 2016-03-31T12:29:17  <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63832688939f...28ad4d9fc2be
122 2016-03-31T12:29:18  <GitHub124> bitcoin/master 72fd008 Daniel Kraft: Fix quoting of copyright holders in configure.ac....
123 2016-03-31T12:29:18  <GitHub124> bitcoin/master 28ad4d9 Wladimir J. van der Laan: Merge #7477: Fix quoting of copyright holders in configure.ac....
124 2016-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
125 2016-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
126 2016-03-31T12:46:00  *** frankenmint has joined #bitcoin-core-dev
127 2016-03-31T12:50:38  *** frankenmint has quit IRC
128 2016-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
129 2016-03-31T13:12:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
130 2016-03-31T13:22:30  *** Chris_Stewart_5 has quit IRC
131 2016-03-31T13:29:25  *** Giszmo has joined #bitcoin-core-dev
132 2016-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
133 2016-03-31T13:36:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
134 2016-03-31T13:43:25  *** MarcoFalke has joined #bitcoin-core-dev
135 2016-03-31T13:46:46  *** frankenmint has joined #bitcoin-core-dev
136 2016-03-31T13:51:24  *** frankenmint has quit IRC
137 2016-03-31T13:57:04  *** fengling has joined #bitcoin-core-dev
138 2016-03-31T14:01:56  *** fengling has quit IRC
139 2016-03-31T14:20:46  <GitHub142> [bitcoin] laanwj pushed 5 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/c251f46bea8f...ecaa178a235a
140 2016-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
141 2016-03-31T14:20:47  <GitHub142> bitcoin/0.11 90de0e1 Cory Fields: build: Split hardening/fPIE options out...
142 2016-03-31T14:20:47  <GitHub142> bitcoin/0.11 5c0b357 Cory Fields: build: Use fPIC rather than fPIE for qt objects....
143 2016-03-31T14:20:48  <GitHub142> bitcoin/0.11 d626faa Luke Dashjr: Merge commit '5c0b357' into backports-for-0.11.3
144 2016-03-31T14:31:30  *** trippysalmon has joined #bitcoin-core-dev
145 2016-03-31T14:46:14  *** zooko has joined #bitcoin-core-dev
146 2016-03-31T14:46:29  <MarcoFalke> Anything holding back 7691?
147 2016-03-31T15:17:32  *** frankenmint has joined #bitcoin-core-dev
148 2016-03-31T15:22:01  *** frankenmint has quit IRC
149 2016-03-31T15:27:29  *** zooko` has joined #bitcoin-core-dev
150 2016-03-31T15:29:18  *** zooko has quit IRC
151 2016-03-31T15:35:47  *** abritoid has quit IRC
152 2016-03-31T16:00:15  *** fengling has joined #bitcoin-core-dev
153 2016-03-31T16:04:56  *** fengling has quit IRC
154 2016-03-31T16:06:13  *** chris2000 has quit IRC
155 2016-03-31T16:09:52  *** zooko` has quit IRC
156 2016-03-31T16:10:48  *** Bootvis has joined #bitcoin-core-dev
157 2016-03-31T16:13:18  *** Don_John has joined #bitcoin-core-dev
158 2016-03-31T16:21:56  <sdaftuar> wumpus: can you explain the infinite loop in EncodeDecimal that #7751 addressed?
159 2016-03-31T16:22:27  *** JeromeLegoupil has joined #bitcoin-core-dev
160 2016-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
161 2016-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
162 2016-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
163 2016-03-31T16:29:02  <morcos> it seems better if our rpc tests dont' encode them that way?
164 2016-03-31T16:35:32  *** abritoid has joined #bitcoin-core-dev
165 2016-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
166 2016-03-31T16:47:55  *** zooko has joined #bitcoin-core-dev
167 2016-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
168 2016-03-31T16:52:34  *** zooko` has joined #bitcoin-core-dev
169 2016-03-31T16:53:48  *** zooko has quit IRC
170 2016-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
171 2016-03-31T17:02:04  *** Cheeseo has quit IRC
172 2016-03-31T17:10:39  <MarcoFalke> NicolasDorier, I can still see it
173 2016-03-31T17:10:41  <MarcoFalke> +        if (!CheckFinalTx(tx, flags)
174 2016-03-31T17:11:06  <NicolasDorier> ?? one second
175 2016-03-31T17:11:41  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/R9q9fyfu/
176 2016-03-31T17:11:47  <NicolasDorier> I removed the flags
177 2016-03-31T17:11:54  <NicolasDorier> and it compiles on travis
178 2016-03-31T17:12:49  <NicolasDorier> MarcoFalke: you see the like with flags as "add" ?
179 2016-03-31T17:12:58  <NicolasDorier> the line
180 2016-03-31T17:13:18  <MarcoFalke> travis is all red
181 2016-03-31T17:13:54  <MarcoFalke> check char 25 in this line
182 2016-03-31T17:13:56  <NicolasDorier> nop, only two build which are red because I pushed too fast, if can again should work fine
183 2016-03-31T17:14:10  <NicolasDorier> hu are we on same commit ?
184 2016-03-31T17:14:25  <NicolasDorier> ad930cdab3b23801f8a415cc4e900a182a6f8bc6 ?
185 2016-03-31T17:15:12  <wumpus> sdaftuar: in python 3.4, round(Decimal) no longer converts the decimal to a float
186 2016-03-31T17:15:26  <MarcoFalke> git grep 'if (!CheckFinalTx(tx, flags)'
187 2016-03-31T17:15:34  <wumpus> sdaftuar: so EncodeDecimal returns a (rounded) Decimal, which is again passed to EncodeDecimal
188 2016-03-31T17:15:36  <MarcoFalke> on the commit you posted
189 2016-03-31T17:15:43  <MarcoFalke> what is the result?
190 2016-03-31T17:16:13  <NicolasDorier> ooooooh
191 2016-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)
192 2016-03-31T17:16:34  <NicolasDorier> omg sorry, wtf did it compiled on several conf in travis and on my machine
193 2016-03-31T17:16:40  <sdaftuar> wumpus: ah okay
194 2016-03-31T17:16:52  <wumpus> sdaftuar: that shouldn't be backported to pre-0.12, no
195 2016-03-31T17:17:09  <MarcoFalke> I think there is an issue with travis if you push faster than it can start the build.
196 2016-03-31T17:17:24  <MarcoFalke> It will just compile the current ref instad of the commit you pushed
197 2016-03-31T17:17:28  <wumpus> MarcoFalke: yes, it will try to fetch the pull then fails
198 2016-03-31T17:17:44  <wumpus> oh okay
199 2016-03-31T17:18:03  <wumpus> sdaftuar: you can still use the old authproxy.py if yo udon't care about python 3 compat
200 2016-03-31T17:18:22  <sdaftuar> wumpus: right, yeah i figured out how to workaround the issue for now
201 2016-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?
202 2016-03-31T17:18:50  <sdaftuar> i know bitcoind supports it
203 2016-03-31T17:19:42  <NicolasDorier> MarcoFalke: Just repushed, sorry for the myopa :D
204 2016-03-31T17:20:29  <MarcoFalke> np
205 2016-03-31T17:20:48  *** Tasoshi_ has joined #bitcoin-core-dev
206 2016-03-31T17:22:48  *** cguida has quit IRC
207 2016-03-31T17:23:05  *** cguida has joined #bitcoin-core-dev
208 2016-03-31T17:24:28  <wumpus> sdaftuar: how is passing strings 'outside the json spec'?
209 2016-03-31T17:24:30  *** Tasoshi has quit IRC
210 2016-03-31T17:24:44  <sdaftuar> for numeric values i mean
211 2016-03-31T17:24:49  <wumpus> what it sends it 100% valid json
212 2016-03-31T17:25:12  <wumpus> well the underlying problem is that python has no way to send-this-string-unquoted
213 2016-03-31T17:25:12  <sdaftuar> hm, so i guess the rpc calls themselves now support numeric or string?  i suppose that makes sense.
214 2016-03-31T17:25:25  *** MarcoFalke has quit IRC
215 2016-03-31T17:25:27  <wumpus> casting to float defeats the purpose of using decimal in the first place
216 2016-03-31T17:25:46  <wumpus> so I think this is better
217 2016-03-31T17:26:20  <wumpus> besides reimplementing the json module to support arbitrary number formats, like univalue
218 2016-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
219 2016-03-31T17:29:03  <wumpus> indeed, this is implemented in AmountFromValue
220 2016-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 :)
221 2016-03-31T17:31:06  <instagibbs> and comments tend to have lingo I don't really grok
222 2016-03-31T17:31:08  <wumpus> the doxygen docs have a call tree
223 2016-03-31T17:31:14  <instagibbs> hmm ill check that
224 2016-03-31T17:32:36  <morcos> sipa: gmaxwell: i was just trying to do a quick review of #7568 and i'm very confused
225 2016-03-31T17:32:37  <wumpus> https://dev.visucore.com/bitcoin/doxygen/
226 2016-03-31T17:32:58  <instagibbs> yeah found it, thanks. Just need to find the "tip" of the flow I'm looking for now :)
227 2016-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.
228 2016-03-31T17:33:32  <morcos> We have to measure when the block was actually found, not the time on the block right?
229 2016-03-31T17:33:49  <instagibbs> wumpus, oh this is actually really useful, it has callee & caller graph
230 2016-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
231 2016-03-31T17:42:50  *** frankenmint has joined #bitcoin-core-dev
232 2016-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 ?
233 2016-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.
234 2016-03-31T17:50:50  <NicolasDorier> so you mean in case we need to revert it would be easier ?
235 2016-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
236 2016-03-31T17:51:07  <wumpus> I tend to agree it may be too early to remove it
237 2016-03-31T17:51:20  <NicolasDorier> ok I close the pr for now or keep around ?
238 2016-03-31T17:51:22  <wumpus> and for future softforks there may be other, new, flags to pass around
239 2016-03-31T17:51:22  <morcos> I like #7779 as the right approach
240 2016-03-31T17:51:35  <morcos> OR a step in the right direction
241 2016-03-31T17:52:00  <NicolasDorier> ok let's do that then, I close the PR ?
242 2016-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)
243 2016-03-31T17:52:14  <morcos> I think that its better to abstract ways to do that for better testing
244 2016-03-31T17:52:30  <morcos> That would be my recommendation (close the PR)
245 2016-03-31T17:52:58  <NicolasDorier> ok did it
246 2016-03-31T17:53:00  <wumpus> NicolasDorier: yes I think so, we can always bring it back when it's time
247 2016-03-31T17:53:02  <morcos> NicolasDorier: I actually thought until today that we shouldn't even have the LOCKTIME_VERIFY_SEQUENCE flag at all
248 2016-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
249 2016-03-31T17:53:34  <NicolasDorier> morcos, I think there is case where we need it
250 2016-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
251 2016-03-31T17:53:54  <NicolasDorier> if the fork is not activated, the flag is off
252 2016-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
253 2016-03-31T17:54:35  <morcos> No reason to call it with no flag and have it just short circuit
254 2016-03-31T17:55:36  <NicolasDorier> ah yes I see what you mean
255 2016-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
256 2016-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
257 2016-03-31T17:57:08  <morcos> For blocks you recreate that set of flags each block
258 2016-03-31T17:57:20  <morcos> but for the mempool, you want to know what was active as of the last block
259 2016-03-31T17:57:43  <morcos> maybe thats somethign we should just save as a global from connectBlock or maybe there is a better way
260 2016-03-31T17:57:45  <wumpus> well not exactly that, I think
261 2016-03-31T17:57:53  <wumpus> usually we start enforcing things for the mempool first
262 2016-03-31T17:57:59  <morcos> wumpus: well you want AT LEAST that
263 2016-03-31T17:58:10  <wumpus> I think for the mempool you want to do *everything*
264 2016-03-31T17:58:29  <wumpus> there's generally no point in merging a softfork and not enforcing it for the mempool
265 2016-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
266 2016-03-31T17:59:11  <morcos> I think somehow you should have the STANDARD_FLAGS and the currently active consensus flags
267 2016-03-31T17:59:27  <morcos> instead we have STANDARD_FLAGS and sort of original consensus flags
268 2016-03-31T17:59:34  <wumpus> well sure, the standard flags need to be stricter than anything that is currently active
269 2016-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"
270 2016-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
271 2016-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
272 2016-03-31T18:02:41  <morcos> yeah i keep getting concerned around mempool issues during a soft fork activation
273 2016-03-31T18:02:47  <morcos> but i don't think there are any current problems
274 2016-03-31T18:03:22  <morcos> wumpus: did you see my prior comment on alert chain triggering.  i'm not pro removal
275 2016-03-31T18:03:31  <morcos> i'm NOW pro removal i mean
276 2016-03-31T18:03:51  <morcos> bad-chain alert triggering, ugh, i can't type today
277 2016-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
278 2016-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
279 2016-03-31T18:06:27  <morcos> ok, i'll be back for that
280 2016-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
281 2016-03-31T18:13:02  <gmaxwell> ere very few timelocked transactions being made)
282 2016-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.
283 2016-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.
284 2016-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
285 2016-03-31T18:20:20  <zooko`> at least closely related to the bad-chain-alert-triggering that you're talking about
286 2016-03-31T18:20:24  <zooko`> disabling: https://github.com/zcash/zcash/issues/131#issuecomment-204063197
287 2016-03-31T18:20:45  *** zooko` is now known as zooko
288 2016-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
289 2016-03-31T18:21:37  <zooko> sipa: oh, thanks.
290 2016-03-31T18:21:48  *** frankenmint has quit IRC
291 2016-03-31T18:22:13  *** d_t has joined #bitcoin-core-dev
292 2016-03-31T18:24:40  <sipa> morcos: see my comments on the PR
293 2016-03-31T18:25:02  <sipa> morcos: i don't know what the reason is for the actual false firing we frequently see now
294 2016-03-31T18:33:32  <sipa> morcos: i actually have no idea how much block timestamps are off
295 2016-03-31T18:35:31  <gmaxwell> I doubt it's block timestamps.
296 2016-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.
297 2016-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.
298 2016-03-31T18:37:40  <helo> should it be bother-until-dismissed?
299 2016-03-31T18:39:43  <helo> in -qt, that is
300 2016-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?
301 2016-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.
302 2016-03-31T18:47:20  <morcos> gmaxwell: i'm surprised you don't think its the block time stamps
303 2016-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
304 2016-03-31T18:48:02  <helo> potentially bad (but probably not) might warrant getting someone's attention... -paranoialevel=N
305 2016-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
306 2016-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);}
307 2016-03-31T18:50:33  <dgenr8> '
308 2016-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
309 2016-03-31T18:56:17  *** kangx has joined #bitcoin-core-dev
310 2016-03-31T18:56:34  <sipa> in the short term i am mostly concernes with fixing the spurious alerts
311 2016-03-31T18:56:56  <sipa> longer term, we should think hard about what the cases are to detect
312 2016-03-31T18:57:29  <sipa> for example, if miners would intentionally keep timestamps low, isn't that something to alert about as well?
313 2016-03-31T18:58:27  <jonasschnelli> Right? The meeting is now +1 on GMT?
314 2016-03-31T18:58:28  <dgenr8> time warp
315 2016-03-31T18:58:36  <wumpus> yes I think so
316 2016-03-31T18:59:05  <wumpus> no, I mean meeting is +0 UTC, but that's now isn't it?
317 2016-03-31T18:59:05  <Luke-Jr> ?
318 2016-03-31T18:59:16  <Luke-Jr> my calendar says it should start right now
319 2016-03-31T18:59:20  <paveljanik> yup
320 2016-03-31T18:59:21  <petertodd> Luke-Jr: ack
321 2016-03-31T18:59:39  <wumpus> meeting is in Reykjavik time, they don't have DST
322 2016-03-31T18:59:45  <wumpus> #startmeeting
323 2016-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.
324 2016-03-31T18:59:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
325 2016-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
326 2016-03-31T19:00:27  <jonasschnelli> topic proposal (short): p2p layer encryption
327 2016-03-31T19:00:35  <wumpus> ACTION: hunt down miners that mine MTP violations <- don't know about this one
328 2016-03-31T19:00:50  <wumpus> main topic is the softfork backports I think
329 2016-03-31T19:01:16  <sipa> topic: short update on segwit and segnet4
330 2016-03-31T19:01:29  <wumpus> cool
331 2016-03-31T19:01:43  <wumpus> #topic short update on segwit and segnet4
332 2016-03-31T19:02:00  <cfields> topic suggestion: net-refactor update
333 2016-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
334 2016-03-31T19:02:45  *** frankenmint has joined #bitcoin-core-dev
335 2016-03-31T19:02:49  <jonasschnelli> Nice!
336 2016-03-31T19:02:51  <wumpus> good to hear!
337 2016-03-31T19:02:52  <petertodd> sipa: +1
338 2016-03-31T19:03:00  <jonasschnelli> also had no crash on my segnet4 node.. :)
339 2016-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
340 2016-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.
341 2016-03-31T19:04:01  <gmaxwell> it's not well founded uncertanty.
342 2016-03-31T19:04:12  <gmaxwell> oops. [sorry for OT]
343 2016-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
344 2016-03-31T19:04:48  <sipa> so that upgrade tests from pre-segwit code post fork can be tested
345 2016-03-31T19:04:58  <sipa> and so that the consensus critical part can be reviewed separately
346 2016-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
347 2016-03-31T19:05:26  <sipa> ack, will do
348 2016-03-31T19:05:49  <cfields> yes, that would be great
349 2016-03-31T19:06:07  <petertodd> I should add segwit to python-bitcoinlib...
350 2016-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
351 2016-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.
352 2016-03-31T19:07:07  <petertodd> sipa: ah cool - are you going to do that with the existing script_(in)valid.json framework?
353 2016-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, ...
354 2016-03-31T19:07:46  <sipa> petertodd: yes
355 2016-03-31T19:08:18  <btcdrak> #link https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit
356 2016-03-31T19:08:21  <wumpus> #action start generating mtp violating transactions (gmaxwell)
357 2016-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)
358 2016-03-31T19:08:51  <sipa> petertodd: tbd, i'm sure i'll find a way
359 2016-03-31T19:09:00  <sipa> but i haven't looked into it deeply
360 2016-03-31T19:09:56  <sipa> EOT? (end of topic)
361 2016-03-31T19:10:20  <sipa> btcdrak: no, use segwit-base...segwit
362 2016-03-31T19:10:34  <sipa> (so you don't see the backports before segwit)
363 2016-03-31T19:10:57  <wumpus> ok
364 2016-03-31T19:11:21  <wumpus> #topic net-refactor update
365 2016-03-31T19:11:52  <wumpus> @cfields
366 2016-03-31T19:11:56  <cfields> ok. I've pushed an up-to-date version to my net-refactor10 branch...
367 2016-03-31T19:12:13  <cfields> at this point, it's ready for testing and review, but i'm not entirely sure how to proceed
368 2016-03-31T19:12:30  <wumpus> ohh I'm two branches behind
369 2016-03-31T19:13:01  <wumpus> what is unclear?
370 2016-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...
371 2016-03-31T19:13:14  <btcdrak> sipa: this then? https://github.com/sipa/bitcoin/compare/segwit-base...sipa:segwit
372 2016-03-31T19:13:20  <sipa> btcdrak: ack
373 2016-03-31T19:13:33  <wumpus> well if it is one big change it should be one commit
374 2016-03-31T19:13:49  <wumpus> splitting makes sense if there are atomic changes
375 2016-03-31T19:14:13  <wumpus> especially if they're somewhat independent
376 2016-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
377 2016-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
378 2016-03-31T19:15:37  <cfields> s/refactor/PR small refactoring chunks/
379 2016-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.
380 2016-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
381 2016-03-31T19:17:30  <wumpus> congrats :)
382 2016-03-31T19:17:40  <cfields> I suppose that's it for now
383 2016-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
384 2016-03-31T19:18:42  <cfields> wumpus: understood. I'm starting to doubt whether it makes sense for .13.
385 2016-03-31T19:18:59  <sipa> when is the feature freeze for 0.13?
386 2016-03-31T19:18:59  <wumpus> #topic softfork backports
387 2016-03-31T19:19:00  <jonasschnelli> I have already started reviewing it but need to read myself more into libevent first.
388 2016-03-31T19:19:14  <petertodd> cfields: well, keep in mind that what's keeping everyone busy is stuff that'll be backported
389 2016-03-31T19:19:18  <jtimon> NicolasDorier:
390 2016-03-31T19:19:20  <btcdrak> backports are #7543 and #7716
391 2016-03-31T19:19:24  <cfields> jonasschnelli: for the sake of review, I'd say you can do it in 2 main chunks
392 2016-03-31T19:19:41  <cfields> first, libbtcnet can be considered to be a black box that works as intended
393 2016-03-31T19:19:53  <jtimon> what? it was a suggestion for extension, I think you got simplifications I missed'
394 2016-03-31T19:19:57  <cfields> then, reviewing libbtcnet itself
395 2016-03-31T19:20:04  <wumpus> sipa: 2016-05-15 https://github.com/bitcoin/bitcoin/issues/7679
396 2016-03-31T19:20:11  <btcdrak> so #7543 is a straight up cherry-pick from master, easy peasy.
397 2016-03-31T19:20:30  <btcdrak> #7716 needs a bit more review, but the tests, as per the comments make it quite easy to verify.
398 2016-03-31T19:20:40  <sipa> i gave a command line for easy mechanical review of 7543 :)
399 2016-03-31T19:20:51  <morcos> "easy"
400 2016-03-31T19:21:13  <btcdrak> #7543 has 5 tested ACKs so far. It should be ready for merge.
401 2016-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)
402 2016-03-31T19:22:04  <phantomcircuit> cfields: link to current net refactor work?
403 2016-03-31T19:22:37  <wumpus> agree on the 0.12 backport btcdrak
404 2016-03-31T19:22:47  <cfields> phantomcircuit: https://github.com/theuni/bitcoin/tree/net-refactor10
405 2016-03-31T19:22:52  <wumpus> #action #7543 has 5 tested ACKs so far. It should be ready for merge
406 2016-03-31T19:23:28  <btcdrak> wumpus: I'll go round bugging more people for review of #7716 this week.
407 2016-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
408 2016-03-31T19:24:19  <wumpus> #link  https://github.com/theuni/bitcoin/tree/net-refactor10
409 2016-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.
410 2016-03-31T19:25:06  <wumpus> what would be the effect of not backporting to 0.11?
411 2016-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
412 2016-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
413 2016-03-31T19:25:57  <morcos> Just a though, given that segwit will also likely be difficult to get properly tested in 0.11
414 2016-03-31T19:26:25  <gmaxwell> I've had this thought too. Unfortunately none of the users of these things will give us any feedback.
415 2016-03-31T19:26:26  <petertodd> morcos: ack - and also, esp. from miners, do we have a clear request to do a backport?
416 2016-03-31T19:26:33  <wumpus> do miners use 0.11?
417 2016-03-31T19:26:58  <wumpus> if not, backporting softfork to 0.11 is not *that* important
418 2016-03-31T19:27:06  <phantomcircuit> wumpus: miners use git master...
419 2016-03-31T19:27:09  <morcos> This is an opensource project anyway, nothing stopping other people from backporting to 0.11 themselves
420 2016-03-31T19:27:21  <wumpus> sure, but we have a PR open for 0.11
421 2016-03-31T19:27:23  <morcos> We should concentrate our efforts where they will be most effective
422 2016-03-31T19:27:24  <sdaftuar> hah - low probability of getting that right
423 2016-03-31T19:27:29  <wumpus> people that want it can review it
424 2016-03-31T19:27:31  <sdaftuar> but agree that it's difficult to review
425 2016-03-31T19:27:46  *** Guyver2 has joined #bitcoin-core-dev
426 2016-03-31T19:27:55  <wumpus> if no one wants it, no one should review it
427 2016-03-31T19:28:04  <wumpus> so the decision would be more 'backport to 0.11 should block 0.12 deployment'
428 2016-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.
429 2016-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?
430 2016-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
431 2016-03-31T19:28:29  <Luke-Jr> wumpus: yes, miners still use 0.11
432 2016-03-31T19:28:38  <wumpus> morcos: well the plan was to release 0.11.3 and 0.12.1 at the same time
433 2016-03-31T19:28:48  <Luke-Jr> wumpus: and that is likely to remain the case for some time
434 2016-03-31T19:28:52  <wumpus> that means that 0.11.3 will block 0.12.1
435 2016-03-31T19:29:10  <morcos> Yes thats what i'm objecting to!
436 2016-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.
437 2016-03-31T19:29:30  <jonasschnelli> cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.11." | wc -l    ---> 1581
438 2016-03-31T19:29:34  <jonasschnelli> cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.12." | wc -l --> 1276
439 2016-03-31T19:29:47  <jonasschnelli> I think a BP for 0.11 would be good.
440 2016-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
441 2016-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
442 2016-03-31T19:30:24  <btcdrak> morcos: so far 3 people have tested #7716.
443 2016-03-31T19:30:32  <Luke-Jr> wumpus: it also has no well-tested CPFP yet ;)
444 2016-03-31T19:30:34  <morcos> yes and 2 of them think it was a waste of time
445 2016-03-31T19:31:01  <wumpus> so can we get people that use 0.11.x involved in testing it?
446 2016-03-31T19:31:01  <btcdrak> For the record, I am fine not to backport to 0.11
447 2016-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
448 2016-03-31T19:31:16  <wumpus> this is an open source project, so at some point it's scratch your own itch
449 2016-03-31T19:31:18  <morcos> than deploying CSV to 0.11
450 2016-03-31T19:31:22  <jonasschnelli> morcos : +1
451 2016-03-31T19:31:29  <morcos> wumpus: sure, so lets not delay 0.12.1
452 2016-03-31T19:31:30  <paveljanik> +1
453 2016-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
454 2016-03-31T19:31:38  <btcdrak> +1
455 2016-03-31T19:31:39  <morcos> jl2012: thanks
456 2016-03-31T19:31:41  <wumpus> but what if bbackporting to 0.11.x helps segwit deployment, by making sure miners use it?
457 2016-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.
458 2016-03-31T19:31:50  <wumpus> ok
459 2016-03-31T19:31:52  <btcdrak> please can we merge 7543 and start the RC phase.
460 2016-03-31T19:31:58  <jonasschnelli> Agree with wumpus: 0.12 is relatively new. The time will also works towers 0.12 adaptation.
461 2016-03-31T19:32:04  <jonasschnelli> towards
462 2016-03-31T19:32:06  <morcos> btcdrak: well that brings us to next topic, bad-chain alerts
463 2016-03-31T19:32:07  <Luke-Jr> it may be easier to get morcos's new CPFP stuff tested well
464 2016-03-31T19:32:10  <gmaxwell> it is premature to RC on 0.12 at this second. (maybe in a couple days)
465 2016-03-31T19:32:19  <wumpus> it'd be better if we would have first done a bugfix release for 0.12
466 2016-03-31T19:32:20  <morcos> Luke-Jr: heh, thanks but sdaftuar's
467 2016-03-31T19:32:24  <Luke-Jr> oh, oops
468 2016-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
469 2016-03-31T19:32:48  *** achow101 has joined #bitcoin-core-dev
470 2016-03-31T19:32:48  <wumpus> then again I know of no *serious* bugs in 0.12
471 2016-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
472 2016-03-31T19:33:05  <wumpus> new topic bad chain alerts?
473 2016-03-31T19:33:06  <morcos> btcdrak: i think i mostly agree with that
474 2016-03-31T19:33:11  <wumpus> #topic bad chain alerts
475 2016-03-31T19:33:59  <gmaxwell> is that bad "chain alerts" or "bad chain" alerts? :)
476 2016-03-31T19:34:14  <jonasschnelli> second.
477 2016-03-31T19:34:23  <wumpus> hehe both
478 2016-03-31T19:34:27  <sipa> (bad ((bad chain) alerts))
479 2016-03-31T19:34:29  <gmaxwell> I think it's actually more the first.
480 2016-03-31T19:34:36  <btcdrak> sipa: groan
481 2016-03-31T19:34:43  <morcos> wumpus: i think the proper thing to do here is properly research what was causing the false positives.
482 2016-03-31T19:34:53  <wumpus> so, disable for now, then try to fix in master, if that succeeds backport to 0.12.2?
483 2016-03-31T19:35:01  <morcos> that would be my vote
484 2016-03-31T19:35:01  <btcdrak> wumpus: +1
485 2016-03-31T19:35:04  <gmaxwell> +1
486 2016-03-31T19:35:06  <sdaftuar> ack
487 2016-03-31T19:35:20  <gmaxwell> We urgently must stop the false positives or the facility becomes completely useless.
488 2016-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
489 2016-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
490 2016-03-31T19:35:40  <wumpus> gmaxwell: right
491 2016-03-31T19:35:44  <gmaxwell> I think the work that Tom has done improving it is valuable and welcome, but clearly not enough yet.
492 2016-03-31T19:36:05  <morcos> gmaxwell: or it might be enough, but we're not sure yet
493 2016-03-31T19:36:07  <wumpus> gmaxwell: it makes sense to merge that for master
494 2016-03-31T19:36:12  <sipa> morcos: under assumptions of constant hash rate,nodes that are up 100% of the time, and correct block timestamps
495 2016-03-31T19:36:33  <petertodd> I recently spoke to a very confused user who thought the alerts meant bitcoin was fending off attack :/
496 2016-03-31T19:36:33  <sipa> morcos: if any of those assumptions are wrong, it will fail more
497 2016-03-31T19:36:46  <wumpus> ah a bad-weather check that only works under good-weather conditions :)
498 2016-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
499 2016-03-31T19:37:03  <dgenr8> sipa: why do you think it will fail more?
500 2016-03-31T19:37:16  <wumpus> petertodd: yes, it confuses users
501 2016-03-31T19:37:21  <gmaxwell> dgenr8: fail more than meni's calculation.
502 2016-03-31T19:37:25  <wumpus> petertodd: especially because the alert just won't go away
503 2016-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
504 2016-03-31T19:37:50  <morcos> and it obscures other alerts
505 2016-03-31T19:37:51  <dgenr8> morcos: hard to argue with that ;)
506 2016-03-31T19:38:01  <morcos> "maybe" :)
507 2016-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.
508 2016-03-31T19:38:13  <dgenr8> bad weather check that never detects bad weather
509 2016-03-31T19:38:15  <petertodd> wumpus: when we fix them, probably worthwhile to hide the alerts in the gui for the first release
510 2016-03-31T19:38:39  <wumpus> #action disable bad-chain alert for 0.12.1
511 2016-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
512 2016-03-31T19:38:59  <wumpus> who's going to make a PR?
513 2016-03-31T19:39:19  <morcos> yes i agree with sipa
514 2016-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.
515 2016-03-31T19:39:32  <petertodd> wumpus: I'll do it
516 2016-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.
517 2016-03-31T19:39:33  <morcos> this is just about backporting to 0.12
518 2016-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
519 2016-03-31T19:40:02  <wumpus> right.
520 2016-03-31T19:40:05  <dgenr8> wumpus: that's great
521 2016-03-31T19:40:14  <petertodd> wumpus: what branch would be best to do it against?
522 2016-03-31T19:40:20  <wumpus> petertodd: 0.12
523 2016-03-31T19:40:30  <wumpus> only 0.12
524 2016-03-31T19:40:33  <petertodd> wumpus: ack
525 2016-03-31T19:40:42  <btcdrak> oh
526 2016-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
527 2016-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.
528 2016-03-31T19:40:49  <btcdrak> I just submitted
529 2016-03-31T19:40:59  <jonasschnelli> ^^ :-)
530 2016-03-31T19:41:01  <sipa> i think disabling should go in master
531 2016-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.
532 2016-03-31T19:41:28  <dgenr8> gmaxwell: ah I forgot the "exclude false positives" code
533 2016-03-31T19:41:30  <sipa> so that if no appropriate imorovement is found for 0.13, we don't need a separate "fix" there
534 2016-03-31T19:41:36  <btcdrak> sipa: we're likely to fix it before then surely?
535 2016-03-31T19:41:40  <wumpus> sipa: I don't agree, we should aim for improvement in master
536 2016-03-31T19:41:44  <morcos> wumpus: I agree with sipa, otherwise we forget and have the broken one back for 0.13
537 2016-03-31T19:41:49  <morcos> wumpus: yes AIM
538 2016-03-31T19:41:53  <wumpus> sipa: if it itsn't fixed by 0.13 then we can easily disable it
539 2016-03-31T19:42:05  <sipa> wumpus: disabling is considered an improvement, it should in master and be backported
540 2016-03-31T19:42:09  <btcdrak> morcos: we wont forget. If it's not ready by 0.13 we can just disbale it
541 2016-03-31T19:42:10  <wumpus> sigh
542 2016-03-31T19:42:13  <sipa> but i don't care strongly
543 2016-03-31T19:42:15  <sipa> :)
544 2016-03-31T19:42:17  <morcos> we always forget!
545 2016-03-31T19:42:19  <wumpus> I don't care
546 2016-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
547 2016-03-31T19:42:43  <btcdrak> well how about we merge 7780 the cherry-pick it into master. same diff
548 2016-03-31T19:42:48  <morcos> if it makes it on a task list somewhere, thats good enough
549 2016-03-31T19:42:56  <morcos> but just saying it here is a mistake
550 2016-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.
551 2016-03-31T19:43:25  <wumpus> if you disable it that means there is effectgively no testing for the improved code
552 2016-03-31T19:43:29  <sipa> ok, let's fix in master
553 2016-03-31T19:43:34  <sipa> i retract my comment
554 2016-03-31T19:43:57  <gmaxwell> wumpus: already people have stopped reporting false postives. :(
555 2016-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 :)
556 2016-03-31T19:44:00  <morcos> i withdraw comment due to fear of the wrath of maxwell  (kidding trolls, kidding)
557 2016-03-31T19:44:32  <sipa> morcos: you should fear maxwell's demon indeed
558 2016-03-31T19:44:42  <wumpus> hah
559 2016-03-31T19:45:02  * petertodd shakes head
560 2016-03-31T19:45:15  <petertodd> (thereby increasing entropy slightly)
561 2016-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
562 2016-03-31T19:45:31  <morcos> next topic
563 2016-03-31T19:45:35  <wumpus> morcos: right
564 2016-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 :)
565 2016-03-31T19:46:23  <morcos> i am prone to hyperbole on the rare occasion
566 2016-03-31T19:46:24  <wumpus> any other topics?
567 2016-03-31T19:46:26  <sdaftuar> topic suggestion: CPFP mining
568 2016-03-31T19:46:32  <wumpus> #topic CPFP mining
569 2016-03-31T19:46:33  <sipa> sdaftuar: answer is yes
570 2016-03-31T19:46:53  <sdaftuar> mostly i just want to bug people for review
571 2016-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
572 2016-03-31T19:47:06  <morcos> first step is for people to give concept feedback for 7598, refactor of CreateNewBlock
573 2016-03-31T19:47:19  <sdaftuar> ^ yes that's what i was going to say
574 2016-03-31T19:47:20  <morcos> its a kind of large change, and lets get it to a design we all like better
575 2016-03-31T19:47:38  <morcos> sdaftuar and i can rebuild the CPFP on whatever the design is people like best
576 2016-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
577 2016-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!)
578 2016-03-31T19:49:09  <sipa> morcos: ok
579 2016-03-31T19:50:22  <morcos> hmm
580 2016-03-31T19:51:20  <jonasschnelli> 5mins for p2p enc/auth?
581 2016-03-31T19:51:22  <morcos> i'm just trying to think about itming of all these things
582 2016-03-31T19:51:28  <morcos> 5/15 isn't that far away
583 2016-03-31T19:51:41  <morcos> and some changes on top of segwit will be necessary
584 2016-03-31T19:51:53  <morcos> do we punt on these other things for now and try to get segwit merged
585 2016-03-31T19:51:57  <morcos> or continue in parallel or what
586 2016-03-31T19:52:25  <morcos> i'm not sure i know the answer...
587 2016-03-31T19:52:28  <wumpus> jonasschnelli: sure
588 2016-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.
589 2016-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.
590 2016-03-31T19:52:36  <jonasschnelli> Continuing makes probably only sense if most of us prefere a own/custom solution.
591 2016-03-31T19:52:53  <wumpus> #topic p2p encryption/authentication
592 2016-03-31T19:53:16  <petertodd> jonasschnelli: fwiw, note that .onion addresses do work pretty well for p2p encryption and authentication
593 2016-03-31T19:53:19  <sipa> jonasschnelli: you can literally copy the crypto code from openssh; it's 300 lines for chacha20-poly1305
594 2016-03-31T19:53:25  <wumpus> I'm all for adapting something that already exists as long as it's not openssl
595 2016-03-31T19:53:31  *** MarcoFa has joined #bitcoin-core-dev
596 2016-03-31T19:53:32  <sipa> and ecdh and signing we already have
597 2016-03-31T19:54:29  <jonasschnelli> I think it would allow extremely simple setups for wallet nodes (spv) to increase privacy.
598 2016-03-31T19:54:33  <petertodd> sipa: copying ssh sounds pretty reasonable to me
599 2016-03-31T19:54:34  <Luke-Jr> jonasschnelli: ready for BIP #s yet?
600 2016-03-31T19:54:36  <btcdrak> jonasschnelli: continuing to work on those BIPs is a clear win
601 2016-03-31T19:54:55  <jonasschnelli> tor is an alternative, but not preferred by everyone and probably consequences on performance.
602 2016-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)
603 2016-03-31T19:55:09  <jonasschnelli> Luke-Jr: BIP is _not_ ready yet.
604 2016-03-31T19:55:18  <sipa> but thinking about it can continur
605 2016-03-31T19:55:26  * wumpus also likes chacha20-poly1305
606 2016-03-31T19:55:30  <jonasschnelli> Right. No rush. Can take 1-2 years. I just want to keep it moving.
607 2016-03-31T19:55:51  <sipa> chacha20-poly1305 is faster than sha256 ;)
608 2016-03-31T19:56:08  <warren> Are folks thinking this would be optional, not default?
609 2016-03-31T19:56:11  <cfields> sipa / jonasschnelli: note that you can easily test with libbtcnet, so it'll be familiar after the net refactor
610 2016-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
611 2016-03-31T19:56:16  <jonasschnelli> Okay. Will continue finish the BIP and seek out for funding for cryptanalysis, etc.
612 2016-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
613 2016-03-31T19:56:36  <cfields> sipa / jonasschnelli: i added support for chunked reads as suggested, in case i forgot to mention
614 2016-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
615 2016-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. :)
616 2016-03-31T19:57:07  <sipa> related topic: shameless plug for https://github.com/sipa/ctaes (since it was a topic last week)
617 2016-03-31T19:57:13  <petertodd> sipa: thanks!
618 2016-03-31T19:57:21  <jonasschnelli> gmaxwell: Agree!
619 2016-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.
620 2016-03-31T19:57:31  <wumpus> #link https://github.com/sipa/ctaes
621 2016-03-31T19:57:41  <jonasschnelli> cfields: good idea.
622 2016-03-31T19:57:50  <gmaxwell> please not yet.
623 2016-03-31T19:57:52  <cfields> heh, offer retracted after gmaxwell's plea :)
624 2016-03-31T19:58:14  <jonasschnelli> Yes. Not now. First we need an implementation and clear review from maxwell and sipa.
625 2016-03-31T19:58:26  <gmaxwell> I'm happy to help refining it, though.
626 2016-03-31T19:58:33  <jonasschnelli> (after the BIP is "stable").
627 2016-03-31T19:58:47  <jonasschnelli> gmaxwell: yes. Will bother you soon with tons of q.
628 2016-03-31T19:58:53  <gmaxwell> jonasschnelli: Thank you!
629 2016-03-31T19:59:43  <jonasschnelli> </p2pencauth>
630 2016-03-31T19:59:47  * sipa afk
631 2016-03-31T19:59:56  <wumpus> #endmeeting
632 2016-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)
633 2016-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
634 2016-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
635 2016-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
636 2016-03-31T20:00:06  <morcos> wait sorry if i zoned out
637 2016-03-31T20:00:15  <morcos> did we agree not to hold up 0.12.1 for 0.11.3 ?
638 2016-03-31T20:00:24  <jonasschnelli> I think so.
639 2016-03-31T20:00:48  <wumpus> I don't think we agreed in anything in that regard, then again meetings are not for making decisions :)
640 2016-03-31T20:00:51  <jonasschnelli> But it was not a clear obvious decision I guess.
641 2016-03-31T20:01:07  <jonasschnelli> ok.
642 2016-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.
643 2016-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 ;)
644 2016-03-31T20:02:16  <wumpus> jtimon: meeting is +0 UTC, or Reykjavik time
645 2016-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
646 2016-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
647 2016-03-31T20:02:52  <wumpus> according to my calendar it just ended
648 2016-03-31T20:03:11  <morcos> jtimon: you are funny, you were chatting offtopic during hte meeting, yet you didn't notice it was happening? :)
649 2016-03-31T20:03:23  <wumpus> morcos: I personally tend to agree though, dependencies between releaases just inhibit flexibilty
650 2016-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
651 2016-03-31T20:04:19  <morcos> wumpus: yes, but lets let worry about its own blockers only.
652 2016-03-31T20:04:29  <morcos> wait
653 2016-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
654 2016-03-31T20:05:17  <wumpus> jtimon: that's what it is already
655 2016-03-31T20:05:29  <paveljanik> jtimon, then am and pm can change its meaning ;-)
656 2016-03-31T20:05:44  <wumpus> jtimon: it's planned in UTC+0 which has no time savings
657 2016-03-31T20:05:55  *** fengling has joined #bitcoin-core-dev
658 2016-03-31T20:06:01  <jtimon> morcos: yeah, sorry about that, I was answering on IRC not to disrupt gihub :(
659 2016-03-31T20:06:30  *** cryptapus has quit IRC
660 2016-03-31T20:06:47  <wumpus> meeting is always: 19:00 to 20:00 (GMT+00:00) Reykjavik
661 2016-03-31T20:06:48  <jtimon> wumpus: yeah, it's perfect, sorry, I was just kidding about more radical "clock regimes" and I would ACK
662 2016-03-31T20:06:55  <wumpus> jtimon: ohh okay
663 2016-03-31T20:06:59  <wumpus> jtimon: sorry :)
664 2016-03-31T20:07:08  <jtimon> no worries, my fault
665 2016-03-31T20:07:18  <btcdrak> morcos: yes we agreed not to hold up 0.12.1
666 2016-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
667 2016-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!
668 2016-03-31T20:07:56  <petertodd> jtimon: (also c) my brother is a pilot and does that already - sibling rivalry!)
669 2016-03-31T20:08:02  <jtimon> petertodd: mhmm, never thought about privacy...
670 2016-03-31T20:08:17  <petertodd> jtimon: _lots_ of stuff leaks where you are by leaking your local TZ
671 2016-03-31T20:08:41  <wumpus> yes, it does, e.g. git
672 2016-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...)
673 2016-03-31T20:09:57  *** JeromeLegoupil has quit IRC
674 2016-03-31T20:10:14  <wumpus> I don't really understand that, why protocols don't just use UTC timestamps or dates
675 2016-03-31T20:10:16  *** fengling has quit IRC
676 2016-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
677 2016-03-31T20:10:32  <petertodd> wumpus: nsa conspiracy obvs :)
678 2016-03-31T20:10:39  <wumpus> hehe
679 2016-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?
680 2016-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
681 2016-03-31T20:11:12  <jtimon> well, notalways, debian seems to listen, ubuntu doesn't
682 2016-03-31T20:11:41  <jtimon> wumpus: UTC is still flawed
683 2016-03-31T20:12:53  <sipa> instagibbs: you don't; individual tests specify what chain they run it
684 2016-03-31T20:13:10  <instagibbs> sipa, the default string parameter is MAIN
685 2016-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
686 2016-03-31T20:13:24  <instagibbs> maybe I'm not looking at the right examples, but I don't see it being changed?
687 2016-03-31T20:14:17  <wumpus> instagibbs: it's a matter of passing the right chainparams to the appropriate functions, let me see
688 2016-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
689 2016-03-31T20:14:53  <sipa> instagibbs: i guess almost all unit tests run in main (maybe actually all)
690 2016-03-31T20:14:58  <instagibbs> i need to learn the right incantation
691 2016-03-31T20:15:15  <sipa> instagibbs: there is no incantation, it's not supposed to be configurable
692 2016-03-31T20:15:34  <instagibbs> well... it's odd it has a parameter then
693 2016-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
694 2016-03-31T20:15:55  <instagibbs> I see
695 2016-03-31T20:15:55  <sipa> instagibbs: wait, you mean in the code or on the command line?
696 2016-03-31T20:16:07  <wumpus> but the right incantation is: SelectParams(CBaseChainParams::TESTNET);
697 2016-03-31T20:16:19  <wumpus> see eg base58_tests.cpp
698 2016-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
699 2016-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
700 2016-03-31T20:18:12  <wumpus> unless you are testing something that uses the globally configured params
701 2016-03-31T20:18:14  <instagibbs> wumpus, it's yelling at me about coinbase stuff
702 2016-03-31T20:18:36  <instagibbs> anyhoo, one sec
703 2016-03-31T20:21:20  <jtimon> so, given that there's people congregated I feel tempted to ask about my latest too crazy ideas
704 2016-03-31T20:21:42  <petertodd> jtimon: heh
705 2016-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
706 2016-03-31T20:22:47  <jtimon> 2) are we coing to unify consensus flags or what?
707 2016-03-31T20:23:16  <Luke-Jr> I don't know that it makes sense to release 0.12.1 without 0.11 being ready
708 2016-03-31T20:23:37  <Luke-Jr> since 0.12 is not ready for mining
709 2016-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
710 2016-03-31T20:24:43  <instagibbs> wumpus, SelectParams did the trick +1
711 2016-03-31T20:25:02  <jtimon> do we still have selectparams? facepalm
712 2016-03-31T20:25:29  <instagibbs> unit tests use it <_<
713 2016-03-31T20:25:50  <sipa> Luke-Jr: increasing precision: i don't think we need it (it's less needed the larger fees are)
714 2016-03-31T20:25:54  <sipa> eh, jtimon
715 2016-03-31T20:26:03  <sipa> Luke-Jr: why is 0.12 not ready for mining?
716 2016-03-31T20:26:08  <Luke-Jr> sipa: no CPFP
717 2016-03-31T20:26:14  <sipa> Luke-Jr: neither did 0.11
718 2016-03-31T20:26:17  <Luke-Jr> yes it does
719 2016-03-31T20:26:25  <Luke-Jr> just not in Core
720 2016-03-31T20:26:43  <jtimon> yeah, we don't have a factory for tests yet, #6907 sigh
721 2016-03-31T20:26:57  <gmaxwell> Luke-Jr: analysis run by sdaftuar showed that it appeared no one was CFPF mining a couple months ago.
722 2016-03-31T20:27:15  <Luke-Jr> gmaxwell: that can't be right, considering people are *using* CPFP on a regular basis
723 2016-03-31T20:27:32  <Luke-Jr> and I know for certain a number of miners are
724 2016-03-31T20:27:46  <gmaxwell> but do they solve more than a block per week?
725 2016-03-31T20:28:21  <Luke-Jr> yes
726 2016-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
727 2016-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
728 2016-03-31T20:29:53  <Luke-Jr> …
729 2016-03-31T20:29:55  <jtimon> oh CFPF...<lurker mode>
730 2016-03-31T20:30:19  <jtimon> CPFP
731 2016-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
732 2016-03-31T20:33:57  *** MarcoFa has quit IRC
733 2016-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
734 2016-03-31T20:37:26  <jtimon> so I'm kind of worried of committing to a work I won't finish
735 2016-03-31T20:37:53  <morcos> jtimon: ok. no problem.  i think i will close my two open PR's though for now..
736 2016-03-31T20:38:11  <morcos> i feel a lot of other stuff happening, unless you tihnk either of them is worth pursuing
737 2016-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
738 2016-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
739 2016-03-31T20:39:53  <jtimon> nah, I don't think this is urgent
740 2016-03-31T20:40:35  *** JeromeLegoupil has joined #bitcoin-core-dev
741 2016-03-31T20:42:20  *** laurentmt has joined #bitcoin-core-dev
742 2016-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
743 2016-03-31T20:43:43  <jtimon> morcos: did I got this right? you mostly care about encapsulating the minRealyFee global first
744 2016-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
745 2016-03-31T20:45:08  <morcos> s/other codes/other classes/files/
746 2016-03-31T20:48:25  <jtimon> ok, I now wonder how many of them we need though
747 2016-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
748 2016-03-31T20:49:25  <jtimon> policy/policy depends on the dust one
749 2016-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
750 2016-03-31T20:50:27  <jtimon> 2
751 2016-03-31T20:51:07  <jtimon> morcos: does that make sense to you? You know that code better than me
752 2016-03-31T20:54:50  <jtimon> anyway, I should show you some code before asking
753 2016-03-31T20:56:04  *** justanot1eruser has quit IRC
754 2016-03-31T20:59:25  *** BCBot_ has quit IRC
755 2016-03-31T20:59:25  *** BCBot has quit IRC
756 2016-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
757 2016-03-31T21:01:10  *** BCBot has joined #bitcoin-core-dev
758 2016-03-31T21:01:16  *** cryptapus_afk is now known as cryptapus
759 2016-03-31T21:08:51  *** laurentmt has quit IRC
760 2016-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
761 2016-03-31T21:12:35  <jtimon> look the better, but you guys first please if you are available whenever}]);
762 2016-03-31T21:13:09  <morcos> so is there a specific PR you want me to review now
763 2016-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,
764 2016-03-31T21:18:17  <jtimon> all the better.
765 2016-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
766 2016-03-31T21:34:59  *** xabbix has quit IRC
767 2016-03-31T21:36:30  *** xabbix has joined #bitcoin-core-dev
768 2016-03-31T21:36:31  *** xabbix has joined #bitcoin-core-dev
769 2016-03-31T21:39:16  *** droark has joined #bitcoin-core-dev
770 2016-03-31T21:47:40  *** JeromeLegoupil has quit IRC
771 2016-03-31T21:52:27  *** brg444 has joined #bitcoin-core-dev
772 2016-03-31T21:54:23  *** brg444 has left #bitcoin-core-dev
773 2016-03-31T22:06:03  *** Guyver2 has quit IRC
774 2016-03-31T22:08:13  *** fengling has joined #bitcoin-core-dev
775 2016-03-31T22:12:21  *** Thireus has quit IRC
776 2016-03-31T22:12:40  *** Thireus has joined #bitcoin-core-dev
777 2016-03-31T22:13:16  *** fengling has quit IRC
778 2016-03-31T22:28:40  *** justanotheruser has joined #bitcoin-core-dev
779 2016-03-31T22:32:41  *** cryptapus is now known as cryptapus_afk
780 2016-03-31T22:35:15  *** droark has quit IRC
781 2016-03-31T22:38:04  *** zooko has quit IRC
782 2016-03-31T22:45:04  *** gevs has quit IRC
783 2016-03-31T22:50:39  *** AaronvanW has quit IRC
784 2016-03-31T22:55:40  *** lolwut has joined #bitcoin-core-dev
785 2016-03-31T22:58:28  *** gevs has joined #bitcoin-core-dev
786 2016-03-31T22:58:28  *** gevs has joined #bitcoin-core-dev
787 2016-03-31T23:00:47  *** lolwut has quit IRC
788 2016-03-31T23:39:32  *** PRab has quit IRC
789 2016-03-31T23:59:01  *** frankenmint has quit IRC