1 2019-04-18T00:18:39  *** fanquake has quit IRC
  2 2019-04-18T00:50:15  *** millerti has quit IRC
  3 2019-04-18T00:54:29  *** Jackielove4u_ has joined #bitcoin-core-dev
  4 2019-04-18T00:55:10  *** Liliaceae_ has joined #bitcoin-core-dev
  5 2019-04-18T00:55:13  *** Varunram_ has joined #bitcoin-core-dev
  6 2019-04-18T00:55:31  *** michagogo_ has joined #bitcoin-core-dev
  7 2019-04-18T00:57:20  *** gmaxwell_ has joined #bitcoin-core-dev
  8 2019-04-18T00:57:30  *** commavir_ has joined #bitcoin-core-dev
  9 2019-04-18T00:57:33  *** omonk_ has joined #bitcoin-core-dev
 10 2019-04-18T00:57:33  *** windsok_ has joined #bitcoin-core-dev
 11 2019-04-18T01:00:57  *** jonasschnelli_ has joined #bitcoin-core-dev
 12 2019-04-18T01:02:40  *** Jackielove4u has quit IRC
 13 2019-04-18T01:02:40  *** omonk has quit IRC
 14 2019-04-18T01:02:40  *** Varunram has quit IRC
 15 2019-04-18T01:02:40  *** michagogo has quit IRC
 16 2019-04-18T01:02:40  *** Liliaceae has quit IRC
 17 2019-04-18T01:02:40  *** windsok has quit IRC
 18 2019-04-18T01:02:40  *** commavir has quit IRC
 19 2019-04-18T01:02:40  *** jonasschnelli has quit IRC
 20 2019-04-18T01:02:40  *** gmaxwell has quit IRC
 21 2019-04-18T01:02:44  *** commavir_ is now known as commavir
 22 2019-04-18T01:02:44  *** Jackielove4u_ is now known as Jackielove4u
 23 2019-04-18T01:02:44  *** Varunram_ is now known as Varunram
 24 2019-04-18T01:02:44  *** Liliaceae_ is now known as Liliaceae
 25 2019-04-18T01:07:33  <luke-jr> sometimes I wish software had an increment-only security-fix counter common across the rest of the version :x
 26 2019-04-18T01:07:53  <luke-jr> so one could know so long as the Nth digit is latest, it has all known security issues patched
 27 2019-04-18T01:12:36  *** Haeapw has joined #bitcoin-core-dev
 28 2019-04-18T01:13:39  *** pinheadmz has quit IRC
 29 2019-04-18T02:01:26  *** gmaxwell_ has quit IRC
 30 2019-04-18T02:01:26  *** gmaxwell_ has joined #bitcoin-core-dev
 31 2019-04-18T02:01:35  *** gmaxwell_ is now known as gmaxwell
 32 2019-04-18T02:15:55  *** pinheadmz has joined #bitcoin-core-dev
 33 2019-04-18T02:31:04  <echeveria> luke-jr: that doesn't really work so well where patches needed total rewrites, ie the utxo
 34 2019-04-18T02:31:51  <luke-jr> sure it does? if 99 has a bug, anything unaffected must be >=100
 35 2019-04-18T02:32:11  <luke-jr> then the advisory can just say "be sure you have version >= x.y.100
 36 2019-04-18T02:34:42  <kallewoof> that's a nice idea, but if version 2.1.3.99 has a vulnerability that none of the other versions have, then 2.1.2.99 is not affected even though its security counter < 100
 37 2019-04-18T02:35:33  <kallewoof> unless the authors just bump the version without changing anything every time security counter is bumped up, even for unaffected versions.
 38 2019-04-18T02:35:49  <kallewoof> s/bump the version/release same v with counter updated/
 39 2019-04-18T02:38:09  *** pinheadmz has quit IRC
 40 2019-04-18T02:47:05  *** scoop has quit IRC
 41 2019-04-18T02:59:16  *** pinheadmz has joined #bitcoin-core-dev
 42 2019-04-18T03:13:27  *** justanotheruser has joined #bitcoin-core-dev
 43 2019-04-18T03:16:01  *** pinheadmz has quit IRC
 44 2019-04-18T03:24:33  <luke-jr> kallewoof: yeah, but if that's the worst case scenario, it's still an improvement
 45 2019-04-18T03:25:34  <luke-jr> and using 2.1.3.100 instead of 2.1.2.99 is less of a problem with this, than if 2.1.3.100 might be vulnerable, but 2.1.2.99 isn't.
 46 2019-04-18T03:26:41  * kallewoof nods
 47 2019-04-18T03:38:50  *** karna has joined #bitcoin-core-dev
 48 2019-04-18T03:39:22  *** spinza has quit IRC
 49 2019-04-18T03:45:31  *** pinheadmz has joined #bitcoin-core-dev
 50 2019-04-18T03:52:00  *** Dean_Guss has joined #bitcoin-core-dev
 51 2019-04-18T03:59:30  *** spinza has joined #bitcoin-core-dev
 52 2019-04-18T04:01:21  *** pinheadmz has quit IRC
 53 2019-04-18T04:08:03  *** karna has quit IRC
 54 2019-04-18T04:17:04  *** dqx_ has joined #bitcoin-core-dev
 55 2019-04-18T04:22:03  *** dqx_ has joined #bitcoin-core-dev
 56 2019-04-18T04:40:03  *** belcher has quit IRC
 57 2019-04-18T05:19:03  *** dqx__ has joined #bitcoin-core-dev
 58 2019-04-18T05:22:10  *** dqx_ has quit IRC
 59 2019-04-18T05:31:25  *** pinheadmz has joined #bitcoin-core-dev
 60 2019-04-18T05:38:48  *** dqx__ has quit IRC
 61 2019-04-18T06:02:30  *** pinheadmz has quit IRC
 62 2019-04-18T06:04:05  *** jonasschnelli_ has quit IRC
 63 2019-04-18T06:04:05  *** jonasschnelli_ has joined #bitcoin-core-dev
 64 2019-04-18T06:04:40  *** jnewbery has quit IRC
 65 2019-04-18T06:04:54  *** jnewbery has joined #bitcoin-core-dev
 66 2019-04-18T06:16:27  *** hebasto has joined #bitcoin-core-dev
 67 2019-04-18T06:40:24  *** EagleTM has joined #bitcoin-core-dev
 68 2019-04-18T07:25:57  *** harding has quit IRC
 69 2019-04-18T07:34:21  *** harding has joined #bitcoin-core-dev
 70 2019-04-18T07:43:57  *** Ll1i1lL has quit IRC
 71 2019-04-18T07:49:42  *** murrayn_ has quit IRC
 72 2019-04-18T07:50:03  *** murrayn has joined #bitcoin-core-dev
 73 2019-04-18T08:34:57  *** Ll1i1lL has joined #bitcoin-core-dev
 74 2019-04-18T08:40:18  *** Ll1i1lL has quit IRC
 75 2019-04-18T08:51:43  *** setpill has joined #bitcoin-core-dev
 76 2019-04-18T09:02:06  *** dqx has quit IRC
 77 2019-04-18T09:02:47  *** dqx has joined #bitcoin-core-dev
 78 2019-04-18T09:11:20  *** darosior has joined #bitcoin-core-dev
 79 2019-04-18T09:14:08  *** Plush has joined #bitcoin-core-dev
 80 2019-04-18T09:14:38  *** zorrologo has joined #bitcoin-core-dev
 81 2019-04-18T09:17:18  *** belcher has joined #bitcoin-core-dev
 82 2019-04-18T09:21:36  *** timothy has joined #bitcoin-core-dev
 83 2019-04-18T09:27:50  *** IRC-Source_65 has joined #bitcoin-core-dev
 84 2019-04-18T09:28:10  *** IRC-Source_65 has quit IRC
 85 2019-04-18T09:34:51  *** profmac has quit IRC
 86 2019-04-18T09:37:30  *** fanquake has joined #bitcoin-core-dev
 87 2019-04-18T09:39:37  *** Ll1i1lL has joined #bitcoin-core-dev
 88 2019-04-18T09:47:46  *** profmac has joined #bitcoin-core-dev
 89 2019-04-18T09:48:56  *** hebasto has quit IRC
 90 2019-04-18T10:02:30  *** midnightmagic has joined #bitcoin-core-dev
 91 2019-04-18T10:22:06  *** spinza has quit IRC
 92 2019-04-18T10:30:36  *** spinza has joined #bitcoin-core-dev
 93 2019-04-18T10:38:04  *** dqx_ has joined #bitcoin-core-dev
 94 2019-04-18T10:47:37  *** AaronvanW has joined #bitcoin-core-dev
 95 2019-04-18T10:54:36  *** goatpig_ has joined #bitcoin-core-dev
 96 2019-04-18T10:54:52  *** goatpig_ has left #bitcoin-core-dev
 97 2019-04-18T10:55:27  *** goatpig has joined #bitcoin-core-dev
 98 2019-04-18T10:55:45  *** Aaronvan_ has joined #bitcoin-core-dev
 99 2019-04-18T10:57:00  *** AaronvanW has quit IRC
100 2019-04-18T11:12:11  *** strattog has joined #bitcoin-core-dev
101 2019-04-18T11:13:23  *** strattog has quit IRC
102 2019-04-18T11:22:49  *** T-Junk has joined #bitcoin-core-dev
103 2019-04-18T11:29:01  *** Claveprivada has joined #bitcoin-core-dev
104 2019-04-18T11:35:46  *** darosior has quit IRC
105 2019-04-18T11:41:18  *** spaced0ut has quit IRC
106 2019-04-18T11:51:55  *** Guyver2 has joined #bitcoin-core-dev
107 2019-04-18T12:00:02  *** T-Junk has quit IRC
108 2019-04-18T12:02:01  *** belcher has quit IRC
109 2019-04-18T12:14:49  *** Claveprivada has quit IRC
110 2019-04-18T12:20:48  *** rafalcpp has quit IRC
111 2019-04-18T12:22:34  *** rafalcpp has joined #bitcoin-core-dev
112 2019-04-18T12:22:48  *** jonatack has joined #bitcoin-core-dev
113 2019-04-18T12:31:58  *** bitcoin-git has joined #bitcoin-core-dev
114 2019-04-18T12:31:58  <bitcoin-git> [bitcoin] ariard opened pull request #15842: refactor: replace isPotentialtip/waitForNotifications by higher method (master...2019-04-is-potential-tip) https://github.com/bitcoin/bitcoin/pull/15842
115 2019-04-18T12:32:00  *** bitcoin-git has left #bitcoin-core-dev
116 2019-04-18T12:32:11  *** belcher has joined #bitcoin-core-dev
117 2019-04-18T12:41:02  *** scoop has joined #bitcoin-core-dev
118 2019-04-18T12:46:10  *** spaced0ut has joined #bitcoin-core-dev
119 2019-04-18T12:50:39  *** scoop_ has joined #bitcoin-core-dev
120 2019-04-18T12:52:55  *** whartung1 has joined #bitcoin-core-dev
121 2019-04-18T12:54:13  *** scoop has quit IRC
122 2019-04-18T12:59:22  *** jonatack has quit IRC
123 2019-04-18T13:10:31  *** hebasto has joined #bitcoin-core-dev
124 2019-04-18T13:17:18  *** side^effects has joined #bitcoin-core-dev
125 2019-04-18T13:36:25  *** scoop_ has quit IRC
126 2019-04-18T13:38:02  *** scoop has joined #bitcoin-core-dev
127 2019-04-18T13:38:02  *** scoop has quit IRC
128 2019-04-18T13:38:10  *** scoop has joined #bitcoin-core-dev
129 2019-04-18T13:45:52  *** darosior has joined #bitcoin-core-dev
130 2019-04-18T13:49:32  *** bitcoin-git has joined #bitcoin-core-dev
131 2019-04-18T13:49:32  <bitcoin-git> [bitcoin] MarcoFalke pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/dae72998e857...e4beef611a42
132 2019-04-18T13:49:32  <bitcoin-git> bitcoin/master 4368384 Jim Posen: index: Allow atomic commits of index state to be extended.
133 2019-04-18T13:49:33  <bitcoin-git> bitcoin/master 62b7a4f Jim Posen: index: Ensure block locator is not stale after chain reorg.
134 2019-04-18T13:49:34  <bitcoin-git> bitcoin/master ba6ff9a Jim Posen: blockfilter: Functions to translate filter types to/from names.
135 2019-04-18T13:49:37  *** bitcoin-git has left #bitcoin-core-dev
136 2019-04-18T13:49:53  *** bitcoin-git has joined #bitcoin-core-dev
137 2019-04-18T13:49:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #14121: Index for BIP 157 block filters (master...bip157-index) https://github.com/bitcoin/bitcoin/pull/14121
138 2019-04-18T13:49:55  *** bitcoin-git has left #bitcoin-core-dev
139 2019-04-18T13:56:46  <jnewbery> \o/
140 2019-04-18T14:14:00  *** pinheadmz has joined #bitcoin-core-dev
141 2019-04-18T14:14:05  <echeveria> seems that broke the tests
142 2019-04-18T14:16:48  <MarcoFalke> yeah, it compiled back when I tested it, but now the test header file has been moved to setup_common.h
143 2019-04-18T14:17:00  <MarcoFalke> echeveria: Mind to fix it?
144 2019-04-18T14:17:38  <MarcoFalke> yay, silent merge conflicts
145 2019-04-18T14:27:04  *** bitcoin-git has joined #bitcoin-core-dev
146 2019-04-18T14:27:05  <bitcoin-git> [bitcoin] jamesob opened pull request #15843: tests: fix outdate include in blockfilter_index_tests (master...2019-04-blockfilter-include-fix) https://github.com/bitcoin/bitcoin/pull/15843
147 2019-04-18T14:27:06  *** bitcoin-git has left #bitcoin-core-dev
148 2019-04-18T14:29:08  *** scoop has quit IRC
149 2019-04-18T14:29:35  *** scoop has joined #bitcoin-core-dev
150 2019-04-18T14:33:08  *** scoop has quit IRC
151 2019-04-18T14:33:21  *** scoop has joined #bitcoin-core-dev
152 2019-04-18T14:39:30  *** bitcoin-git has joined #bitcoin-core-dev
153 2019-04-18T14:39:30  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e4beef611a42...693c743a32e4
154 2019-04-18T14:39:31  <bitcoin-git> bitcoin/master 89e8df1 James O'Beirne: tests: fix outdate include in blockfilter_index_tests
155 2019-04-18T14:39:31  <bitcoin-git> bitcoin/master 693c743 MarcoFalke: Merge #15843: tests: fix outdated include in blockfilter_index_tests
156 2019-04-18T14:39:33  *** bitcoin-git has left #bitcoin-core-dev
157 2019-04-18T14:40:19  *** bitcoin-git has joined #bitcoin-core-dev
158 2019-04-18T14:40:20  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15843: tests: fix outdated include in blockfilter_index_tests (master...2019-04-blockfilter-include-fix) https://github.com/bitcoin/bitcoin/pull/15843
159 2019-04-18T14:40:24  *** bitcoin-git has left #bitcoin-core-dev
160 2019-04-18T14:46:05  *** scoop has quit IRC
161 2019-04-18T14:47:24  *** jb55 has joined #bitcoin-core-dev
162 2019-04-18T14:48:00  *** scoop has joined #bitcoin-core-dev
163 2019-04-18T14:54:59  *** scoop has quit IRC
164 2019-04-18T14:55:08  *** scoop has joined #bitcoin-core-dev
165 2019-04-18T15:00:02  *** whartung1 has quit IRC
166 2019-04-18T15:00:04  *** _Sam-- has joined #bitcoin-core-dev
167 2019-04-18T15:04:48  *** matael1 has joined #bitcoin-core-dev
168 2019-04-18T15:12:18  *** dqx_ has quit IRC
169 2019-04-18T15:13:27  *** jonatack has joined #bitcoin-core-dev
170 2019-04-18T15:20:56  *** scoop has quit IRC
171 2019-04-18T15:23:52  *** morcos_ has joined #bitcoin-core-dev
172 2019-04-18T15:26:44  *** setpill has quit IRC
173 2019-04-18T15:27:25  *** morcos has quit IRC
174 2019-04-18T15:27:26  *** morcos_ is now known as morcos
175 2019-04-18T15:31:17  *** pinheadmz has quit IRC
176 2019-04-18T15:34:28  *** scoop has joined #bitcoin-core-dev
177 2019-04-18T15:35:00  *** bitcoin-git has joined #bitcoin-core-dev
178 2019-04-18T15:35:00  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
179 2019-04-18T15:35:01  *** bitcoin-git has left #bitcoin-core-dev
180 2019-04-18T15:35:15  *** bitcoin-git has joined #bitcoin-core-dev
181 2019-04-18T15:35:15  <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
182 2019-04-18T15:35:16  *** bitcoin-git has left #bitcoin-core-dev
183 2019-04-18T15:35:56  <MarcoFalke> PSA: GitHub delivered a corrupt branch for one pull request #15778
184 2019-04-18T15:35:57  <gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
185 2019-04-18T15:44:19  *** dqx_ has joined #bitcoin-core-dev
186 2019-04-18T15:45:43  *** dqx_ has quit IRC
187 2019-04-18T15:46:14  *** bitcoin-git has joined #bitcoin-core-dev
188 2019-04-18T15:46:16  <bitcoin-git> [bitcoin] laanwj pushed 7 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e57462c6ba60...e753cbd64507
189 2019-04-18T15:46:17  <bitcoin-git> bitcoin/0.18 8f7cfb0 James O'Beirne: gitignore: add *.dat
190 2019-04-18T15:46:18  <bitcoin-git> bitcoin/0.18 c69138a James O'Beirne: gitignore: add *.plist (clang-check)
191 2019-04-18T15:46:19  <bitcoin-git> bitcoin/0.18 9c572e3 Jack Mallers: doc: mention creating application support bitcoin folder on OSX
192 2019-04-18T15:46:21  *** bitcoin-git has left #bitcoin-core-dev
193 2019-04-18T15:46:39  *** bitcoin-git has joined #bitcoin-core-dev
194 2019-04-18T15:46:39  <bitcoin-git> [bitcoin] laanwj merged pull request #15818: [0.18] doc backports (0.18...0.18-doc-backports) https://github.com/bitcoin/bitcoin/pull/15818
195 2019-04-18T15:46:43  *** bitcoin-git has left #bitcoin-core-dev
196 2019-04-18T15:47:14  *** bitcoin-git has joined #bitcoin-core-dev
197 2019-04-18T15:47:15  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/693c743a32e4...f5aaeae0cdfc
198 2019-04-18T15:47:16  <bitcoin-git> bitcoin/master 4ddeb2f Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
199 2019-04-18T15:47:17  <bitcoin-git> bitcoin/master 8a33f4d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
200 2019-04-18T15:47:18  <bitcoin-git> bitcoin/master f5aaeae Wladimir J. van der Laan: Merge #15801: Bugfix: GUI: Options: Initialise prune setting range before ...
201 2019-04-18T15:47:19  *** bitcoin-git has left #bitcoin-core-dev
202 2019-04-18T15:47:37  *** bitcoin-git has joined #bitcoin-core-dev
203 2019-04-18T15:47:38  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e753cbd64507...a58d80d1b261
204 2019-04-18T15:47:38  <bitcoin-git> bitcoin/0.18 5546207 Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
205 2019-04-18T15:47:39  <bitcoin-git> bitcoin/0.18 a58d80d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
206 2019-04-18T15:47:41  *** bitcoin-git has left #bitcoin-core-dev
207 2019-04-18T15:48:08  *** bitcoin-git has joined #bitcoin-core-dev
208 2019-04-18T15:48:08  <bitcoin-git> [bitcoin] laanwj merged pull request #15801: Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit (master...bugfix_gui_prune_range) https://github.com/bitcoin/bitcoin/pull/15801
209 2019-04-18T15:48:09  *** bitcoin-git has left #bitcoin-core-dev
210 2019-04-18T15:51:27  *** millerti has joined #bitcoin-core-dev
211 2019-04-18T15:53:41  *** scoop has quit IRC
212 2019-04-18T15:54:21  *** gggggggggggg has quit IRC
213 2019-04-18T15:56:40  <MarcoFalke> john has force pushed  #15778, and the branch is no longer corrupted. Though, something to keep in mind when blindly fetching from GitHub.
214 2019-04-18T15:56:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
215 2019-04-18T16:06:12  <wumpus> MarcoFalke: it's an argument, I think, to encourage signing of the top commit in PRs as well
216 2019-04-18T16:07:34  <wumpus> at least corruption by github will then always be detected
217 2019-04-18T16:07:48  <MarcoFalke> Agree
218 2019-04-18T16:08:32  <MarcoFalke> They could still serve an outdated branch (what happened in this case), but signing is strictly better
219 2019-04-18T16:09:32  *** ezzzy has joined #bitcoin-core-dev
220 2019-04-18T16:10:08  <MarcoFalke> Even a dummy key without a passphrase would be sufficient.
221 2019-04-18T16:10:55  <MarcoFalke> A one-line wrapper script can be gpg --homedir="/path/to/dummy_key/gpg_dir/"
222 2019-04-18T16:11:23  <MarcoFalke> And then set git config gpg.program $THE_WRAPPER_SCRIPT
223 2019-04-18T16:12:16  <MarcoFalke> And then call git commit --gpg-sign=$THE_KEY_ID (or create another wrapper for that)
224 2019-04-18T16:15:45  *** tarboss has joined #bitcoin-core-dev
225 2019-04-18T16:16:12  *** tarboss has left #bitcoin-core-dev
226 2019-04-18T16:19:19  *** ezzzy has quit IRC
227 2019-04-18T16:26:36  *** spinza has quit IRC
228 2019-04-18T16:30:19  *** Dean_Guss has quit IRC
229 2019-04-18T16:32:15  *** spinza has joined #bitcoin-core-dev
230 2019-04-18T16:36:09  *** jarthur has joined #bitcoin-core-dev
231 2019-04-18T17:09:27  *** Aaronvan_ is now known as AaronvanW
232 2019-04-18T17:12:28  *** darosior has quit IRC
233 2019-04-18T17:19:02  *** omonk_ has quit IRC
234 2019-04-18T17:23:39  *** jarthur has quit IRC
235 2019-04-18T17:23:46  *** omonk has joined #bitcoin-core-dev
236 2019-04-18T17:24:16  *** jarthur has joined #bitcoin-core-dev
237 2019-04-18T17:33:42  *** pinheadmz has joined #bitcoin-core-dev
238 2019-04-18T17:46:12  *** bitcoin-git has joined #bitcoin-core-dev
239 2019-04-18T17:46:12  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f5aaeae0cdfc...6ce77a3668b9
240 2019-04-18T17:46:13  <bitcoin-git> bitcoin/master 2d8ba4f r8921039: remove out-of-date comment on pay-to-witness support
241 2019-04-18T17:46:13  <bitcoin-git> bitcoin/master 6ce77a3 Wladimir J. van der Laan: Merge #15833: [doc] remove out-of-date comment on pay-to-witness support
242 2019-04-18T17:46:25  *** bitcoin-git has left #bitcoin-core-dev
243 2019-04-18T17:47:00  *** bitcoin-git has joined #bitcoin-core-dev
244 2019-04-18T17:47:01  <bitcoin-git> [bitcoin] laanwj merged pull request #15833: [doc] remove out-of-date comment on pay-to-witness support (master...fix_comment_ExtractDestinations_does_support_pay_to_witness) https://github.com/bitcoin/bitcoin/pull/15833
245 2019-04-18T17:47:02  *** bitcoin-git has left #bitcoin-core-dev
246 2019-04-18T17:48:38  *** bitcoin-git has joined #bitcoin-core-dev
247 2019-04-18T17:48:38  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6ce77a3668b9...84adc79e105c
248 2019-04-18T17:48:39  <bitcoin-git> bitcoin/master 81b2830 Tobias Kaderle: qt: update request payment button text and tab description
249 2019-04-18T17:48:39  <bitcoin-git> bitcoin/master 84adc79 Wladimir J. van der Laan: Merge #15829: qt: update request payment button text and tab description
250 2019-04-18T17:48:42  *** bitcoin-git has left #bitcoin-core-dev
251 2019-04-18T17:49:25  *** bitcoin-git has joined #bitcoin-core-dev
252 2019-04-18T17:49:26  <bitcoin-git> [bitcoin] laanwj merged pull request #15829: qt: update request payment button text and tab description (master...squash_rebase_14484) https://github.com/bitcoin/bitcoin/pull/15829
253 2019-04-18T17:49:29  *** bitcoin-git has left #bitcoin-core-dev
254 2019-04-18T17:53:40  *** bitcoin-git has joined #bitcoin-core-dev
255 2019-04-18T17:53:41  <bitcoin-git> [bitcoin] dongcarl opened pull request #15844: depends: Purge libtool archives (master...2019-04-depends-purge-libtool-archives) https://github.com/bitcoin/bitcoin/pull/15844
256 2019-04-18T17:53:42  *** bitcoin-git has left #bitcoin-core-dev
257 2019-04-18T17:54:58  *** bitcoin-git has joined #bitcoin-core-dev
258 2019-04-18T17:54:58  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/84adc79e105c...2d4f70cabd6d
259 2019-04-18T17:54:58  <bitcoin-git> bitcoin/master 942ff20 nkostoulas: contrib: gh-merge: Use pagination to fetch all review comments
260 2019-04-18T17:54:59  <bitcoin-git> bitcoin/master 2d4f70c Wladimir J. van der Laan: Merge #15838: scripts and tools: Fetch missing review comments in github-m...
261 2019-04-18T17:55:00  *** bitcoin-git has left #bitcoin-core-dev
262 2019-04-18T17:55:47  *** bitcoin-git has joined #bitcoin-core-dev
263 2019-04-18T17:55:47  <bitcoin-git> [bitcoin] laanwj merged pull request #15838: scripts and tools: Fetch missing review comments in github-merge.py  (master...2019-04-fix-merge-script) https://github.com/bitcoin/bitcoin/pull/15838
264 2019-04-18T17:55:48  *** bitcoin-git has left #bitcoin-core-dev
265 2019-04-18T18:00:02  *** matael1 has quit IRC
266 2019-04-18T18:04:31  *** darosior has joined #bitcoin-core-dev
267 2019-04-18T18:05:37  *** Jayflux has joined #bitcoin-core-dev
268 2019-04-18T18:23:27  *** face has quit IRC
269 2019-04-18T18:32:08  *** justanotheruser has quit IRC
270 2019-04-18T18:36:30  *** abbitcryptic has joined #bitcoin-core-dev
271 2019-04-18T18:41:02  *** bitcoin-git has joined #bitcoin-core-dev
272 2019-04-18T18:41:02  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
273 2019-04-18T18:41:15  *** bitcoin-git has left #bitcoin-core-dev
274 2019-04-18T18:44:30  *** abbitcryptic has quit IRC
275 2019-04-18T18:54:35  *** Aaronvan_ has joined #bitcoin-core-dev
276 2019-04-18T18:57:56  *** AaronvanW has quit IRC
277 2019-04-18T19:00:04  <wumpus> #startmeeting
278 2019-04-18T19:00:04  <lightningbot> Meeting started Thu Apr 18 19:00:04 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
279 2019-04-18T19:00:04  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
280 2019-04-18T19:00:14  <jnewbery> hi
281 2019-04-18T19:00:17  <kanzure> hi
282 2019-04-18T19:00:28  <sipa> hi
283 2019-04-18T19:00:33  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
284 2019-04-18T19:00:42  <achow101> hi
285 2019-04-18T19:00:46  <jonasschnelli_> hi
286 2019-04-18T19:00:53  <jamesob> hi
287 2019-04-18T19:00:55  <meshcollider> hi
288 2019-04-18T19:00:56  <MarcoFalke> when rc4?
289 2019-04-18T19:01:07  <wumpus> #topic 0.18.0rc4
290 2019-04-18T19:01:21  <jonasschnelli_> I guess #15839 is holding it back
291 2019-04-18T19:01:23  <gribble> https://github.com/bitcoin/bitcoin/issues/15839 | [0.18] Revert GetData randomization change (#14897) by sdaftuar · Pull Request #15839 · bitcoin/bitcoin · GitHub
292 2019-04-18T19:01:28  *** jonasschnelli_ is now known as jonasschnelli
293 2019-04-18T19:01:30  <MarcoFalke> Needs merge
294 2019-04-18T19:01:42  <wumpus> that seems to be the only one left?
295 2019-04-18T19:01:54  <MarcoFalke> yeah, after that I think we are good to tag rc4
296 2019-04-18T19:01:59  <wumpus> good to know
297 2019-04-18T19:02:09  <gmaxwell> oh I thought the revert was merged already.
298 2019-04-18T19:02:38  <wumpus> ok, let's merge that one and tag rc4 after the meeting
299 2019-04-18T19:02:43  <sipa> ack
300 2019-04-18T19:02:46  <jonasschnelli> ack
301 2019-04-18T19:02:50  <MarcoFalke> #action merge 15839 and tag rc4
302 2019-04-18T19:03:27  <wumpus> #topic High priority for review
303 2019-04-18T19:03:39  <wumpus> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+project%3Abitcoin%2Fbitcoin%2F8  6 PRs on there right now
304 2019-04-18T19:04:33  <wumpus> anything to add/remove? I guess everyone does this outside of the meetings nowadays
305 2019-04-18T19:04:48  <sipa> can i have 15427?
306 2019-04-18T19:04:59  <sipa> #15427
307 2019-04-18T19:05:01  <gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
308 2019-04-18T19:05:02  <MarcoFalke> can I have #15758?
309 2019-04-18T19:05:04  <gribble> https://github.com/bitcoin/bitcoin/issues/15758 | qa: Add further tests to wallet_balance by MarcoFalke · Pull Request #15758 · bitcoin/bitcoin · GitHub
310 2019-04-18T19:05:05  <moneyball> i have a brief topic i'd like to cover after we go through other topics - an opportunity to meet with the github CEO and share feedback from this project
311 2019-04-18T19:05:41  <jnewbery> gwillen asked for #15024 to go in after the last wallet meeting
312 2019-04-18T19:05:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub
313 2019-04-18T19:06:07  <gwillen> jnewbery: thanks, I was just trying to find that but I'm on an airplane with bad wifi
314 2019-04-18T19:06:21  <wumpus> sipa MarcoFalke added
315 2019-04-18T19:06:27  <MarcoFalke> thx
316 2019-04-18T19:06:40  <sipa> thanks
317 2019-04-18T19:07:03  <wumpus> also added
318 2019-04-18T19:07:12  <gwillen> +1 thanks!
319 2019-04-18T19:07:30  <wumpus> looks like both achow101 and sdaftuar have two PRs on the list now :o
320 2019-04-18T19:07:45  <achow101> oops
321 2019-04-18T19:08:05  <jonasschnelli> sdaftuar will resolve now
322 2019-04-18T19:08:14  <wumpus> can/should we make a choice what to keep on there?
323 2019-04-18T19:08:16  <MarcoFalke> If they were suggested by different people, it should be fine
324 2019-04-18T19:08:17  <sipa> i propose a trial by combat to determine whose PRs remain
325 2019-04-18T19:08:33  *** pinheadmz has left #bitcoin-core-dev
326 2019-04-18T19:08:34  <MarcoFalke> Everyone can suggest one pr (it doesn't have to be their own)
327 2019-04-18T19:08:39  <instagibbs> is your PR heavier than a duck
328 2019-04-18T19:08:40  <wumpus> sipa:everyone gets to have one PR
329 2019-04-18T19:08:47  *** pinheadmz has joined #bitcoin-core-dev
330 2019-04-18T19:08:51  <wumpus> MarcoFalke: hmm
331 2019-04-18T19:08:57  <achow101> instagibbs: how many lines of code does a duck weigh?
332 2019-04-18T19:08:59  <gmaxwell> Yes, but based on who proposed.
333 2019-04-18T19:08:59  <jonasschnelli> MarcoFalke: that really hard to keep the overview
334 2019-04-18T19:09:03  <gmaxwell> not who authored.
335 2019-04-18T19:09:07  <wumpus> I don't really care but it's kind of getting out of hand
336 2019-04-18T19:09:12  <gmaxwell> (or that was my understanding)
337 2019-04-18T19:09:13  <MarcoFalke> but I agree that achow101 and sdaftuar should pick one pull that stays
338 2019-04-18T19:09:16  <wumpus> jonasschnelli: yeah, exactly
339 2019-04-18T19:09:23  <jonasschnelli> How do we keep track who proposed?
340 2019-04-18T19:09:24  <wumpus> github doesn't track this
341 2019-04-18T19:09:43  <MarcoFalke> remove NOTFOUND for sdaftuar
342 2019-04-18T19:09:44  <achow101> let's remove #15741 for now. it needs to be rebased anyways
343 2019-04-18T19:09:46  <wumpus> so are all 9 things on the list proposed by different people?
344 2019-04-18T19:09:46  <gribble> https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub
345 2019-04-18T19:09:56  <wumpus> ok
346 2019-04-18T19:10:29  <wumpus> thank you, done
347 2019-04-18T19:10:30  <gmaxwell> In the future we can use some greppable line in IRC to record requests.
348 2019-04-18T19:10:56  <wumpus> 7 PRs on the list now, that's just about managebale
349 2019-04-18T19:11:03  <wumpus> any other topics?
350 2019-04-18T19:11:10  <moneyball> there are 4
351 2019-04-18T19:11:14  <MarcoFalke> moneyball: has a bunch
352 2019-04-18T19:11:16  <moneyball> https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
353 2019-04-18T19:11:24  <jonasschnelli> We could also add a project column per non-author-proposer
354 2019-04-18T19:11:36  <jonasschnelli> I don't expect we would have a lot
355 2019-04-18T19:11:44  <wumpus> moneyball: thanks
356 2019-04-18T19:12:09  <wumpus> #topic Should send-to-non-v0-witness be standard (sipa)
357 2019-04-18T19:12:15  <sipa> hi
358 2019-04-18T19:12:28  <sipa> so we currently have two policy rules w.r.t. future segwit versions
359 2019-04-18T19:12:51  <sipa> one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard
360 2019-04-18T19:12:52  <wumpus> jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards'
361 2019-04-18T19:13:07  <sipa> the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard
362 2019-04-18T19:13:35  <sipa> i believe that first rule does more harm than good
363 2019-04-18T19:14:05  <gmaxwell> The tradeoff is: if you make payments to bech32 addresses with 'future' segwit versions, should your payment get stuck (esp ugly for a send many or if your wallet has few inputs)  OR  should users be somewhat more exposed to stupidly sending to an insecure 'future' address.
364 2019-04-18T19:14:09  <meshcollider> I'm inclined to agree
365 2019-04-18T19:14:18  <gmaxwell> I agree the first rule does more harm than good.
366 2019-04-18T19:14:20  <sipa> i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late
367 2019-04-18T19:14:27  *** darosior has quit IRC
368 2019-04-18T19:14:34  <sipa> so if we want that rule, i believe it belongs in the wallet, not in relay policy
369 2019-04-18T19:14:36  <MarcoFalke> No wallet should create thos addresses
370 2019-04-18T19:14:47  <luke-jr> (getting stuck is a problem because it locks up your change)
371 2019-04-18T19:14:57  <gmaxwell> To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets.
372 2019-04-18T19:15:09  <sdaftuar> sipa: are you suggesting it should be wallet rule to not send to those addresses?
373 2019-04-18T19:15:25  <sipa> sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet
374 2019-04-18T19:15:30  <gmaxwell> ugh.
375 2019-04-18T19:15:48  <sdaftuar> sipa: i think i can agree that it should not be a relay policy, but i'm skeptical of making it a wallet rule
376 2019-04-18T19:15:57  <jnewbery> Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction
377 2019-04-18T19:16:06  <wumpus> I tend to agree, this selfs a self-sabotaging relay policy
378 2019-04-18T19:16:21  <sipa> sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :)
379 2019-04-18T19:16:22  <jnewbery> I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay
380 2019-04-18T19:16:26  <luke-jr> tangent: if relay policy allows it, maybe it should always allow RBF on it?
381 2019-04-18T19:16:50  <sipa> jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best
382 2019-04-18T19:16:52  <sdaftuar> jnewbery: if wallet doesn't send to such addresses, we will have a similar problem rolling out v1 segwit addresses as rolling out bech32
383 2019-04-18T19:16:53  <gmaxwell> jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity.
384 2019-04-18T19:16:57  <luke-jr> jnewbery: but isn't the whole point of Bech32's extensibility in this regard, so that we don't need to upgrade wallets to send to new versions?
385 2019-04-18T19:17:17  <sipa> luke-jr: yup
386 2019-04-18T19:17:18  <wumpus> forward compatibility is kind of useful
387 2019-04-18T19:17:22  <meshcollider> Exactly...
388 2019-04-18T19:17:23  <gmaxwell> and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address.
389 2019-04-18T19:17:49  <sipa> yeah, i think my preference is not having the rule in the first place
390 2019-04-18T19:17:50  <luke-jr> IMO allow relay and wallet, but force RBF opt-in ;)
391 2019-04-18T19:17:59  <jnewbery> delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15
392 2019-04-18T19:18:05  <wumpus> there's *tons* of ways to send coins into the void, I don't think doing this accidentally is anything more likely than sending to a non-existant classic address for ex.
393 2019-04-18T19:18:06  <meshcollider> So I also dont think the wallet should refuse to send either, a warning at most
394 2019-04-18T19:18:08  <jnewbery> it's caused by other wallets and exchanges in the ecosystem
395 2019-04-18T19:18:15  <gmaxwell> We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
396 2019-04-18T19:18:23  <luke-jr> jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do
397 2019-04-18T19:18:30  <sdaftuar> luke-jr: +1
398 2019-04-18T19:18:43  <jnewbery> which is not send to non-v0 until there is a defined v1
399 2019-04-18T19:18:56  <wumpus> a warning would be okey
400 2019-04-18T19:18:57  <achow101> the fact that it's not a relay policy will lock up change
401 2019-04-18T19:18:58  <gmaxwell> We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves
402 2019-04-18T19:19:05  <wumpus> but I think we agree, this should not be relay policy
403 2019-04-18T19:19:17  <sipa> i'll PR removing it from relay policy
404 2019-04-18T19:19:21  <wumpus> relay policy has never been used to protect users, if so, why no excessive fee check?
405 2019-04-18T19:19:31  <sipa> wumpus: exactly
406 2019-04-18T19:19:31  <jonasschnelli> indeed
407 2019-04-18T19:19:32  <gmaxwell> wumpus: kinda one sec on that point.
408 2019-04-18T19:19:33  <instagibbs> sipa, it's worth a mailing list email?
409 2019-04-18T19:19:35  <jnewbery> I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1
410 2019-04-18T19:19:55  <gmaxwell> wumpus: There is a non-protection argument too... we generally tend to not relay forward compatiblity features, in order to protect their future usage.
411 2019-04-18T19:19:58  <jonasschnelli> instagibbs: seems to be Core policy,... no need for ML?!
412 2019-04-18T19:20:01  <luke-jr> jnewbery: but then we could just as well make a new address format for every version
413 2019-04-18T19:20:05  <gmaxwell> wumpus: but for _output types_ this doesn't apply.
414 2019-04-18T19:20:11  <wumpus> gmaxwell:right
415 2019-04-18T19:20:11  <cfields> replace-by-version? :p
416 2019-04-18T19:20:23  <MarcoFalke> jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated
417 2019-04-18T19:20:26  <luke-jr> jonasschnelli: it seems likely a topic other software would want to consider and act on too
418 2019-04-18T19:20:27  <sipa> actually
419 2019-04-18T19:20:28  <instagibbs> jonasschnelli, people may have made assumptions based on current policy, right or wrong?
420 2019-04-18T19:20:32  <jnewbery> luke-jr: that' not the same at all. This is a one-line (or config) or config
421 2019-04-18T19:20:35  <gmaxwell> jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets.
422 2019-04-18T19:20:38  <sipa> this is a violation of BIP173
423 2019-04-18T19:20:45  <gmaxwell> sipa: correct.
424 2019-04-18T19:20:47  <sipa> "Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. "
425 2019-04-18T19:20:47  <jonasschnelli> oh
426 2019-04-18T19:21:02  <wumpus> it makes sense to inform people on the ML
427 2019-04-18T19:21:08  <jonasschnelli> so we need to change BIPS.md :p
428 2019-04-18T19:21:15  <gmaxwell> The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
429 2019-04-18T19:21:41  <wumpus> it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good
430 2019-04-18T19:21:48  <luke-jr> considering BIP173, it's arguably a bug to fix in backports even ;)
431 2019-04-18T19:21:48  <sipa> i believe this code actually predates bip173
432 2019-04-18T19:21:58  <gmaxwell> sipa: it does.
433 2019-04-18T19:21:59  <wumpus> heh
434 2019-04-18T19:22:01  <achow101> so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs?
435 2019-04-18T19:22:10  <MarcoFalke> wallets should send to any address a merchant provides them, but the wallet itself should only generate v1 addresses after the v1 fork activated
436 2019-04-18T19:22:11  <luke-jr> achow101: inputs*?
437 2019-04-18T19:22:35  <sipa> achow101: i'd just drop the rule entirely
438 2019-04-18T19:22:47  <luke-jr> MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion
439 2019-04-18T19:22:50  <gmaxwell> We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules.  Outputs are fine.
440 2019-04-18T19:22:53  <sipa> maybe we want to independently add a warning in the GUI
441 2019-04-18T19:23:03  <MarcoFalke> achow101: outputs would be relayed, but spending from them would be non-standard
442 2019-04-18T19:23:05  <luke-jr> sipa: policy should prevent spending v1 UTXOs
443 2019-04-18T19:23:13  <sipa> luke-jr: it already does
444 2019-04-18T19:23:14  <achow101> ah, I see
445 2019-04-18T19:23:16  <luke-jr> sipa: nah, because of P2Sh stuff
446 2019-04-18T19:23:34  <luke-jr> sipa: yes, but it sounded like you might be talking about dropping it too
447 2019-04-18T19:23:36  <sipa> luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed
448 2019-04-18T19:23:48  <sipa> ah no, i'm only talking about the sending to part
449 2019-04-18T19:23:52  <luke-jr> k
450 2019-04-18T19:23:57  <sipa> (which is implemented completely independently)
451 2019-04-18T19:24:07  <gmaxwell> right thats another point against blocking v1 outputs:  It's _impossible_ to block p2sh v1 outputs...
452 2019-04-18T19:24:25  <sdaftuar> it would be nice to not bother implementing p2sh for v1, i think?
453 2019-04-18T19:24:27  <luke-jr> and because of ^, I don't think we should warn sending to v1 outputs either
454 2019-04-18T19:25:01  <luke-jr> sdaftuar: is there a benefit to that?
455 2019-04-18T19:25:14  <achow101> sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though
456 2019-04-18T19:25:16  <sipa> that's an independent discussion
457 2019-04-18T19:25:22  <gmaxwell> There are many ways people can hand you insecure addresses already... I at least don't have any reason to think that insecure future-version addresses are a worse problem than things like copy and pasting example addresses.
458 2019-04-18T19:25:29  <instagibbs> achow101, you can define it to be illegal tho
459 2019-04-18T19:25:39  <sipa> jnewbery: what's your opinion?
460 2019-04-18T19:25:41  <instagibbs> or just leave it undefined
461 2019-04-18T19:25:43  <sdaftuar> sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible
462 2019-04-18T19:25:46  <gmaxwell> achow101: we could, for example, close of p2sh embedded spending in the future entirely.
463 2019-04-18T19:25:58  <gmaxwell> s/of/off/
464 2019-04-18T19:26:04  <jnewbery> I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them
465 2019-04-18T19:26:23  <gmaxwell> jnewbery: what do you mean by validate them?
466 2019-04-18T19:26:27  <luke-jr> ^
467 2019-04-18T19:26:38  <jnewbery> I think people upgrade Bitcoin Core fairly frequently in general, so I can't see this being something that holds up adoption of segwit v1
468 2019-04-18T19:26:42  <gmaxwell> There normally isn't really any validation of outputs.
469 2019-04-18T19:26:44  <luke-jr> why does the sender care if the recipient spends it or not
470 2019-04-18T19:26:45  <jnewbery> I mean that they can be spent
471 2019-04-18T19:27:11  <instagibbs> sdaftuar, another point to doing that is then you *know* which version you're sending to, up to wallet to guard against edge cases
472 2019-04-18T19:27:14  <jnewbery> All other things being equal, I'd prefer the wallet not to be able to send to a class of unspendable addresses that we can easily check
473 2019-04-18T19:27:23  <luke-jr> jnewbery: the sender doesn't know if they can or can't be spent
474 2019-04-18T19:27:27  <sipa> jnewbery: would you be ok with a GUI-only warning?
475 2019-04-18T19:27:29  <wumpus> so to be clear: the discussion is about the relay policy, the wallet is a different topic
476 2019-04-18T19:27:39  <jnewbery> for example, we don't send to v0 with non 42/64 character witnesses
477 2019-04-18T19:27:45  <gmaxwell> (FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support)
478 2019-04-18T19:27:49  <luke-jr> jnewbery: it is spendable, just rejected by policy
479 2019-04-18T19:28:02  <gmaxwell> jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem.
480 2019-04-18T19:28:09  <jnewbery> I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :)
481 2019-04-18T19:28:13  <wumpus> the wallet not being able to send to certain addresses doesn't nearly block forward compatiblity as much as a restrictive relay policy does
482 2019-04-18T19:28:16  <sipa> gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented
483 2019-04-18T19:28:29  <luke-jr> most nodes are 0.16 still
484 2019-04-18T19:28:41  <jonasschnelli> I think we should allow sending to v1+ in the wallet and in the GUI
485 2019-04-18T19:28:50  <jnewbery> Right, my opinion is that the forward-compatibility issue is not a huge issue
486 2019-04-18T19:28:54  <gmaxwell> most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle...
487 2019-04-18T19:29:11  <wumpus> jnewbery: you mean not for relaying either?
488 2019-04-18T19:29:18  <luke-jr> 0.16.1 is 50% of all nodes it looks like
489 2019-04-18T19:29:19  <jonasschnelli> forward compatibility seems to be more important than foot-gun that trigger very very rarely
490 2019-04-18T19:29:25  <jnewbery> No, I think we should relay sending to V anything
491 2019-04-18T19:29:31  <jonasschnelli> And we don't (and can't) prevent P2SH forms anyway
492 2019-04-18T19:29:43  <wumpus> I'm confused now
493 2019-04-18T19:30:01  <jnewbery> I think we're all in agreement about mempool policy
494 2019-04-18T19:30:03  <wumpus> so, do we agree on changing this relay policy?
495 2019-04-18T19:30:09  <jonasschnelli> yes
496 2019-04-18T19:30:10  <sipa> i think so
497 2019-04-18T19:30:11  <meshcollider> Yes
498 2019-04-18T19:30:21  <luke-jr> +1
499 2019-04-18T19:30:25  <achow101> ack
500 2019-04-18T19:30:25  <gmaxwell> luke-jr: I think something weird is going on wrt versions, so that figure might be distored. (e.g. run your figures but exclude china...)
501 2019-04-18T19:30:26  <jnewbery> the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :)
502 2019-04-18T19:30:30  <wumpus> ok!
503 2019-04-18T19:30:37  <jonasschnelli> I guess the we are not agreeing about wether the wallet allows to send to v1+
504 2019-04-18T19:30:44  <wumpus> jnewbery: I think a warning makes sense
505 2019-04-18T19:30:45  <meshcollider> I'm ok with a wallet warning
506 2019-04-18T19:30:50  <luke-jr> gmaxwell: Chinese users are real though?
507 2019-04-18T19:30:55  <gmaxwell> I think a warning is foolish.
508 2019-04-18T19:31:01  <jonasschnelli> me 2
509 2019-04-18T19:31:13  <luke-jr> if we could reliably warn, it might be worth considering, but we can't
510 2019-04-18T19:31:16  <gmaxwell> luke-jr: Yes but I'm not confident that they're users. We can talk offline.
511 2019-04-18T19:31:20  <jonasschnelli> Assume one will send to v1 with 0.18.0 in one year where we assume having v1
512 2019-04-18T19:31:22  <luke-jr> becuase of p2sh etc
513 2019-04-18T19:31:40  <jonasschnelli> (if 0.18.0 would have the warning)
514 2019-04-18T19:31:54  <luke-jr> jonasschnelli: if warnings were reliable, we could base it on what we see in blocks
515 2019-04-18T19:31:57  <gmaxwell> I could even see blocking sending, but only up until a certian time.
516 2019-04-18T19:32:06  <jonasschnelli> I'm sure users would send to the p2sh version of it just thy bypass the warning
517 2019-04-18T19:32:10  <luke-jr> eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay
518 2019-04-18T19:32:28  <gmaxwell> But forever warning or blocking is just going to make it so that we can't quickly switch to v1 address generation by default.
519 2019-04-18T19:32:29  <jonasschnelli> luke-jr: yes. But that complex to implement without knowing the future
520 2019-04-18T19:32:39  <MarcoFalke> How would the warning be worded?
521 2019-04-18T19:32:40  <luke-jr> well, because we can't detect it reliably anyway, no point doing it even that way
522 2019-04-18T19:33:05  <gmaxwell> I feel like the principle of outputs is being lost here.
523 2019-04-18T19:33:08  <luke-jr> (I suppose we could look for spends getting mined instead)
524 2019-04-18T19:33:25  <gmaxwell> When a third party provides you with an output, thats it. It is none of your business what their policy is.
525 2019-04-18T19:33:37  <sdaftuar> gmaxwell: i agree with that
526 2019-04-18T19:33:42  <gmaxwell> This is one of the underlying principles behind p2sh and later hash based addresses.
527 2019-04-18T19:33:55  <luke-jr> gmaxwell: good point
528 2019-04-18T19:33:58  <MarcoFalke> "Warning: You are sending to an address that miners can steal from"?
529 2019-04-18T19:33:59  <gmaxwell> It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P
530 2019-04-18T19:33:59  <instagibbs> We can't do anything when someone gives you a bcash address either
531 2019-04-18T19:34:06  <luke-jr> MarcoFalke: that might not be true though
532 2019-04-18T19:34:09  <jonasschnelli> Warning if the last <tbd> blocks have no Vx output spent is probably an overkill?
533 2019-04-18T19:34:15  <MarcoFalke> And the the users go on reddit and ask what it means
534 2019-04-18T19:34:18  <gmaxwell> MarcoFalke: that warning wouldn't be true after some point in the future.
535 2019-04-18T19:34:35  <MarcoFalke> s/can/may for a limited time/
536 2019-04-18T19:34:38  <instagibbs> I'm not sure what warnings would achieve.
537 2019-04-18T19:35:09  <luke-jr> it would achieve people moving back to P2SH wrappers
538 2019-04-18T19:35:12  *** Kvaciral has joined #bitcoin-core-dev
539 2019-04-18T19:35:13  <instagibbs> lol
540 2019-04-18T19:35:17  <sdaftuar> yuck!
541 2019-04-18T19:35:22  <gmaxwell> and still sending to v1
542 2019-04-18T19:35:24  <gmaxwell> :P
543 2019-04-18T19:35:29  <luke-jr> right
544 2019-04-18T19:36:12  <wumpus> time for next topic, I think
545 2019-04-18T19:36:16  <jnewbery> +1
546 2019-04-18T19:36:22  <wumpus> #topic Bitcoin Core design documentation (jnewbery)
547 2019-04-18T19:36:25  <gmaxwell> instagibbs: good point on the bcash addresses. I've been told that this has been causing some pretty big nussances for some people (mostly the other direction, someone buys bcash thinks its bitcoin and sends it to an exchange bitcoin address....)
548 2019-04-18T19:36:31  <MarcoFalke> I'd prefer: "Warning: You are sending to a p2sh address"
549 2019-04-18T19:36:48  <instagibbs> gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing
550 2019-04-18T19:37:04  <jnewbery> There are currently a lot of high-level design considerations that aren't documented in the codebase. Some of them may exist in individual contributor's gists, or might not be written down at all.
551 2019-04-18T19:37:15  <jnewbery> Should we try to have some standard location to put them in so it's easier for people to understand why things are the way they are? One suggestion would be to use github's wiki feature.
552 2019-04-18T19:37:30  <jnewbery> Examples: P2P banning/disconnecting design philosophy
553 2019-04-18T19:37:35  <instagibbs> jnewbery, ACK, but note that it's mostly me imagining other people doing the work
554 2019-04-18T19:37:41  <wumpus> why not the doc folder?
555 2019-04-18T19:37:46  <jnewbery> Past critical bugs that have been fixed
556 2019-04-18T19:37:49  <achow101> we have that devwiki repo we use for release notes. could put other docs there
557 2019-04-18T19:37:58  <jonasschnelli> I also prefer within the sources
558 2019-04-18T19:38:04  <MarcoFalke> agree with wumpus. Should be in ./doc/
559 2019-04-18T19:38:10  <jonasschnelli> Also,.. how do we prevent from getting outdated?
560 2019-04-18T19:38:22  <gmaxwell> I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work.
561 2019-04-18T19:38:24  <MarcoFalke> jonasschnelli: Yell at people for not updating the docs
562 2019-04-18T19:38:26  <wumpus> achow101:yes, that would be another option
563 2019-04-18T19:38:33  <jnewbery> I don't think adding docs should go through the same review process as code changes
564 2019-04-18T19:38:36  <gmaxwell> Maybe put a boiler plate header on them that they could be outdated.
565 2019-04-18T19:38:44  <jnewbery> gmaxwell: github wikis are repos. You can clone them locally
566 2019-04-18T19:38:47  <gmaxwell> and add a last updated date to each document or something.
567 2019-04-18T19:38:51  <wumpus> jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point
568 2019-04-18T19:39:06  <MarcoFalke> jnewbery: yes they should. Wrong documentation is more harmful than no documentation
569 2019-04-18T19:39:08  <gmaxwell> even having it in the history is useful too.
570 2019-04-18T19:39:28  <luke-jr> IMO it should be separate from the code.
571 2019-04-18T19:39:37  <wumpus> but I like the idea, if anyone is willing to write this ata ll
572 2019-04-18T19:39:47  <luke-jr> this is an easy case to modularise; it has no ties to our versions/branches
573 2019-04-18T19:39:49  <sipa> i like the idea of putting a "Last updated at" + warning it could be outdated
574 2019-04-18T19:39:55  <sdaftuar> MarcoFalke: wait what, wrong documentation is more harmful than nothing?  can you explain?
575 2019-04-18T19:40:21  <gmaxwell> I don't really care what repo its in, just should be in some repo for sure. :)
576 2019-04-18T19:40:30  <jnewbery> I'm not suggesting that someone goes and writes a bunch of documentation. I'm suggesting that people who want to contribute documentation should have somewhere to put it.
577 2019-04-18T19:40:41  <instagibbs> to motivate this, things like p2p design are basically in the heads of a handful of people, I've never seen it written down anywhere aside from IRC
578 2019-04-18T19:40:54  <wumpus> sdaftuar: because it gets people to waste time, thinking of solutions based on the documentation, then it doesn't really apply to the current code base anymore
579 2019-04-18T19:41:04  <MarcoFalke> sdaftuar: I was talking about review
580 2019-04-18T19:41:09  <gmaxwell> sdaftuar: I'm also of the view that wrong documentation can be worse than nothing.  ::shrugs:: it isn't always. Depends on the recipent and how the wrong doc was written.
581 2019-04-18T19:41:11  <MarcoFalke> not about outdated documentation
582 2019-04-18T19:41:21  <gmaxwell> (okay maybe not also)
583 2019-04-18T19:41:28  <sdaftuar> wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs
584 2019-04-18T19:41:38  <gmaxwell> But I still think it's worth doing even if it ends up outdated.
585 2019-04-18T19:42:05  <wumpus> wrong code comments can cause a lot of damage, maybe less so for high level docs
586 2019-04-18T19:42:09  <gmaxwell> Its just somewhat important the the text itself reflect the possibility of it being outdated.
587 2019-04-18T19:42:18  <MarcoFalke> agree that outdated (timestamped) documentation is helpful
588 2019-04-18T19:42:27  <sdaftuar> anyway i would certainly appreciate having a place to put docs that i have written, so if we can decide to put stuff like that anywhere, i will happily contribute
589 2019-04-18T19:42:29  <jnewbery> An argument for a wiki and not in the PR is that we won't get a bunch of helpful new contributors opening PRs to fix spelling in the docs
590 2019-04-18T19:42:51  <wumpus> well, put it in the wiki then
591 2019-04-18T19:42:54  <jnewbery> *not in the repo
592 2019-04-18T19:42:59  <wumpus> everyone has write access to that one :)
593 2019-04-18T19:43:06  <gmaxwell> Is a bunch of spelling fixes important? :P
594 2019-04-18T19:43:11  <luke-jr> github wikis are just git repos
595 2019-04-18T19:43:17  <jnewbery> I don't think it exists for bitcoin/bitcoin
596 2019-04-18T19:43:19  <wumpus> gmaxwell:not important, but I agree re: PR bottlenecks
597 2019-04-18T19:43:20  <MarcoFalke> which is the downside that anyone can vandalize
598 2019-04-18T19:43:26  <wumpus> jnewbery: it doesn't for access control
599 2019-04-18T19:43:31  <wumpus> jnewbery: please use the devwiki
600 2019-04-18T19:43:34  <MarcoFalke> how hard is it to run a spellchecker these days?
601 2019-04-18T19:43:36  <wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
602 2019-04-18T19:43:39  <luke-jr> MarcoFalke: can address that when/if it happens
603 2019-04-18T19:43:47  <MarcoFalke> ok
604 2019-04-18T19:43:52  <jnewbery> why not a wiki in bitcoin/bitcoin?
605 2019-04-18T19:44:00  <luke-jr> jnewbery: because it's Core-specific?
606 2019-04-18T19:44:02  <wumpus> because it'd only be writabel by people with commit access
607 2019-04-18T19:44:06  <jnewbery> ah
608 2019-04-18T19:44:06  <luke-jr> (and if it isn't, we have BIPs)
609 2019-04-18T19:44:08  <sipa> we could also see from time to time whether a wiki article is sufficiently mature and stable to include it in the doc/ directory directly
610 2019-04-18T19:44:19  <gmaxwell> Also be careful with making publically writable stuff in bitcoin/bitcoin.
611 2019-04-18T19:44:19  <wumpus> the only way to do delegation on github is to have multiple repos
612 2019-04-18T19:44:32  <wumpus> gmaxwell: yes, I don't want that
613 2019-04-18T19:44:42  <jonasschnelli> gmaxwell: indeed
614 2019-04-18T19:44:44  <gmaxwell> "ATTENTION. OLD BITCOIN IS VULNERABLE. DOWNLOAD HOTFIX NOW  http://secure.haxor.com/bitcoin.exe"
615 2019-04-18T19:44:55  <MarcoFalke> hmmm
616 2019-04-18T19:44:56  <sdaftuar> ouch :(
617 2019-04-18T19:45:00  <wumpus> no need to throw everything in the same place
618 2019-04-18T19:45:01  <jonasschnelli> heh
619 2019-04-18T19:45:12  <jnewbery> ok, thanks. Sounds like https://github.com/bitcoin-core/bitcoin-devwiki/wiki is the place
620 2019-04-18T19:45:15  <luke-jr> gmaxwell: 404
621 2019-04-18T19:45:23  <sipa> lol
622 2019-04-18T19:45:25  <MarcoFalke> 15 minutes left. Next topic
623 2019-04-18T19:45:27  <jonasschnelli> rofl
624 2019-04-18T19:45:40  <luke-jr> but wait, I need to get the hotfix!
625 2019-04-18T19:45:44  <gmaxwell> luke-jr: "wine <urlib error>: 404"
626 2019-04-18T19:45:49  <wumpus> #topic opportunity to provide feedback with GitHub CEO (moneyball)
627 2019-04-18T19:46:01  <instagibbs> you gotta add sudo
628 2019-04-18T19:46:04  *** darosior has joined #bitcoin-core-dev
629 2019-04-18T19:46:06  <MarcoFalke> moneyball is github ceo?
630 2019-04-18T19:46:07  <moneyball> so jimpo and i received an email from a guy at github: I run a program for our CEO Nat Friedman connecting him with community members in GitHub. It’s an hour long chat on Friday’s where you can talk about anything GitHub that’s on your mind. I was wondering if you all would like to join us. You’re welcome to bring other maintainers up to a max of about 7 people. Many groups bring a “top 10” list with
631 2019-04-18T19:46:07  <moneyball> them and we go through that. We also have some demos and mockups of stuff to show and then discuss. Tell us how to improve GitHub.
632 2019-04-18T19:46:18  <wumpus> (I don't really have anything to discuss wrt hardcoded seeds at the moment)
633 2019-04-18T19:46:25  <meshcollider> wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself
634 2019-04-18T19:46:39  <MarcoFalke> wumpus: ok
635 2019-04-18T19:46:43  <instagibbs> moneyball, sorry who is "we" wrt demos
636 2019-04-18T19:46:52  <cfields> moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity.
637 2019-04-18T19:47:01  *** timothy has quit IRC
638 2019-04-18T19:47:04  <moneyball> This is an opportunity for the project to communicate 1) annoying bugs/reliability issues 2) new feature requests 3) maybe what it would take for the project to be comfortable using GitHub long-term
639 2019-04-18T19:47:06  <gmaxwell> sounds good for people with opinions. :)
640 2019-04-18T19:47:07  <cfields> (we=DCI)
641 2019-04-18T19:47:32  <moneyball> I am happy to attend this but (a) we need to compile a list (b) it would really be better if at least 1 other dev joined me who has deeper experience with the top 10 list than I do
642 2019-04-18T19:47:33  <cfields> instagibbs: lol, sorry, that wasn't in response to you.
643 2019-04-18T19:47:34  <luke-jr> open source github? :p
644 2019-04-18T19:47:42  <MarcoFalke> feature request: Nicely display pgp signed comments
645 2019-04-18T19:47:47  <wumpus> meshcollider: maybe, but once you want to lock down access, the only mechanism is the list of people with write access to the repo, which is the people with commit access
646 2019-04-18T19:47:52  <moneyball> luke-jr: i'd say nothing is off-limits!
647 2019-04-18T19:48:00  <luke-jr> MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea
648 2019-04-18T19:48:12  <MarcoFalke> Just display, not verifying
649 2019-04-18T19:48:12  <jonasschnelli> Probably interested people should form a list of feature requests and/or bugs (gist or wiki)
650 2019-04-18T19:48:13  <instagibbs> stop having commits reported in git commit timestamp order :P
651 2019-04-18T19:48:16  <moneyball> instagibbs: "we" is github
652 2019-04-18T19:48:25  <jonasschnelli> No need to post your feature request here and now
653 2019-04-18T19:48:31  <sipa> yeah
654 2019-04-18T19:48:32  <luke-jr> instagibbs: that's git-log's default too though
655 2019-04-18T19:48:37  <moneyball> yeah i am not intending to create the list right now in this meeting
656 2019-04-18T19:48:48  <jonasschnelli> moneyball: Thanks and great opportunity I agree
657 2019-04-18T19:48:53  <cfields> moneyball: I'd be interested.
658 2019-04-18T19:48:54  <moneyball> i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me
659 2019-04-18T19:48:55  <gmaxwell> if someone makes a list I'll dump some gripes in and other people can decide if they agree or think they're important.
660 2019-04-18T19:48:58  <gwillen> instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order
661 2019-04-18T19:49:06  <gwillen> there has been an open issue on this for a fucking age
662 2019-04-18T19:49:10  <meshcollider> It is in-person right, not remote attendance?
663 2019-04-18T19:49:52  <gwillen> (for reference https://github.com/isaacs/github/issues/386)
664 2019-04-18T19:49:56  <moneyball> an in-person lunch in SF
665 2019-04-18T19:50:34  <luke-jr> gwillen: --graph would be nice too :p
666 2019-04-18T19:50:44  <gwillen> let's not ask for a pony here ;-)
667 2019-04-18T19:50:47  <wumpus> gwillen: yes please
668 2019-04-18T19:50:51  <sipa> maybe open an issue on our tracker, where people can comment with things to mention?
669 2019-04-18T19:51:01  <sipa> (also, ack topo sort; i've personnally asked them for this years ago)
670 2019-04-18T19:51:02  <MarcoFalke> +1 instagibbs suggestion
671 2019-04-18T19:51:37  <jnewbery> yes please!
672 2019-04-18T19:51:38  <moneyball> sipa: i will do that
673 2019-04-18T19:51:48  <wumpus> what I"d like is to be able to do finer permission control, e.g. be able to give people access to issues/PR management without giving them write and merge access to the repo
674 2019-04-18T19:52:13  <sipa> moneyball: thanks
675 2019-04-18T19:52:15  <moneyball> if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub
676 2019-04-18T19:52:33  <luke-jr> wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient
677 2019-04-18T19:52:39  <moneyball> in the mean time please contribute to the Issue i'll create. i'll post it here once created.
678 2019-04-18T19:52:53  <meshcollider> Sounds good
679 2019-04-18T19:53:04  <cfields> I think it'd be most useful for us to discuss things that are paranoia-related, since that's what's most interesting about us to them, I'd think.
680 2019-04-18T19:53:13  <wumpus> luke-jr: well if 'checker script' is sufficiently general, sure, though I wouldn't want to include the entirety of travis in there, such a check needs to be fast
681 2019-04-18T19:53:19  <cfields> Things like "display order" they'll hear from everyone.
682 2019-04-18T19:53:35  <ryanofsky> my github feature request would be ability to base prs on top of other prs (just hide commits from base pr)
683 2019-04-18T19:53:37  <luke-jr> wumpus: eg, just the PGP checks
684 2019-04-18T19:53:39  <jnewbery> They should hear it from everyone!
685 2019-04-18T19:53:55  <luke-jr> ryanofsky: ooh, good idea
686 2019-04-18T19:53:56  <meshcollider> I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to
687 2019-04-18T19:53:59  <gmaxwell> luke-jr: that was exactly my thought.
688 2019-04-18T19:54:03  <sipa> cfields: good point
689 2019-04-18T19:54:12  <gmaxwell> (re enforce pgp allowing for access split)
690 2019-04-18T19:54:13  <jonasschnelli> paranoid-mode would probably exclude using github
691 2019-04-18T19:54:15  <cfields> ok, maybe s/paranoia-related/related to the way we use github uniquely/
692 2019-04-18T19:54:19  <sipa> cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns
693 2019-04-18T19:54:30  <cfields> sipa: yes, right.
694 2019-04-18T19:54:31  <wumpus> jonasschnelli:yes, I think that's a very slippery slope :)
695 2019-04-18T19:54:34  <gwillen> cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years
696 2019-04-18T19:54:38  <sipa> any other topics?
697 2019-04-18T19:54:45  <instagibbs> 6 min left
698 2019-04-18T19:54:48  <gmaxwell> gwillen: thre just may be an arch reason as to why its hard.
699 2019-04-18T19:54:49  <luke-jr> one thing I would find useful: a way for email notifications to distinguish between general project stuff, and stuff specifically I'm invovled in, and stuff I'm specifically mentioned in
700 2019-04-18T19:54:49  <wumpus> don't think so
701 2019-04-18T19:54:50  <gwillen> so if they're literally asking us for feedback, it would be good to say "why are you ignoring community feedback, please listen to it"
702 2019-04-18T19:55:26  <luke-jr> right now I often just ignore github notifications in bulk because there's so many, and don't see when people ask me things
703 2019-04-18T19:55:34  <ryanofsky> luke-jr, i think that already exists, you can filter based on to address
704 2019-04-18T19:55:36  <wumpus> luke-jr:there is, you acn filter on author@github.com and things like that
705 2019-04-18T19:55:41  <cfields> moneyball: maybe you can provide some context for why they reached out to us specifically?
706 2019-04-18T19:55:57  <gmaxwell> I mean. there is a lot of little stuff, like they were totally unable to keep randos from taking over the attribution on imported commits, but we eventually 'fixed' that by creating a dummy account.  I don't think this is worth discussing, since we 'fixed it' but its still kind of embarassing on their part.
707 2019-04-18T19:56:04  <moneyball> jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us
708 2019-04-18T19:56:08  <luke-jr> wumpus: I don't understand
709 2019-04-18T19:56:24  <jonasschnelli> But never forget, they need community feedback to improve to earn money for corporate customers
710 2019-04-18T19:56:32  <jonasschnelli> *from
711 2019-04-18T19:56:33  <ryanofsky> luke-jr, if you want to filter mentions look for Mention <mention@noreply.github.com> in To: header
712 2019-04-18T19:56:34  <gwillen> gmaxwell: I definitely agree on focusing on active problems with no good workaround
713 2019-04-18T19:56:37  <wumpus> luke-jr there's a special to-address they'll add in those cases fornmentions
714 2019-04-18T19:56:42  <cfields> moneyball: heh, gotcha. Thanks.
715 2019-04-18T19:56:47  <luke-jr> hmm
716 2019-04-18T19:57:44  <wumpus> #endmeeting
717 2019-04-18T19:57:44  <lightningbot> Meeting ended Thu Apr 18 19:57:44 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
718 2019-04-18T19:57:44  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.html
719 2019-04-18T19:57:44  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.txt
720 2019-04-18T19:57:44  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.log.html
721 2019-04-18T19:58:17  <gmaxwell> gwillen: it may also be with the ownership change their priorties are usefully different now.
722 2019-04-18T19:58:29  <wumpus> luke-jr: https://help.github.com/en/articles/about-email-notifications#filtering-email-notifications mentions all of them
723 2019-04-18T19:58:32  *** bitcoin-git has joined #bitcoin-core-dev
724 2019-04-18T19:58:32  <bitcoin-git> [bitcoin] sipa opened pull request #15846: [POLICY] Make sending to future native witness outputs standard (master...201904_futuresegwitstandard) https://github.com/bitcoin/bitcoin/pull/15846
725 2019-04-18T19:58:32  <gwillen> gmaxwell: I would say the right focus is on impact-to-us in our issues, which does not rule out little things if they are actively causing problems
726 2019-04-18T19:58:38  *** bitcoin-git has left #bitcoin-core-dev
727 2019-04-18T19:58:49  <gwillen> I think it's better to get them to fix supid little shit than to ask them for important things they'll never do
728 2019-04-18T19:58:53  <cfields> moneyball: Thanks for bringing that up!
729 2019-04-18T19:58:53  <gwillen> (but obviously both would be nice)
730 2019-04-18T19:59:39  <luke-jr> wumpus: thanks
731 2019-04-18T20:00:45  <gmaxwell> gwillen: like eons back I was talking to someone at github and telling them that I wanted a feature where you could set a repo so that newly created issues / PRs would only be visible to the submitter/project contribs (or at least logged in users) for 24 hours or whatever, in order to cut down abuse of github for trolling... and the reply was that sort of thing wouldn't be a popular feature in
732 2019-04-18T20:00:45  <gmaxwell> github because it would retard account growth.
733 2019-04-18T20:00:51  <gmaxwell> Maybe that would be less important now.
734 2019-04-18T20:01:25  <gwillen> I think this is exactly the sort of thing to bring up when they think we're important enough to ask us for feedback
735 2019-04-18T20:01:28  <gmaxwell> (that was motivated by a couple instances where some trolling jerk opened a PR to do some dumb change then went and spammed reddit with CORE DEVS GONNA XXX!)
736 2019-04-18T20:01:39  <gwillen> (I do agree it's also a good opportunity to bring up philosophically-aligned stuff about privacy and trust)
737 2019-04-18T20:01:53  <instagibbs> would also be nice so i dont have to read "ACTIVATED 1GB BLOCKS" PRs
738 2019-04-18T20:02:01  <instagibbs> as a non-maintainer
739 2019-04-18T20:02:55  <gmaxwell> I'm not sure how much of that is just my dislike of the modern 'everyone can scribble on everything' web. :P
740 2019-04-18T20:03:41  <wumpus> it would have been nice, with better people
741 2019-04-18T20:04:06  <gwillen> "better people" would solve many problems, but it was not to be
742 2019-04-18T20:04:20  <sipa> like the need for bitcoin?
743 2019-04-18T20:04:34  <wumpus> ^^
744 2019-04-18T20:04:53  <gwillen> heh!
745 2019-04-18T20:05:21  <gwillen> gmaxwell: in seriousness I think better anti-troll features would be huge for github in light of its increasing use as a Social Netowkr
746 2019-04-18T20:05:28  <gwillen> and also as a platform for grandstanding
747 2019-04-18T20:06:15  <gmaxwell> (related, githubs anti-spam has burned us a couple times with them vanishing perfectly reasonable comments without a trace and it looking like we deleted them)
748 2019-04-18T20:06:29  <gwillen> this would help with all the "rar I want to make a political statement against your repository" issues
749 2019-04-18T20:06:45  <gwillen> since there would no longer be a motivation to file them if they could be moderated before publication
750 2019-04-18T20:06:54  <gmaxwell> yup.
751 2019-04-18T20:07:01  <jonasschnelli> If I could ask for a feature, then it would be making github commit order rebase save
752 2019-04-18T20:07:11  <gmaxwell> gwillen: Also it would be less stressful to deal with them.
753 2019-04-18T20:07:22  <gwillen> jonasschnelli: is this the same as the toposort thing we were discussing upthread
754 2019-04-18T20:07:27  <gwillen> or a different issue
755 2019-04-18T20:07:33  <gmaxwell> just another idiot with an offtopic request, ... ploink.
756 2019-04-18T20:07:46  <gmaxwell> vs oh god inescapable dramafest.
757 2019-04-18T20:09:50  <jonasschnelli> gwillen: I don't know what toposort refers to... but then one I mentioned is that once you do a rebase, the commit order it messed up
758 2019-04-18T20:10:04  <moneyball> Please submit your ideas for improving GitHub here! https://github.com/bitcoin/bitcoin/issues/15847
759 2019-04-18T20:10:06  <sipa> jonasschnelli: yes, github sorts commits by author date
760 2019-04-18T20:10:13  <sipa> jonasschnelli: not by their dependency order
761 2019-04-18T20:10:24  *** bitcoin-git has joined #bitcoin-core-dev
762 2019-04-18T20:10:24  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2d4f70cabd6d...d1c2ed8dd768
763 2019-04-18T20:10:25  *** darosior has quit IRC
764 2019-04-18T20:10:25  <bitcoin-git> bitcoin/master fa346fe MarcoFalke: doc: Remove upgrade note in release notes from EOL versions
765 2019-04-18T20:10:25  <bitcoin-git> bitcoin/master d1c2ed8 MarcoFalke: Merge #15821: doc: Remove upgrade note in release notes from EOL versions
766 2019-04-18T20:10:26  <jonasschnelli> Making it impossible to manually sort things or even group with pure "message-commits"
767 2019-04-18T20:10:37  *** bitcoin-git has left #bitcoin-core-dev
768 2019-04-18T20:11:12  *** bitcoin-git has joined #bitcoin-core-dev
769 2019-04-18T20:11:12  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15821: doc: Remove upgrade note in release notes from EOL versions (master...1904-docRelEOL) https://github.com/bitcoin/bitcoin/pull/15821
770 2019-04-18T20:11:15  *** bitcoin-git has left #bitcoin-core-dev
771 2019-04-18T20:11:30  <gwillen> jonasschnelli: yeah, that is the same issue that at least half a dozen people in here also mentioned including me
772 2019-04-18T20:11:39  <gwillen> so we should include it in our feedback for sure :-)
773 2019-04-18T20:11:57  *** bitcoin-git has joined #bitcoin-core-dev
774 2019-04-18T20:11:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/a58d80d1b261...607b1b74986b
775 2019-04-18T20:11:58  <bitcoin-git> bitcoin/0.18 8602d8b Suhas Daftuar: Revert "Change in transaction pull scheduling to prevent InvBlock-related ...
776 2019-04-18T20:11:58  <bitcoin-git> bitcoin/0.18 607b1b7 MarcoFalke: Merge #15839: [0.18] Revert GetData randomization change (#14897)
777 2019-04-18T20:12:01  *** bitcoin-git has left #bitcoin-core-dev
778 2019-04-18T20:12:17  *** bitcoin-git has joined #bitcoin-core-dev
779 2019-04-18T20:12:17  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15839: [0.18] Revert GetData randomization change (#14897) (0.18...2019-04-revert-14897) https://github.com/bitcoin/bitcoin/pull/15839
780 2019-04-18T20:12:20  *** bitcoin-git has left #bitcoin-core-dev
781 2019-04-18T20:13:44  <MarcoFalke> So pull in the release notes and tag rc4?
782 2019-04-18T20:16:40  <wumpus> find w/ me
783 2019-04-18T20:18:20  <wumpus> huh didi I forget to push my translations update?
784 2019-04-18T20:20:37  <MarcoFalke> there was one for rc3 or rc2, I might recall
785 2019-04-18T20:22:15  *** bitcoin-git has joined #bitcoin-core-dev
786 2019-04-18T20:22:16  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/607b1b74986b...a4fc2fbb111e
787 2019-04-18T20:22:16  <bitcoin-git> bitcoin/0.18 a4fc2fb Wladimir J. van der Laan: gui: Pre-rc4 translations update
788 2019-04-18T20:22:18  *** bitcoin-git has left #bitcoin-core-dev
789 2019-04-18T20:24:35  *** darosior has joined #bitcoin-core-dev
790 2019-04-18T20:28:48  <kanzure> why is bitcoin-git exiting so frequently. can we fix this?
791 2019-04-18T20:29:41  <sipa> it joins for every message
792 2019-04-18T20:30:38  <gwillen> it is not a persistent process, it is stateless, so it can't stay joined when not messaging
793 2019-04-18T20:30:51  *** Guyver2 has quit IRC
794 2019-04-18T20:30:54  <luke-jr> if we remove the +n on the channel, it can send without joining
795 2019-04-18T20:31:06  <luke-jr> this may or may not be spam suicide though
796 2019-04-18T20:31:09  <gwillen> right
797 2019-04-18T20:31:16  <gwillen> probably better to tolerate a few extra lines
798 2019-04-18T20:31:37  <wumpus> we had that in the past, but it's not a good idea
799 2019-04-18T20:31:42  <gwillen> I'm not sure how -n interacts with bans, it might make them ineffective
800 2019-04-18T20:32:25  <wumpus> FWIW in general it can be pretty useful to disable join/part notifications for busy channels like this
801 2019-04-18T20:32:55  *** bitcoin-git has joined #bitcoin-core-dev
802 2019-04-18T20:32:56  <bitcoin-git> [bitcoin] darosior opened pull request #15848: Add a check for free disk space at first startup. ref #15813 (master...check_free_disk_size) https://github.com/bitcoin/bitcoin/pull/15848
803 2019-04-18T20:32:57  *** bitcoin-git has left #bitcoin-core-dev
804 2019-04-18T20:34:43  <luke-jr> wumpus: my client only does it globally
805 2019-04-18T20:38:17  *** bitcoin-git has joined #bitcoin-core-dev
806 2019-04-18T20:38:17  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/a4fc2fbb111e...438483983a45
807 2019-04-18T20:38:17  <bitcoin-git> bitcoin/0.18 4384839 Wladimir J. van der Laan: doc: Move release notes from wiki
808 2019-04-18T20:38:19  *** bitcoin-git has left #bitcoin-core-dev
809 2019-04-18T20:39:19  <sdaftuar> laanwj: i was just trying to edit the wiki to remove mention of 14897 from the release notes
810 2019-04-18T20:39:33  <sdaftuar> er wumpus ^^
811 2019-04-18T20:41:04  <sdaftuar> i guess there are other edits that still need to be made as well, should we just do that via PR between now and final release?
812 2019-04-18T20:41:06  <wumpus> sdaftuar: uhmm
813 2019-04-18T20:41:16  <wumpus> sdaftuar: I see various TODOs by Pieter are also still in there
814 2019-04-18T20:41:24  <sdaftuar> yeah i just saw that too
815 2019-04-18T20:41:59  <wumpus> for this reason I prefer to leave merging back the release notes for -final instead of a rc
816 2019-04-18T20:42:10  <wumpus> but yes, only way to edit it now is on the branch
817 2019-04-18T20:42:16  <sdaftuar> ok sounds good
818 2019-04-18T20:42:47  <gmaxwell> why doesn't the bot just stay in all the time?
819 2019-04-18T20:43:35  <wumpus> ready to tag rc4?
820 2019-04-18T20:43:50  <gwillen> gmaxwell: it can't, it's stateless
821 2019-04-18T20:43:52  <wumpus> gmaxwell: gwillen | it is not a persistent process, it is stateless, so it can't stay joined when not messaging
822 2019-04-18T20:43:57  <wumpus> it's a design choice
823 2019-04-18T20:44:54  <wumpus> it'd certainly be possible to have a persistent bot, but, github's own notification did exactly the same as this and that's what we ported
824 2019-04-18T20:47:18  <wumpus> FWIW source for the bot is here, I guess persistent bot functionality would be welcome if anyone implemented it: https://github.com/gkrizek/ghi
825 2019-04-18T20:49:59  *** darosior has quit IRC
826 2019-04-18T20:50:17  *** darosior has joined #bitcoin-core-dev
827 2019-04-18T20:51:28  *** bitcoin-git has joined #bitcoin-core-dev
828 2019-04-18T20:51:28  <bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
829 2019-04-18T20:51:29  *** bitcoin-git has left #bitcoin-core-dev
830 2019-04-18T20:51:43  *** bitcoin-git has joined #bitcoin-core-dev
831 2019-04-18T20:51:43  <bitcoin-git> [bitcoin] laanwj deleted tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/9b2d3aafcf91...000000000000
832 2019-04-18T20:51:44  *** bitcoin-git has left #bitcoin-core-dev
833 2019-04-18T20:52:18  *** bitcoin-git has joined #bitcoin-core-dev
834 2019-04-18T20:52:18  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/438483983a45...379f71ea4f27
835 2019-04-18T20:52:18  <bitcoin-git> bitcoin/0.18 379f71e Wladimir J. van der Laan: build: Bump version to rc4
836 2019-04-18T20:52:22  *** bitcoin-git has left #bitcoin-core-dev
837 2019-04-18T20:53:09  *** bitcoin-git has joined #bitcoin-core-dev
838 2019-04-18T20:53:09  <bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
839 2019-04-18T20:53:10  *** darosior has quit IRC
840 2019-04-18T20:53:22  *** bitcoin-git has left #bitcoin-core-dev
841 2019-04-18T20:54:34  *** darosior has joined #bitcoin-core-dev
842 2019-04-18T20:58:38  <gmaxwell> luke-jr: I've been monitoring not just what versions I see out there, but also hosts that connect to me that are fetching old blocks-- IOW ones that look like they're syncing up.
843 2019-04-18T20:59:04  <gmaxwell> luke-jr: and I've noticed that almost all syncing up hosts I see are 0.16.1 and coming from a relatively small number of networks in china.
844 2019-04-18T20:59:32  <gmaxwell> Which made me wonder if perhaps some chinese language docs pointed to an outdated download... but jl2012 was unable to find anything.
845 2019-04-18T21:00:01  *** Jayflux has quit IRC
846 2019-04-18T21:02:28  <gmaxwell> also their behavior appears to be weird, e.g. I see them downloading a moderate number of blocks then stop and stay connected.
847 2019-04-18T21:06:00  *** darosior has quit IRC
848 2019-04-18T21:06:29  <luke-jr> gmaxwell: hmm, any relation to the networks?
849 2019-04-18T21:12:42  <gmaxwell> luke-jr: these are the networks with 10 or more distinct hosts https://0bin.net/paste/WmG3qoFHHfOV2xoE#lzkxzcVyHrSvgi+yZjFvpoqocGNtWu6lDhhFOubsgGE  the first three each have many more than the others.
850 2019-04-18T21:13:12  *** fabianfabian has joined #bitcoin-core-dev
851 2019-04-18T21:13:30  <gmaxwell> beyond 'china' I'm not aware of anything that links these hosts.
852 2019-04-18T21:15:03  *** bitcoin-git has joined #bitcoin-core-dev
853 2019-04-18T21:15:03  <bitcoin-git> [bitcoin] jamesob opened pull request #15849: Thread names in logs and deadlock debug tools (master...2018-05-threadnames-take-2) https://github.com/bitcoin/bitcoin/pull/15849
854 2019-04-18T21:15:08  *** bitcoin-git has left #bitcoin-core-dev
855 2019-04-18T21:15:09  <gmaxwell> Every network in that list is china, and thats also doubly intresting considering the historic near absence of bitcoin nodes in china.
856 2019-04-18T21:17:53  <luke-jr> hrm
857 2019-04-18T21:18:07  *** jb55 has quit IRC
858 2019-04-18T21:19:12  *** darosior has joined #bitcoin-core-dev
859 2019-04-18T21:19:49  *** EagleTM has quit IRC
860 2019-04-18T21:20:02  *** EagleTM has joined #bitcoin-core-dev
861 2019-04-18T21:20:30  <gmaxwell> so I think either something is causing chinese language users to use 0.16.1 or that there is some DOS attack or attack prep that happens to currently look like 0.16.1.
862 2019-04-18T21:20:42  <gmaxwell> if it is confused users I still don't know why there are so many.
863 2019-04-18T21:21:21  *** CrystalNice has joined #bitcoin-core-dev
864 2019-04-18T21:21:49  <gmaxwell> in the past week-ish I've observed 1395 distinct chinese IPs syncing old blocks with 0.16.1.  And like ... 2 hosts that weren't chinese 0.16.1.
865 2019-04-18T21:22:03  <gmaxwell> (and were syncing old blocks)
866 2019-04-18T21:22:45  <gmaxwell> if nothing else it might make sense for you to make a versions page that split china and the rest of the world, so we could see if there was a chinese language specific issue with running old versions.
867 2019-04-18T21:23:37  <midnightmagic> appliance maybe
868 2019-04-18T21:24:05  <gmaxwell> possibly.
869 2019-04-18T21:25:54  <luke-jr> gmaxwell: my methodology is incompatible with splitting by region, sadly
870 2019-04-18T21:37:52  *** darosior has quit IRC
871 2019-04-18T21:38:10  *** darosior has joined #bitcoin-core-dev
872 2019-04-18T21:38:34  *** darosior has joined #bitcoin-core-dev
873 2019-04-18T21:45:06  *** jb55 has joined #bitcoin-core-dev
874 2019-04-18T22:29:30  *** darosior has quit IRC
875 2019-04-18T22:46:04  *** owowo has quit IRC
876 2019-04-18T22:51:15  *** owowo has joined #bitcoin-core-dev
877 2019-04-18T22:51:47  *** justanotheruser has joined #bitcoin-core-dev
878 2019-04-18T22:51:49  *** AaronvanW has joined #bitcoin-core-dev
879 2019-04-18T22:51:49  *** justanotheruser has quit IRC
880 2019-04-18T22:53:31  *** fabianfabian has quit IRC
881 2019-04-18T22:54:03  *** Aaronvan_ has quit IRC
882 2019-04-18T22:56:10  *** justanotheruser has joined #bitcoin-core-dev
883 2019-04-18T22:57:37  *** spinza has quit IRC
884 2019-04-18T22:59:51  *** justanotheruser has quit IRC
885 2019-04-18T23:03:00  *** dqx_ has joined #bitcoin-core-dev
886 2019-04-18T23:04:17  *** justanotheruser has joined #bitcoin-core-dev
887 2019-04-18T23:06:19  *** jarthur has quit IRC
888 2019-04-18T23:06:48  *** spinza has joined #bitcoin-core-dev
889 2019-04-18T23:27:59  *** belcher has quit IRC
890 2019-04-18T23:33:51  *** AaronvanW has quit IRC
891 2019-04-18T23:35:08  *** dqx_ has quit IRC
892 2019-04-18T23:40:06  *** belcher has joined #bitcoin-core-dev
893 2019-04-18T23:59:24  *** EagleTM has quit IRC