1 2018-01-31T00:08:10  *** Victorsueca has quit IRC
  2 2018-01-31T00:18:57  *** colatkinson has quit IRC
  3 2018-01-31T00:23:41  *** Karyon_ has joined #bitcoin-dev
  4 2018-01-31T00:25:05  *** kunla has quit IRC
  5 2018-01-31T00:25:06  *** Jomamma has joined #bitcoin-dev
  6 2018-01-31T00:28:11  *** PaulCape_ has quit IRC
  7 2018-01-31T00:32:27  *** colatkinson has joined #bitcoin-dev
  8 2018-01-31T00:34:21  *** impulse has joined #bitcoin-dev
  9 2018-01-31T00:38:40  *** PaulCapestany has joined #bitcoin-dev
 10 2018-01-31T00:40:18  *** gnubeard has quit IRC
 11 2018-01-31T00:40:53  *** damons has joined #bitcoin-dev
 12 2018-01-31T00:50:51  *** kallewoof has quit IRC
 13 2018-01-31T00:53:07  *** justan0theruser has quit IRC
 14 2018-01-31T00:58:46  *** justanotheruser has joined #bitcoin-dev
 15 2018-01-31T00:58:47  *** justanotheruser has quit IRC
 16 2018-01-31T00:59:02  *** justanotheruser has joined #bitcoin-dev
 17 2018-01-31T01:01:10  *** Dizzle has quit IRC
 18 2018-01-31T01:04:24  *** jb55 has joined #bitcoin-dev
 19 2018-01-31T01:15:46  *** Victorsueca has joined #bitcoin-dev
 20 2018-01-31T01:19:54  *** Qatz has quit IRC
 21 2018-01-31T01:26:57  *** colatkinson has quit IRC
 22 2018-01-31T01:27:32  *** pmx has quit IRC
 23 2018-01-31T01:27:55  *** Qatz has joined #bitcoin-dev
 24 2018-01-31T01:33:42  *** kallewoof has joined #bitcoin-dev
 25 2018-01-31T01:37:46  *** Jomamma is now known as cryptojanitor
 26 2018-01-31T01:37:57  *** Victorsueca has quit IRC
 27 2018-01-31T01:39:47  *** CheckDavid has quit IRC
 28 2018-01-31T01:42:04  *** Victorsueca has joined #bitcoin-dev
 29 2018-01-31T01:44:18  *** cryptojanitor is now known as CryptoJanitor
 30 2018-01-31T01:48:00  *** CryptoJanitor is now known as cryptojanitor
 31 2018-01-31T02:08:33  *** Victorsueca has quit IRC
 32 2018-01-31T02:08:48  *** droark has quit IRC
 33 2018-01-31T02:20:09  *** Victorsueca has joined #bitcoin-dev
 34 2018-01-31T02:27:07  *** Karyon_ has quit IRC
 35 2018-01-31T02:27:34  *** Karyon_ has joined #bitcoin-dev
 36 2018-01-31T02:31:01  *** Giszmo has joined #bitcoin-dev
 37 2018-01-31T02:39:40  *** To7 has quit IRC
 38 2018-01-31T02:49:37  *** cdecker has quit IRC
 39 2018-01-31T02:49:56  *** Murch has quit IRC
 40 2018-01-31T02:50:47  *** cdecker has joined #bitcoin-dev
 41 2018-01-31T02:53:18  *** droark has joined #bitcoin-dev
 42 2018-01-31T03:11:48  *** Karyon_ has quit IRC
 43 2018-01-31T03:15:04  *** pmx has joined #bitcoin-dev
 44 2018-01-31T03:22:56  *** echeveria has quit IRC
 45 2018-01-31T03:23:23  *** windsok has quit IRC
 46 2018-01-31T03:35:10  *** jb55 has quit IRC
 47 2018-01-31T03:50:08  *** Karyon_ has joined #bitcoin-dev
 48 2018-01-31T03:51:03  *** robink has quit IRC
 49 2018-01-31T03:52:53  *** robink has joined #bitcoin-dev
 50 2018-01-31T04:04:04  *** jb55 has joined #bitcoin-dev
 51 2018-01-31T04:04:08  *** dabura667 has joined #bitcoin-dev
 52 2018-01-31T04:07:16  *** wxss has quit IRC
 53 2018-01-31T04:10:08  *** segy has quit IRC
 54 2018-01-31T04:14:11  *** segy has joined #bitcoin-dev
 55 2018-01-31T04:20:18  *** jb55 has quit IRC
 56 2018-01-31T04:22:48  *** Karyon_ has quit IRC
 57 2018-01-31T04:24:18  *** jb55 has joined #bitcoin-dev
 58 2018-01-31T04:24:57  *** Krellan has quit IRC
 59 2018-01-31T04:38:27  *** jb55 has quit IRC
 60 2018-01-31T05:00:10  *** Karyon_ has joined #bitcoin-dev
 61 2018-01-31T05:05:12  *** arubi has quit IRC
 62 2018-01-31T05:06:15  *** arubi has joined #bitcoin-dev
 63 2018-01-31T05:10:53  *** arubi has quit IRC
 64 2018-01-31T05:10:56  *** arubi_ has joined #bitcoin-dev
 65 2018-01-31T05:13:05  *** Giszmo has quit IRC
 66 2018-01-31T05:14:49  *** arubi_ has quit IRC
 67 2018-01-31T05:15:16  *** arubi has joined #bitcoin-dev
 68 2018-01-31T05:21:13  *** justan0theruser has joined #bitcoin-dev
 69 2018-01-31T05:22:09  *** justanotheruser has quit IRC
 70 2018-01-31T05:30:12  *** flokie has quit IRC
 71 2018-01-31T05:45:09  *** d3vt4r has joined #bitcoin-dev
 72 2018-01-31T05:47:48  *** Karyon_ has quit IRC
 73 2018-01-31T05:49:18  <d3vt4r> sup hommies
 74 2018-01-31T05:49:57  <d3vt4r> Prices are crashing came here for refuge
 75 2018-01-31T05:51:04  *** Dizzle has joined #bitcoin-dev
 76 2018-01-31T06:21:42  *** ghost43 has quit IRC
 77 2018-01-31T06:21:57  *** ghost43 has joined #bitcoin-dev
 78 2018-01-31T06:27:26  *** keymone has joined #bitcoin-dev
 79 2018-01-31T06:43:13  *** Krellan has joined #bitcoin-dev
 80 2018-01-31T06:47:45  *** Krellan has quit IRC
 81 2018-01-31T07:06:03  *** Krellan has joined #bitcoin-dev
 82 2018-01-31T07:06:06  *** Krellan has quit IRC
 83 2018-01-31T07:06:13  *** AndBobsYourUncle has joined #bitcoin-dev
 84 2018-01-31T07:07:47  *** Krellan has joined #bitcoin-dev
 85 2018-01-31T07:08:48  *** airbreather has quit IRC
 86 2018-01-31T07:09:23  *** airbreather has joined #bitcoin-dev
 87 2018-01-31T07:11:10  *** fatalhalt has quit IRC
 88 2018-01-31T07:15:00  *** fatalhalt has joined #bitcoin-dev
 89 2018-01-31T07:16:08  *** airbreather has quit IRC
 90 2018-01-31T07:18:47  *** airbreather has joined #bitcoin-dev
 91 2018-01-31T07:28:55  *** d3vt4r has quit IRC
 92 2018-01-31T07:35:18  *** jtimon has quit IRC
 93 2018-01-31T07:44:19  *** meshcollider has quit IRC
 94 2018-01-31T07:54:46  *** Victorsueca has quit IRC
 95 2018-01-31T07:56:02  *** Victorsueca has joined #bitcoin-dev
 96 2018-01-31T08:05:13  *** airbreather_ has joined #bitcoin-dev
 97 2018-01-31T08:08:08  *** airbreather has quit IRC
 98 2018-01-31T08:14:17  *** Diablo-D3 has quit IRC
 99 2018-01-31T08:15:39  *** windsok has joined #bitcoin-dev
100 2018-01-31T08:22:54  *** firemanxbr has joined #bitcoin-dev
101 2018-01-31T08:26:55  *** tombusby has quit IRC
102 2018-01-31T08:27:42  *** ula has quit IRC
103 2018-01-31T08:28:09  *** tombusby has joined #bitcoin-dev
104 2018-01-31T08:32:15  *** Diablo-D3 has joined #bitcoin-dev
105 2018-01-31T08:39:53  *** Diablo-D3 has quit IRC
106 2018-01-31T08:40:34  *** Diablo-D3 has joined #bitcoin-dev
107 2018-01-31T09:09:30  *** firemanxbr has quit IRC
108 2018-01-31T09:13:14  *** firemanxbr has joined #bitcoin-dev
109 2018-01-31T09:16:08  *** nazarewk has joined #bitcoin-dev
110 2018-01-31T09:26:01  *** Krellan has quit IRC
111 2018-01-31T09:26:52  *** Krellan has joined #bitcoin-dev
112 2018-01-31T09:34:58  *** rmt has quit IRC
113 2018-01-31T09:38:02  *** d9b4bef9 has quit IRC
114 2018-01-31T09:39:07  *** d9b4bef9 has joined #bitcoin-dev
115 2018-01-31T09:40:45  *** promag has joined #bitcoin-dev
116 2018-01-31T09:43:31  *** Dizzle has quit IRC
117 2018-01-31T09:54:38  *** wxss has joined #bitcoin-dev
118 2018-01-31T09:58:56  *** one_zero has quit IRC
119 2018-01-31T09:59:48  *** meshcollider has joined #bitcoin-dev
120 2018-01-31T10:11:13  *** nazarewk has quit IRC
121 2018-01-31T10:15:25  *** damons is now known as damons_is_away
122 2018-01-31T10:28:12  *** ongolaBoy has joined #bitcoin-dev
123 2018-01-31T10:29:04  *** Karyon_ has joined #bitcoin-dev
124 2018-01-31T10:44:47  *** checksauce has joined #bitcoin-dev
125 2018-01-31T10:49:47  *** promag has quit IRC
126 2018-01-31T10:50:37  *** Karyon has joined #bitcoin-dev
127 2018-01-31T10:51:10  *** snoogle has joined #bitcoin-dev
128 2018-01-31T10:51:52  *** snoogle has left #bitcoin-dev
129 2018-01-31T10:52:36  *** damons_is_away is now known as damons
130 2018-01-31T10:52:48  *** snoogle has joined #bitcoin-dev
131 2018-01-31T10:53:45  <snoogle> hi
132 2018-01-31T10:53:55  *** Karyon_ has quit IRC
133 2018-01-31T10:54:15  *** snoogle has left #bitcoin-dev
134 2018-01-31T11:00:41  *** Karyon has quit IRC
135 2018-01-31T11:12:35  <wumpus> ageis: getchaintxstats has a field 'txcount' that is the total number of transactions
136 2018-01-31T11:12:51  *** Guyver2 has joined #bitcoin-dev
137 2018-01-31T11:14:48  *** snoogle has joined #bitcoin-dev
138 2018-01-31T11:25:55  *** joeyy has quit IRC
139 2018-01-31T11:27:25  *** snoogle has quit IRC
140 2018-01-31T11:27:34  *** jtimon has joined #bitcoin-dev
141 2018-01-31T11:53:02  *** Krellan has quit IRC
142 2018-01-31T11:55:18  *** dabura667 has quit IRC
143 2018-01-31T12:03:17  *** Krellan has joined #bitcoin-dev
144 2018-01-31T12:09:56  *** kunla has joined #bitcoin-dev
145 2018-01-31T12:34:30  *** Karyon has joined #bitcoin-dev
146 2018-01-31T12:57:17  *** checksauce has quit IRC
147 2018-01-31T12:59:48  *** Karyon has quit IRC
148 2018-01-31T13:12:34  *** airbreather_ is now known as airbreather
149 2018-01-31T13:19:37  *** meshcollider has quit IRC
150 2018-01-31T13:20:52  *** Karyon has joined #bitcoin-dev
151 2018-01-31T13:41:26  *** Karyon has quit IRC
152 2018-01-31T13:43:49  *** damons is now known as damons_is_away
153 2018-01-31T13:44:40  *** Karyon has joined #bitcoin-dev
154 2018-01-31T14:07:55  *** treehug88 has quit IRC
155 2018-01-31T14:14:33  *** Krellan has quit IRC
156 2018-01-31T14:15:29  *** Krellan has joined #bitcoin-dev
157 2018-01-31T14:22:37  *** meshcollider has joined #bitcoin-dev
158 2018-01-31T14:23:19  *** Karyon has quit IRC
159 2018-01-31T14:23:46  *** Karyon has joined #bitcoin-dev
160 2018-01-31T14:26:16  *** Giszmo has joined #bitcoin-dev
161 2018-01-31T14:38:25  *** kunla has quit IRC
162 2018-01-31T14:43:29  *** Beef has quit IRC
163 2018-01-31T14:44:50  *** Giszmo has quit IRC
164 2018-01-31T14:49:23  *** Pavle has joined #bitcoin-dev
165 2018-01-31T15:03:03  *** AndyS2 has joined #bitcoin-dev
166 2018-01-31T15:07:44  *** Karyon has quit IRC
167 2018-01-31T15:08:13  *** damons_is_away is now known as damons
168 2018-01-31T15:14:39  *** Pavle has quit IRC
169 2018-01-31T15:20:48  *** Krellan has quit IRC
170 2018-01-31T15:21:24  *** Krellan has joined #bitcoin-dev
171 2018-01-31T15:26:09  *** kunla has joined #bitcoin-dev
172 2018-01-31T15:31:04  *** Krellan has quit IRC
173 2018-01-31T15:36:57  *** Krellan has joined #bitcoin-dev
174 2018-01-31T15:41:05  *** To7 has joined #bitcoin-dev
175 2018-01-31T15:41:12  *** Krellan has quit IRC
176 2018-01-31T15:41:21  *** wraithm has joined #bitcoin-dev
177 2018-01-31T15:46:58  *** Krellan has joined #bitcoin-dev
178 2018-01-31T15:47:52  *** damons has quit IRC
179 2018-01-31T15:49:27  *** damons has joined #bitcoin-dev
180 2018-01-31T15:50:25  *** SopaXorzTaker has joined #bitcoin-dev
181 2018-01-31T15:57:50  *** kunla has quit IRC
182 2018-01-31T16:04:21  *** Giszmo has joined #bitcoin-dev
183 2018-01-31T16:22:57  *** Giszmo has quit IRC
184 2018-01-31T16:34:02  *** echeveria has joined #bitcoin-dev
185 2018-01-31T16:37:20  *** agricocb has quit IRC
186 2018-01-31T16:39:27  *** dcousens has quit IRC
187 2018-01-31T16:39:37  *** meshcollider has quit IRC
188 2018-01-31T16:40:04  *** Giszmo has joined #bitcoin-dev
189 2018-01-31T16:40:29  *** gielbier_ has joined #bitcoin-dev
190 2018-01-31T16:40:30  *** dcousens has joined #bitcoin-dev
191 2018-01-31T16:41:22  <gielbier_> hmz. 0.15.99 validateaddress tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx gives true. 0.16.0rc1 false . Bug?
192 2018-01-31T16:42:18  <contrapumpkin> #bitcoin-core-dev might be able to give you a better answer
193 2018-01-31T16:49:57  *** elichai2 has joined #bitcoin-dev
194 2018-01-31T17:02:46  <arubi> gielbier_, are you on testnet on both?
195 2018-01-31T17:08:33  *** Giszmo has quit IRC
196 2018-01-31T17:09:02  *** Victorsueca has quit IRC
197 2018-01-31T17:09:36  *** one_zero has joined #bitcoin-dev
198 2018-01-31T17:09:53  *** Krellan has quit IRC
199 2018-01-31T17:10:08  *** kunla has joined #bitcoin-dev
200 2018-01-31T17:10:14  *** Victorsueca has joined #bitcoin-dev
201 2018-01-31T17:19:52  <gielbier_> regtest
202 2018-01-31T17:19:59  <gielbier_> but yeah on both
203 2018-01-31T17:20:17  *** Krellan has joined #bitcoin-dev
204 2018-01-31T17:23:33  <arubi> gielbier_, right, regtest bech32 start with bcrt1
205 2018-01-31T17:23:47  <arubi> so tb1 is not a valid prefix on regtest (finally!) :)
206 2018-01-31T17:24:35  *** Giszmo has joined #bitcoin-dev
207 2018-01-31T17:24:53  <arubi> so maybe that wallet was created with testnet?  or core used to output testnet bech32 addresses for regtest?
208 2018-01-31T17:25:35  <arubi> example of regtest bech32 : bcrt1qq0a6yzzjdfutgt45x38cztj4xyzwwvjnle0xat
209 2018-01-31T17:28:23  <gielbier_> ah ok :)
210 2018-01-31T17:28:42  <gielbier_> yeah it was an old testnet wallet i think
211 2018-01-31T17:37:28  <gielbier_> but we used unit test for testnet/regtest . needed to update them for bech32
212 2018-01-31T17:39:21  <arubi> nice, the more bech32 the better
213 2018-01-31T17:54:46  *** Krellan has quit IRC
214 2018-01-31T17:55:49  *** Krellan has joined #bitcoin-dev
215 2018-01-31T18:07:55  *** jb55 has joined #bitcoin-dev
216 2018-01-31T18:14:58  *** Krellan has quit IRC
217 2018-01-31T18:15:30  *** Krellan has joined #bitcoin-dev
218 2018-01-31T18:36:24  *** Dizzle has joined #bitcoin-dev
219 2018-01-31T18:40:55  *** Murch has joined #bitcoin-dev
220 2018-01-31T18:50:59  *** Victorsueca has quit IRC
221 2018-01-31T18:52:14  *** Victorsueca has joined #bitcoin-dev
222 2018-01-31T18:52:28  *** kunla has quit IRC
223 2018-01-31T18:53:20  *** kunla has joined #bitcoin-dev
224 2018-01-31T18:58:12  *** Steve_1982 has joined #bitcoin-dev
225 2018-01-31T19:05:40  *** robink has quit IRC
226 2018-01-31T19:07:14  *** robink has joined #bitcoin-dev
227 2018-01-31T19:07:58  *** ongolaBoy has quit IRC
228 2018-01-31T19:08:56  *** bugs_ has joined #bitcoin-dev
229 2018-01-31T19:12:34  *** adiabat has quit IRC
230 2018-01-31T19:14:34  *** adiabat has joined #bitcoin-dev
231 2018-01-31T19:17:29  *** tombusby has quit IRC
232 2018-01-31T19:19:27  *** tombusby has joined #bitcoin-dev
233 2018-01-31T19:20:18  *** uebera|| has quit IRC
234 2018-01-31T19:20:54  *** damons has quit IRC
235 2018-01-31T19:22:16  *** uebera|| has joined #bitcoin-dev
236 2018-01-31T19:26:07  *** SopaXorzTaker has quit IRC
237 2018-01-31T19:33:59  *** Giszmo has quit IRC
238 2018-01-31T19:34:03  *** nazarewk has joined #bitcoin-dev
239 2018-01-31T19:38:56  *** Steve_1982 has quit IRC
240 2018-01-31T19:41:11  *** jb55 has quit IRC
241 2018-01-31T19:41:54  *** meshcollider has joined #bitcoin-dev
242 2018-01-31T19:51:44  *** dcousens has quit IRC
243 2018-01-31T19:57:19  *** dcousens has joined #bitcoin-dev
244 2018-01-31T20:07:04  *** damons has joined #bitcoin-dev
245 2018-01-31T20:13:48  *** nazarewk has quit IRC
246 2018-01-31T20:32:44  *** Krellan has quit IRC
247 2018-01-31T20:33:53  *** Krellan has joined #bitcoin-dev
248 2018-01-31T20:33:58  *** GreatWizard has joined #bitcoin-dev
249 2018-01-31T20:42:32  *** dermoth has quit IRC
250 2018-01-31T20:56:08  *** dermoth has joined #bitcoin-dev
251 2018-01-31T21:05:39  *** Victorsueca has quit IRC
252 2018-01-31T21:06:47  *** Victorsueca has joined #bitcoin-dev
253 2018-01-31T21:10:11  *** eklitzke has quit IRC
254 2018-01-31T21:17:05  <reardencode> I'm working on a BIP to enable transaction inputs to expire if they aren't mined by an MTP/height, anyone interested in discussing / offering an early review?
255 2018-01-31T21:17:31  <arubi> is that supposed to be consensus or just policy?
256 2018-01-31T21:17:42  *** GreatWizard has quit IRC
257 2018-01-31T21:17:53  <reardencode> consensus
258 2018-01-31T21:18:22  <arubi> soft fork?  how then?
259 2018-01-31T21:18:50  <reardencode> yes, soft fork, similar to BIP68, adding additional validation to nSequence
260 2018-01-31T21:19:46  <arubi> it's a bit of an issue to put that in script
261 2018-01-31T21:20:17  <reardencode> not talking about adding it to OP_CHECKSEQUENCEVERIFY yet - no script behavior changes at this time
262 2018-01-31T21:20:40  <arubi> so how are you going to enforce it?
263 2018-01-31T21:21:32  <reardencode> if an input with sequence "don't mine me after MTP 2018-01-31" is mined into a block with MTP 2018-02-01, nodes reject the block
264 2018-01-31T21:21:35  *** Dizzle has quit IRC
265 2018-01-31T21:22:38  *** firemanxbr has quit IRC
266 2018-01-31T21:22:44  <reardencode> (this is the same as how BIP68 is enforced on nSequence, only in the opposite direction)
267 2018-01-31T21:23:12  *** firemanxbr has joined #bitcoin-dev
268 2018-01-31T21:24:22  <arubi> yes, I understand that, there's an issue with that thinking.  (brb)
269 2018-01-31T21:25:24  *** eklitzke has joined #bitcoin-dev
270 2018-01-31T21:25:48  <reardencode> awesome, I'd love to hear the issue!
271 2018-01-31T21:28:49  <arubi> back.  reardencode, in bitcoin there's a property of transaction validity that says that once a transaction is valid, it can't become invalid.  it makes managing mempool and block reorgs a lot simpler
272 2018-01-31T21:29:15  <reardencode> arubi: ah, I didn't know that! can you link me to some resources on that topic?
273 2018-01-31T21:30:16  <arubi> with this change you'll have to constantly chcekc and evict transactions from your mempool as they decay in time, and also it makes payments with these transactions a bit worse which ruins fungibility
274 2018-01-31T21:30:25  <arubi> oh I don't know if it's documented anywhere :)
275 2018-01-31T21:31:39  <reardencode> lol - trying to think this through from a software engineering perspective: I don't think you'd need to keep scanning the mempool -- just evict-on-read if the transaction is now invalid (that's how most caches I've written work any way)
276 2018-01-31T21:32:02  <arubi> yea but what about ones already in mempool that decayed?
277 2018-01-31T21:32:17  <reardencode> regarding reduced fungibility: once confirmed these transactions have no different validity than any other - admitedly they are completely valueless when 0-conf
278 2018-01-31T21:32:35  *** agricocb has joined #bitcoin-dev
279 2018-01-31T21:32:40  <reardencode> arubi: that's what I mean - when you read a tx from the mempool, you can check at that time if it's decayed past its validity and evict it
280 2018-01-31T21:32:44  <reardencode> no need to scan proactively
281 2018-01-31T21:33:02  <arubi> well if you're mining blocks you're pretty much updating mempool constantly
282 2018-01-31T21:33:11  <arubi> I mena, you are always, but requesting block templates
283 2018-01-31T21:33:30  <reardencode> sure, and I'm sure you check txs as you read them to see if a new transaction has (for example) spent one of that transactions inputs in the meantime
284 2018-01-31T21:33:44  <arubi> only if a block comes in would you need to check that
285 2018-01-31T21:33:45  <reardencode> so this adds one additional (and easy) check as you are reading your mempool any way
286 2018-01-31T21:34:26  *** stalled has quit IRC
287 2018-01-31T21:34:36  <reardencode> how do you reconcile the statement that a transaction never becomes invalid after it's been valid with RBF?
288 2018-01-31T21:34:58  <arubi> both versions are valid
289 2018-01-31T21:35:08  <arubi> until a block is mined.  just not together of course
290 2018-01-31T21:35:21  <reardencode> fair
291 2018-01-31T21:35:30  <arubi> I'm sure you can code it, but it goes against transaction validity rules as they are in bitcoin right now.  it's a pretty big change
292 2018-01-31T21:35:55  *** agricocb has quit IRC
293 2018-01-31T21:36:02  <reardencode> yeah, I didn't realize that assumption was so deeply relied upon (although I should have, any current state of a system will become relied upon by someone)
294 2018-01-31T21:36:17  *** agricocb has joined #bitcoin-dev
295 2018-01-31T21:37:43  <reardencode> ok, if you still have a minute, let's take this back a level: I think that there's a pretty big problem with bitcoin currently, because transactions can (and did in recent months) languish in the network mempool for many months. This makes using bitcoin difficult, especially for making exchanges that are not denominated in bitcoin (due to exchange rate changes).
296 2018-01-31T21:38:18  <reardencode> I think that offering transaction authors a way to expire their transactions after a _defined_ period, instead of whenever the mempool owners want to is a powerful tool to enable new payments usecases
297 2018-01-31T21:38:32  *** Beef has joined #bitcoin-dev
298 2018-01-31T21:40:48  <arubi> it would make some coins worth less than others,
299 2018-01-31T21:40:58  <reardencode> arubi: I still don't understand that claim, can you elaborate?
300 2018-01-31T21:42:04  <arubi> coins that can expire are not only 0-conf, but potentially no-conf.  that's pretty dangerous to accept as payment
301 2018-01-31T21:42:47  <reardencode> we already have that distinction with non-RBF transactions and RBF transactions
302 2018-01-31T21:43:13  <reardencode> it's just a sliding scale of reliability for 0-conf, it doesn't change the value of the coins once mined
303 2018-01-31T21:43:21  <arubi> not really, any transaction can be replaced, but as long as it wasn't the first payment is always good
304 2018-01-31T21:43:44  <arubi> there's not difference in reliability between rbf and non-rbf.  consensus rules are the same re. replacement
305 2018-01-31T21:44:35  <arubi> with decaying transactions, there's both risk of double spending before confirmed, and a risk of it just disappearing.  there's no way to operate on such coin with confidence before it's confirmed
306 2018-01-31T21:44:41  <reardencode> hmm, I may not fully understand RBF rules, can't I RBF a transactoin with one that pays me the entire input?
307 2018-01-31T21:44:53  <arubi> you could do that both with rbf and non rbf
308 2018-01-31T21:45:13  <arubi> rbf is just policy.  the actual consensus rules are no different between rbf and non-rbf
309 2018-01-31T21:46:43  <reardencode> I don't think that distinction matters here: If I make an RBF transaction that pays Alice 1BTC and then she makes a transaction paying .5BTC to Bob, but I RBF the original so that it only pays Alice .05BTC, how's that any different than me making an expiring payment to her?
310 2018-01-31T21:46:55  <reardencode> in either case if the original transaction doesn't end up in a block, Alice is screwed
311 2018-01-31T21:47:46  <reardencode> relying on 0-conf transactions is always a gamble, bigger with RBF an deven bigger with an expiring transaction
312 2018-01-31T21:47:57  <arubi> rbf is irrelevant here.  any 0-conf is vulnerable to double spending.  a decaying transaction is vulnerable both to double spending and just disappearing
313 2018-01-31T21:48:59  <reardencode> how about this: any transaction is vulnerable to just disappearing if its fee is low and most mempools are full
314 2018-01-31T21:49:17  <arubi> not true.  sender and recipient will continue to broadcast it
315 2018-01-31T21:49:53  <reardencode> right, recipient can rebroadcast if they've saved the full TX
316 2018-01-31T21:50:09  <arubi> their wallet does that already.  at least core does
317 2018-01-31T21:50:55  <reardencode> anyhow, I agree that expiring transactions reduce the strength of 0-conf, but 0-conf is already a crapshoot, so I'm still not seeing why deterministic time limits on the tx would reduce fungibility at all
318 2018-01-31T21:51:40  <reardencode> if your payer is cooperative, they can resend, and if your payer is cooperative, they won't double spend - if your payer is malicious, you're screwed in either ase
319 2018-01-31T21:51:40  *** meshcollider has quit IRC
320 2018-01-31T21:53:04  *** dafuq[m] has quit IRC
321 2018-01-31T21:54:56  <arubi> I'm trying to think if say a block was mined without our decaying tx in it and MTP is now past the decay date
322 2018-01-31T21:55:35  <arubi> can a miner re-org that block and set time so that MTP on that block == the MTP that was on the last block
323 2018-01-31T21:56:01  <arubi> now they can include the decaying tx since it hasn't decayed yet
324 2018-01-31T21:57:08  <reardencode> good question - I'd need to review MTP rules
325 2018-01-31T21:59:28  <arubi> with cltv\csv it's okay because the transaction becomes relay-able as mtp crosses the thing encoded in nsequence, so it's only the /next/ block that could include the timelocked transaction
326 2018-01-31T21:59:56  <arubi> so no issue in reorg since any chain that reorgs will allow inclusion of the relayed timelocked tx
327 2018-01-31T22:00:57  *** Murch has quit IRC
328 2018-01-31T22:01:05  <reardencode> this seems like an issue of reliability of the expiration mechanism: at what point can I be certain that no future block reorganization could allow my (supposedly expired) transaction in
329 2018-01-31T22:01:40  <arubi> suggestions I've seen were putting a 100 block maturity on it
330 2018-01-31T22:01:46  <reardencode> so the MTP mechanism uses the median of the psat 6 blocks timestamp which is designed to resist reorganization attempts
331 2018-01-31T22:01:53  <reardencode> er meidan of the past 11
332 2018-01-31T22:01:56  <arubi> block maturity-like rule.  like on generation txs
333 2018-01-31T22:01:59  <reardencode> which puts it typically at the 6th past block
334 2018-01-31T22:02:07  <arubi> right
335 2018-01-31T22:02:43  *** Murch has joined #bitcoin-dev
336 2018-01-31T22:02:50  <reardencode> I'll have to think harder about how that impacts my proposal for sure, because if there were a way for a malicious miner to include my tx _after_ I wanted it to expire, that'd be bad.
337 2018-01-31T22:04:03  <arubi> basically any bad enough reorg can do that.  all depends on how hard it might be
338 2018-01-31T22:04:37  <reardencode> sure, it's all probabilities, just like relying on any confirmed tx ;)
339 2018-01-31T22:05:52  <arubi> if enough people use this mechanism, it might be a good attack vector by a malicious miner against a lot of people at once
340 2018-01-31T22:06:52  <arubi> either intentionally skewing the clock forward so txs decay faster, or reorg to do the other thing ^
341 2018-01-31T22:08:49  <reardencode> yep, given that we have the blockchain, which is theoretically immutable after sufficient time, we should be able to define a reference point against which we can apply consensus rules for a mechanism like this
342 2018-01-31T22:09:11  <arubi> that's where imposing maturity on these transactions comes in
343 2018-01-31T22:09:17  <reardencode> in the worst case, using block height would be definitive, but given the broad skew of block durations, I'd like to offer MTP as well
344 2018-01-31T22:10:12  <arubi> but payments that need to mature in order to become useful are less attractive to any recipient.  what if they want to sell "now"?
345 2018-01-31T22:10:23  <arubi> so that's where fungibility is hurt imo
346 2018-01-31T22:10:33  <reardencode> right, so your concern now is once an expiring transaction is mined, can a malicious miner reorg the chain to make it impossible to ever mine that transaction
347 2018-01-31T22:12:05  <arubi> right, without there being a double spend of it
348 2018-01-31T22:13:12  <gmaxwell> 13:17:05 < reardencode> I'm working on a BIP to enable transaction inputs to expire if they aren't mined by an MTP/height, anyone interested in
349 2018-01-31T22:13:48  <gmaxwell> any such proposal is probably dead on arrival, becuase they break monotonicity.  and also probably an insult to the community because they suggest you haven't botered reading up on the 50 other times they've been proposed. :-/
350 2018-01-31T22:14:40  <gmaxwell> every other time its come up the conclusion seems to be that they'd be okay if they required maturity on respend, but then no one wants the feature anymore.
351 2018-01-31T22:15:07  <arubi> there's any written proposal?  tbh I never saw one
352 2018-01-31T22:15:24  <arubi> just sparse logs about it
353 2018-01-31T22:15:35  <gmaxwell> Generally it seems like the primary motivation for these things is a misunderstanding of distributed systems-- the idea that there is a singular 'now' that things could expire by... but thats unphysical.
354 2018-01-31T22:15:48  <gmaxwell> arubi: it's been on the list several times before as well as bitcoin talk.
355 2018-01-31T22:15:49  <reardencode> gmaxwell: :( sorry, I'm relatively new to _bitcoin_ development and admit to not searching enough on prior work
356 2018-01-31T22:17:05  <reardencode> gmaxwell: hah, and you've answered in the past https://github.com/bitcoin/bitcoin/pull/3509
357 2018-01-31T22:17:15  <reardencode> arubi: ^ for written similar proposal
358 2018-01-31T22:17:19  <gmaxwell> it's not so much your fault.
359 2018-01-31T22:17:22  <arubi> oh there we go :)
360 2018-01-31T22:17:48  <gmaxwell> there is just a bit of death by 1001 cuts.
361 2018-01-31T22:17:56  <arubi> "otherwise innocuous reorganization makes all its ancestors forever non-confirmable, even absent a double spend" oh verbatim
362 2018-01-31T22:18:30  <gmaxwell> Perhaps there are new idea that could make some of these things more useful, but we never get to them because people show up and rehash the same discussions over and over again.
363 2018-01-31T22:18:37  <gmaxwell> And any one person doing it is no big crime.
364 2018-01-31T22:18:56  <gmaxwell> but after almost ten years of it, the cumulative weight is exhausting.
365 2018-01-31T22:19:11  <gmaxwell> and it causes serious long term practitioners to stop reading new proposals, which is unfortunate.
366 2018-01-31T22:19:25  <reardencode> gmaxwell: Yeah, I'm deeply interested in solving the problem of "My transaction is stuck for 3 months" for both payment processors trying to offer meaningful exchange locks, and users
367 2018-01-31T22:20:10  <reardencode> I absolutely should have googled harder for ealier proposals, and will try to come up with something that doesn't require 100 block maturity
368 2018-01-31T22:20:19  <arubi> maybe you could put an encoding of a signature and a txout that pays back to yourself in the witness :)
369 2018-01-31T22:20:34  *** Murch has quit IRC
370 2018-01-31T22:20:45  <arubi> something like gmaxwell's "would just be double-spent before they are considered fully expired"
371 2018-01-31T22:21:08  <gmaxwell> reardencode: but I think thats why no progress is made; it /might/ be unrealistic to do anything like this without a maturity.
372 2018-01-31T22:21:30  <reardencode> arubi: yeah, build a tx that can be spent by the receiver, or after "expiration" pays to the sender
373 2018-01-31T22:21:37  <gmaxwell> or more generally: it might be impossible to do without a significant cost.
374 2018-01-31T22:21:50  <gmaxwell> Free lunches are few and far between.
375 2018-01-31T22:21:54  *** Murch has joined #bitcoin-dev
376 2018-01-31T22:22:25  <reardencode> gmaxwell: yeah, I know I'm new here, but that part I'm aware of.
377 2018-01-31T22:23:28  <gmaxwell> "if after_time x else y" is non-monotone.  "y or if after_time x" is monotone.  The latter is 'can be spent by y until after a time it can be spent by either x or y'.
378 2018-01-31T22:24:49  <arubi> so 'expire or if after_time refund' is monotone?
379 2018-01-31T22:26:02  <arubi> rather 'can be spent by y or if after_time can refund x or pay y'
380 2018-01-31T22:26:36  <arubi> ah no :(
381 2018-01-31T22:27:16  <arubi> why pay y if you want it to expire.  you could say you just refund x, making it a double spend
382 2018-01-31T22:29:44  *** elichai2 has quit IRC
383 2018-01-31T22:30:26  <gmaxwell> what people want to accomplish is an expiration where no transaction fee is required.
384 2018-01-31T22:31:34  <gmaxwell> I /think/ this is fundimentally not possible without breaking reorgs (the maturity requirement just gives you a requirement that at least any reorg that breaks it is just some implausably large number of blocks)
385 2018-01-31T22:32:42  <reardencode> now that I understand the reorg implications, I agree that expiring transactions enforced by consensus have the same properties as mined coins.
386 2018-01-31T22:44:12  <reardencode> although the more I think about it, for the payment processor scenario, waiting up to up to 17 hours to release funds (depending on the processors risk tolerance) doesn't sound unpalatable and in the usual case (say 12 block expiration, mined in 3) the realistic level of certainty provided is quite high
387 2018-01-31T22:44:42  *** stalled has joined #bitcoin-dev
388 2018-01-31T22:45:02  <reardencode> it does make limit the use cases for expiring transactions significantly from what I had original envisioned though.
389 2018-01-31T22:45:19  <reardencode> (I / everyone else who's thought of it over the years)
390 2018-01-31T22:47:19  *** Giszmo has joined #bitcoin-dev
391 2018-01-31T22:54:39  *** Krellan has quit IRC
392 2018-01-31T22:55:16  *** elgrecoFL has joined #bitcoin-dev
393 2018-01-31T22:55:18  *** Krellan has joined #bitcoin-dev
394 2018-01-31T22:57:30  *** Giszmo has quit IRC
395 2018-01-31T22:57:40  <reardencode> https://github.com/zcash/zips/pull/131 active discussion on zcash
396 2018-01-31T23:01:39  *** Giszmo has joined #bitcoin-dev
397 2018-01-31T23:07:06  *** bugs_ has quit IRC
398 2018-01-31T23:07:18  <gmaxwell> zcash is just kinda broken to begin with, their shielded transactions are busted and can't even reorg by one block
399 2018-01-31T23:07:55  <gmaxwell> and they at least previously were going to deploy some consensus rule that nodes won't reorg by more than a couple blocks which opens up some pretty amusing attacks and random failures.
400 2018-01-31T23:08:43  <reardencode> color me unsurprised -- bitcoin (appears to be) the only cryptocurrency developed by adults ;)
401 2018-01-31T23:09:08  <gmaxwell> Zcash is weird because their crypto privacy stuff is very interesting... it's just all the other stuff is half assed.
402 2018-01-31T23:09:16  <gmaxwell> and mostly just optimized for pumping.
403 2018-01-31T23:09:36  <reardencode> yep -- I originally got super excited about zcash because of the privacy
404 2018-01-31T23:09:45  <gmaxwell> e.g. their difficulty control code is totally unstable and even with constant hashrate swings wildly. ... they deployed it without even doing the most trivial simulations of it.
405 2018-01-31T23:10:01  <gmaxwell> even bcash did a better job, and they're also pretty crazy. :)
406 2018-01-31T23:10:25  <reardencode> wow, low blow at the zcash folks
407 2018-01-31T23:11:24  <gmaxwell> hah
408 2018-01-31T23:11:38  <gmaxwell> Well it's just kind of embarassing for everyone.
409 2018-01-31T23:12:08  <contrapumpkin> well, even the snark stuff is pretty impractical for them isn't it?
410 2018-01-31T23:12:10  <reardencode> I swear I'll give up eventually, but it seems like expiring transactions could still be pretty useful in scenarios like end of 2017, ie. it's better to try to send a tx that expires tomorrow, and is then in an unspendable state for another 17 hours, than to have your coin stuck in limbo for 3 months
411 2018-01-31T23:12:50  <gmaxwell> reardencode: yes, no disagreement that it could be useful.  But man, there is so much stuff that would be _awesome_ so long as you ignore the costs; or ignore that it has to work in an adversarial setting. :)
412 2018-01-31T23:13:19  <reardencode> so in a common wallet use case, you might set an expiration of 200 blocks, and if it confirms within 100 blocks, no special rules are applied to spending the results, but if it takes > 100 blocks to confirm, then it must mature for 100 blocks before spending (like a coinbase tx)
413 2018-01-31T23:13:25  <gmaxwell> contrapumpkin: they're going to hardfork to replace it with newer stuff which is less unrealistic, though it doesn't sound like they're going to force txn to use it still.
414 2018-01-31T23:13:32  <contrapumpkin> ah
415 2018-01-31T23:14:46  <reardencode> gmaxwell: yeah, I'm not trying to get a free lunch here, I'm seriously invested in both the political, economic, and technological future of bitcoin, and I think that this is a problem with solving in the protocol
416 2018-01-31T23:15:00  <gmaxwell> reardencode: but what if it confirms at 100, and gets spent again at 100... then there is a reorg, and now the spend again is borked.
417 2018-01-31T23:15:28  *** wxss has quit IRC
418 2018-01-31T23:15:29  <gmaxwell> That seems bad to me.
419 2018-01-31T23:17:49  <reardencode> hmm, right, which means you might as wall just always wait or it to mature in the first place
420 2018-01-31T23:18:28  <reardencode> gmaxwell: any reference on why monotonicity is super important to the threat modeling of bitcoin?
421 2018-01-31T23:19:05  <reardencode> I'm trying to ponder the implications of having transaction expiration and letting the market sort out how many blocks deep / how long before its expiration a tx needs to be mined to make those coins full fungible
422 2018-01-31T23:19:31  <gmaxwell> not just threat model, it's necessary for the system to come to consensus.  Reorgs of any depth are possible (but fall off in probablity that decreases exponentially with depth under some somewhat plausable security assumptions).
423 2018-01-31T23:20:06  <gmaxwell> the only time the potential reorg depth becomes hard bounded is if you assume mining is centeralized.
424 2018-01-31T23:21:46  <reardencode> ok, I think I'm starting to get it actually -- what you don't want is to have fork-A coin and fork-B coin that accidentally can't come back together because transactions that some people care about can only exist in one or the other
425 2018-01-31T23:22:36  <reardencode> hence the coinbase must be deep before it can be spent so that miners don't have huge incentives to make persistent forks all the time
426 2018-01-31T23:23:36  <gmaxwell> not just incentives, so that it doesn't happen just by chance.
427 2018-01-31T23:23:46  <reardencode> mhm
428 2018-01-31T23:24:41  <gmaxwell> e.g. if there was no maturity and mined coins instantly went into circulation, then there could be a two block reorg (which happen just by chance from time to time, and are guarenteed to happen if there are sizable internet partitions) -- and then an unbounded number of transactions by third parties could be invalidated. (well the number of confirmed txn by third parties that would be invalidated wou
429 2018-01-31T23:24:47  <gmaxwell> ld be bounded by the block size, but still perhaps huge).
430 2018-01-31T23:25:04  <gmaxwell> it would mean that even if you trusted your counterparties quite a bit you couldn't regard transactions as confirmed until they were pretty deep.
431 2018-01-31T23:25:38  <reardencode> right, and similar would apply to expiring transactions, especially those mined close to their expiration, they would need to be pretty deep to be trustworthy
432 2018-01-31T23:25:43  <gmaxwell> also, these sorts of events can destroy coins, since you might have discarded the private keys required to reissue new transactions.
433 2018-01-31T23:26:50  <gmaxwell> Right, so one alternative idea that we've previously discussed is that you could have every txout carry with it the height of the highest non-monotone event in its history.. and any otherwise monotone txn that consume some set of inputs would propagate forward the maximum of the inputs heights as the heights on its outputs.
434 2018-01-31T23:27:42  <gmaxwell> Then every output would be colored by it's non-monotone taint, and you could consider that when accepting payments.  But even ignoring the complexity of doing this,  there is a concern where it would create a race to the bottom, just like we've seen with confirmation counts.
435 2018-01-31T23:28:37  <gmaxwell> E.g. many exchanges accept 3conf as irreversably confirmed even from more or less anonymous customers, even for very high value transactions... but this is kind of absurd, considering that 3deep reorgs have happened many times in bitcoin, and with mining centeralization at is is there are many different pools that if hacked/compromised could easily produce three deep reorgs.
436 2018-01-31T23:28:40  <reardencode> right, and then you have people trusting the new 1-confirmation coins (ie. coins which had an expiring transaction in the last block) and then they get all pissed off when their value is destroyed
437 2018-01-31T23:29:07  <gmaxwell> yea... so there would be commercial pressure to accept shallow coins, and people would because MOST of the time it's fine.
438 2018-01-31T23:29:21  <gmaxwell> and then everything blows up when a once-in-a-year event happens.
439 2018-01-31T23:29:30  <gmaxwell> so we're better off if the system just doesn't allow it.
440 2018-01-31T23:30:16  <gmaxwell> (you could imagine that it would be plausable to design a cryptocurrency where you could also trade debt as equivilent to coins, and it would work fine until someone fails to repay the debt, and then you get a big system wide failure)
441 2018-01-31T23:30:24  <reardencode> so the difference between this and a run of the mill double spend is that the run of the mill double spend attempt would require the double spender to collude with the miner to insert the malicious transaction into the bottom of the reorg?
442 2018-01-31T23:30:32  <gmaxwell> (so for everyone's benefit bitcoin requires transactions be presently solvent. :) )
443 2018-01-31T23:31:44  *** meshcollider has joined #bitcoin-dev
444 2018-01-31T23:31:55  <gmaxwell> reardencode: right a double spend requires malace by both the double spender and a reorg.. and only impacts decendents of the double spend. Whereas a reorg break doesn't even require malice at all by anyone (though malice can make it more likely), and it breaks every non-monotone thing, not just single transactions.
445 2018-01-31T23:32:30  *** mlz has quit IRC
446 2018-01-31T23:35:06  *** mlz has joined #bitcoin-dev
447 2018-01-31T23:36:17  <reardencode> gotcha, thanks for taking the time, I really appreciate it
448 2018-01-31T23:37:07  *** Belxjander has quit IRC
449 2018-01-31T23:37:47  *** wraithm has quit IRC
450 2018-01-31T23:37:54  <reardencode> gmaxwell: so, I'm a reasonably clever software engineer who would like to contribute to bitcoin, what's a better direction for me to invest my effort other than trying to make transactions expire?
451 2018-01-31T23:38:27  *** Giszmo has quit IRC
452 2018-01-31T23:38:35  <gmaxwell> Well working on consensus protocol changes is the worst way to get started, you'll go splat fast.
453 2018-01-31T23:39:01  <gmaxwell> it's better to first become really well informed about the system by working on other stuff.
454 2018-01-31T23:39:09  *** jcarpenter2 has joined #bitcoin-dev
455 2018-01-31T23:39:29  <gmaxwell> Then at least your ideas on protocol changes can be constucted and presented in a way that will be better accepted.
456 2018-01-31T23:40:17  <reardencode> gmaxwell: btw, I actually had written my thoughts on this up in full bip format: https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.mediawiki
457 2018-01-31T23:40:42  <reardencode> (not that I expect you to read it, but just that I did get pretty deep into understanding the protocol and prior BIPs before bringing it up in here)
458 2018-01-31T23:41:24  <gmaxwell> there are now so many 'bips' being written without being well informed or discussed I worry that BIPs in general are going to get abandoned.
459 2018-01-31T23:42:17  <reardencode> gmaxwell: doesn't surprise me -- I was trying to figure out how best to start and someone on reddit suggested writing it up in BIP style as a starting point, guess I was misled by a redditor ;)
460 2018-01-31T23:44:19  <gmaxwell> hm interesting.
461 2018-01-31T23:45:47  <gmaxwell> I haven't thought about why it was happening.  There are some factors that I was aware of.. e.g. the general idea about bips is that anything could get published, but since discussion is required first people would not bother going forward with non-viable stuff once they saw from discussion that it wasn't viable.
462 2018-01-31T23:46:18  *** kunla has quit IRC
463 2018-01-31T23:46:26  <gmaxwell> That worked for a long time, but a couple things changed, one is that because of political drama the bar for discussion became ultra low. e.g. stuff where no one bothered responding is getting assigned numbers now.
464 2018-01-31T23:46:31  *** Belxjander has joined #bitcoin-dev
465 2018-01-31T23:46:58  <gmaxwell> Also, because of people getting worn out it's more common that rehashed or broken proposals just get ignored.
466 2018-01-31T23:48:14  <midnightmagic> Maybe a two-tier. The first drafts aren't BIPs but instead RFC or something.
467 2018-01-31T23:48:26  <midnightmagic> Moved up to BIP once sufficient comment is acquired.
468 2018-01-31T23:48:26  <gmaxwell> oh also this channel is 99.9% dead.
469 2018-01-31T23:48:31  <gmaxwell> which probably doesn't help.
470 2018-01-31T23:48:48  <gmaxwell> this is the first discussion of over a couple lines here in a long time.
471 2018-01-31T23:48:56  <midnightmagic> It doesn't have to be anymore; the Prior Problem has been solved.
472 2018-01-31T23:49:06  <gmaxwell> yes but the stink remains.
473 2018-01-31T23:49:28  <midnightmagic> But ..  right. I was going to say.
474 2018-01-31T23:49:29  <gmaxwell> Actually I only bothered rejoining here to monitor for a while to decide if I should forcably shut down the channel or not.
475 2018-01-31T23:50:01  <gmaxwell> so far been leaning towards shutting it down... almost not traffic, and what is here is mostly people shouting into the void. :)
476 2018-01-31T23:50:03  <midnightmagic> I'm sure nanotube would be amenable to pretty much whatever you guys want to do with it.
477 2018-01-31T23:50:12  <gmaxwell> Sure.
478 2018-01-31T23:50:41  <midnightmagic> (Which I guess didn't need to be said but typing is a habit.)
479 2018-01-31T23:51:15  <gmaxwell> Based on the past I'm uneasy about actually using it again, I mean having technical control and historical mandate for -wizards hasn't prevent it from being a drama vector.
480 2018-01-31T23:52:07  <midnightmagic> That was mostly in the name. Seems to annoy the pathological ODD types.
481 2018-01-31T23:52:26  <gmaxwell> I don't think so.
482 2018-01-31T23:52:26  <midnightmagic> (imo)
483 2018-01-31T23:52:28  <midnightmagic> No?
484 2018-01-31T23:53:23  *** Guyver2 has quit IRC
485 2018-01-31T23:53:36  <gmaxwell> I think the non-viability of large unmoderated public discussion channels for useful discussion combined with a believe of entitlement to apparently public resources is the issue.
486 2018-01-31T23:53:50  <midnightmagic> Entitlement -- yes. "I'm a wizard, Harry."
487 2018-01-31T23:54:03  <midnightmagic> ODD and massive entitlement.
488 2018-01-31T23:54:09  <gmaxwell> midnightmagic: right "I'm a developer, Harry."
489 2018-01-31T23:54:18  <midnightmagic> heh
490 2018-01-31T23:54:42  <gmaxwell> we fix that with -core-dev because the set of people who might feel entitled is acceptably small.
491 2018-01-31T23:55:34  <midnightmagic> Channel name matches the topic. I'm pretty surprised how effective that is, personally. There seems to be some respect that engenders straight off, with a small corner.
492 2018-01-31T23:55:39  <gmaxwell> I think a better fix which I haven't tried yet is to replace channels with ones with clear owners; to eliminate the entitlement problem.
493 2018-01-31T23:55:54  <contrapumpkin> #gmaxwell
494 2018-01-31T23:56:24  <gmaxwell> Pretty much exactly that.  something like #gmaxwells-den and then no one gets bent when gmaxwell sets the freeking rules.
495 2018-01-31T23:56:31  <midnightmagic> I believe that would make people think they were ego-busting.
496 2018-01-31T23:56:36  <midnightmagic> (To invade it.)
497 2018-01-31T23:56:58  <gmaxwell> well you just ban them. I never minded banning people in wizards or here, the annoying drama is the whitenighting after the fact.
498 2018-01-31T23:57:27  <gmaxwell> By people who are usually okay but aren't yet worn out by the borderline behavior and haven't really internalized that if the main anchors of the venue walk the venue is dead.
499 2018-01-31T23:57:37  <midnightmagic> I still think a multi-level set of introducers would mean that, e.g. I could randomly invite a bunch of people who've asked me, and then they invite people who ask them, and so on until the shitheads appear. Invading that set would be way more time-consuming than just registering a freenode account.
500 2018-01-31T23:58:14  <gmaxwell> Having open venues has a lot of advantages. Including the fact that the people with the most to offer are not going to jump through a lot of hoops.
501 2018-01-31T23:58:37  <midnightmagic> Yes. Anchors. That was something I've grasped pretty much right from the start. I've often, often, repetitively said that if e.g. sipa goes away the point of the channel-under-discussion pretty much goes away.
502 2018-01-31T23:59:50  <gmaxwell> I /think/ making ownership explicit is virtuious because it's almost always implicit anyways-- e.g. this channel died virtually completely when we left. 10000 fold reduction in daily traffic, easily.  Effectively the anchors owned it, but got abused when they wanted to do whatever was needed to keep it usable for them.