1 2017-03-23T00:02:42  *** magicwund has joined #bitcoin-core-dev
  2 2017-03-23T00:07:34  *** magicwund has quit IRC
  3 2017-03-23T00:08:57  *** owowo has joined #bitcoin-core-dev
  4 2017-03-23T00:21:43  *** Chris_Stewart_5 has quit IRC
  5 2017-03-23T00:43:19  *** owowo has quit IRC
  6 2017-03-23T00:44:21  <bitcoin-git> [bitcoin] tjps opened pull request #10059: [trivial] Removed one Boost usage and headers in util.cpp (master...tjps_boost) https://github.com/bitcoin/bitcoin/pull/10059
  7 2017-03-23T00:53:24  <bitcoin-git> [bitcoin] jnewbery closed pull request #10055: [test] [POC] Stop and start bitcoind nodes asynchronously in functional tests (master...stopstartasync) https://github.com/bitcoin/bitcoin/pull/10055
  8 2017-03-23T01:00:33  *** echonaut has quit IRC
  9 2017-03-23T01:00:59  *** echonaut has joined #bitcoin-core-dev
 10 2017-03-23T01:02:22  *** CubicEarth has quit IRC
 11 2017-03-23T01:06:02  *** owowo has joined #bitcoin-core-dev
 12 2017-03-23T01:06:02  *** owowo has joined #bitcoin-core-dev
 13 2017-03-23T01:08:43  *** PRab has quit IRC
 14 2017-03-23T01:10:25  <bitcoin-git> [bitcoin] achow101 opened pull request #10060: [RPC] Ensure an item exists on the rpcconsole stack before adding (master...fix-rpcconsole-empty-stack) https://github.com/bitcoin/bitcoin/pull/10060
 15 2017-03-23T01:10:46  *** owowo has quit IRC
 16 2017-03-23T01:11:19  *** PaulCape_ has joined #bitcoin-core-dev
 17 2017-03-23T01:11:27  *** owowo has joined #bitcoin-core-dev
 18 2017-03-23T01:12:10  *** PaulCapestany has quit IRC
 19 2017-03-23T01:22:51  *** magicwund has joined #bitcoin-core-dev
 20 2017-03-23T01:27:12  *** magicwund has quit IRC
 21 2017-03-23T01:31:03  *** echonaut has quit IRC
 22 2017-03-23T01:31:48  *** echonaut has joined #bitcoin-core-dev
 23 2017-03-23T01:47:37  *** magicwund has joined #bitcoin-core-dev
 24 2017-03-23T01:51:05  *** [Author] has joined #bitcoin-core-dev
 25 2017-03-23T01:51:57  *** magicwund has quit IRC
 26 2017-03-23T02:10:38  *** Giszmo has quit IRC
 27 2017-03-23T02:10:51  *** Giszmo has joined #bitcoin-core-dev
 28 2017-03-23T02:51:30  *** mol has quit IRC
 29 2017-03-23T02:54:13  *** dodomojo has joined #bitcoin-core-dev
 30 2017-03-23T02:55:14  *** dodomojo has joined #bitcoin-core-dev
 31 2017-03-23T03:00:28  *** magicwund has joined #bitcoin-core-dev
 32 2017-03-23T03:04:52  *** AaronvanW has quit IRC
 33 2017-03-23T03:04:57  *** magicwund has quit IRC
 34 2017-03-23T03:13:21  *** dodomojo_ has joined #bitcoin-core-dev
 35 2017-03-23T03:15:22  *** dodomojo has quit IRC
 36 2017-03-23T03:40:09  *** dodomojo_ has quit IRC
 37 2017-03-23T03:43:07  *** CubicEarth has joined #bitcoin-core-dev
 38 2017-03-23T03:49:10  *** blueyez has joined #bitcoin-core-dev
 39 2017-03-23T03:54:46  *** magicwund has joined #bitcoin-core-dev
 40 2017-03-23T03:55:03  *** harrymm has joined #bitcoin-core-dev
 41 2017-03-23T03:55:45  *** moli has joined #bitcoin-core-dev
 42 2017-03-23T04:03:23  *** chris200_ has joined #bitcoin-core-dev
 43 2017-03-23T04:04:07  *** Ylbam has quit IRC
 44 2017-03-23T04:05:52  *** chris2000 has quit IRC
 45 2017-03-23T04:07:57  *** magicwund has quit IRC
 46 2017-03-23T04:26:50  *** CubicEarth has quit IRC
 47 2017-03-23T04:27:00  *** rafalcpp has quit IRC
 48 2017-03-23T04:27:48  *** CubicEarth has joined #bitcoin-core-dev
 49 2017-03-23T04:28:57  *** jtimon has quit IRC
 50 2017-03-23T04:44:34  *** CubicEar_ has joined #bitcoin-core-dev
 51 2017-03-23T04:44:42  *** CubicEarth has quit IRC
 52 2017-03-23T04:46:17  *** CubicEar_ is now known as CubicEarth
 53 2017-03-23T05:06:57  *** CubicEarth has quit IRC
 54 2017-03-23T05:08:25  *** CubicEarthh has joined #bitcoin-core-dev
 55 2017-03-23T05:09:19  *** CubicEarthh has quit IRC
 56 2017-03-23T05:12:10  *** moli has quit IRC
 57 2017-03-23T05:12:58  *** CubicEarthh has joined #bitcoin-core-dev
 58 2017-03-23T05:17:25  <bitcoin-git> [bitcoin] tjps opened pull request #10061: [net] Added SetSocketNoDelay() utility function (master...tjps_nodelay) https://github.com/bitcoin/bitcoin/pull/10061
 59 2017-03-23T05:39:13  *** kungfuant has joined #bitcoin-core-dev
 60 2017-03-23T05:54:38  *** arubi_ has joined #bitcoin-core-dev
 61 2017-03-23T05:56:43  *** arubi has quit IRC
 62 2017-03-23T06:04:31  *** Giszmo has quit IRC
 63 2017-03-23T06:05:07  *** afk11 has quit IRC
 64 2017-03-23T06:11:04  *** afk11 has joined #bitcoin-core-dev
 65 2017-03-23T06:13:03  *** [b__b] has quit IRC
 66 2017-03-23T06:13:04  *** isle2983 has quit IRC
 67 2017-03-23T06:13:05  *** murr4y has quit IRC
 68 2017-03-23T06:13:06  *** xiangfu has quit IRC
 69 2017-03-23T06:13:06  *** xiangfu has joined #bitcoin-core-dev
 70 2017-03-23T06:13:08  *** [b__b] has joined #bitcoin-core-dev
 71 2017-03-23T06:15:34  *** murr4y has joined #bitcoin-core-dev
 72 2017-03-23T06:26:09  *** moli_ has joined #bitcoin-core-dev
 73 2017-03-23T06:26:18  <bitcoin-git> [bitcoin] kallewoof opened pull request #10062: [net] Clean up the net.h file. (master...20170322-cleanup-net) https://github.com/bitcoin/bitcoin/pull/10062
 74 2017-03-23T07:01:35  *** MarcoFalke has quit IRC
 75 2017-03-23T07:03:05  *** instagibbs_ has quit IRC
 76 2017-03-23T07:03:07  *** afk11 has quit IRC
 77 2017-03-23T07:03:31  *** arubi_ has quit IRC
 78 2017-03-23T07:03:31  *** wasi has quit IRC
 79 2017-03-23T07:03:35  *** morcos has quit IRC
 80 2017-03-23T07:04:15  *** afk11 has joined #bitcoin-core-dev
 81 2017-03-23T07:04:28  *** wasi has joined #bitcoin-core-dev
 82 2017-03-23T07:04:35  *** zxzzt has quit IRC
 83 2017-03-23T07:04:36  *** xiangfu has quit IRC
 84 2017-03-23T07:04:40  *** morcos has joined #bitcoin-core-dev
 85 2017-03-23T07:04:42  *** MarcoFalke has joined #bitcoin-core-dev
 86 2017-03-23T07:05:13  *** xiangfu has joined #bitcoin-core-dev
 87 2017-03-23T07:05:22  *** zxzzt has joined #bitcoin-core-dev
 88 2017-03-23T07:07:01  *** arubi has joined #bitcoin-core-dev
 89 2017-03-23T07:07:23  *** instagibbs has joined #bitcoin-core-dev
 90 2017-03-23T07:11:42  *** riemann has joined #bitcoin-core-dev
 91 2017-03-23T07:18:26  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02d64bd929c9...86f7d5b69bb7
 92 2017-03-23T07:18:26  <bitcoin-git> bitcoin/master 97b8213 practicalswift: Fix parameter naming inconsistencies between .h and .cpp files...
 93 2017-03-23T07:18:27  <bitcoin-git> bitcoin/master 86f7d5b Jonas Schnelli: Merge #10029: Fix parameter naming inconsistencies between .h and .cpp files...
 94 2017-03-23T07:18:47  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #10029: Fix parameter naming inconsistencies between .h and .cpp files (master...fix-header-parameter-naming-inconsistencies) https://github.com/bitcoin/bitcoin/pull/10029
 95 2017-03-23T07:19:12  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86f7d5b69bb7...7b585cf70ec5
 96 2017-03-23T07:19:12  <bitcoin-git> bitcoin/master c4a6929 Matt Corallo: Clarify assumptions made about when BlockCheck is called
 97 2017-03-23T07:19:13  <bitcoin-git> bitcoin/master 7b585cf Jonas Schnelli: Merge #9558: Clarify assumptions made about when BlockCheck is called...
 98 2017-03-23T07:19:22  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9558: Clarify assumptions made about when BlockCheck is called (master...2017-01-blockcheckeddocs) https://github.com/bitcoin/bitcoin/pull/9558
 99 2017-03-23T07:27:43  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b585cf70ec5...3568b30ca31d
100 2017-03-23T07:27:44  <bitcoin-git> bitcoin/master 6d8fe35 Andrew Chow: 'help' rpc commands autocomplete...
101 2017-03-23T07:27:44  <bitcoin-git> bitcoin/master 3568b30 Jonas Schnelli: Merge #9500: [Qt][RPC] Autocomplete commands for 'help' command in debug console...
102 2017-03-23T07:28:11  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9500: [Qt][RPC] Autocomplete commands for 'help' command in debug console (master...help-rpc-autocomplete) https://github.com/bitcoin/bitcoin/pull/9500
103 2017-03-23T07:36:08  *** magicwund has joined #bitcoin-core-dev
104 2017-03-23T07:40:57  *** magicwund has quit IRC
105 2017-03-23T07:44:48  *** BashCo has quit IRC
106 2017-03-23T07:48:42  *** riemann has quit IRC
107 2017-03-23T08:06:29  *** BashCo has joined #bitcoin-core-dev
108 2017-03-23T08:14:21  *** moli_ has quit IRC
109 2017-03-23T08:15:39  *** Victorsueca has joined #bitcoin-core-dev
110 2017-03-23T08:21:37  *** Madars_ has quit IRC
111 2017-03-23T08:22:08  *** juscamarena has quit IRC
112 2017-03-23T08:22:51  *** Madars_ has joined #bitcoin-core-dev
113 2017-03-23T08:30:27  *** juscamarena has joined #bitcoin-core-dev
114 2017-03-23T08:33:55  *** moli_ has joined #bitcoin-core-dev
115 2017-03-23T08:41:02  *** Ylbam has joined #bitcoin-core-dev
116 2017-03-23T08:42:22  *** belcher has quit IRC
117 2017-03-23T08:44:49  *** Evel-Knievel has joined #bitcoin-core-dev
118 2017-03-23T08:48:03  *** CubicEarthh has quit IRC
119 2017-03-23T08:52:27  *** belcher has joined #bitcoin-core-dev
120 2017-03-23T09:09:16  *** riemann has joined #bitcoin-core-dev
121 2017-03-23T09:38:10  *** udiWertheimer has joined #bitcoin-core-dev
122 2017-03-23T09:47:44  *** idufohid has joined #bitcoin-core-dev
123 2017-03-23T09:48:53  *** CubicEarthh has joined #bitcoin-core-dev
124 2017-03-23T09:53:48  *** CubicEarthh has quit IRC
125 2017-03-23T09:57:28  *** idufohid has quit IRC
126 2017-03-23T09:57:36  *** rafalcpp has joined #bitcoin-core-dev
127 2017-03-23T09:59:38  *** Guyver2 has joined #bitcoin-core-dev
128 2017-03-23T10:01:57  *** udiWertheimer has quit IRC
129 2017-03-23T10:03:49  *** go1111111 has quit IRC
130 2017-03-23T10:06:01  *** idufohid has joined #bitcoin-core-dev
131 2017-03-23T10:13:06  *** idufohid has quit IRC
132 2017-03-23T10:39:39  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3568b30ca31d...dfef6b6af080
133 2017-03-23T10:39:40  <bitcoin-git> bitcoin/master 72163d4 practicalswift: [tests] Remove unused and duplicate imports
134 2017-03-23T10:39:40  <bitcoin-git> bitcoin/master 3897459 practicalswift: [tests] Remove unused variables
135 2017-03-23T10:39:41  <bitcoin-git> bitcoin/master dfef6b6 MarcoFalke: Merge #10047: [tests] Remove unused variables and imports...
136 2017-03-23T10:40:22  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10047: [tests] Remove unused variables and imports (master...remove-unused-python-imports) https://github.com/bitcoin/bitcoin/pull/10047
137 2017-03-23T10:47:16  *** idufohid has joined #bitcoin-core-dev
138 2017-03-23T10:49:39  *** CubicEarthh has joined #bitcoin-core-dev
139 2017-03-23T10:51:44  *** AaronvanW has joined #bitcoin-core-dev
140 2017-03-23T10:51:44  *** AaronvanW has joined #bitcoin-core-dev
141 2017-03-23T10:52:52  *** idufohid has quit IRC
142 2017-03-23T10:54:40  *** CubicEarthh has quit IRC
143 2017-03-23T10:59:11  *** idufohid has joined #bitcoin-core-dev
144 2017-03-23T10:59:43  *** NicolasDorier has quit IRC
145 2017-03-23T11:03:58  *** idufohid has quit IRC
146 2017-03-23T11:12:56  *** NicolasDorier has joined #bitcoin-core-dev
147 2017-03-23T11:23:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/dfef6b6af080...a230b0588788
148 2017-03-23T11:23:29  <bitcoin-git> bitcoin/master 94b528b Russell Yanofsky: [qa] Remove bumpfee.py get_change_address hack
149 2017-03-23T11:23:29  <bitcoin-git> bitcoin/master e6b2963 Russell Yanofsky: [qa] Get rid of nondeterminism in bumpfee.py...
150 2017-03-23T11:23:30  <bitcoin-git> bitcoin/master 1dfd64f Russell Yanofsky: [qa] Make bumpfee.py test function order consistent...
151 2017-03-23T11:23:43  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9701: Make bumpfee tests less fragile (master...pr/bumpfee-fragile) https://github.com/bitcoin/bitcoin/pull/9701
152 2017-03-23T11:46:29  *** shesek has quit IRC
153 2017-03-23T11:50:28  <luke-jr> woo, sizefp code builds finally
154 2017-03-23T11:51:00  <luke-jr> although it's still incomplete.. need a good way to detect the "no full size proofs on right sides of duplicate merkle link hashes"
155 2017-03-23T11:51:35  <luke-jr> but I'd better get to bed so I can be up for the meeting :x
156 2017-03-23T12:00:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
157 2017-03-23T12:02:01  *** d9b4bef9 has quit IRC
158 2017-03-23T12:03:07  *** d9b4bef9 has joined #bitcoin-core-dev
159 2017-03-23T12:03:58  *** shesek has joined #bitcoin-core-dev
160 2017-03-23T12:04:18  *** jannes has joined #bitcoin-core-dev
161 2017-03-23T12:18:52  *** magicwund has joined #bitcoin-core-dev
162 2017-03-23T12:22:57  *** magicwund has quit IRC
163 2017-03-23T12:53:22  *** magicwund has joined #bitcoin-core-dev
164 2017-03-23T13:01:22  *** magicwund has quit IRC
165 2017-03-23T13:06:50  *** kexkey has joined #bitcoin-core-dev
166 2017-03-23T13:12:44  *** magicwund has joined #bitcoin-core-dev
167 2017-03-23T13:15:05  *** isle2983 has joined #bitcoin-core-dev
168 2017-03-23T13:17:14  *** magicwund has quit IRC
169 2017-03-23T13:31:24  <btcdrak> wow it's Thursday again already... how time flies
170 2017-03-23T13:43:59  *** magicwund has joined #bitcoin-core-dev
171 2017-03-23T13:48:43  <bitcoin-git> [bitcoin] flack opened pull request #10063: add missing spaces so that markdown recognizes headline (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10063
172 2017-03-23T13:48:58  *** magicwund has quit IRC
173 2017-03-23T13:52:01  *** jtimon has joined #bitcoin-core-dev
174 2017-03-23T13:55:13  *** Giszmo has joined #bitcoin-core-dev
175 2017-03-23T14:08:05  *** Giszmo has quit IRC
176 2017-03-23T14:20:54  *** Giszmo has joined #bitcoin-core-dev
177 2017-03-23T14:21:07  *** magicwund has joined #bitcoin-core-dev
178 2017-03-23T14:26:27  *** magicwund has quit IRC
179 2017-03-23T14:27:10  *** Turner has joined #bitcoin-core-dev
180 2017-03-23T14:37:00  *** magicwund has joined #bitcoin-core-dev
181 2017-03-23T14:38:05  *** BashCo_ has joined #bitcoin-core-dev
182 2017-03-23T14:40:42  *** BashCo has quit IRC
183 2017-03-23T14:43:29  *** BashCo has joined #bitcoin-core-dev
184 2017-03-23T14:45:27  *** BashCo_ has quit IRC
185 2017-03-23T14:59:18  *** owowo has quit IRC
186 2017-03-23T15:10:43  *** talmai has joined #bitcoin-core-dev
187 2017-03-23T15:10:53  *** owowo has joined #bitcoin-core-dev
188 2017-03-23T15:47:47  *** abpa has joined #bitcoin-core-dev
189 2017-03-23T15:50:39  *** CubicEarthh has joined #bitcoin-core-dev
190 2017-03-23T15:59:30  *** riemann has quit IRC
191 2017-03-23T16:14:07  *** bityogi has joined #bitcoin-core-dev
192 2017-03-23T16:26:29  *** laurentmt has joined #bitcoin-core-dev
193 2017-03-23T16:38:45  *** talmai has quit IRC
194 2017-03-23T16:52:30  *** cryptapus has joined #bitcoin-core-dev
195 2017-03-23T16:58:20  *** jouke has quit IRC
196 2017-03-23T16:58:20  *** jouke has joined #bitcoin-core-dev
197 2017-03-23T16:59:44  *** CubicEarthh has quit IRC
198 2017-03-23T17:05:52  *** magicwund has quit IRC
199 2017-03-23T17:15:47  *** magicwund has joined #bitcoin-core-dev
200 2017-03-23T17:19:33  *** juscamarena has quit IRC
201 2017-03-23T17:26:23  *** juscamarena has joined #bitcoin-core-dev
202 2017-03-23T17:34:10  *** ChillazZ has quit IRC
203 2017-03-23T17:34:25  *** gabridome has joined #bitcoin-core-dev
204 2017-03-23T18:02:50  *** laurentmt has quit IRC
205 2017-03-23T18:08:23  *** talmai has joined #bitcoin-core-dev
206 2017-03-23T18:16:58  *** talmai has quit IRC
207 2017-03-23T18:17:51  *** talmai has joined #bitcoin-core-dev
208 2017-03-23T18:26:54  *** GoldSlash has joined #bitcoin-core-dev
209 2017-03-23T18:27:45  *** talmai_ has joined #bitcoin-core-dev
210 2017-03-23T18:28:31  *** talmai has quit IRC
211 2017-03-23T18:29:23  *** Sosumi has joined #bitcoin-core-dev
212 2017-03-23T18:30:54  *** talmai_ has quit IRC
213 2017-03-23T18:31:32  *** talmai has joined #bitcoin-core-dev
214 2017-03-23T18:34:34  <gmaxwell> meeting in 20 minutes.
215 2017-03-23T18:34:49  *** GoldSlash_ has joined #bitcoin-core-dev
216 2017-03-23T18:37:18  *** GoldSlash__ has joined #bitcoin-core-dev
217 2017-03-23T18:37:39  *** GoldSlash_ has quit IRC
218 2017-03-23T18:40:03  *** GoldSlash__ has quit IRC
219 2017-03-23T18:41:22  *** GoldSlash__ has joined #bitcoin-core-dev
220 2017-03-23T18:43:22  *** schmidty has quit IRC
221 2017-03-23T18:43:46  *** GoldSlash__ has quit IRC
222 2017-03-23T18:47:09  <petertodd> sipa: IIRC there's something not unlike that in rust with deref coercion
223 2017-03-23T18:49:10  *** Giszmo has quit IRC
224 2017-03-23T18:50:04  <gmaxwell> luke-jr: does your prover optimize that it's cheaper to provide merkle membership proofs when you show transactions with common parents in the tree?  e.g.  Say that the sizes are   1000 900 100 910   you get more size-proof per proof-size if you select 1000,900  instead of 1000,910.
225 2017-03-23T18:50:35  *** chjj has quit IRC
226 2017-03-23T18:51:51  <luke-jr> gmaxwell: the current code doesn't
227 2017-03-23T18:53:50  *** juscamarena has quit IRC
228 2017-03-23T18:55:51  <gmaxwell> luke-jr: I would eliminate transactions by first assuming all are in and then asking "can I leave out this leaf?" for each interior node and child, then remove the one that eliminates the most proof size per transaction size proven.
229 2017-03-23T18:56:10  *** juscamarena has joined #bitcoin-core-dev
230 2017-03-23T18:56:47  <gmaxwell> (proof size including the membership proofs, and the extra data, so it'll tend to remove txn that have a lot of extradata)
231 2017-03-23T18:57:37  <gmaxwell> luke-jr: this is another reason for a softfork increasing the minimum transaction size in the future.  Your proofs should also be able to prove that there is a transaction smaller than a minimum.
232 2017-03-23T18:58:04  <gmaxwell> would be interesting to profile your proofs on the existing chain with a fake block limit of 750k and also see how the proof size changes as a function of the minimum transaction size.
233 2017-03-23T19:00:03  <sipa> PING
234 2017-03-23T19:00:14  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
235 2017-03-23T19:00:17  <kanzure> hi.
236 2017-03-23T19:00:17  <jonasschnelli> hi
237 2017-03-23T19:00:18  <petertodd> hi
238 2017-03-23T19:00:20  <wumpus> #startmeeting
239 2017-03-23T19:00:20  <lightningbot> Meeting started Thu Mar 23 19:00:20 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
240 2017-03-23T19:00:20  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
241 2017-03-23T19:00:20  <sipa> hi
242 2017-03-23T19:00:20  <achow101> hi
243 2017-03-23T19:00:27  <gmaxwell> Welcome to meeting.
244 2017-03-23T19:00:34  <cfields> hi
245 2017-03-23T19:00:49  *** chjj has joined #bitcoin-core-dev
246 2017-03-23T19:00:50  <btcdrak> greetings!
247 2017-03-23T19:00:57  <wumpus> proposed topics?
248 2017-03-23T19:01:14  <btcdrak> holiday at the beach?
249 2017-03-23T19:01:27  <petertodd> btcdrak: that's what the financial crypto conference is for
250 2017-03-23T19:01:29  <gmaxwell> wumpus: The segwit address proposal on the list.
251 2017-03-23T19:01:35  <petertodd> gmaxwell: +1
252 2017-03-23T19:01:37  <wumpus> sounds good to me
253 2017-03-23T19:01:39  <btcdrak> +1
254 2017-03-23T19:01:44  <wumpus> #topic  segwit address proposal
255 2017-03-23T19:01:53  <jonasschnelli> proposed topic: DER encoded priv keys in wallet
256 2017-03-23T19:02:05  <jonasschnelli> ack #sw addr format
257 2017-03-23T19:02:12  <sipa> general opinions/questions about the segwit addr format?
258 2017-03-23T19:02:25  <gmaxwell> We might have made a strategic error in getting 1:1 comments from too many people, causing a darth of comments on the list.  Comments on the list would be good even if they're just "I reviewed this before, LGTM"
259 2017-03-23T19:02:26  <jonasschnelli> Andreas S. concern about QRCode?
260 2017-03-23T19:02:44  <kanzure> who has reviewed bech32 by now?
261 2017-03-23T19:02:45  <btcdrak> ML post is here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013749.html
262 2017-03-23T19:03:03  <sipa> jonasschnelli: petertodd responded, by i can give some extra commemtd
263 2017-03-23T19:03:04  <petertodd> gmaxwell: along thsoe lines, I think making some of those 1:1 comments public might be helpful for new devs interested in learning how these processes work
264 2017-03-23T19:03:06  <sipa> *commemts
265 2017-03-23T19:03:10  <jonasschnelli> IMO QRCode have redundant parts while - as far as I understand bech32 – has also error correction.. seems a bit unefficient. Though QRCode are another layer I guess.
266 2017-03-23T19:03:47  <jonasschnelli> (need to read petertodd's response; wasn't aware(
267 2017-03-23T19:03:55  <gmaxwell> jonasschnelli: He suggested it use more characters but using anything non-alphanum makes it so double click copy doesn't work in browsers,  also being a non power-of-prime base makes strong error detection infesable, and at best could reduce the size by a couple percent.
268 2017-03-23T19:04:09  <gmaxwell> These points are all addressed in the document, I believe.
269 2017-03-23T19:04:29  <kanzure> tromp's MiXcAsE proposal was a joke right?
270 2017-03-23T19:04:43  <sipa> gmaxwell: base 43 is actually totally doable as it is a prime
271 2017-03-23T19:04:46  <petertodd> gmaxwell: there's a few things that the document doesn't mention as clearly as it could, like how non-alphanum poses barriers for non-english-speaking users
272 2017-03-23T19:04:50  <wumpus> jonasschnelli: I don't think the qr error detection/correction is strong enough for somthing as critical to get right as an address
273 2017-03-23T19:04:51  <gmaxwell> (in fact in an earlier revision we used - as a seperator but dropped it for click copy compatibility)
274 2017-03-23T19:04:51  <sipa> gmaxwell: but it requires bignum code to convert
275 2017-03-23T19:05:04  <jonasschnelli> wumpus: Yes. Agree.
276 2017-03-23T19:05:24  <sipa> petertodd: feel free to suggest better language :)
277 2017-03-23T19:05:29  <gmaxwell> wumpus: it would probably be fine if we only ever used QR codes.. but obviously that isn't possible.
278 2017-03-23T19:06:03  <petertodd> sipa: will do - also thanks for having such a great list of rationals already! really helpful to understand why something was chosen and what the tradeoffs are
279 2017-03-23T19:06:09  <gmaxwell> petertodd: yes, though really being num only be best for international support but the result is significantly bigger and slower to deal with. :(  I tried that out at one point.
280 2017-03-23T19:06:13  <wumpus> gmaxwell: a more compact format could be used with qr codes, in any case, if that's desirable. That doesn't affect this standard.
281 2017-03-23T19:06:21  <luke-jr> QR codes could hypothetically encode it in binary, but meh
282 2017-03-23T19:06:36  *** juscamarena has quit IRC
283 2017-03-23T19:06:43  <kanzure> rationale section was good, although i think it would be worthwhile to describe the 'exhaustive search'
284 2017-03-23T19:06:47  <kanzure> in public
285 2017-03-23T19:06:49  <wumpus> luke-jr: right.
286 2017-03-23T19:06:59  <gmaxwell> luke-jr: if we had a binary QR only format I assume it would intentionally begin with something like a null byte to make sure it doesn't get mangled by text channels.
287 2017-03-23T19:07:14  <petertodd> gmaxwell: yeah, we're fortunate that lots of non-english-speakers still known the alphabet; even english speakers often don't know the names of punctuation symbols, and those names are also not entirely canonical
288 2017-03-23T19:07:25  *** handlex has joined #bitcoin-core-dev
289 2017-03-23T19:07:40  *** Giszmo has joined #bitcoin-core-dev
290 2017-03-23T19:07:57  <jonasschnelli> It's probably not worth to design an additional binary addr standard for QrCodes. Maybe they are only temporary? Gone in 3-4 yrs?
291 2017-03-23T19:08:04  <gmaxwell> There were a lot of other rational things we trimmed from the document. One of pieter's concerns was that the length of the document would make it seem complicated (though the proposal is pretty simple.); feedback on reddit seemed to somewhat validate that.
292 2017-03-23T19:08:12  <petertodd> luke-jr: so by matchin QR code's special-case character set support, we end up with an encoding that at the low level is basically binary anyway
293 2017-03-23T19:08:35  <gmaxwell> jonasschnelli: I think that it's probably not worth it for that, but industry feedback would be nice.
294 2017-03-23T19:08:50  <gmaxwell> petertodd: thats a point, though the unfortuate thing is that it's exposed to mangling.
295 2017-03-23T19:09:04  <sipa> the alphanuneric mode is pretty efficient; only 10% extra compared to binary
296 2017-03-23T19:09:12  <sipa> it uses 5.5 bits per character
297 2017-03-23T19:09:16  <gmaxwell> e.g. QR decoder -> something that munges up the strings -> software -> coins in sppppaccccceeee.
298 2017-03-23T19:09:24  <sipa> so 5.5 bits per 5 bits of data is pretty goof
299 2017-03-23T19:09:26  <sipa> good
300 2017-03-23T19:09:34  <petertodd> jonasschnelli: I think the day Qr codes aren't heavily used will be the day bech32 is irrelevant anyway because people are all paying each other by very different means :)
301 2017-03-23T19:09:49  <jonasschnelli> probably... :)
302 2017-03-23T19:10:04  <sipa> while base58 uses 8 bits per 5.86 bits of data
303 2017-03-23T19:10:15  <gmaxwell> sipas point is more important, only a 10%-ish overhead in this format vs some binary QR code.
304 2017-03-23T19:10:50  <sipa> if you also drop the checksum, we get much larger savings of course
305 2017-03-23T19:11:13  <sipa> in practice you'd get a 25% reduction for p2wpkh
306 2017-03-23T19:11:23  <jonasschnelli> side note: could the Bech32 encoding also be used for private keys (== 32bit seeds)?
307 2017-03-23T19:11:29  <gmaxwell> true. but ugh. the some text handling path replaces a character.
308 2017-03-23T19:11:31  <sipa> jonasschnelli: good question!
309 2017-03-23T19:11:37  <wumpus> indeed, for base58 addresses there also never has been a binary standard for qr codes
310 2017-03-23T19:11:44  <sipa> jonasschnelli: we've been thinking about a stronger checksum for private keys
311 2017-03-23T19:11:45  <Anduck> QR codes iirc can work even if 30% of the code misread
312 2017-03-23T19:11:46  <wumpus> which would have saved a lot more
313 2017-03-23T19:12:03  <petertodd> jonasschnelli: yes - in fact I'm planning on using it for non-bitcoin applications too
314 2017-03-23T19:12:06  <sipa> possibly 12 checksum characters (which is the maximum doable with 64 bit arithmetic)
315 2017-03-23T19:12:24  <jonasschnelli> Yes. An alternative for bip39?
316 2017-03-23T19:12:42  <gmaxwell> For private keys additional error _correction_ is interesting, and additional overhead is not very consequential.
317 2017-03-23T19:12:43  *** juscamarena has joined #bitcoin-core-dev
318 2017-03-23T19:12:59  <sipa> bech32 can only correct 2 errors, but detect 4
319 2017-03-23T19:13:17  *** magicwund has quit IRC
320 2017-03-23T19:13:22  <sipa> for addresses you really only care about detection
321 2017-03-23T19:13:29  <sipa> but for private keys you want correction
322 2017-03-23T19:13:37  <wumpus> yes, quite a different use case
323 2017-03-23T19:13:45  <gmaxwell> So we've been working on that some in the background. So it would be a different spec but just very similar. (e.g. similar kind of 5 lines of code) for the 12 digit checksum or what not.
324 2017-03-23T19:13:58  <sipa> with a 12 character checksum, correcting 3 errors is trivial
325 2017-03-23T19:14:07  <jonasschnelli> current WIF can correct 0.
326 2017-03-23T19:14:15  <sipa> but perhaps we can find one that can correct 4
327 2017-03-23T19:14:20  <gmaxwell> kanzure: we left out a lot of technical manutia about the construction which is interesting but not really relevant to the spec.
328 2017-03-23T19:15:05  <wumpus> makes sense to keep the spec focused and minimal, that way people will more likely read it :) you could link to an additional description, or include it as appendix or such
329 2017-03-23T19:15:42  <sipa> earlier version explained finite field arithmetic and generator polynomials :)
330 2017-03-23T19:15:45  <petertodd> wumpus: maybe good to make it a spec + design document? put rational/etc. in the latter. IIRC SHA3 had a document like that, among others.
331 2017-03-23T19:15:58  <wumpus> petertodd: yes indeed
332 2017-03-23T19:16:05  <jonasschnelli> The question about the level of complexity: We should't care. Pieter's stuff tend to be complicated. But only because its great and though through well. Awesome work IMO!
333 2017-03-23T19:16:06  <jtimon> I haven't fully reviewed it, but I've had a fast read on several versions of the doc and asked questions to sipa
334 2017-03-23T19:16:42  <gmaxwell> Finding a 12-digit code that corrects 4 may take more computing power than we have with just the a hundred cores here... though sipa has done a lot to take that search from completely intractable to plausable. :)   I think this work is a lot lower priority though other things we could be working on (like utxo database refactors and tx compaction) ....
335 2017-03-23T19:17:27  <sipa> jonasschnelli: i think the result is actually surprisingly simple
336 2017-03-23T19:17:30  *** hejdjdusuabxb has joined #bitcoin-core-dev
337 2017-03-23T19:17:50  <sipa> (but i'm probably biased)
338 2017-03-23T19:17:52  <gmaxwell> In any case, review and comment please!
339 2017-03-23T19:17:59  <luke-jr> I think it's more important to *detect* errors, than to correct them
340 2017-03-23T19:18:07  <sipa> luke-jr: for addresses, absolutely
341 2017-03-23T19:18:19  <luke-jr> 4 seems a bit low in that regard
342 2017-03-23T19:18:51  <jonasschnelli> sipa: I think deeply understanding the specs takes a coupe of hours... and it's different to the current base58check. This may frighten off people... but that shouldn't be something that should affect the process of selecting the *next* addr encoding format IMO
343 2017-03-23T19:18:53  <gmaxwell> luke-jr: for private keys you can generate the resulting wallet and check against the blockchain.. so correcting can be very useful.
344 2017-03-23T19:18:53  <petertodd> luke-jr: what do you mean by "4" in the above?
345 2017-03-23T19:19:12  <luke-jr> [19:12:59] <sipa> bech32 can only correct 2 errors, but detect 4
346 2017-03-23T19:19:36  <gmaxwell> Well it is _guarenteed_ to detect 4 errors, more than 4 you have a 1:2^30 chance of detecting.
347 2017-03-23T19:19:56  <sipa> luke-jr: well it has a 99.9999999068% chance to detect more errors
348 2017-03-23T19:19:58  <luke-jr> if I carefully construct gibberish, I'd expect it to be rejected
349 2017-03-23T19:20:14  <luke-jr> sipa: ah, okay
350 2017-03-23T19:20:38  <petertodd> luke-jr: for this application, the threat is random mistakes, not malice - in the malice case someone could just replace the address anyway
351 2017-03-23T19:20:50  <gmaxwell> This graph shows the probablity of an error going undetected (y) as a function of how likely the user is to make mistakes (x):
352 2017-03-23T19:20:53  <gmaxwell> https://people.xiph.org/~greg/temp/bch-eff3.png
353 2017-03-23T19:21:08  <sipa> jonasschnelli: https://github.com/sipa/bech32/blob/master/ref/python/segwit_addr.py <- full encoder/decoder implementation
354 2017-03-23T19:21:13  <cfields> great work indeed. From what I remember from our discussions before, the work to derive the function was complex, but afterwards, implementing it is simple. Seems best-case to me :). Will review now that it's final.
355 2017-03-23T19:21:42  <jonasschnelli> sipa: 121 lines... yes. thats indeed very simple.
356 2017-03-23T19:21:50  <gmaxwell> As you can see, if the user's error rate is below 3.53 errors per address entered, this code has better protection than a 32bit hash (like base58 check uses).  And because of case modulation, users are MUCH less likely to make mistakes with this format.
357 2017-03-23T19:22:07  *** BashCo_ has joined #bitcoin-core-dev
358 2017-03-23T19:22:16  *** laurentmt has joined #bitcoin-core-dev
359 2017-03-23T19:22:37  *** magicwund has joined #bitcoin-core-dev
360 2017-03-23T19:22:38  <gmaxwell> If the user is unlikely to make errors, then the effective protection of this scheme tends to infinity.
361 2017-03-23T19:23:22  <gmaxwell> e.g. 0.1% chance of error per character and the probablity that an errored string goes undetected is 1:2^60.
362 2017-03-23T19:23:40  <sipa> enough on this topic, i guess
363 2017-03-23T19:24:10  <wumpus> other topics?
364 2017-03-23T19:24:18  <gmaxwell> jonasschnelli suggested the der wallet thing.
365 2017-03-23T19:24:30  <jonasschnelli> Yes. We still keep all priv keys DER encoded in BDB
366 2017-03-23T19:24:47  <jonasschnelli> I think we should bundle the next wallet db update with remvoing DER
367 2017-03-23T19:24:50  <gmaxwell> The compressed flag has no effect on our operation. We should always set it IMO... make the wallet sightly smaller. Its dumb that the data is stored at all.. it's not used.  But since it's there, better to make it small.
368 2017-03-23T19:24:57  *** BashCo has quit IRC
369 2017-03-23T19:25:04  <gmaxwell> if we make the format incompatible, sure.
370 2017-03-23T19:25:29  <jonasschnelli> Reading DER (old versions) must be supported. But new wallets should store in plain.
371 2017-03-23T19:25:33  <wumpus> #topic DER privkeys in wallet
372 2017-03-23T19:25:33  <gmaxwell> Why are we even storing seralized private keys when BIP32 is in use?
373 2017-03-23T19:25:41  <jonasschnelli> Yes.
374 2017-03-23T19:25:44  <jonasschnelli> Importprivkey
375 2017-03-23T19:25:48  <jonasschnelli> and old wallets
376 2017-03-23T19:26:00  <jonasschnelli> But I think HD wallets should only have a single privkey (the HD seed)
377 2017-03-23T19:26:02  <gmaxwell> okay, for that, sure. But I agree, fine to not use DER private keys for that.
378 2017-03-23T19:26:22  <jonasschnelli> Also the seed key is also DER right now. :/
379 2017-03-23T19:26:27  <gmaxwell> but otherwise there shouldn't be seralized private keys. Pubkeys yes. :)
380 2017-03-23T19:26:37  <gmaxwell> wut
381 2017-03-23T19:26:52  <jonasschnelli> Yes. Ideally it should be... and I think we are working in this direction...
382 2017-03-23T19:26:55  <wumpus> didn't we have an issue related to this?
383 2017-03-23T19:26:56  <gmaxwell> okay well, whatever, there is only one there. We could encode it as cat pictures for all I care.
384 2017-03-23T19:26:56  <phantomcircuit> yeah it's saved using the same format as other private keys
385 2017-03-23T19:27:26  <gmaxwell> wumpus: there is an issue open over the compressed flag, though its inconsequential.
386 2017-03-23T19:27:31  <jonasschnelli> wumpus: Yes. https://github.com/bitcoin/bitcoin/issues/10041
387 2017-03-23T19:27:38  <wumpus> gmaxwell: ok
388 2017-03-23T19:27:44  <jonasschnelli> and a fix: https://github.com/bitcoin/bitcoin/pull/10043
389 2017-03-23T19:27:56  <wumpus> I wasn't aware it was inconsequential
390 2017-03-23T19:27:58  <gmaxwell> I think that to the extent that we continue to write those keys (e.g. for old wallets) that we should always use the compressed flag.
391 2017-03-23T19:28:00  * luke-jr ponders if importprivkey should be rejected for HD wallets
392 2017-03-23T19:28:02  <wumpus> did anyone reply that to the issue?
393 2017-03-23T19:28:03  <jonasschnelli> Though,... as long as nobody reads BDB from the outside it shoudn't matter
394 2017-03-23T19:28:07  <gmaxwell> wumpus: we decided compressed/uncompressed from the pubkey.
395 2017-03-23T19:28:24  <gmaxwell> wumpus: the public key inside the der private key does nothing.
396 2017-03-23T19:28:25  <wumpus> luke-jr: would be nice to keep HD wallets 'pure'
397 2017-03-23T19:28:34  <wumpus> luke-jr: at the least it should throw a warning
398 2017-03-23T19:28:51  <wumpus> gmaxwell: weird :)
399 2017-03-23T19:28:52  <jonasschnelli> luke-jr: Yes. We should reject... in that case
400 2017-03-23T19:28:55  <luke-jr> if we could do warnings, importprivkey should always throw a warning anyway :p
401 2017-03-23T19:29:02  <gmaxwell> Background: The DER private key format includes the public key, along with all the ECC group parameters, and other overheads all packed in hundreds of bytes of ASN1 parsing hell.
402 2017-03-23T19:29:14  <jonasschnelli> wumpus: Yes. It wired... better DER is gone sooner then later
403 2017-03-23T19:29:29  <jonasschnelli> It would be another thing that will make future devs stumbel
404 2017-03-23T19:29:34  <wumpus> agreed
405 2017-03-23T19:29:49  <wumpus> so if there is a backwards-incompatible wallet change, that could be included, I guess
406 2017-03-23T19:29:54  <gmaxwell> Turns out we were trying to tell the der private key to use compressed or not on the basis of the key using compressed or not...  but the code was wrong. But it doesn't matter because we never did anything with the private key embedded public key.
407 2017-03-23T19:30:12  <jonasschnelli> wumpus: Yes. The hd chain split...
408 2017-03-23T19:30:23  <jonasschnelli> (which we hopefully can merge soon)
409 2017-03-23T19:30:28  <wumpus> jonasschnelli: right
410 2017-03-23T19:30:55  <jonasschnelli> I think we would have enought time post hd split merge to remove DER for 0.14
411 2017-03-23T19:31:00  <gmaxwell> we should stage up several incompatible changes to make at once, the multitude of versions is a support burden. Changing the private key formats would be one of them.
412 2017-03-23T19:31:09  <luke-jr> jonasschnelli: 0.14 is gone; you mean 0.15?
413 2017-03-23T19:31:13  <BlueMatt> 15
414 2017-03-23T19:31:22  <jonasschnelli> Ergh.. yes.
415 2017-03-23T19:32:13  <jonasschnelli> Do we expect that the wallet db handles error correction or should we directly switch to something like Bech32 for our internal privkey serialisation?
416 2017-03-23T19:32:19  <BlueMatt> gmaxwell: the code looks the same either way? wallet version 14990 14991 14992 can all be in the same release, whatever...code is still wallet.AmUpgradedTo(THING)
417 2017-03-23T19:32:54  <gmaxwell> in our code but not necessarily in other tools.
418 2017-03-23T19:33:00  <gmaxwell> also we have to worry about interactions.
419 2017-03-23T19:33:27  <BlueMatt> fair
420 2017-03-23T19:33:37  <wumpus> the wallet db has no error correction
421 2017-03-23T19:33:38  <BlueMatt> gmaxwell: to be clear, are you suggesting they all happen in one wallet version, or in one release?
422 2017-03-23T19:33:55  <BlueMatt> (I mean we dont support wallet versions from mid-release, but it'd be really annoying...)
423 2017-03-23T19:34:02  <jonasschnelli> wumpus: I think this would/should be very desirable
424 2017-03-23T19:34:04  <wumpus> (berkeleydb doesn't and neither does leveldb, the latter only has detection)
425 2017-03-23T19:34:15  <wumpus> jonasschnelli: yes, encoding privkeys in a resilient format makes sense
426 2017-03-23T19:34:20  <wumpus> jonasschnelli: though doesn't encryption break that?
427 2017-03-23T19:34:30  <wumpus> jonasschnelli: the error correction should be around the encryption, not inside it
428 2017-03-23T19:34:41  <wumpus> otherwise one bit change will  completely mangle it anyway
429 2017-03-23T19:34:44  <gmaxwell> BlueMatt: preferable to be one version, but certantly one release. I don't know that we really don't support midrelease wallets. "sorry dude, your funds are gone, you made the mistake of helping us test." :P  there are degrees of non-support.
430 2017-03-23T19:34:48  <luke-jr> we have never broken wallet versions from mid-release AFAIK
431 2017-03-23T19:34:50  <jonasschnelli> wumpus: good point
432 2017-03-23T19:35:18  <gmaxwell> bech32 is not helpful for the kinds of errors we would find on disk.. you'll usually lose a whole sector at a time.
433 2017-03-23T19:35:24  <wumpus> eh, wallets from mid-release should not suddenly break in later updates
434 2017-03-23T19:35:45  <jonasschnelli> There is also a PR i'd like to bundle with chain-split/rm DER that would detatch the client version from the wallet version/migration handling (PR is called "wallet flags" or similar)
435 2017-03-23T19:35:48  <gmaxwell> To make a wallet database master key error robust you should just repeat it across multiple disk sectors. :P
436 2017-03-23T19:36:01  <wumpus> gmaxwell: I've seen single bit errors happen on disk too, though usually due to bus errors
437 2017-03-23T19:36:28  <gmaxwell> wumpus: yea, but not as common. And it would be fine to have a wallet format with a 4kb master key. .. but I think thats stuff to think about for the post BDB world.
438 2017-03-23T19:36:30  <petertodd> wumpus: repeating across multiple disk errors fixes that too :)
439 2017-03-23T19:36:33  <wumpus> but some of the corrupted block files I"ve analyzed certainly had single bit errors
440 2017-03-23T19:36:47  <gmaxwell> sorry I stated it too strongly.
441 2017-03-23T19:37:18  <wumpus> in any case - for HD wallets we need to store way less private keys
442 2017-03-23T19:37:22  <wumpus> so blowing up the master key to 4kb is fine
443 2017-03-23T19:37:32  <gmaxwell> ya, t'was my intended point. :)
444 2017-03-23T19:37:35  <wumpus> if that helps protect against various kinds of corruption
445 2017-03-23T19:37:40  <BlueMatt> gmaxwell: ok, so multiple version numbers, but external tools only need support them as a group and -walletupgrade only supports them as a group?
446 2017-03-23T19:38:16  <sipa> the wallet flags idea removes that release/walletversion inconsistency completely
447 2017-03-23T19:38:16  <gmaxwell> BlueMatt: I think that would be okay but why multiple versions? add the code with the features, then a patch that turns all of them on with a single version.
448 2017-03-23T19:38:18  *** handlex has quit IRC
449 2017-03-23T19:38:52  <sipa> gmaxwell: that's very hard for testing
450 2017-03-23T19:39:16  <sipa> as you'd need to be able to override the min version in tests to be able to even observe the feature
451 2017-03-23T19:39:19  <BlueMatt> yea, was just thinking easier for review burden, but I suppose thats fine too
452 2017-03-23T19:39:35  <BlueMatt> sipa: not so hard to have an extra commit in a pr that doesnt get merged
453 2017-03-23T19:39:44  <sipa> BlueMatt: ugh
454 2017-03-23T19:39:48  <gmaxwell> we just create support hurdles for ourselves supporting mixed features. "oh this change brakes bob's wallet because he had a mid-release version that had X and not Y"
455 2017-03-23T19:39:54  <sipa> code in master should be testable
456 2017-03-23T19:40:19  <sipa> wallet flags does not necessarily imply supporting mixed features
457 2017-03-23T19:40:41  <gmaxwell> As long as it doesn't then I don't mind.
458 2017-03-23T19:40:56  <gmaxwell> Just please lets not dribble in three different incompatible versions during a release cycle.
459 2017-03-23T19:41:03  <BlueMatt> jonasschnelli: detaching client version, fine, but would strongly prefer a serially increasing version number and not flags
460 2017-03-23T19:41:06  <gmaxwell> and end up with people with weird wallets that will break later.
461 2017-03-23T19:41:24  <sipa> we could also detach walletversion from client version
462 2017-03-23T19:41:32  <sipa> that would accomplish the same thing
463 2017-03-23T19:41:38  <BlueMatt> yea, that ^
464 2017-03-23T19:41:41  <gmaxwell> unless we're going to add tests for all the possible variations we shouldn't let people running master encounter them unawares.
465 2017-03-23T19:41:46  <sipa> and just increment the wallet version when a new feature is added
466 2017-03-23T19:41:52  <BlueMatt> wasnt sipa magic number picker for a while? can we just go back to that
467 2017-03-23T19:42:12  <BlueMatt> or jonasschnelli, since he owns wallet these days, mostly
468 2017-03-23T19:42:21  <gmaxwell> for testing you should just be able to set a commandline paramter that turns on future versions/features.
469 2017-03-23T19:42:51  <gmaxwell> e.g. default wallet created is version X  but there is code for version Y (or flag Y) and you can ask for it for testing, but until its the default its unstable and all bets are off.
470 2017-03-23T19:43:13  <jonasschnelli> Need to think about it. Flags seems to be good anyways (supports HD, watch only,...) but most not be linked to the wallet database version.. hmm..
471 2017-03-23T19:43:25  <gmaxwell> I don't care if we retain compatiblity for a wallet someone created by running bitcoind with --force-wallet-screw-me-over-now-now-now
472 2017-03-23T19:43:28  <jonasschnelli> s/most/must
473 2017-03-23T19:43:43  *** pindarhk has quit IRC
474 2017-03-23T19:44:06  <BlueMatt> jonasschnelli: flags just makes things more complicated to support (interactions, yuck), and I'm not sure we have a compelling use-case for turning on some stuff but not others, aside from "I want my wallet to work all the way back to version 0.X"
475 2017-03-23T19:44:07  *** pindarhk has joined #bitcoin-core-dev
476 2017-03-23T19:44:11  <gmaxwell> And I'm fine with flags too, of course, but not with supporting arbritary combinations. (unless someone really wants to build extensive automated testing for all the combinations)
477 2017-03-23T19:44:37  <luke-jr> BlueMatt: Core isn't the only compatible wallet.
478 2017-03-23T19:44:47  <gmaxwell> e.g. basically a version implies flags... and you use flags in the code, and that doesn't mean that all combinations of flags get tested.
479 2017-03-23T19:45:13  <BlueMatt> luke-jr: all other wallets that read our wallet format are unsupported, I believe (and, hell, probably easier for them if we dont have flags with interactions...)
480 2017-03-23T19:45:15  <jtimon> right, you can have flags and maybe even have debug option for experimental wallet features that we can remove in releases (or just not leave any wallet feature that doesn't have a version yet)
481 2017-03-23T19:45:22  <jonasschnelli> Flags would allow flexible backporting? But I think we don't want to do this.
482 2017-03-23T19:45:35  <jtimon> or just an extra commit that doesn't get merged like BlueMatt says
483 2017-03-23T19:45:40  <luke-jr> BlueMatt: you're rather aggressive with "unsupported" IMO
484 2017-03-23T19:45:42  <wumpus> we never backport wallet features
485 2017-03-23T19:45:54  <gmaxwell> luke-jr: Our _binary_ wallet format isn't intended to be interoperable. If it is, great! but without a spec and a moving target, it isn't something we can guaretee.  To begin with there would need to be an extensive all features all flags test suite... and I think it would be a waste of time to construct that for this format (esp since we're never going to specify BDB itself).
486 2017-03-23T19:45:57  <BlueMatt> luke-jr: we have limited resources, but, fair point
487 2017-03-23T19:46:11  <wumpus> yes, the database formats are not an external interface
488 2017-03-23T19:46:58  <wumpus> we reserve the right to change them completely from one release to another without advance notice, though that will usually not happen
489 2017-03-23T19:47:05  <gmaxwell> I don't know if wallet format compatiblity is a reasonable goal in general, at least not this year-- just because it's so integrally tied to the functionality.
490 2017-03-23T19:47:27  <wumpus> older wallets should *always* work
491 2017-03-23T19:47:34  <wumpus> that's the only guarantee
492 2017-03-23T19:47:36  <gmaxwell> but obviously we don't want to create unnecessary incompatiblity.
493 2017-03-23T19:47:43  <gmaxwell> right.
494 2017-03-23T19:47:51  <gmaxwell> okay, is this horse dead yet?
495 2017-03-23T19:47:55  <wumpus> yes
496 2017-03-23T19:47:57  <jonasschnelli> yes
497 2017-03-23T19:47:59  <wumpus> other topics?
498 2017-03-23T19:48:07  <sipa> lunch?
499 2017-03-23T19:48:11  <gmaxwell> I'd like to know if people might be willing to sign onto a statement like this:
500 2017-03-23T19:48:12  <luke-jr> wallet format changes move slowly. I try to avoid backporting pending PRs to Knots now, but IMO once they get merged they should be fair.
501 2017-03-23T19:48:15  <gmaxwell> https://0bin.net/paste/vSuqwACPe8WzpCnI#4katsiFvmtzK85e8eNgNVuElwD8kTbjPVuQnkontSyF
502 2017-03-23T19:48:17  <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
503 2017-03-23T19:48:29  <jtimon> sorry, "--force-wallet-screw-me-over-now-now-now" is exactly what I meant
504 2017-03-23T19:48:32  <petertodd> gmaxwell: ACK
505 2017-03-23T19:48:32  * BlueMatt proposes we have a weekly call for "what pr are you blocked on and want review on", though we've had mixed results when I've done that before
506 2017-03-23T19:48:36  <gmaxwell> (gee thanks for the link gribble)
507 2017-03-23T19:49:06  <wumpus> #topic statement against running closed source node code
508 2017-03-23T19:49:16  <kanzure> "If it ever does, you may safely assume that the actual contributors to the project are locked in a basement somewhere. In that case, please send help." and food
509 2017-03-23T19:49:21  <luke-jr> gmaxwell: I haven't thought about it sufficiently to be certain about "never"
510 2017-03-23T19:49:23  <wumpus> gmaxwell: ACK
511 2017-03-23T19:49:30  <petertodd> gmaxwell: though I think the statement should be a little more clear on what the risks are - this is money so such a binary may very well be an attempt to steal your coins
512 2017-03-23T19:49:51  <wumpus> or may have hidden vulnerabilities, bugdoors and backdoors
513 2017-03-23T19:50:01  <BlueMatt> gmaxwell: seems reasonable
514 2017-03-23T19:50:04  <jtimon> BlueMatt: the original flags can be replaced with the version flag once you have a version for a set of them
515 2017-03-23T19:50:07  <kanzure> yep seems good to me
516 2017-03-23T19:50:20  <gmaxwell> luke-jr: I think I have, plus 1001 other open source packages have. As I point out in the document even if all other options fail, "shut off" remains an option too.
517 2017-03-23T19:50:27  <jonasschnelli> Yes. A statement would be good. Also.. github.binaries with a SHA256 on reddit is _not_ want you want for a such ecosystem
518 2017-03-23T19:50:31  <luke-jr> true
519 2017-03-23T19:50:41  <petertodd> wumpus: see, I think it's good to say in such a statement "hidden vulnerabilities, bugdoors and backdoors" and *also* give a 100% concrete example for the non-devs reading it
520 2017-03-23T19:50:41  <jtimon> I mean, you can have a single fWalletForNextVersionExperimental flag
521 2017-03-23T19:50:42  <gmaxwell> okay well I would welcome revisions. I didn't want to make it long and explaining all the options and risks.
522 2017-03-23T19:50:58  <gmaxwell> Just saying "don't run these things if 'we' do" is protective to both the users and us.
523 2017-03-23T19:51:04  <wumpus> we have this stringent gitian process which costs quite a lot of time, maybe we should put more focus on it...
524 2017-03-23T19:51:34  <gmaxwell> In any earlier draft I had listed out some of the options we have (and have used before) and it was 3x longer than this just explining a couple of them. :)
525 2017-03-23T19:51:45  <kanzure> also, submitting source code "later" is not acceptable either
526 2017-03-23T19:51:47  <achow101> the statement should say "Bitcoin Core project", not "Bitcoin project" IMO
527 2017-03-23T19:51:52  <wumpus> I sometimes have the feeling we're doing all this auditability for nothing if people are ready to just download random crap binaries of the internet and run them, though I guess some do validate it...
528 2017-03-23T19:52:07  <gmaxwell> wumpus: well we know not everyone does that.
529 2017-03-23T19:52:19  <sipa> wumpus: i think it's a slow process... the best we can do is talk about it, and highlight what we're doing
530 2017-03-23T19:52:37  <sipa> and just the increase in number of gitian builders on itself is a good sign
531 2017-03-23T19:52:40  <kanzure> mentioning bugdoors, backdoors and other malware is important
532 2017-03-23T19:52:46  <sipa> (reminds me, i need to build 0.14...)
533 2017-03-23T19:53:05  <petertodd> wumpus: I know for a fact that many high-value users do verify PGP signatures and the like, e.g. exchanges and custodians. That effort isn't wasted.
534 2017-03-23T19:53:07  <gmaxwell> okay, well I can work with some people on some language twiddling. Sounds like a couple people are interested.
535 2017-03-23T19:53:20  <wumpus> I guess the important thing is that some people do validate it, and can raise a stink if things don't match, which is not possible with random crap executables
536 2017-03-23T19:53:28  <wumpus> petertodd: right.
537 2017-03-23T19:53:29  <gmaxwell> and luke-jr if you want to talk later and have me convince you that we'd would never in the future do a binary release, I'd be happy to.
538 2017-03-23T19:53:39  <BlueMatt> one of these days I'm gonna finally convince cfields to finish his "trusting trust" compiler-builder for use in gitian, then I'll be much louder...the trusting-ubuntu part of gitian is...irritating at best (but still infinitely better than the alternative)
539 2017-03-23T19:53:48  <gmaxwell> (_NEVER_ I mean, in the strongest sense, I'm sure you already are convinced that almost never would hold)
540 2017-03-23T19:54:09  <luke-jr> yeah, I certainly can't think of any circumstances that would ever justify it.
541 2017-03-23T19:54:42  <cfields> BlueMatt: yea, that's a goal of mine for 0.15.
542 2017-03-23T19:54:43  <petertodd> gmaxwell: I like that you explicitly mentioned in that doc that interruption of service is perferable
543 2017-03-23T19:54:54  <BlueMatt> cfields: yippee
544 2017-03-23T19:55:02  <BlueMatt> topic?
545 2017-03-23T19:55:11  * BlueMatt proposes we have a weekly call for "what pr are you blocked on and want review on", though we've had mixed results when I've done that before
546 2017-03-23T19:55:26  <gmaxwell> petertodd: well I tested some of this explination on reddit while talking to people 1:1 about some things. so I have an idea of what needs to be explained.
547 2017-03-23T19:55:34  <jtimon> gmaxwell: I would prefer if we mentioned free software explicitly or even replace open source with free software, but I agree with everything said in that statement
548 2017-03-23T19:55:36  <sipa> BlueMatt: sounds good to me
549 2017-03-23T19:55:43  <sipa> BlueMatt: everyone gets to list 1 PR?
550 2017-03-23T19:55:49  <BlueMatt> sipa: sure
551 2017-03-23T19:55:51  <jonasschnelli> Maybe two? :)
552 2017-03-23T19:55:58  <BlueMatt> mine is 9725
553 2017-03-23T19:56:02  <gmaxwell> jtimon: ack. Thanks for the feedback I'll revise some and consult with others that had comments.
554 2017-03-23T19:56:06  <jonasschnelli> #9725
555 2017-03-23T19:56:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
556 2017-03-23T19:56:11  <wumpus> so jonasschnelli's wallet chain split seems important
557 2017-03-23T19:56:21  <jonasschnelli> yes. please. #9294
558 2017-03-23T19:56:25  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
559 2017-03-23T19:56:26  <kanzure> on that last topic, uh, maybe wee should point out that backdoors have been found in node software already (ahem some exchanges come to mind..).
560 2017-03-23T19:56:33  <BlueMatt> list from last week was #8694, 9294, 9725 and #7729
561 2017-03-23T19:56:35  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
562 2017-03-23T19:56:39  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
563 2017-03-23T19:57:06  <BlueMatt> any additions/replacements or should we let the list stand?
564 2017-03-23T19:57:47  <gmaxwell> #9959 could probably take some more reviews.
565 2017-03-23T19:57:48  <wumpus> I'd also really like to have feedback on my patches to add UNIX sockets support at some point (#9979,  #9919) though it's not really urgent
566 2017-03-23T19:57:49  <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
567 2017-03-23T19:57:50  <gribble> https://github.com/bitcoin/bitcoin/issues/9979 | p2p: Bare minimum to support UNIX sockets by laanwj · Pull Request #9979 · bitcoin/bitcoin · GitHub
568 2017-03-23T19:57:52  <gribble> https://github.com/bitcoin/bitcoin/issues/9919 | UNIX sockets support for RPC by laanwj · Pull Request #9919 · bitcoin/bitcoin · GitHub
569 2017-03-23T19:58:05  <gmaxwell> (suhas doesn't appear to be here now, so I thought I'd mention it)
570 2017-03-23T19:58:07  * jtimon reminds to build 0.14
571 2017-03-23T19:58:30  <luke-jr> I still have to look over BlueMatt's review on multiwallet, so I'll refrain from listing one this time ;)
572 2017-03-23T19:58:34  <gmaxwell> wumpus: Those are a great idea. I will be trying them out. Did we find out if your patch to libevent is going to make it upstream?
573 2017-03-23T19:58:35  <cfields> wumpus: ah, i hadn't seen the p2p one
574 2017-03-23T19:58:40  <jonasschnelli> Can we keep the most important 1PR list on github somehow? A project?
575 2017-03-23T19:58:57  <sipa> jonasschnelli: sounds good to me
576 2017-03-23T19:59:02  <jonasschnelli> I think this would be great because priorizing reviews is hard right now
577 2017-03-23T19:59:10  <wumpus> gmaxwell: still haven't heard about that one, but I don't think it should matter for getting these patches in
578 2017-03-23T19:59:11  <sipa> a PR can belong to multiple projects, right?
579 2017-03-23T19:59:21  <gmaxwell> keep in mind to prioritize things that we would want in a 0.14.1.
580 2017-03-23T19:59:23  <wumpus> sipa: AFAIK yes
581 2017-03-23T19:59:26  <jonasschnelli> hopefully
582 2017-03-23T19:59:29  <luke-jr> PR labels seems workable for that too
583 2017-03-23T19:59:37  <wumpus> we already have so many labels
584 2017-03-23T19:59:39  <luke-jr> "Top Priority" or somethign perhaps
585 2017-03-23T19:59:48  <luke-jr> wumpus: but labels are easy to filter :D
586 2017-03-23T19:59:59  <wumpus> also I use those to classify pulls for the release notes, so I'd prefer not to use them for non-categoritical things
587 2017-03-23T20:00:04  <jonasschnelli> Project seems to be the better choice...
588 2017-03-23T20:00:07  <wumpus> yes
589 2017-03-23T20:00:12  <gmaxwell> "author:wumpus" (since he does most of the merging any of his PRs are effectively 1-reviewer disadvantaged for getting in)
590 2017-03-23T20:00:17  <sipa> DONG
591 2017-03-23T20:00:29  <wumpus> #endmeeting
592 2017-03-23T20:00:29  <lightningbot> Meeting ended Thu Mar 23 20:00:29 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
593 2017-03-23T20:00:29  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.html
594 2017-03-23T20:00:29  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.txt
595 2017-03-23T20:00:29  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-23-19.00.log.html
596 2017-03-23T20:00:31  <gmaxwell> Okay, I think its time to feed sipa.
597 2017-03-23T20:00:35  <luke-jr> lol
598 2017-03-23T20:00:38  <jonasschnelli> hehe
599 2017-03-23T20:00:51  <jtimon> I've been waiting on #8855 (previously #6907 previously part of other prs) for so long...
600 2017-03-23T20:00:52  <sipa> must... not... chew PRs
601 2017-03-23T20:00:53  <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
602 2017-03-23T20:00:53  <kanzure> programmer chow is other programmers
603 2017-03-23T20:00:55  <gribble> https://github.com/bitcoin/bitcoin/issues/6907 | Chainparams: Use a regular factory for creating chainparams by jtimon · Pull Request #6907 · bitcoin/bitcoin · GitHub
604 2017-03-23T20:00:57  * jonasschnelli will be in SF in September.
605 2017-03-23T20:00:58  <luke-jr> when did we agree on a 1 hour limit to meetings anyway? IIRC there was only a set start time.. maybe they should go for 24 hours? :p
606 2017-03-23T20:01:02  <sipa> jonasschnelli: cool!
607 2017-03-23T20:01:12  <gmaxwell> luke-jr: because without a limit some people would starve.
608 2017-03-23T20:01:17  <sipa> jonasschnelli: i may be in switzerland next month
609 2017-03-23T20:01:21  <kanzure> luke-jr: maybe it should be based on time until 6 blocks
610 2017-03-23T20:01:31  <jonasschnelli> sipa: If you are,... tell me and let's hand out.
611 2017-03-23T20:01:33  <luke-jr> gmaxwell: am I the only one who eats during meetings sometimes?
612 2017-03-23T20:01:40  <luke-jr> kanzure: hehe
613 2017-03-23T20:01:45  <jtimon> another old one with several previous attempts is #8498 but I guess that's my fault for saying "Optimization" without doing benchmarks...
614 2017-03-23T20:01:45  <jonasschnelli> s/hand/hang
615 2017-03-23T20:01:48  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
616 2017-03-23T20:02:46  *** dcousens has joined #bitcoin-core-dev
617 2017-03-23T20:02:55  <BlueMatt> we always have office space available for those who want a stopover between .eu and sf :P
618 2017-03-23T20:03:04  <BlueMatt> and we have good flights :)
619 2017-03-23T20:04:04  <luke-jr> does SF<->EU go that direction?
620 2017-03-23T20:04:34  <jonasschnelli> BlueMatt: Ah.. man. I fly to SF over Iceland!
621 2017-03-23T20:04:41  <jtimon> I suspect #9608 will also be open for ages, but at least that will force me to read every change in ProcessMessage...
622 2017-03-23T20:04:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9608 | Net: Divide ProcessMessage in smaller functions by jtimon · Pull Request #9608 · bitcoin/bitcoin · GitHub
623 2017-03-23T20:04:56  <BlueMatt> jtimon: we said you get to pick one :P
624 2017-03-23T20:05:24  *** BashCo_ has quit IRC
625 2017-03-23T20:05:59  <sipa> jonasschnelli: cool, wowair?
626 2017-03-23T20:06:00  <cfields> jtimon: I'll chime in on that one.
627 2017-03-23T20:06:18  <jtimon> just like #8329 and #8337 force me to review every change in certain functions
628 2017-03-23T20:06:19  <jonasschnelli> sipa: Yes. :|
629 2017-03-23T20:06:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8329 | Consensus: MOVEONLY: Move functions for tx verification by jtimon · Pull Request #8329 · bitcoin/bitcoin · GitHub
630 2017-03-23T20:06:23  <gribble> https://github.com/bitcoin/bitcoin/issues/8337 | Consensus: MOVEONLY: Move functions for header verification by jtimon · Pull Request #8337 · bitcoin/bitcoin · GitHub
631 2017-03-23T20:07:11  <jtimon> BlueMatt: if only one, then #8855, actually it doesn't need rebase but I'll just do it in case there's new uses of Params(std::string)
632 2017-03-23T20:07:13  <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
633 2017-03-23T20:15:06  *** hejdjdusuabxb has quit IRC
634 2017-03-23T20:16:06  *** talmai has quit IRC
635 2017-03-23T20:16:21  <jtimon> cfields: cool thanks, rebased, no new uses of Params(std::string)
636 2017-03-23T20:19:34  *** cryptapus has quit IRC
637 2017-03-23T20:21:18  *** laurentmt has quit IRC
638 2017-03-23T20:26:22  <jtimon> gmaxwell: is there anything planned for 0.14.1 ?
639 2017-03-23T20:27:04  *** BashCo has joined #bitcoin-core-dev
640 2017-03-23T20:27:06  <sipa> bug fixes
641 2017-03-23T20:28:50  *** GoldSlash__ has joined #bitcoin-core-dev
642 2017-03-23T20:29:36  *** GoldSlash has quit IRC
643 2017-03-23T20:33:34  *** moli_ has quit IRC
644 2017-03-23T20:35:01  <bitcoin-git> [bitcoin] jtimon closed pull request #9845: RPC: cleanups in rpc/server (master...0.15-extern-rpc-server) https://github.com/bitcoin/bitcoin/pull/9845
645 2017-03-23T20:38:17  *** Sosumi has quit IRC
646 2017-03-23T20:40:16  *** adiabat has joined #bitcoin-core-dev
647 2017-03-23T20:40:17  *** moli_ has joined #bitcoin-core-dev
648 2017-03-23T20:40:45  *** moli_ has quit IRC
649 2017-03-23T20:41:07  *** moli_ has joined #bitcoin-core-dev
650 2017-03-23T20:49:18  *** juscamarena has quit IRC
651 2017-03-23T20:53:46  *** Giszmo has quit IRC
652 2017-03-23T21:05:00  *** magicwund has quit IRC
653 2017-03-23T21:07:49  <BlueMatt> wumpus: were we gonna label peoples' review-picks as "blocking someone" or should i just put up a list somewhere
654 2017-03-23T21:08:10  *** Giszmo has joined #bitcoin-core-dev
655 2017-03-23T21:09:19  <gmaxwell> jtimon: there are a number of fixes already merged.
656 2017-03-23T21:09:38  <jtimon> I see
657 2017-03-23T21:09:46  <gmaxwell> jtimon: I'd like to see one ship in the not far future.  I'm kinda surprised how few bugs we've had with 0.14.0
658 2017-03-23T21:10:48  <BlueMatt> I believe the list was me: 9725
659 2017-03-23T21:10:49  <BlueMatt> jonas: 9294
660 2017-03-23T21:10:49  <BlueMatt> wlad: 7729 (+9979, 9919, though not blocking per se)
661 2017-03-23T21:10:49  <BlueMatt> suhas: 9959
662 2017-03-23T21:10:49  <BlueMatt> jorge: 8855
663 2017-03-23T21:11:42  <jtimon> I think it had to do with delaying forking the 0.14 branch, or perhaps I just want to think that
664 2017-03-23T21:12:03  <jtimon> BlueMatt: thanks, that's cool, perhaps we can do that at the end of every meeting
665 2017-03-23T21:12:22  <BlueMatt> jtimon: that was my plan
666 2017-03-23T21:12:32  <jtimon> well ack your plan then
667 2017-03-23T21:13:19  <BlueMatt> though I think jonasschnelli has things to respond to from my review on 9294
668 2017-03-23T21:13:37  <jtimon> that will save me "review begging" comments
669 2017-03-23T21:16:07  <BlueMatt> oh, and I'll go ahead and add alex as 9942, because iirc he has a few things based on that too
670 2017-03-23T22:06:04  *** rockhouse has quit IRC
671 2017-03-23T22:06:04  *** rockhouse has joined #bitcoin-core-dev
672 2017-03-23T22:55:53  <kanzure> testnet bug report (maybe) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013765.html
673 2017-03-23T22:57:05  <sipa> segwit nodes don't download blocks from non-segwit nodes, by design
674 2017-03-23T23:01:22  *** Guyver2 has quit IRC
675 2017-03-23T23:30:29  <gmaxwell> *when segwit is active.
676 2017-03-23T23:36:29  *** voyager_ has quit IRC
677 2017-03-23T23:37:06  *** voyager_ has joined #bitcoin-core-dev
678 2017-03-23T23:42:49  <bitcoin-git> [bitcoin] tjps opened pull request #10067: [trivial] Dead code removal (master...tjps_dead_code) https://github.com/bitcoin/bitcoin/pull/10067