1 2015-10-01T01:43:32 *** lightningbot has joined #bitcoin-dev
2 2015-10-01T01:43:33 -sendak.freenode.net- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
3 2015-10-01T01:43:53 *** dangerm00se has quit IRC
4 2015-10-01T01:54:24 *** notj has quit IRC
5 2015-10-01T01:55:56 *** mjerr has quit IRC
6 2015-10-01T02:01:00 *** StormDev2 has quit IRC
7 2015-10-01T02:01:19 *** StormDev2 has joined #bitcoin-dev
8 2015-10-01T02:04:11 *** tawster has quit IRC
9 2015-10-01T02:05:23 *** [Derek] has joined #bitcoin-dev
10 2015-10-01T02:06:11 *** StormDev2 has quit IRC
11 2015-10-01T02:06:37 *** StormDev2 has joined #bitcoin-dev
12 2015-10-01T02:11:32 *** CodeShark_ has quit IRC
13 2015-10-01T02:12:41 *** Iriez has quit IRC
14 2015-10-01T02:13:58 *** AvatarA has quit IRC
15 2015-10-01T02:16:24 *** YoY has joined #bitcoin-dev
16 2015-10-01T02:16:25 *** AaronvanW has quit IRC
17 2015-10-01T02:20:09 *** YOU-G has joined #bitcoin-dev
18 2015-10-01T02:20:26 *** CheckDavid has joined #bitcoin-dev
19 2015-10-01T02:26:29 *** sparetire_ has joined #bitcoin-dev
20 2015-10-01T02:28:33 *** StormDev2 has quit IRC
21 2015-10-01T02:28:53 *** StormDev2 has joined #bitcoin-dev
22 2015-10-01T02:30:25 *** ericmuyser has joined #bitcoin-dev
23 2015-10-01T02:31:00 *** n0n0__ has quit IRC
24 2015-10-01T02:32:51 *** pikefloyd has joined #bitcoin-dev
25 2015-10-01T02:35:06 *** roxtrongo has quit IRC
26 2015-10-01T02:35:12 *** ericmuyser has quit IRC
27 2015-10-01T02:37:10 *** roxtrongo has joined #bitcoin-dev
28 2015-10-01T02:40:03 *** agricocb has quit IRC
29 2015-10-01T02:40:41 *** StormDev2 has quit IRC
30 2015-10-01T02:42:18 *** won9 has quit IRC
31 2015-10-01T02:44:01 *** p15x has quit IRC
32 2015-10-01T02:45:58 *** btcdrak has left #bitcoin-dev
33 2015-10-01T02:47:03 *** melvster has quit IRC
34 2015-10-01T02:49:46 *** pfallenop has quit IRC
35 2015-10-01T02:50:19 *** pfallenop has joined #bitcoin-dev
36 2015-10-01T02:50:45 *** Iriez has joined #bitcoin-dev
37 2015-10-01T02:52:31 *** DatBeeDoe has joined #bitcoin-dev
38 2015-10-01T02:53:54 *** pfallenop has quit IRC
39 2015-10-01T02:54:18 *** pfallenop has joined #bitcoin-dev
40 2015-10-01T02:56:12 *** ThomasV has joined #bitcoin-dev
41 2015-10-01T02:58:17 *** halffull has joined #bitcoin-dev
42 2015-10-01T03:00:28 *** roxtrong_ has joined #bitcoin-dev
43 2015-10-01T03:00:41 *** melvster has joined #bitcoin-dev
44 2015-10-01T03:03:40 *** roxtrongo has quit IRC
45 2015-10-01T03:04:19 *** rnvk has left #bitcoin-dev
46 2015-10-01T03:04:36 *** dfletcher has quit IRC
47 2015-10-01T03:05:19 *** InternetFriend has joined #bitcoin-dev
48 2015-10-01T03:06:13 *** tawster has joined #bitcoin-dev
49 2015-10-01T03:06:50 *** Palsson has quit IRC
50 2015-10-01T03:12:02 *** agricocb has joined #bitcoin-dev
51 2015-10-01T03:12:10 *** InternetFriend has quit IRC
52 2015-10-01T03:16:40 *** moa has joined #bitcoin-dev
53 2015-10-01T03:17:37 *** InternetFriend has joined #bitcoin-dev
54 2015-10-01T03:22:35 *** Palsson has joined #bitcoin-dev
55 2015-10-01T03:25:05 *** noobfikt has joined #bitcoin-dev
56 2015-10-01T03:26:20 *** billotronic has joined #bitcoin-dev
57 2015-10-01T03:29:18 *** roxtrong_ has quit IRC
58 2015-10-01T03:30:54 *** InternetFriend has quit IRC
59 2015-10-01T03:31:07 *** ericmuyser has joined #bitcoin-dev
60 2015-10-01T03:33:26 *** halffull has quit IRC
61 2015-10-01T03:36:07 *** ericmuyser has quit IRC
62 2015-10-01T03:39:19 *** InternetFriend has joined #bitcoin-dev
63 2015-10-01T03:40:28 *** Guyver2 has joined #bitcoin-dev
64 2015-10-01T03:43:00 *** ericmuyser has joined #bitcoin-dev
65 2015-10-01T03:50:21 *** InternetFriend has quit IRC
66 2015-10-01T03:50:26 *** Cocodude has joined #bitcoin-dev
67 2015-10-01T03:51:07 *** rdymac has joined #bitcoin-dev
68 2015-10-01T03:51:43 *** YOU-G has quit IRC
69 2015-10-01T03:53:37 *** tych0 has joined #bitcoin-dev
70 2015-10-01T03:55:14 *** notj has joined #bitcoin-dev
71 2015-10-01T03:55:36 *** blackjid has quit IRC
72 2015-10-01T03:55:46 *** _tmh has joined #bitcoin-dev
73 2015-10-01T03:56:05 *** blackjid has joined #bitcoin-dev
74 2015-10-01T04:00:31 *** DatBeeDoe has quit IRC
75 2015-10-01T04:00:48 *** notj has quit IRC
76 2015-10-01T04:01:02 *** DatBeeDoe has joined #bitcoin-dev
77 2015-10-01T04:05:54 *** dfletcher has joined #bitcoin-dev
78 2015-10-01T04:06:52 *** aschildbach has joined #bitcoin-dev
79 2015-10-01T04:08:54 *** maraoz has joined #bitcoin-dev
80 2015-10-01T04:14:33 *** InternetFriend has joined #bitcoin-dev
81 2015-10-01T04:14:41 *** justanotheruser has quit IRC
82 2015-10-01T04:15:08 *** InternetFriend has quit IRC
83 2015-10-01T04:15:19 *** damethos has quit IRC
84 2015-10-01T04:15:49 *** damethos has joined #bitcoin-dev
85 2015-10-01T04:17:41 *** mjerr has joined #bitcoin-dev
86 2015-10-01T04:23:13 *** DougieBot5000 has joined #bitcoin-dev
87 2015-10-01T04:23:51 *** noobfikt has quit IRC
88 2015-10-01T04:24:06 *** DatBeeDoe has quit IRC
89 2015-10-01T04:31:40 *** nsh has quit IRC
90 2015-10-01T04:34:04 *** rubensayshi has quit IRC
91 2015-10-01T04:35:00 *** rubensayshi has joined #bitcoin-dev
92 2015-10-01T04:37:34 *** nsh has joined #bitcoin-dev
93 2015-10-01T04:41:18 *** zooko has joined #bitcoin-dev
94 2015-10-01T04:42:16 *** aschildbach has quit IRC
95 2015-10-01T04:42:28 *** nwilcox has quit IRC
96 2015-10-01T04:47:34 <zooko> Is hearn still banned from this channel?
97 2015-10-01T04:47:39 *** c0rw1n is now known as c0rw|away
98 2015-10-01T04:51:34 *** d_t has joined #bitcoin-dev
99 2015-10-01T04:51:49 *** Giszmo has joined #bitcoin-dev
100 2015-10-01T04:55:49 <jcorgan> i don't think so
101 2015-10-01T04:57:02 *** GAit has joined #bitcoin-dev
102 2015-10-01T04:57:54 *** nsh has quit IRC
103 2015-10-01T04:59:26 *** _tmh has quit IRC
104 2015-10-01T04:59:47 *** _tmh has joined #bitcoin-dev
105 2015-10-01T05:00:47 *** hoystein_ has quit IRC
106 2015-10-01T05:01:48 *** ParadoxSpiral has joined #bitcoin-dev
107 2015-10-01T05:01:58 *** damethos has quit IRC
108 2015-10-01T05:02:47 *** bedeho has joined #bitcoin-dev
109 2015-10-01T05:06:36 *** nsh has joined #bitcoin-dev
110 2015-10-01T05:10:10 *** lightningbot has joined #bitcoin-dev
111 2015-10-01T05:10:10 -leguin.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
112 2015-10-01T05:12:37 <Guest1234> BlueMatt no, I was just curious and if it was needed I could try and code it
113 2015-10-01T05:12:46 *** nwilcox has joined #bitcoin-dev
114 2015-10-01T05:13:00 <jgarzik> zooko, no - but disruptive behavior can be banned again
115 2015-10-01T05:13:12 *** FredEE has joined #bitcoin-dev
116 2015-10-01T05:13:24 <jgarzik> IMNSHO it was an emotional reaction, better done by one of the other chanops
117 2015-10-01T05:13:31 *** sneak has quit IRC
118 2015-10-01T05:14:30 *** sneak has joined #bitcoin-dev
119 2015-10-01T05:14:39 *** kyuupichan has quit IRC
120 2015-10-01T05:16:02 *** GandalfTheWizard has quit IRC
121 2015-10-01T05:16:14 *** xenog has joined #bitcoin-dev
122 2015-10-01T05:17:12 <zooko> tbh I didn't understand what happened. I guess the ban was motivated by other stuff from other forums, that I haven't read.
123 2015-10-01T05:18:43 *** GandalfTheWizar1 has joined #bitcoin-dev
124 2015-10-01T05:19:00 *** YoY has quit IRC
125 2015-10-01T05:19:01 *** GandalfTheWizar1 has quit IRC
126 2015-10-01T05:20:11 *** lightningbot_ has joined #bitcoin-dev
127 2015-10-01T05:20:57 *** FredEE has quit IRC
128 2015-10-01T05:23:23 *** damethos has joined #bitcoin-dev
129 2015-10-01T05:24:01 *** jeadre has quit IRC
130 2015-10-01T05:24:27 *** Jaume has joined #bitcoin-dev
131 2015-10-01T05:25:34 *** jeadre has joined #bitcoin-dev
132 2015-10-01T05:25:44 *** kyuupichan has joined #bitcoin-dev
133 2015-10-01T05:26:03 *** notj has joined #bitcoin-dev
134 2015-10-01T05:26:12 *** Cocodude has left #bitcoin-dev
135 2015-10-01T05:30:10 *** lig0tningbot has joined #bitcoin-dev
136 2015-10-01T05:32:48 *** bedeho has quit IRC
137 2015-10-01T05:34:18 *** notj has quit IRC
138 2015-10-01T09:18:05 *** lightningbot has joined #bitcoin-dev
139 2015-10-01T09:18:22 <morcos> ok, if i can move it along, no objections so far. so lets let BlueMatt get his code a bit more complete, and then we can all keep trying to attack it
140 2015-10-01T09:18:27 <morcos> next subtopic is chain limits
141 2015-10-01T09:18:27 <sipa> morcos: ack
142 2015-10-01T09:18:29 <gmaxwell> OK.
143 2015-10-01T09:18:31 <jgarzik> ack
144 2015-10-01T09:18:32 <BlueMatt> jtimon: I responded on that pull with something that used the fee estimator, but never submitted it as a pr
145 2015-10-01T09:18:47 <CodeShark> ack
146 2015-10-01T09:18:50 <morcos> all of these approachs are much more attackable the bigger package sizes can be
147 2015-10-01T09:18:52 <BlueMatt> gmaxwell: yes, that is something else we need to discuss
148 2015-10-01T09:18:59 <morcos> the proposed limits that we implemented already are too generous
149 2015-10-01T09:19:01 <sipa> ### SUBTOPIC: CHAIN LIMITS
150 2015-10-01T09:19:03 <BlueMatt> two more things to discuss: a) lower package size limits
151 2015-10-01T09:19:06 <jtimon> gmaxwell: I agree that this should be mostly orthogonal to the fee estimator, but at the same time I believe a dynamic minRelayFee should be calculated withing the estimator, that's my concern
152 2015-10-01T09:19:12 <BlueMatt> b) accepting multiple txn at once
153 2015-10-01T09:19:16 *** lightnin7bot has joined #bitcoin-dev
154 2015-10-01T09:19:25 <morcos> oh please lets hold off on b)
155 2015-10-01T09:19:35 <morcos> thats a whole differnt ball of wax
156 2015-10-01T09:19:45 <morcos> and not needed right now
157 2015-10-01T09:19:49 <jgarzik> +1
158 2015-10-01T09:19:51 <BlueMatt> oh, and, maybe, decay constant for #6722, but maybe thats too implementation-detail for this talk
159 2015-10-01T09:19:59 <BlueMatt> morcos: I think its quite simple
160 2015-10-01T09:20:05 <BlueMatt> use mapOrphans to accept multiple txn at once
161 2015-10-01T09:20:15 <BlueMatt> i just wanted to mention it to make sure no one would complain if i did that
162 2015-10-01T09:20:20 <gmaxwell> BlueMatt: stop. offtopic now. What the heck is the new topic?
163 2015-10-01T09:20:26 <morcos> can that PLEASE be a separate pull
164 2015-10-01T09:20:31 <jgarzik> <sipa> ### SUBTOPIC: CHAIN LIMITS
165 2015-10-01T09:20:32 <sipa> ack morcos
166 2015-10-01T09:20:36 <BlueMatt> morcos: ok
167 2015-10-01T09:20:39 <jgarzik> +1 morcos
168 2015-10-01T09:20:40 <BlueMatt> hence why i mentioned it :p
169 2015-10-01T09:20:44 <BlueMatt> anyway, so chain limits.....
170 2015-10-01T09:20:47 <sipa> morcos: elaborate on topic
171 2015-10-01T09:20:54 <morcos> hmm
172 2015-10-01T09:20:56 <BlueMatt> all of the mempool limiting stuff is wayyyyy easier to attack if you have bigger chain limits
173 2015-10-01T09:21:06 <BlueMatt> ratio of max-chain-size to block size
174 2015-10-01T09:21:07 <sipa> BlueMatt: you mean smaller chain limits :)
175 2015-10-01T09:21:16 <sipa> ah, attackable
176 2015-10-01T09:21:16 <sipa> yes
177 2015-10-01T09:21:17 <morcos> ok one problem is that you can construct funny looking packages that have a very high descendant package feerate and a very low ancestor package feerate
178 2015-10-01T09:21:22 <BlueMatt> ratio of max-chain-size to reasonable tx size, etc
179 2015-10-01T09:21:24 <BlueMatt> all matter a lot
180 2015-10-01T09:21:27 <morcos> these packages will not be mined any time soon , nor evicted
181 2015-10-01T09:21:42 <morcos> they serve to clog up your mempool (until time based eviction)
182 2015-10-01T09:21:50 <gmaxwell> I thought just limiting depth was reasonably prudent.
183 2015-10-01T09:21:54 <morcos> this is of course extremely bad right now without CPFP mining code
184 2015-10-01T09:21:56 <CodeShark> shouldn't the total fee calculation weigh ancestors more than descendants?
185 2015-10-01T09:21:59 <jgarzik> +1 gmaxwell
186 2015-10-01T09:22:09 <sdaftuar> gmaxwell: what exactly do you mean by depth?
187 2015-10-01T09:22:44 <jgarzik> I'm highly biased, but I think time limiting should go sooner rather than later as it serves as a natural limit for many of these other attributes
188 2015-10-01T09:22:46 <morcos> right now the effective limits in place are 100 ancestors 900kb ancestor package size, 1000 descendants, 2500kb descendant package size
189 2015-10-01T09:22:46 <gmaxwell> I am not aware of any applications that require very long chains of unconfirmed transactions right now. Though I realize that both size and depth are an issue, because of tx soft size limits, if the depth can not be longer than 10 you can still fit in a block.
190 2015-10-01T09:23:11 <gmaxwell> but I was just just thinking in terms of a linear chain, and thats .. a problem.
191 2015-10-01T09:23:13 <jgarzik> vast majority of user applications do not construct long chains at all -- they avoid it
192 2015-10-01T09:23:14 <gmaxwell> :(
193 2015-10-01T09:23:15 <morcos> the reaosn to have larger descendant packages is you can't control that yourself, somebody pays you and bob, and bob chains off a million descendants and he ends up screwing you
194 2015-10-01T09:23:15 <CodeShark> the metric should be something like total fees / expected time to confirmation (or something like that)
195 2015-10-01T09:23:22 <jgarzik> let's not over-optimize for an unusual user case
196 2015-10-01T09:23:53 <morcos> so i'd propose that we reduce at least to : ancestor = 25/250kb descendant = 50/500kb
197 2015-10-01T09:23:59 <BlueMatt> total size of packages effects whether your decision making in 6722 is optimal for more cases or just vaguely optimal
198 2015-10-01T09:24:08 <gmaxwell> jgarzik: some of this is due to malleability which is being fixed over time; so we should not be too agressive there.
199 2015-10-01T09:24:08 <BlueMatt> total package tx count is more related to runtime
200 2015-10-01T09:24:21 <jgarzik> there are user risks inherent in long chains that incentivize against building them at all
201 2015-10-01T09:24:22 <morcos> using data from april and may of this year, each of those limits on its own would affect no more than 5% of txs
202 2015-10-01T09:24:25 <sipa> jgarzik: i think time limiting should definitely be part of the release, but as some of the alternative limiting code patches already have that integrated, it may not be useful to pre-merge that part already
203 2015-10-01T09:24:29 <jgarzik> gmaxwell, agree; it's a balance
204 2015-10-01T09:24:56 <gmaxwell> There are two issues as I understand it, runtime blowup from deep chains; and packages that can't be mined in one go (over 1mb) (or at least are so big that quantization in mining decisions really lowers their prospects of being mined)
205 2015-10-01T09:24:59 <jgarzik> sipa, nod - time-limiting PR is closed until dust settles
206 2015-10-01T09:25:02 <jgarzik> can be re-created easily
207 2015-10-01T09:25:12 <jgarzik> just waiting for the moment :)
208 2015-10-01T09:25:26 <jgarzik> notably packages
209 2015-10-01T09:25:28 <morcos> whether those limits are sufficiently aggresive or not remains to be seen, but if we think those are politcially palpable it will be helpful to think about what attacks we can construe on 6722 if constrained to those limits
210 2015-10-01T09:25:42 <morcos> gmaxwell: its worse than that
211 2015-10-01T09:25:47 <sipa> we can start with relatively lax limits
212 2015-10-01T09:26:08 <sipa> if specific attacks are found that cause large packages/chains to cause probably, we can recosinder the defaults
213 2015-10-01T09:26:21 <morcos> if you have a say 900kb ancestor package limit, then even if the ancestor fee rate is reasonably high, default mining code is likely going to find 100kb of very high fee txs to include first, and then there won't be room for your ancestor package
214 2015-10-01T09:26:25 <BlueMatt> I think almost every attack we've come up with against 6722 is directly limited by package size/volume
215 2015-10-01T09:26:41 <jgarzik> time limiting will wind up evicting an early ancestor of a long chain, of course
216 2015-10-01T09:26:46 <morcos> sipa: what is relatively lax?
217 2015-10-01T09:26:50 <gmaxwell> I think limits that allow 3 or 4 deep linear chains of ordinary dependant transactions are sufficient to cover all current usecases that I'm aware of... (e.g. not unduely limiting)
218 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
219 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
220 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
221 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
222 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
223 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
224 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
225 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
226 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
227 2015-10-01T09:26:57 <sipa> morcos: what we have now? :)
228 2015-10-01T09:26:58 <jgarzik> that mitigates some attacks, which is good.
229 2015-10-01T09:27:10 <jgarzik> +1 gmaxwell
230 2015-10-01T09:27:11 <morcos> i'd call those VERY lax
231 2015-10-01T09:27:12 <CodeShark> so no more satoshi dice? ;)
232 2015-10-01T09:27:15 <gmaxwell> morcos: sorry, thats what I was going for with "quantization effects", I just mean the transaction is in or out, and a big package is more costly than its size implies.
233 2015-10-01T09:27:26 <jgarzik> CodeShark: those guys wait for confirmations these days
234 2015-10-01T09:27:33 <jgarzik> too many thefts
235 2015-10-01T09:27:45 *** slowpoison has joined #bitcoin-dev
236 2015-10-01T09:27:55 <morcos> sipa, you think my new proposal is too strict: ancestor = 25/250kb descendant = 50/500kb
237 2015-10-01T09:28:19 <sipa> all good to me... i think they're all way beyond what is needed
238 2015-10-01T09:28:19 <BlueMatt> what you really want is smaller package size, not tx count...that part worries me more
239 2015-10-01T09:28:25 <BlueMatt> and you really cant go very small
240 2015-10-01T09:28:38 <BlueMatt> since one of the important metrics is ratio of package size to block size :(
241 2015-10-01T09:28:39 *** FredEE has joined #bitcoin-dev
242 2015-10-01T09:28:47 <jgarzik> I think morcos limits are lax :)
243 2015-10-01T09:28:47 <BlueMatt> 500kb is much larger than you wait, ideally, I think
244 2015-10-01T09:28:53 <BlueMatt> want
245 2015-10-01T09:28:56 *** Bootvis has joined #bitcoin-dev
246 2015-10-01T09:28:58 <morcos> the way i view it is after months of working on this stuff , we keep finding slightly more obscure attacks and fixing them , if the limits are just significantly smaller to begin with it just gives us a bigger safety buffer
247 2015-10-01T09:29:00 <BlueMatt> but probably a reasonable limit
248 2015-10-01T09:29:12 <sipa> morcos: ack then
249 2015-10-01T09:29:13 *** priidu has joined #bitcoin-dev
250 2015-10-01T09:29:14 <sdaftuar> +1 morcos
251 2015-10-01T09:29:25 <jgarzik> ack morcos limits - and would be ok with smaller limits
252 2015-10-01T09:29:33 <sipa> i have no good intuition for what is needed here... i would think much smaller is acceptable
253 2015-10-01T09:29:41 <sipa> but no need to unnecessarily restrict things
254 2015-10-01T09:30:09 <sdaftuar> seems like next step is to email the dev list and see if anyone has use cases we
255 2015-10-01T09:30:09 <morcos> so i don't wnat to email the dev list and propose different limits over and over
256 2015-10-01T09:30:12 <sdaftuar> 're missing?
257 2015-10-01T09:30:14 <morcos> should i aim for even smaller?
258 2015-10-01T09:30:55 <sipa> i think 25/50k 50/100k would also be fine :)
259 2015-10-01T09:31:09 <sdaftuar> so 100k -> 50k for standard transactions?
260 2015-10-01T09:31:10 <CodeShark> not sure I understand that notation - what's the numerator?
261 2015-10-01T09:31:15 <sipa> CodeShark: number of transactions
262 2015-10-01T09:31:37 <BlueMatt> 100k would be ideal for mempool limiting stuff, imo
263 2015-10-01T09:31:40 <CodeShark> so allocate 50k for 25 transactions, allocate 100k for 50?
264 2015-10-01T09:31:44 <BlueMatt> but I think thats more constricting than we want to be?
265 2015-10-01T09:31:52 *** noobfikt has joined #bitcoin-dev
266 2015-10-01T09:31:52 <BlueMatt> does someone have numbers for how many single txn are over 50kb?
267 2015-10-01T09:31:54 <sipa> ### MEETING AT 50%
268 2015-10-01T09:32:10 <morcos> ok, i will email the dev list with several proposals
269 2015-10-01T09:32:11 <gmaxwell> sdaftuar: when emailing the dev list please pass your message by a second set of eyes to make sure you don't accidentally make people think things will be forbidden completely when instead they's just have to wait for the first layer to confirm.
270 2015-10-01T09:32:31 <morcos> gmaxwell: yes good to emphasize
271 2015-10-01T09:32:34 <sdaftuar> gmaxwell: yep. i'll let morcos do it anyway :)
272 2015-10-01T09:32:44 <sipa> anything else to discuss about chain limits?
273 2015-10-01T09:32:44 <morcos> i think not reducing the std tx limit of 100k makes sense right?
274 2015-10-01T09:32:55 *** aidanh has quit IRC
275 2015-10-01T09:32:59 <morcos> and if you want to chain one thing of that, might it not need to be of almost similar size?
276 2015-10-01T09:33:00 <gmaxwell> sdaftuar: (we've suffered this with the dust limit stuff; where people _constantly_ think the dust limit prevents you from _spending_ low value utxo, partially because initial communications were unclear and triggered some confused press)
277 2015-10-01T09:33:09 <morcos> i guess you only need to spend one of its outputs
278 2015-10-01T09:33:11 *** FredEE has quit IRC
279 2015-10-01T09:33:28 <jgarzik> gmaxwell, a high hashrate miner was even confused about that....
280 2015-10-01T09:33:48 <morcos> ok will post proposed email here tomorrow, with some stats on historical txs
281 2015-10-01T09:33:48 <gmaxwell> morcos: std limit is largely for legacy reasons (old validation code loaded all input txn into memory), but it turns out to be useful in many surprising places (e.g. capping sighash cost), so I think we should not touch it. We've had very few complaints about it.
282 2015-10-01T09:34:01 <sdaftuar> ok if we're done with chain limits, can we talk briefly about default mempool size?
283 2015-10-01T09:34:17 <sipa> ### SUBTOPIC: default mempool size
284 2015-10-01T09:34:22 <morcos> think BlueMatt agreed to go at least 300MB, thats seems enough for me for now
285 2015-10-01T09:34:39 <morcos> but i do think 100MB is too low for default
286 2015-10-01T09:34:39 <jgarzik> Previously discussions have measured size in days first, size second.
287 2015-10-01T09:34:49 <morcos> 300MB is less thna 1 day
288 2015-10-01T09:34:51 <sdaftuar> well we're under a day still
289 2015-10-01T09:34:57 <sdaftuar> but 300MB seems much better to me
290 2015-10-01T09:34:58 <morcos> but not REALLY because its a day backlog
291 2015-10-01T09:35:01 <jgarzik> 2 days, was the past discussion
292 2015-10-01T09:35:24 <morcos> if you are the bottom of the 300MB mempool you're probably 2 days away from getting confirmed
293 2015-10-01T09:35:25 <gmaxwell> This has some interaction with the minimum supported amount of memory to run bitcoin core, but 300mb sounds fine to me. We should perhaps autoscale it on low memory systems; though I don't think we have any portable way to accomidate that. I think for now lets just do something stupid/simple.
294 2015-10-01T09:35:25 <jonasschnelli> the current default is "unlimited", i think it should be at least 300MB.
295 2015-10-01T09:35:37 <sipa> jonasschnelli: 2 days, at max block size, would be 900 MB usage
296 2015-10-01T09:35:44 *** wpalczynski has joined #bitcoin-dev
297 2015-10-01T09:35:49 <sipa> eh, jgarzik ^
298 2015-10-01T09:36:05 <wumpus> 900MB is unacceptable imo
299 2015-10-01T09:36:05 *** CoinMuncher has quit IRC
300 2015-10-01T09:36:09 <morcos> lets stick with 300... its plenty for the current usage we're seeing. its a command line option
301 2015-10-01T09:36:11 <sdaftuar> ok if 300MB is our current proposal that's fine with me (move along)...
302 2015-10-01T09:36:14 <wumpus> yes
303 2015-10-01T09:36:22 <jonasschnelli> ack
304 2015-10-01T09:36:25 <BlueMatt> yea, I dont like 900, 300 ack
305 2015-10-01T09:36:27 <morcos> future changes where people want to really take advantage of weekly cycles can consider ways to reasonably make the mempool biger
306 2015-10-01T09:36:30 <BlueMatt> hence why I picked that :p
307 2015-10-01T09:36:40 <sipa> topic mempool limiting done?
308 2015-10-01T09:36:43 <morcos> ack
309 2015-10-01T09:36:44 <sdaftuar> ack
310 2015-10-01T09:36:45 <BlueMatt> ack
311 2015-10-01T09:36:46 <gmaxwell> ack
312 2015-10-01T09:36:52 <wumpus> next topic, upcoming CLTV softfork?
313 2015-10-01T09:36:52 <jgarzik> +1
314 2015-10-01T09:36:59 <Luke-Jr> is there a reliable way to measure system RAM?
315 2015-10-01T09:37:02 <Luke-Jr> oh well, nm
316 2015-10-01T09:37:06 <sipa> ### TOPIC: CLTV softfork
317 2015-10-01T09:37:09 <wumpus> Luke-Jr: let's take that offline
318 2015-10-01T09:37:31 *** aidanh has joined #bitcoin-dev
319 2015-10-01T09:37:48 <maaku> sipa: clarity on topic? we discussing softfork deployment strategy, or content of softfork
320 2015-10-01T09:37:48 <sipa> anyone has anything to say on CLTV?
321 2015-10-01T09:37:49 <btcdrak> So the question is, do we want to push out CLTV using IsSuperMajority now, or wait for BIP68+CSV to be finished?
322 2015-10-01T09:37:50 <Luke-Jr> so is versionbits ready? or would we be triggering on >=?
323 2015-10-01T09:38:01 <wumpus> so, CLTV is ready for merge, including backport PRs. But there are some people talking about including other stuff in the softfork as well such as CSV.
324 2015-10-01T09:38:01 <sipa> maaku: deployment
325 2015-10-01T09:38:34 <wumpus> also the content I suppose, as it affects deployment
326 2015-10-01T09:38:36 <btcdrak> The other question is are we going to mask out BIP101's blockversion or stick with a test of blockver >= 4 with no mask
327 2015-10-01T09:38:38 <Luke-Jr> wumpus: if we use versionbits, CMV might as well be independent
328 2015-10-01T09:38:40 <wumpus> CLTV could be run out now
329 2015-10-01T09:38:50 *** dEBRUYNE has joined #bitcoin-dev
330 2015-10-01T09:38:58 <sipa> if versionbits is deployed for a future softfork, we'll need to wait until all ISM-based softforks are over
331 2015-10-01T09:39:02 <maaku> regarding content, I'd much prefer explaining the soft-fork with all the various lock-time stuff together
332 2015-10-01T09:39:10 <gmaxwell> CLTV BIP is a year old today, the design is older still. It's gone through a lot of maturation, and is clearly quite mature and ready (there is even some altcoin deployment). So, obviously I am ACK on the view that its ready for short term deployment.
333 2015-10-01T09:39:12 <wumpus> versionbits has no code yet, so I think it's off the table for this one
334 2015-10-01T09:39:17 <Luke-Jr> btcdrak: it's important that we don't make blockver>=4 a consensus rule long-term or we lose a bit for versionbits
335 2015-10-01T09:39:18 <maaku> it'd be a lot of wasted effort to pull of two soft-forks
336 2015-10-01T09:39:34 <CodeShark> versionbits has code - but not complete ;)
337 2015-10-01T09:39:37 <wumpus> it will need to be written, tested, reviewed, and we'll be a few months further
338 2015-10-01T09:39:38 <sipa> IMHO, once versionbits exists, softforks can be iterated much more quickly
339 2015-10-01T09:39:39 <gmaxwell> maaku: we need to become more adept at keeping a pipeline of soft forks going, though.. A thing to keep in mind.
340 2015-10-01T09:39:52 <wumpus> that's true sipa
341 2015-10-01T09:39:56 <sipa> and once versionbits exists, there is less overhead from "scheduling another softfork"
342 2015-10-01T09:39:57 <bsm1175321> +1 gmaxwell
343 2015-10-01T09:39:58 <btcdrak> maaku how far away would BIP68/112/113 be from merge?
344 2015-10-01T09:40:09 <jl2012> sipa: no need for waiting if the future softfork includes CLTV
345 2015-10-01T09:40:15 <maaku> btcdrak: as far as I am aware they are all merge-ready
346 2015-10-01T09:40:21 <jgarzik> If it's ready go to, go
347 2015-10-01T09:40:24 * Luke-Jr notes once CLTV softfork >=4 is merged, we won't be able to do versionbits until it completes deployment
348 2015-10-01T09:40:35 <sipa> Luke-Jr: indeed, i noted that too
349 2015-10-01T09:40:44 <sipa> though i don't have a strong opinion
350 2015-10-01T09:40:46 <jtimon> btcdrak I think your plan of waaiting for 0.12 and move with CLTV (and RCLTV and nVersion bits too if they are ready on time) was good
351 2015-10-01T09:40:46 <morcos> Luke-Jr: no verstionbits can just = versionbits +CLTV
352 2015-10-01T09:40:48 <CodeShark> about how long do we expect deployment to take?
353 2015-10-01T09:40:51 <gmaxwell> Maturity of CLTV is such that I think we could achieve very fast deployment. There is strong demand for it.
354 2015-10-01T09:41:06 <btcdrak> if the CSV still will be ready in the next month/6 weeks I would hold off deployment of CLTV personally.
355 2015-10-01T09:41:10 <gmaxwell> CodeShark: I believe certantly no more time than BIP66.
356 2015-10-01T09:41:11 <wumpus> I don't like binding 0.12 to softfork deployment
357 2015-10-01T09:41:11 <Luke-Jr> morcos: ?
358 2015-10-01T09:41:19 <CodeShark> if deployment is a matter of a month or two, I'll wait - if it's going to take six months, I'd rather do version bits first
359 2015-10-01T09:41:24 <warren> What is the maturity of RCLTV?
360 2015-10-01T09:41:25 <sipa> indeed, softfork deployment can be done at any time, including with minor releases
361 2015-10-01T09:41:28 <btcdrak> but I've no strong opinion to block it. We need CLTV out sooner than later.
362 2015-10-01T09:41:30 <gmaxwell> We shouldn't bind major releases and soft-fork deployment.
363 2015-10-01T09:41:34 <sipa> warren: you mean checksequenceverify?
364 2015-10-01T09:41:34 <wumpus> it needs to be backported to 0.10+ anyhow, so it can be done any time
365 2015-10-01T09:41:58 <wumpus> 0.12 could obviously have some mempool-only softforks already in, but that's a different thing
366 2015-10-01T09:42:06 <sipa> argument in favor of IsSuperMajority-based trigger: versionbits may be harder to backport
367 2015-10-01T09:42:07 <btcdrak> but if it's going to hold up future deployment of versionbits deployments, it means we have to push CSV out with blockver >= 5 also
368 2015-10-01T09:42:11 *** DatBeeDoe has joined #bitcoin-dev
369 2015-10-01T09:42:16 <btcdrak> sipa: +1
370 2015-10-01T09:42:32 <jtimon> wumpus: softfork deployment i not coupled with major version, if CSV is not ready by then we can make a minor version for it (maybe using versionbits)
371 2015-10-01T09:42:41 <btcdrak> in fact, considering the backporting issue, I think we cannot reasonably expect to deploy CLTV or CSV with versionbits now
372 2015-10-01T09:42:45 <gmaxwell> On a general matter of principle I do not prefer binding multiple proposals. If multiple proposals happen to coincide I don't see a problem with it. But CLTV has 6 months to a year maturity advantage on the related locking proposals.
373 2015-10-01T09:42:47 <wumpus> jtimon: right
374 2015-10-01T09:42:49 *** mik_ has joined #bitcoin-dev
375 2015-10-01T09:42:55 <sipa> IsSuperMajority is ready, CLTV is ready... let's go for it
376 2015-10-01T09:43:02 <wumpus> agreed gmaxwell, CLTV is ready, let's do it
377 2015-10-01T09:43:02 <maaku> i'm in favor of doing IsSuperMajoirty for this, just not rushing CLTV without CSV (which is ready already)
378 2015-10-01T09:43:11 <gmaxwell> As an aside ignoring version bits for a moment, we can also begin a v=5 rollout while v=4 is in progress so long as the v5 is strictly cumulative.
379 2015-10-01T09:43:12 <jgarzik> +1 gmaxwell
380 2015-10-01T09:43:20 <morcos> I was under the impression that we can deploy CLTV with SuperMajority now, then whenever the next soft fork is ready, assuming we all still think we want both of them, we just condition the second soft fork on also including CLTV
381 2015-10-01T09:43:20 <sipa> gmaxwell: true!
382 2015-10-01T09:43:27 <morcos> yes gmaxwell, thats what i was trying to say poorly
383 2015-10-01T09:43:30 <jtimon> sipa: why make a minor version now if we're about to do a major one?
384 2015-10-01T09:43:30 <maaku> gmaxwell: my argument is no that it is technically difficult, but that it is hard to explain
385 2015-10-01T09:43:34 <warren> sipa: oops, yes
386 2015-10-01T09:44:07 <wumpus> ok: so one BIPxx softfork at a time (don't bind them together), use IsMajority for now, CLTV first
387 2015-10-01T09:44:07 <jgarzik> binding unrelated proposals together creates a logjam
388 2015-10-01T09:44:07 <gmaxwell> maaku: I think it is no more difficult than 4,5 non-overlapping.
389 2015-10-01T09:44:07 <maaku> i don't want to go back to a miner a week or two later with _another_ soft fork point release
390 2015-10-01T09:44:07 <sipa> but CLTV is useful, even without CSV?
391 2015-10-01T09:44:11 <btcdrak> I think we've got consensus to roll out CLTV
392 2015-10-01T09:44:21 <jgarzik> wumpus, ack
393 2015-10-01T09:44:30 <BlueMatt> mehhhh
394 2015-10-01T09:44:36 <jgarzik> CLTV first, versionbits next
395 2015-10-01T09:44:36 <maaku> nack
396 2015-10-01T09:44:39 <BlueMatt> csv is muchhh more useful
397 2015-10-01T09:44:49 <sipa> BlueMatt: but not nearly as ready
398 2015-10-01T09:44:49 <BlueMatt> and i dont really want to push it out another six months
399 2015-10-01T09:44:52 <gmaxwell> maaku: as I said ealier, we need to develop a cadance in general. Expirence with BIP66 was that miner adoption was good even though the benefits of BIP66 were vague to most people.
400 2015-10-01T09:44:53 <BlueMatt> i know
401 2015-10-01T09:44:56 <wumpus> this means #6706 and #6707 (backport CLTV to 0.10 and 0.11 respectivel) need review ASAP
402 2015-10-01T09:45:00 <sipa> BlueMatt: it isn't being pushed out another 6 motnhs
403 2015-10-01T09:45:09 <maaku> what is holding up merging CSV?
404 2015-10-01T09:45:09 <BlueMatt> gmaxwell: cadence is great....when we have versionbits
405 2015-10-01T09:45:17 <btcdrak> jgarzik: nack, csv would need issupermajority rollout due to versionbits backporting difficulty
406 2015-10-01T09:45:28 <CodeShark> about how long do we expect CLTV using IsSuperMajority to take to deploy (if we go that route)?
407 2015-10-01T09:45:32 <jtimon> so, again, we're doing a minor version only for CLTV instead of waiting for 0.12 which is just around the corner?
408 2015-10-01T09:45:34 <jgarzik> rollout will happen quickly
409 2015-10-01T09:45:38 <jgarzik> weeks not months
410 2015-10-01T09:45:42 <sipa> well... the first versiobits rollout will trigger all ISM-based rollouts too
411 2015-10-01T09:45:42 <btcdrak> maaku: good question: why havent there been more reviews on CVS?
412 2015-10-01T09:45:47 <morcos> why don't we set a deadline for CSV to be fully reviewed
413 2015-10-01T09:45:47 <BlueMatt> sipa: in theory its not, in reality it probably is
414 2015-10-01T09:45:50 <sipa> jgarzik: we don't know that
415 2015-10-01T09:45:51 <wumpus> yes, no waiting for 0.12
416 2015-10-01T09:46:05 <wumpus> don't want to couple softfork with a major release
417 2015-10-01T09:46:10 *** h3xc0d3r has quit IRC
418 2015-10-01T09:46:11 <gmaxwell> BlueMatt: We can deploy CLTV basically immediately ... like, within days if we really wanted to, the same is not true for versionbits, and I think it is far less obviously true for CSV, as it's just a less mature proposal.
419 2015-10-01T09:46:23 <jgarzik> +1
420 2015-10-01T09:46:24 <BlueMatt> jgarzik: rollout will not take weeks
421 2015-10-01T09:46:32 <sipa> BIP66 took 5 months
422 2015-10-01T09:46:35 <BlueMatt> gmaxwell: I highly doubt cltv can softfork in weeks
423 2015-10-01T09:46:37 <btcdrak> gmaxwell: I would like to see it as a test of how united the mining community can be.
424 2015-10-01T09:46:37 <jtimon> morcos: btcdrak's plan was to make 0.12 that deadline (and for versionbits to be used in CLTV or not too)
425 2015-10-01T09:46:38 <BlueMatt> that is insane
426 2015-10-01T09:46:55 <gmaxwell> I believe that very rapid rollout is possible and not unlikely. There is clear pent up demand.
427 2015-10-01T09:47:06 <sipa> gmaxwell: i'm unsure about that
428 2015-10-01T09:47:06 <wumpus> yes, the mailing list was clear on that
429 2015-10-01T09:47:15 <BlueMatt> gmaxwell: bip66 took a long time with devs hammering on miners to do it quick
430 2015-10-01T09:47:16 <maaku> what is the imputus to rush this? why are people not reviewing CSV?
431 2015-10-01T09:47:18 <BlueMatt> and yet it didnt happen
432 2015-10-01T09:47:19 <bsm1175321> Proposal: create windows for and deadlines for soft forks. One every 3 months? 6? Window for testnet inclusion, and intended deployment.
433 2015-10-01T09:47:19 <gmaxwell> weeks is unrealistic just on the activation thresholds, but 2 months I think is possible.
434 2015-10-01T09:47:24 <BlueMatt> that is not gonna happen with cltv
435 2015-10-01T09:47:27 <sipa> here is something to consider: the first versionbits rollout will trigger all ISM-based rollouts
436 2015-10-01T09:47:33 <jgarzik> I think 8-12 weeks
437 2015-10-01T09:47:37 *** h3xc0d3r has joined #bitcoin-dev
438 2015-10-01T09:47:48 <sipa> we can implement versionbits, and use it for CSV, even before the ISM-based CLTV softfork occurred
439 2015-10-01T09:47:58 <maaku> I'm not in favor of versionbits for CSV
440 2015-10-01T09:47:59 <CodeShark> what are ISM-based rollouts?
441 2015-10-01T09:48:00 <sipa> it will just mean that they may trigger simultaneously
442 2015-10-01T09:48:02 <BlueMatt> sipa: hmm, indeed
443 2015-10-01T09:48:03 <CodeShark> oh
444 2015-10-01T09:48:05 <Luke-Jr> maaku: wtf?
445 2015-10-01T09:48:06 <michagogo> Does ISM happen faster on testnet?
446 2015-10-01T09:48:07 <sipa> CodeShark: IsSuperMajority
447 2015-10-01T09:48:07 <wumpus> in any case I think it's better to make progress, one step at a time
448 2015-10-01T09:48:08 <CodeShark> IsSuperMajority - duh ;P
449 2015-10-01T09:48:09 <gmaxwell> sipa: so long as it includes CLTV, which I think there is zero concern that it wouldn't.
450 2015-10-01T09:48:10 <btcdrak> CodeShark: issuprtmajority
451 2015-10-01T09:48:15 <sipa> gmaxwell: indeed
452 2015-10-01T09:48:18 <maaku> I'm in favor of IsSuperMajoirty with all lock-time soft-forks together
453 2015-10-01T09:48:34 <Luke-Jr> maaku: why is ISM preferred over versionbits?
454 2015-10-01T09:48:36 <morcos> proposal, end of Oct, release ISM soft fork with CLTV and CSV if its ready
455 2015-10-01T09:48:40 <Luke-Jr> they seem to me to be on the same timeframe
456 2015-10-01T09:48:45 <morcos> 3 months later release 0.12
457 2015-10-01T09:48:54 <maaku> Luke-Jr: versionbits isn't written. CSV is
458 2015-10-01T09:48:55 <sipa> morcos: sounds good to me
459 2015-10-01T09:48:56 <morcos> 3 month later version bits soft fork
460 2015-10-01T09:48:57 <gmaxwell> maaku: even if that means delaying CLTV 6 months, ... a timespan when almost certantly could have been deployed by itself?
461 2015-10-01T09:49:00 <jgarzik> sequence number stuff + versionbits stuff is a lot to swallow
462 2015-10-01T09:49:10 <jtimon> wumpus: we can always create a minor version 2 weeks before the major release, would that solve your "don't couple softforks with major releases" concerns? if your concern is delaying 0.12, that's not going to happen with btcdrak's plan
463 2015-10-01T09:49:24 <gmaxwell> jgarzik: versionbits will always come along with at least some softfork! :)
464 2015-10-01T09:49:28 <maaku> gmaxwell: where is your 6months coming from?
465 2015-10-01T09:49:32 <jgarzik> true
466 2015-10-01T09:49:40 <morcos> i think the concern of giving people too many upgrades in quick succession is valid
467 2015-10-01T09:49:44 <maaku> I am very, very confused here. Do you think it will take 6mo to merge CSV?
468 2015-10-01T09:49:52 <btcdrak> wumpus: Are the CLTV backports ready to merge?
469 2015-10-01T09:49:53 <maaku> If so let me know so I can stop wasting my time.
470 2015-10-01T09:49:59 <wumpus> my concern is not delaying 0.12, it is just that I prefer to keep them administratively separate, so that people explicitly upgrade for the softfork not for other things
471 2015-10-01T09:50:00 <sipa> maaku: i don't think so
472 2015-10-01T09:50:00 <gmaxwell> maaku: it was a benchamrk number. CSV is more than six months younger than CLTV.
473 2015-10-01T09:50:08 <wumpus> btcdrak: no, they still need ACKs
474 2015-10-01T09:50:14 <maaku> gmaxwell: that is meaningless
475 2015-10-01T09:50:20 <gmaxwell> maaku: I don't think it will, but lets imagine for a moment that it takes six months to reach the same maturity as CLTV.
476 2015-10-01T09:50:21 <maaku> we had a six month wait for BIP 66
477 2015-10-01T09:50:24 <sipa> i think focus and priorities are much different now, so no, i think CSV can be merged pretty soon
478 2015-10-01T09:50:27 <sipa> (weeks?)
479 2015-10-01T09:50:32 <btcdrak> CSV should not take more than a few weeks more surely?! omg
480 2015-10-01T09:50:48 <gmaxwell> btcdrak: control your behavior.
481 2015-10-01T09:50:48 <BlueMatt> sipa: ack
482 2015-10-01T09:50:51 <wumpus> also the backports?
483 2015-10-01T09:50:58 *** iv3c has quit IRC
484 2015-10-01T09:51:10 *** nwilcox has joined #bitcoin-dev
485 2015-10-01T09:51:14 <btcdrak> gmaxwell :)
486 2015-10-01T09:51:23 <gmaxwell> maaku: people weren't entirely sitting on their hands during that time.
487 2015-10-01T09:51:24 <wumpus> I'm fine with including CSV if it can be done quickly, but it's certainly a risk if hurried too much at once
488 2015-10-01T09:51:31 <jgarzik> +1
489 2015-10-01T09:51:37 <jtimon> no, if CSV is not ready for CLTV_deadline (be it 0.12 or some time sooner), CSV doesn't have to wait for 0.13, that's the decoupling, no need to wait 6 months
490 2015-10-01T09:51:38 <sipa> proposal: we don't gate anything on versionbits, but encourage CSV and related PRs review, for mempool-only; in 3 weeks we see what's ready to go in a softfork?
491 2015-10-01T09:51:41 <BlueMatt> wumpus: ack
492 2015-10-01T09:51:54 <maaku> jtimon: no one is gating anything on 0.12 release
493 2015-10-01T09:51:56 <wumpus> jtimon: no, CSV doesn't have to wait for 0.13, no one is saying that
494 2015-10-01T09:51:59 <jgarzik> IMO redefining behavior in a soft fork carries a higher risk in general (ref: seq numbers)
495 2015-10-01T09:52:05 <BlueMatt> ACK morcos' original proposal
496 2015-10-01T09:52:11 <BlueMatt> end of oct, softfork
497 2015-10-01T09:52:13 <btcdrak> right, softforks are not dependent on major releases
498 2015-10-01T09:52:17 <BlueMatt> if it includes csv, great, otherwise oh well
499 2015-10-01T09:52:28 <sipa> sounds good to me
500 2015-10-01T09:52:33 <btcdrak> BlueMatt, that's a decent compromise
501 2015-10-01T09:52:33 <gmaxwell> maaku: please, I am not saying it will take six months. But I would consider that an upper bound on how long it might take based on the best available reference case we have. We could have concurrently deployed CLTV and BIP66 and we did not.
502 2015-10-01T09:52:40 <gmaxwell> that sounds okay to me too.
503 2015-10-01T09:52:48 *** h3xc0d3r has quit IRC
504 2015-10-01T09:52:51 <jtimon> maaku: btcdrak's plan (which several people ACKed) was just like sipa's replacing the 3 week deadline with 0.12 at most as a deadline
505 2015-10-01T09:53:00 <gmaxwell> I just do not want us creating more than the most trivial delays due to tying, as these things tend to creep and snowball.
506 2015-10-01T09:53:01 <wumpus> end of oct sounds fine to me
507 2015-10-01T09:53:03 <maaku> what does CSV need to be merged?
508 2015-10-01T09:53:10 <wumpus> agreed gmaxwell, bad experiences with this
509 2015-10-01T09:53:19 <jgarzik> +1
510 2015-10-01T09:53:26 <jgarzik> +1 end of oct, also
511 2015-10-01T09:53:30 <jtimon> maaku: of course even following that plan, if everything is ready in 3 weeks we can create the minor version
512 2015-10-01T09:53:37 <wumpus> but the backports need to be reviewed as well, so it's not like we can do the release right now immediately, so end of oct is still fine IMO
513 2015-10-01T09:53:42 <jonasschnelli> as far as i know CSV has no test /unit or rpc
514 2015-10-01T09:53:46 *** nullbyte has quit IRC
515 2015-10-01T09:53:50 <btcdrak> wumpus +1
516 2015-10-01T09:53:53 <wumpus> jonasschnelli: it certainly needs that
517 2015-10-01T09:53:53 <maaku> jonasschnelli: it has unit tests
518 2015-10-01T09:53:59 <btcdrak> Let's move to the next topic of the CSV bips.
519 2015-10-01T09:54:03 *** h3xc0d3r has joined #bitcoin-dev
520 2015-10-01T09:54:14 <BlueMatt> maaku: so in the next two weeks you hold the ACK-whip
521 2015-10-01T09:54:15 <jgarzik> ### 6 minutes left
522 2015-10-01T09:54:31 <maaku> BlueMatt: I've been doing that the past 2 months to no avail
523 2015-10-01T09:54:34 <BlueMatt> maaku: push for ACKs on this stuff and hopefully it'll be in in two or three weeks and then it gets pushed at the end of oct
524 2015-10-01T09:54:37 <btcdrak> sipabot: next topic please
525 2015-10-01T09:54:45 *** bitcoin-dev092 has joined #bitcoin-dev
526 2015-10-01T09:54:49 <sipa> ### ALL GOALS FOR 0.12 RELEASE
527 2015-10-01T09:54:57 <sipa> who added that?
528 2015-10-01T09:55:04 <maaku> I'm am seriously to the point of forking bitcoin out of frustration :\
529 2015-10-01T09:55:04 <dstadulis> was hold over from last week
530 2015-10-01T09:55:11 <dstadulis> should go to libconsensus
531 2015-10-01T09:55:12 <dstadulis> I believ
532 2015-10-01T09:55:22 <btcdrak> I thought next topic was CSV
533 2015-10-01T09:55:31 <sipa> we just talked about CSV...
534 2015-10-01T09:55:35 <wumpus> what is to discuss about CSV?
535 2015-10-01T09:55:47 <wumpus> BIP is finalized?
536 2015-10-01T09:55:52 <wumpus> BIP112 I mean
537 2015-10-01T09:56:37 <dstadulis> ### Proposed Topic: libconsensus merge time window
538 2015-10-01T09:56:39 <btcdrak> BIP112 is final, the wording needs to be tweaked a little
539 2015-10-01T09:56:50 <sipa> ### TOPIC: libconsensus merge time window
540 2015-10-01T09:56:59 <btcdrak> wumpus: just what is remaining for review points to get ACKs
541 2015-10-01T09:57:10 <jgarzik> would like to concentrate refactors into a pre-announced time window if possible
542 2015-10-01T09:57:17 <jgarzik> merge libconsensus moves quickly
543 2015-10-01T09:57:19 <sipa> jgarzik: that sounds good
544 2015-10-01T09:57:29 <sipa> before or after the normal merge window?
545 2015-10-01T09:57:32 <jgarzik> proposed: week before, or after, translation freeze
546 2015-10-01T09:57:42 <sipa> as in: right after branching off, or after the feature freeze?
547 2015-10-01T09:57:42 <jtimon> I strongly oppose to impose such a restriction on anything related to libconsensus
548 2015-10-01T09:57:53 <sipa> jtimon: s/libconsensus/refactors/
549 2015-10-01T09:57:57 <wumpus> move-only refactors would be OK before branch split-off
550 2015-10-01T09:58:05 <jgarzik> sipa, yes
551 2015-10-01T09:58:06 <wumpus> if it's more involved/risky, it needs to be after
552 2015-10-01T09:58:10 <jgarzik> sipa, but I think earlier is better
553 2015-10-01T09:58:21 <jgarzik> more time to rebase and push more important stuff
554 2015-10-01T09:58:27 <Luke-Jr> IMO the restriction shouldn't be on libconsensus, but on code movement/churn
555 2015-10-01T09:58:31 <sipa> Luke-Jr: ack
556 2015-10-01T09:58:33 <jgarzik> Luke-Jr, ack
557 2015-10-01T09:58:36 <jtimon> sipa: yes, there's small refactors (ie removing dependencies like CChainParams from certain functions) that don't need to wait
558 2015-10-01T09:58:48 <jgarzik> Resolved: s/libconsensus/refactor/
559 2015-10-01T09:58:50 <jgarzik> continue
560 2015-10-01T09:58:52 <wumpus> not going to merge anything with significant risk just before a release
561 2015-10-01T09:59:11 <btcdrak> wumpus: the time to merge something like that is at the beginning of a release cycle
562 2015-10-01T09:59:14 <jgarzik> wumpus, thus my proposal for around the first freeze (string freeze)
563 2015-10-01T09:59:18 <btcdrak> not at the end
564 2015-10-01T09:59:20 <wumpus> (which any serious refactoring to consensus code would be)
565 2015-10-01T09:59:23 <morcos> btcdrak: +1
566 2015-10-01T09:59:28 *** DatBeeDoe has quit IRC
567 2015-10-01T09:59:41 <jgarzik> btcdrak, That's what Linux kernel does -- 0.1 seconds after a release version is posted to the Internet, merge window opens.
568 2015-10-01T09:59:43 *** pavel__ has joined #bitcoin-dev
569 2015-10-01T09:59:44 <jgarzik> including refactors
570 2015-10-01T09:59:47 <sipa> so there is also a change (more than just code movement) that i'd like to do: create a CBlockDB, which manages all mapBlockIndex/CBlockIndex/file location stuff, without a private lock, so that doesn't need cs_main anymore
571 2015-10-01T09:59:49 <wumpus> right, the beginning for 0.13, after 0.12 is split off is the time for more impactful changes
572 2015-10-01T09:59:49 *** paveljanik has quit IRC
573 2015-10-01T09:59:52 *** pavel__ has quit IRC
574 2015-10-01T09:59:57 *** notj has quit IRC
575 2015-10-01T09:59:59 *** cubicearth has joined #bitcoin-dev
576 2015-10-01T10:00:00 <jtimon> I'm fine with having a period for medium/big moveonlies, but remember last time we did that was for "right after major versions", we passed through "right after 0.10" and "right after 0.11" and nothing happened
577 2015-10-01T10:00:02 *** paveljanik has joined #bitcoin-dev
578 2015-10-01T10:00:05 <btcdrak> jgarzik +1
579 2015-10-01T10:00:26 <jgarzik> jtimon, it's up to you to follow that process as a peer developer :)
580 2015-10-01T10:00:31 <sipa> jtimon: things do need to be ready and reviewed at that point
581 2015-10-01T10:00:32 <jgarzik> self-enforcement :)
582 2015-10-01T10:00:32 <wumpus> jtimon: that's because your changes didn't have enough review/agreement
583 2015-10-01T10:00:52 <morcos> does it make sense to do it right after 0.12 splits off or right after 0.12 is released. it seems like after the split there are still a lot of backports, and maybe we shouldn't make those harder
584 2015-10-01T10:01:02 <jtimon> wumpus: I disagree, for people rebasing on top of major versions it's much easier if big refactors happen right before major releases rather than right after them
585 2015-10-01T10:01:10 <jgarzik> right after a branch can be a more painful than right after a full release.
586 2015-10-01T10:01:26 <wumpus> jtimon: AS I said, that's OK for just move-only stuff, but not for anything that incurs risk@
587 2015-10-01T10:01:29 <jgarzik> last minute bug fixes become more onerous to backport.
588 2015-10-01T10:01:36 *** NewLiberty has quit IRC
589 2015-10-01T10:01:44 <jtimon> jgarzik: I was nagging almost everyone with that clearly uneffective ACK-whip, next time I will make sure I nagg you as well
590 2015-10-01T10:01:46 <CodeShark> if we were to just break up main.cpp (consensus-focused or not) it would go to great lengths to reducing rebase headaches ;)
591 2015-10-01T10:02:01 <jgarzik> jtimon, I think it is moving in the right direction now - your issue PR
592 2015-10-01T10:02:09 <sipa> CodeShark: no disagreement there, but not relevant
593 2015-10-01T10:02:12 <jgarzik> the code movement can be created from scratch in minutes.
594 2015-10-01T10:02:20 <CodeShark> sipa: how is that not relevant?
595 2015-10-01T10:02:39 <wumpus> specific strategy on splitting up main is too detailed for the current discussion
596 2015-10-01T10:02:48 <jtimon> jgarzik: I thought it was moving in the right direction when people finally decided to review some libconsensus-related code
597 2015-10-01T10:02:49 <sipa> CodeShark: if there was no cost to that refactor is would happen instantly
598 2015-10-01T10:03:05 <jgarzik> ### meeting T+3 minutes overtime
599 2015-10-01T10:03:26 <jtimon> jgarzik: I'll provide more documentation, but I'm increasingly pesimistic about libconsensus being ever completed
600 2015-10-01T10:03:27 <sipa> meeting over?
601 2015-10-01T10:03:31 <jgarzik> Proposed: last week of October for refactor window.
602 2015-10-01T10:03:43 <sipa> what is the timeframe for 0.12?
603 2015-10-01T10:03:52 <jgarzik> feb 2016
604 2015-10-01T10:04:03 <wumpus> the branch split-off is only december 1 that I remember
605 2015-10-01T10:04:05 <jtimon> as said I certainly prefer before-major than after-major for big refactors
606 2015-10-01T10:04:14 <jtimon> but wumpus disagrees
607 2015-10-01T10:04:31 <jgarzik> Nov 1 close i18n
608 2015-10-01T10:04:34 <jgarzik> Dec 1 feature freeze
609 2015-10-01T10:04:36 <gmaxwell> We are over time.
610 2015-10-01T10:04:42 <sipa> ### MEETING OVER
611 2015-10-01T10:04:49 <wumpus> yes, I disagree. I don't want to merge anything big just before a release. Very bad experiences with that.
612 2015-10-01T10:04:53 <sipa> (but keep talking...)
613 2015-10-01T10:05:06 *** bitcoin-dev092 has quit IRC
614 2015-10-01T10:05:08 <bsm1175321> Great meeting folks. I hope I can offer more next time.
615 2015-10-01T10:05:10 <jtimon> well the "big" part are moveonly commits
616 2015-10-01T10:05:16 <jgarzik> Thus proposed refactor window ~Oct 23 is well before Feb 1 release.
617 2015-10-01T10:05:27 <jgarzik> then next refactor window, proposed: Feb 2
618 2015-10-01T10:05:34 <wumpus> Im ean before *splitoff* not release so much
619 2015-10-01T10:05:58 <jtimon> jgarzik: I prefer that over wumpus alternative
620 2015-10-01T10:05:59 <wumpus> after the split off, development for 0.12 will go on a branch anyway, so changes on master can be more impactful, lots of time to test etc
621 2015-10-01T10:06:28 <jgarzik> having refactor changes in 0.12 will mitigate later pain
622 2015-10-01T10:06:45 <dstadulis> Please amend google doc so I can send minutes out to list https://docs.google.com/document/d/10yfs6_DeF1CnrkpyubNCpIVVPSqBE-tV_KebsI_O41A/edit?usp=sharing
623 2015-10-01T10:06:55 *** NewLiberty has joined #bitcoin-dev
624 2015-10-01T10:06:55 <jtimon> wumpus: exactly the opposite! you don't want the 2 branches to differ a lot!!
625 2015-10-01T10:07:04 <jgarzik> +1
626 2015-10-01T10:07:14 *** shaul has joined #bitcoin-dev
627 2015-10-01T10:07:22 <wumpus> splitoff of 0.12 branch is scheduled for 2016-01-06
628 2015-10-01T10:07:36 <wumpus> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011182.html
629 2015-10-01T10:07:38 <jtimon> after the major release is frozen, then it's fine to have big differences again
630 2015-10-01T10:07:44 <jgarzik> no need to wait until Jan 2016 for libconsensus moves
631 2015-10-01T10:07:53 <jgarzik> late Oct is fine
632 2015-10-01T10:08:08 <jgarzik> keep the pace up
633 2015-10-01T10:08:14 <jgarzik> keep the diffs small
634 2015-10-01T10:08:19 <wumpus> as long as it is move-only.. I'm really scared of introducing consensus bugs
635 2015-10-01T10:08:27 <jtimon> specially in the context of having waited for jan 2015 before and then not having moved anything...
636 2015-10-01T10:08:37 <wumpus> they shouldn't just make it into a major release
637 2015-10-01T10:08:42 <jonasschnelli> maaku: CSV has tests. My mystake. Sorry. Although a RPC test like CLTV provides would be nice (and would allow better testing [by adapting the rpc test] and quicker ACKing)
638 2015-10-01T10:08:58 <CodeShark> let's move everything before 0.12 and make all changes afterwards
639 2015-10-01T10:09:00 <jgarzik> late-Oct merge gives you months of testing for libconsensus code moves
640 2015-10-01T10:09:02 <jgarzik> which are easy to verify
641 2015-10-01T10:09:03 <sipa> jtimon: i think having this meeting helps... it makes it easier to reviewers to know whether other reviewers are on-board with a goal
642 2015-10-01T10:09:04 <jtimon> wumpus: that's why we have release candidates, no?
643 2015-10-01T10:09:09 <wumpus> ok, never mind
644 2015-10-01T10:09:10 <jgarzik> jtimon, +1
645 2015-10-01T10:09:13 <wumpus> do it your way,I'll shut up
646 2015-10-01T10:09:41 <wumpus> jtimon: there's no guarantee at all that subtle problems in refactoring will be found in a RC!
647 2015-10-01T10:09:53 <sipa> let's not be overly pessimistic
648 2015-10-01T10:10:01 <CodeShark> the sooner we do this the less we'll have to worry about it ;)
649 2015-10-01T10:10:01 <jgarzik> The Internet is a great test lab
650 2015-10-01T10:10:02 <sipa> the majority of jtimon's changes _are_ moveonly
651 2015-10-01T10:10:06 <jgarzik> nod
652 2015-10-01T10:10:07 <wumpus> I'm very much against doing this before the splitoff
653 2015-10-01T10:10:18 <sipa> i think we just need to agree on where we want the refactors to go
654 2015-10-01T10:10:20 <CodeShark> move-only is easy to review
655 2015-10-01T10:10:23 <jtimon> wumpus: there's no guarantee they will be found no matter which month of the year you chose to merge them
656 2015-10-01T10:10:25 <jgarzik> I'm with jtimon on this one
657 2015-10-01T10:10:28 <sipa> a few people to look at the move-only changes
658 2015-10-01T10:10:29 <wumpus> move-only is, but they're not move-only
659 2015-10-01T10:10:38 <wumpus> not just move-only I mean
660 2015-10-01T10:10:46 <sipa> i think we can manage
661 2015-10-01T10:11:05 <sipa> no opinion on when, but i do like the idea of a dedicated refactoring space in the release schedule
662 2015-10-01T10:11:06 *** gmaxwell has left #bitcoin-dev
663 2015-10-01T10:11:15 <jtimon> wumpus: I have tried everything I believe, remove most dependencies first then moveonly, moveonly first then remove most dependencies...nothing seemed to be acceptable so far...
664 2015-10-01T10:11:26 <wumpus> yes I like the principle too, but I don't like doing it just before a release splitoff...
665 2015-10-01T10:11:30 <sipa> jtimon: you were just spamming people with code...
666 2015-10-01T10:11:40 <jgarzik> _months_ before a release splitoff
667 2015-10-01T10:11:43 <jgarzik> which is basically dev
668 2015-10-01T10:11:48 *** adam3us has joined #bitcoin-dev
669 2015-10-01T10:11:50 <jgarzik> we need a window before 0.12
670 2015-10-01T10:12:05 <morcos> jtimon: i noticed you said you still owe the high level doc. i'm waiting for that.
671 2015-10-01T10:12:05 <jgarzik> there will be other refactors we want to do
672 2015-10-01T10:12:06 <CodeShark> go easy, sipa ;)
673 2015-10-01T10:12:15 <jtimon> if you want pure moveonly, I can rewirte that in half an hour at any point in time when it's going to be reviewed and potentially merged, no problem
674 2015-10-01T10:12:31 <bsm1175321> Is there a dedicated window where the 0.12rc becomes the testnet code? That rc moves to fixes-only?
675 2015-10-01T10:12:39 <jgarzik> bsm117532: yes
676 2015-10-01T10:12:46 <bsm1175321> What is it, where is it posted?
677 2015-10-01T10:12:47 <jgarzik> bsm117532: branch is fixes only
678 2015-10-01T10:12:51 <jgarzik> bsm117532: mailing list
679 2015-10-01T10:13:04 <morcos> jgarzik: HA! half of the pulls are "fixes"
680 2015-10-01T10:13:08 *** GGuyZ has joined #bitcoin-dev
681 2015-10-01T10:13:16 <sipa> jtimon: sorry, that last thing i said was unnecessary
682 2015-10-01T10:13:25 <jtimon> morcos: well, I believe I explained most of what the doc is going to contain in our conversation after the meeting last week, but you asked for pictures...
683 2015-10-01T10:13:37 <jgarzik> morcos, :)
684 2015-10-01T10:13:45 *** slowpoison has quit IRC
685 2015-10-01T10:14:19 *** MaxSan_ has joined #bitcoin-dev
686 2015-10-01T10:14:19 <jtimon> sipa: it's fine, I was in fact spamming people with code hoping that they would give ANY kind of feedback
687 2015-10-01T10:14:22 <jgarzik> post-branch changes permitted tend to be: docs, obvious bug fixes, oh sh*t network problems. More involved bug fixes are a years-long project :)
688 2015-10-01T10:14:22 <morcos> jtimon: i know i'm newer to the code than other people, but it still not clear to me what the end goal (in terms of code movement / class structure) is that i shoudl be evaluating your pulls on
689 2015-10-01T10:14:45 <morcos> so i can evaluate them for correctness, but i feel like i might be wasting my time if other people might not approve them for direction reasons
690 2015-10-01T10:15:28 <CodeShark> I think we have several somewhat conflated (but at the same time complementary) goals here
691 2015-10-01T10:15:31 <morcos> i'd like to see a high level doc (in an issue or something) with a bunch of ACK's
692 2015-10-01T10:15:39 <jgarzik> morcos, jtimon opened an issue
693 2015-10-01T10:15:46 <morcos> i know, thats what im referring to
694 2015-10-01T10:16:00 <wumpus> isn't that https://github.com/bitcoin/bitcoin/issues/6714 ?
695 2015-10-01T10:16:01 <jtimon> well, the issue now includes an approximate API, everything can be explained just looking at that list: you need to build stuff independently from main.cpp, chainparams.cpp, util.cpp, etc
696 2015-10-01T10:16:03 <morcos> its progress, but its still not enough
697 2015-10-01T10:16:15 <Luke-Jr> can we teach a non-developer how to safely evaluate move-only commits, so we don't need to do it?
698 2015-10-01T10:16:25 <sipa> jtimon: i think you're misunderstanding what morcos is asking for (morcos, correct me if i'm wrong)
699 2015-10-01T10:16:52 *** Aquentin has quit IRC
700 2015-10-01T10:16:58 <jtimon> morcos: what I was told was missing last time, is a list of files, a description of the final desired directory structure and things like that
701 2015-10-01T10:17:00 <sipa> jtimon: i think he wants to see a description of what the responsibility of what directory, what file, is, how they are connected and depend on each other, ...
702 2015-10-01T10:17:10 <morcos> yes and yes
703 2015-10-01T10:17:18 <sipa> not API
704 2015-10-01T10:17:21 <jtimon> if you think there's more missing things for it to "be enough", please tell them to me
705 2015-10-01T10:17:32 <morcos> not complainign about the API, i liek that that is there as part of the issue as well
706 2015-10-01T10:17:53 <wumpus> Luke-Jr: probably easier to write a script :p
707 2015-10-01T10:18:22 *** blackjid has quit IRC
708 2015-10-01T10:18:26 <CodeShark> movebot
709 2015-10-01T10:18:32 <sipa> jtimon: i still don't see anything about that
710 2015-10-01T10:18:33 <wumpus> but I don't think evaluating move-only is the bottleneck, move-only is super easy to review manually as well
711 2015-10-01T10:18:35 <jtimon> I think I undesrtood last time, but you guys will have a chance to ask for more things in the doc
712 2015-10-01T10:18:48 <morcos> jtimon: his last comment 3 hours ago said he still owed the pictures doc
713 2015-10-01T10:18:49 <sipa> jtimon: apart from "Separate consensus critical code into different files"
714 2015-10-01T10:18:53 <morcos> sipa i mena
715 2015-10-01T10:18:56 <jtimon> sipa: it will be a different document with pictures
716 2015-10-01T10:18:58 <morcos> i can't type
717 2015-10-01T10:18:58 *** blackjid has joined #bitcoin-dev
718 2015-10-01T10:19:13 *** GGuyZ has quit IRC
719 2015-10-01T10:19:14 <sipa> ok!
720 2015-10-01T10:19:21 <wumpus> once we agree where what things should be moved
721 2015-10-01T10:19:27 <jgarzik> +1 on seeing directories/files
722 2015-10-01T10:19:29 <jtimon> wumpus: Luke-Jr: that script seems harder to write than the identical-build script...
723 2015-10-01T10:19:43 <wumpus> I have an identical-build script
724 2015-10-01T10:19:49 <morcos> yes so jtimon, once you have that doc (and people think its enough info for them) then we need ACK's on it!
725 2015-10-01T10:19:50 <wumpus> but if you move code around, it's not identiacl
726 2015-10-01T10:19:54 <sipa> most code movement doesn't result in identical builds
727 2015-10-01T10:20:17 <wumpus> it ends up in different plaes in the excutable, pointers will be different, etc
728 2015-10-01T10:20:42 <CodeShark> even if we were to break up main.cpp into files shorter than n lines and include them all in a single .cpp it would make rebasing less painful (although it would be a bit ugly) :p
729 2015-10-01T10:20:46 *** agricocb has quit IRC
730 2015-10-01T10:20:59 <sipa> CodeShark: i don't believe that
731 2015-10-01T10:21:00 <jtimon> pesonally I read a moveonly git diff better than a document describing those movements, but if people want that, I will give them that
732 2015-10-01T10:21:08 <sipa> CodeShark: the hard part is disentangling things
733 2015-10-01T10:21:20 <Luke-Jr> hmm, once upon a time I wrote a script that moved code from one big .c file to many smaller ones, that was intended to avoid breaking third-party patches :P
734 2015-10-01T10:21:28 <wumpus> jtimon: what people would like is higher-level information, why what moves where
735 2015-10-01T10:21:29 <sipa> CodeShark: whether they move to different files or not is not relevant; git's refactoring is good enough to combine changes
736 2015-10-01T10:22:02 <jgarzik> sipa, actually it is -- when the diff is smaller and lower percentage chance of conflict, there is increased productivity
737 2015-10-01T10:22:03 <dstadulis> Nice meeting all, will send out minutes later
738 2015-10-01T10:22:12 <wumpus> thanks dstadulis
739 2015-10-01T10:22:33 <sipa> jgarzik: i mean that one large file that is well organized, or many small files... makes no difference for how much conflict there is
740 2015-10-01T10:23:01 <jtimon> sipa: identical builds wouldn't be for moveonly commits but mainly to break montrous giant switchs that any checkstyle tool would complain about (see #4646 and #5153 )
741 2015-10-01T10:23:03 <sipa> so the question is about turning an entangled mess into something well organized... whether that's in one file or not
742 2015-10-01T10:23:17 <jgarzik> sipa, it does, for subtle reasons - developers will iterate files at different rates
743 2015-10-01T10:23:24 <sipa> jgarzik: perhaps yes
744 2015-10-01T10:23:29 <wumpus> if you divide up the file randomly (as CodeShark proposes jokingly), any change will probably affect not one file but many of them
745 2015-10-01T10:23:34 <wumpus> it doesn't help localize changes
746 2015-10-01T10:23:44 <sipa> wumpus words what i wanted to say better :)
747 2015-10-01T10:23:56 *** treehug88 has quit IRC
748 2015-10-01T10:23:59 <CodeShark> yes, I said it somewhat facetiously
749 2015-10-01T10:24:00 <jgarzik> the initial chunky division into separate files will not be random but purposeful and shapes future per-file iteration speed.
750 2015-10-01T10:24:28 <CodeShark> of course the division shouldn't be random
751 2015-10-01T10:24:36 <wumpus> right
752 2015-10-01T10:24:37 <CodeShark> but it doesn't have to be very fine-grained either
753 2015-10-01T10:24:52 <jgarzik> the initial division should aim for minimizing future cross-file movement.
754 2015-10-01T10:24:57 <wumpus> the problem is, as I remember, is avoiding circular dependencies
755 2015-10-01T10:25:07 <jgarzik> yep
756 2015-10-01T10:25:34 <jtimon> mhmm, I have an idea for a logical division, why don't we start moving consensus and policy code out of main.cpp ?
757 2015-10-01T10:25:39 <jtimon> oh, never mind...
758 2015-10-01T10:25:39 <wumpus> main.cpp is a web of functions calling each other, if you just move a few, you'll have two compilation units that dpend on each other
759 2015-10-01T10:25:55 <Luke-Jr> jtimon: did you make that map suggested at the last meeting?
760 2015-10-01T10:26:01 <Luke-Jr> (if so, I missed it, please link)
761 2015-10-01T10:26:08 <wumpus> but anyhow if the goal is move-only changes that may not be that bad
762 2015-10-01T10:26:22 <wumpus> if it can be disentangled later
763 2015-10-01T10:26:24 <jtimon> What map, a graph of calls?
764 2015-10-01T10:26:38 *** noobfikt has quit IRC
765 2015-10-01T10:26:47 <jtimon> Luke-Jr: ^
766 2015-10-01T10:27:06 *** dstadulis has quit IRC
767 2015-10-01T10:27:18 <Luke-Jr> jtimon: no.. a proposed directory layout, how they relate to each other, what code each file contains, etc
768 2015-10-01T10:27:32 <sipa> Luke-Jr: we were just talking about that
769 2015-10-01T10:27:33 <jtimon> another goal IMO is breaking giant functions into smaller ones (like main::ProcessMessage() )
770 2015-10-01T10:27:40 *** noobfikt has joined #bitcoin-dev
771 2015-10-01T10:27:51 <Luke-Jr> jtimon: do that separately.
772 2015-10-01T10:27:52 <jtimon> Luke-Jr: not yet as we we're commenting right now
773 2015-10-01T10:27:55 *** bsm1175321 has quit IRC
774 2015-10-01T10:28:02 <CodeShark> ProcessMessage should be replaced by a signaling system...but that's a separate issue
775 2015-10-01T10:28:12 <wumpus> yes, that's a separate issue, that's far from move-only-land
776 2015-10-01T10:28:29 <morcos> Hmm
777 2015-10-01T10:28:34 <morcos> so here is where there is some confusion
778 2015-10-01T10:28:45 <morcos> I think all of these thigns should be part of the master plan
779 2015-10-01T10:28:52 <morcos> in one location
780 2015-10-01T10:29:01 <wumpus> yes
781 2015-10-01T10:29:06 <morcos> these are the goals we'd like to move the code archticture in
782 2015-10-01T10:29:13 <morcos> consensus API looks like this
783 2015-10-01T10:29:17 <wumpus> that's true
784 2015-10-01T10:29:19 *** Aquentin has joined #bitcoin-dev
785 2015-10-01T10:29:20 <jtimon> Luke-Jr: about the call graphs, I some times do a small part of it manually ofr things that interest me, but there's proper tools to do so (I believe it was gwillen who showed me the resulting graph for main...)
786 2015-10-01T10:29:22 <morcos> file class layout liek this
787 2015-10-01T10:29:31 <wumpus> jtimon: he's not asking for a call graph
788 2015-10-01T10:29:37 <morcos> ok ...
789 2015-10-01T10:29:56 <CodeShark> for a call graph use doxygen...but that's not what we're after
790 2015-10-01T10:29:58 <wumpus> call graphs can be generated, I think they are even in my generated doxygen documentation, but they're not really informative
791 2015-10-01T10:30:03 <jtimon> wumpus: he said "do that separately"
792 2015-10-01T10:30:16 *** maraoz has quit IRC
793 2015-10-01T10:30:21 <wumpus> jtimon: he was talkling about splitting up PRocessMessage not callgraphs
794 2015-10-01T10:30:34 *** nwilcox has quit IRC
795 2015-10-01T10:30:40 <jgarzik> the blocker on ProcessMessage is someone writing hooks
796 2015-10-01T10:31:06 <wumpus> which should be in the master plan, but is not the first step (as it's more involved and not move-only)
797 2015-10-01T10:31:10 <phantomcircuit> ProcessMessages is certainly in need of a refactor
798 2015-10-01T10:31:12 <jtimon> Dividing ProcessMessage in many separate functions (maybe inline at first for the identical-build check) would help with any later work related to that
799 2015-10-01T10:31:15 *** btc_panhandler_ has quit IRC
800 2015-10-01T10:31:21 <jgarzik> wumpus, move only PR was rejected...
801 2015-10-01T10:31:26 <sipa> jgarzik: i had a plan for doing that, but i don't want to interfere with cfields's libevent refactor there (which i think will include that)
802 2015-10-01T10:31:35 *** Dizzle has quit IRC
803 2015-10-01T10:31:38 <phantomcircuit> the current version has a while loop that executes exactly once
804 2015-10-01T10:31:42 <phantomcircuit> (my fault)
805 2015-10-01T10:31:48 <wumpus> yes, we shouldn't trample on cfields's work
806 2015-10-01T10:32:00 <wumpus> which involves the network code
807 2015-10-01T10:32:15 <wumpus> though I"m not sure in how much it involves the high-level part
808 2015-10-01T10:32:46 <wumpus> that'd be more useful to discuss with him here
809 2015-10-01T10:32:51 *** slowpoison has joined #bitcoin-dev
810 2015-10-01T10:33:12 <sipa> if cfields' project would take too long, i think the solution would be to move individual pieces of logic handling out, one by one (for example the askfor handing, pingpong handing, tx propagation, block propagation)
811 2015-10-01T10:33:35 <CodeShark> I've long been proposing something along these lines: https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinQ/src/CoinQ_peer_io.h
812 2015-10-01T10:33:39 <jgarzik> Move message processing to new 'procmsg' module. #4646 https://github.com/bitcoin/bitcoin/pull/4646
813 2015-10-01T10:33:57 <sipa> jgarzik: i'm still neutral on that
814 2015-10-01T10:34:13 *** BashCo has joined #bitcoin-dev
815 2015-10-01T10:34:46 <jtimon> jgarzik: I think you could have done it with an identical-build commit if you had separate it first in inline functions before moving anything out of main.cpp
816 2015-10-01T10:34:55 <sipa> i think the temporary state it creates is worse than what we have now (something circularly dependent on main and everything else), and the solution to that is more moving, until procmsg is empty again
817 2015-10-01T10:35:03 <wumpus> inline functions won't usually give you identical builds
818 2015-10-01T10:35:23 <wumpus> you underestimate the fragility of compiler results :)
819 2015-10-01T10:35:41 <jtimon> jgarzik: and doing that (breaking up that function but not moving anything) doesn't suffer from sipa's circular dependencies concerns
820 2015-10-01T10:35:41 <jgarzik> Where should the ProcessMessage() code live - in which files? msg-inv.cc, msg-block.cc, ?
821 2015-10-01T10:35:46 *** Guyver2 has quit IRC
822 2015-10-01T10:35:52 *** BashCo_ has quit IRC
823 2015-10-01T10:36:08 <sipa> jgarzik: imho, in handler_tx_propagation, handling_block_propagation, handling_ibd, handling_pingpong, ...
824 2015-10-01T10:36:15 <jgarzik> filenames, please
825 2015-10-01T10:36:20 <sipa> add .cpp
826 2015-10-01T10:36:21 <sipa> :)
827 2015-10-01T10:36:38 <sipa> jgarzik: not per message - sometimes one messages has effects on multiple modules
828 2015-10-01T10:36:42 <jgarzik> *boggle*
829 2015-10-01T10:36:55 <jtimon> as said we don't need to know where to move it for breaking up the function...
830 2015-10-01T10:36:55 <wumpus> not per message, but per concern
831 2015-10-01T10:37:32 <sipa> jgarzik: what i envision is some hook mechanism, where you can install zero or more signal handlers for each message
832 2015-10-01T10:37:46 <jgarzik> sure. I envision filenames shorter than 32 chars
833 2015-10-01T10:37:58 <sipa> remove the handle_ prefix :)
834 2015-10-01T10:38:14 <wumpus> change handler to a directory name
835 2015-10-01T10:38:19 <jtimon> then we can start separating by concern (in fact the parameters of the newly created functions will probably give hints)
836 2015-10-01T10:38:20 <CodeShark> that's exactly what I was proposing, sipa
837 2015-10-01T10:38:40 <sipa> jgarzik: and for example block propagation needs a global view... it needs to prevent downloading from multiple peers at once, so it needs some state lock that is shared across peers
838 2015-10-01T10:38:47 <jtimon> we can have a p2p or messages directory...
839 2015-10-01T10:39:12 <sipa> jgarzik: but that lock should not be cs_main, and when everything related to that concern is in one place, it's much easier to see what needs access to the same shared data
840 2015-10-01T10:39:26 <wumpus> +1 sipa
841 2015-10-01T10:39:27 <sipa> but pingpong handling has no shared state at all
842 2015-10-01T10:39:39 <sipa> so it could run concurrently for multiple peers
843 2015-10-01T10:39:44 <jgarzik> sure. cs_main is the Big Kernel Lock of old-BSD and old-Linux and needs to go in general.
844 2015-10-01T10:39:47 <jtimon> of course removing the use of globals would make those hints more valuable...
845 2015-10-01T10:39:55 <CodeShark> the architecture I had in mind: peer_io (handles connection to a single peer, provides message subscription) -> peer_manager (creates multiple peer connections, queues messages) -> sync_manager (does synchronization tasks)
846 2015-10-01T10:40:13 <sipa> jgarzik: absolutely!
847 2015-10-01T10:40:16 *** shaul has quit IRC
848 2015-10-01T10:40:43 <sipa> i'd like to begin by encapsulating mapBlockIndex into a separate class with its own lock, that manages block references and information about them
849 2015-10-01T10:40:46 <jgarzik> peel back the locks just like was done for RPC.
850 2015-10-01T10:40:52 *** Aquentin has left #bitcoin-dev
851 2015-10-01T10:40:54 <CodeShark> sipa: yes!
852 2015-10-01T10:40:57 <CodeShark> let's please do that
853 2015-10-01T10:41:04 <sipa> i'm afraid however that it will break every other patch...
854 2015-10-01T10:41:07 <jgarzik> sipa, +1
855 2015-10-01T10:41:17 <jgarzik> sipa, do it in late October :)
856 2015-10-01T10:41:27 <jtimon> well, you can "begin" with that while other people "begin" with other parts...
857 2015-10-01T10:41:41 <sipa> jtimon: of course!
858 2015-10-01T10:41:47 <sipa> jtimon: i don't want to conflict with your changes
859 2015-10-01T10:43:12 <jtimon> never mind, I don't mean my changes, it's just something I don't like "let's block anything mempool until X or Y is merged, even if it's code that both X and Y share"...like in the mempool case...
860 2015-10-01T10:43:20 <jgarzik> IMO that's the point of a refactor window - it is _ok_ to conflict with your changes, that's the week to resolve and order and merge things like that.
861 2015-10-01T10:43:33 <jgarzik> Obviously you prioritize user impactful features above refactors, and don't block those.
862 2015-10-01T10:43:51 <sipa> jtimon: well imho mempool limiting is way higher priority than any refactoring
863 2015-10-01T10:43:53 <jgarzik> it's a zen balance of devs ;p
864 2015-10-01T10:44:03 <jgarzik> +1
865 2015-10-01T10:44:06 <sipa> jtimon: it's a security concern of the network
866 2015-10-01T10:44:26 <wumpus> yes, mempool limiting is absolutely highest priority now
867 2015-10-01T10:44:32 <jtimon> sipa: agree, but some refactors were helpful for mempool limiting development and review!
868 2015-10-01T10:45:22 <wumpus> (and CLTV/CSV, if we want them ready for end october)
869 2015-10-01T10:45:50 <CodeShark> the block index refactor will greatly help version bits
870 2015-10-01T10:45:58 <sipa> CodeShark: don't assume that
871 2015-10-01T10:46:00 <jtimon> anyway, never mind, just "i'd like to begin by encapsulating mapBlockInde..." reminded me of you doing that kind of "blocking"
872 2015-10-01T10:46:12 <CodeShark> sipa: why not?
873 2015-10-01T10:50:04 <jtimon> isn't cleaner better?
874 2015-10-01T10:50:04 <CodeShark> if one of your criteria is "clean" then yes, better -> cleaner
875 2015-10-01T10:50:05 <sipa> and you need to make it work now, not with a mythical refactor that doesn't exist
876 2015-10-01T10:50:05 <sipa> CodeShark: i'm challenging that it "helps" with anything related to versionbits
877 2015-10-01T10:50:05 <CodeShark> sipa, read what I wrote
878 2015-10-01T10:52:22 <sipa> CodeShark: i don't understand, but i don't think it matters :)
879 2015-10-01T10:52:22 *** wangchun has quit IRC
880 2015-10-01T10:52:22 *** aj has joined #bitcoin-dev
881 2015-10-01T10:52:31 *** LeMiner has quit IRC
882 2015-10-01T10:52:44 *** rnicoll has quit IRC
883 2015-10-01T10:53:03 <CodeShark> sipa: I might need to provide more background for it to make sense...but we'll do that later ;)
884 2015-10-01T10:53:03 *** neozaru has quit IRC
885 2015-10-01T10:53:03 *** lightningbot has quit IRC
886 2015-10-01T10:53:14 <CodeShark> why so many lightningbots?!?
887 2015-10-01T10:53:24 *** LeMiner has quit IRC
888 2015-10-01T10:53:24 *** rnicoll has quit IRC
889 2015-10-01T10:53:34 *** wangchun has joined #bitcoin-dev
890 2015-10-01T10:53:36 *** jtimon has quit IRC
891 2015-10-01T10:53:58 *** LeMiner has joined #bitcoin-dev
892 2015-10-01T10:54:00 <sipa> i wonder the same thing
893 2015-10-01T10:54:08 <Luke-Jr> /mode #bitcoin-dev +b ââââ?bot
894 2015-10-01T10:54:12 <Luke-Jr> err, without the Unicode..
895 2015-10-01T10:54:22 <Luke-Jr> /mode #bitcoin-dev +b ?????????bot
896 2015-10-01T10:54:48 <Luke-Jr> maybe a * at the end
897 2015-10-01T10:57:29 <Luke-Jr> please?
898 2015-10-01T10:57:36 *** aj has joined #bitcoin-dev
899 2015-10-01T10:57:56 *** maraoz has joined #bitcoin-dev
900 2015-10-01T10:58:06 <Luke-Jr> also, thoughts on Travis building with -Werror ? :p
901 2015-10-01T10:58:22 <Luke-Jr> more importantly: why does master not build? :/
902 2015-10-01T10:58:25 *** nwilcox has joined #bitcoin-dev
903 2015-10-01T10:58:58 *** sipa has left #bitcoin-dev
904 2015-10-01T10:59:24 *** lightningbot has joined #bitcoin-dev
905 2015-10-01T11:00:47 <phantomcircuit> wumpus, ^ yup doesn't build
906 2015-10-01T11:02:47 *** missmogg has quit IRC
907 2015-10-01T11:03:01 *** lewellyn has quit IRC
908 2015-10-01T11:03:15 *** TheAdversary has quit IRC
909 2015-10-01T11:03:25 *** Hasimir has quit IRC
910 2015-10-01T11:03:54 *** missmogg has joined #bitcoin-dev
911 2015-10-01T11:04:29 *** slowpoison has quit IRC
912 2015-10-01T11:04:29 *** lewellyn has joined #bitcoin-dev
913 2015-10-01T11:04:53 <phantomcircuit> huh
914 2015-10-01T11:04:55 *** shaul has joined #bitcoin-dev
915 2015-10-01T11:04:57 <phantomcircuit> Luke-Jr, you sure?
916 2015-10-01T11:05:13 <Luke-Jr> phantomcircuit: looks like the autotools logic to re-run configure is just broken
917 2015-10-01T11:05:19 <Luke-Jr> manually re-configuring fixed it
918 2015-10-01T11:05:23 *** CodeShark has quit IRC
919 2015-10-01T11:05:36 *** CodeShark__ is now known as CodeShark
920 2015-10-01T11:07:30 *** TheAdversary has joined #bitcoin-dev
921 2015-10-01T11:07:36 *** Hasimir has joined #bitcoin-dev
922 2015-10-01T11:09:18 *** lewellyn has quit IRC
923 2015-10-01T11:09:28 *** btc_panhandler_ has joined #bitcoin-dev
924 2015-10-01T11:10:42 *** lewellyn has joined #bitcoin-dev
925 2015-10-01T11:10:59 *** missmogg has quit IRC
926 2015-10-01T11:11:18 *** missmogg has joined #bitcoin-dev
927 2015-10-01T11:12:21 <wumpus> master builds fine, however you need to re-autoconf and configure after #6637
928 2015-10-01T11:12:23 *** romonster has quit IRC
929 2015-10-01T11:12:45 *** romonster has joined #bitcoin-dev
930 2015-10-01T11:16:09 *** lightningbot has joined #bitcoin-dev
931 2015-10-01T11:17:21 <Luke-Jr> wumpus: autotools is *supposed* to automatically take care of that when you run make FWIW ;)
932 2015-10-01T11:17:26 *** shesek has quit IRC
933 2015-10-01T11:17:31 <Luke-Jr> but I'll nag cfields on that
934 2015-10-01T11:17:49 *** lightningbot has joined #bitcoin-dev
935 2015-10-01T11:18:43 *** pikefloyd has quit IRC
936 2015-10-01T11:19:38 *** tawster has quit IRC
937 2015-10-01T11:19:38 *** rolandnsharp has quit IRC
938 2015-10-01T11:19:53 *** Ahmed90 has joined #bitcoin-dev
939 2015-10-01T11:19:54 *** rolandnsharp has joined #bitcoin-dev
940 2015-10-01T11:20:47 *** slowpoison has joined #bitcoin-dev
941 2015-10-01T11:22:33 *** missmogg has quit IRC
942 2015-10-01T11:24:34 *** rdymac has joined #bitcoin-dev
943 2015-10-01T11:25:27 *** palexander has joined #bitcoin-dev
944 2015-10-01T11:30:20 *** palexander has left #bitcoin-dev
945 2015-10-01T11:30:43 *** billotronic has quit IRC
946 2015-10-01T11:32:21 *** lewellyn has joined #bitcoin-dev
947 2015-10-01T11:33:57 *** missmogg has joined #bitcoin-dev
948 2015-10-01T11:36:07 <wumpus> for most changes it does, but for big impactful changes to the build system it doesn't
949 2015-10-01T11:36:27 <wumpus> and moving univalue to a subtree is quite impactful as these things go
950 2015-10-01T11:38:48 *** n0n0_ has quit IRC
951 2015-10-01T11:42:05 *** wraithm has quit IRC
952 2015-10-01T11:44:54 *** BashCo has quit IRC
953 2015-10-01T11:44:59 *** noobfikt has quit IRC
954 2015-10-01T11:46:40 *** romonster has quit IRC
955 2015-10-01T11:47:14 *** ParadoxSpiral_ has quit IRC
956 2015-10-01T11:48:21 *** ne1l has joined #bitcoin-dev
957 2015-10-01T11:48:59 *** lewellyn has quit IRC
958 2015-10-01T11:49:06 *** missmogg has quit IRC
959 2015-10-01T11:49:36 *** lewellyn has joined #bitcoin-dev
960 2015-10-01T11:50:05 *** romonster has joined #bitcoin-dev
961 2015-10-01T11:50:19 *** Emzy has quit IRC
962 2015-10-01T11:50:50 *** ne1l has quit IRC
963 2015-10-01T11:52:00 *** missmogg has joined #bitcoin-dev
964 2015-10-01T11:53:17 *** noobfikt has joined #bitcoin-dev
965 2015-10-01T11:56:33 *** shaul has joined #bitcoin-dev
966 2015-10-01T11:58:36 *** h3xc0d3r has quit IRC
967 2015-10-01T12:02:01 *** notj has joined #bitcoin-dev
968 2015-10-01T12:02:51 *** shaul has quit IRC
969 2015-10-01T12:02:51 *** veleiro has quit IRC
970 2015-10-01T12:03:30 *** notj has quit IRC
971 2015-10-01T12:03:50 *** veleiro1 has joined #bitcoin-dev
972 2015-10-01T12:04:22 *** shaul has joined #bitcoin-dev
973 2015-10-01T12:06:11 *** NewLiberty has quit IRC
974 2015-10-01T12:06:24 *** akrmn has quit IRC
975 2015-10-01T12:10:49 *** h3xc0d3r has joined #bitcoin-dev
976 2015-10-01T12:12:40 *** jtimon has joined #bitcoin-dev
977 2015-10-01T12:12:55 *** ThomasV has joined #bitcoin-dev
978 2015-10-01T12:14:56 *** won9 has joined #bitcoin-dev
979 2015-10-01T12:17:06 *** damethos has joined #bitcoin-dev
980 2015-10-01T12:18:37 *** MaxSan_ has quit IRC
981 2015-10-01T12:18:52 *** one_zero has joined #bitcoin-dev
982 2015-10-01T12:19:16 *** damethos has quit IRC
983 2015-10-01T12:22:48 *** NewLiberty has joined #bitcoin-dev
984 2015-10-01T12:29:13 *** notj has joined #bitcoin-dev
985 2015-10-01T12:31:54 *** ThomasV has quit IRC
986 2015-10-01T12:32:40 *** priidu has quit IRC
987 2015-10-01T12:33:42 *** bedeho has quit IRC
988 2015-10-01T12:33:49 *** twistedline has quit IRC
989 2015-10-01T12:34:11 *** bedeho has joined #bitcoin-dev
990 2015-10-01T12:34:25 *** MaxSan_ has joined #bitcoin-dev
991 2015-10-01T12:37:09 *** BCBot has quit IRC
992 2015-10-01T12:39:26 *** lightningbot has joined #bitcoin-dev
993 2015-10-01T12:40:39 *** BCBot has joined #bitcoin-dev
994 2015-10-01T12:45:24 *** mik_ has quit IRC
995 2015-10-01T12:45:53 *** shaul has joined #bitcoin-dev
996 2015-10-01T12:47:38 *** RazielZ has joined #bitcoin-dev
997 2015-10-01T12:47:59 *** MaxSan_ has quit IRC
998 2015-10-01T12:48:05 *** Raziel has quit IRC
999 2015-10-01T12:48:42 *** maraoz has quit IRC
1000 2015-10-01T12:49:06 *** MaxSan_ has joined #bitcoin-dev
1001 2015-10-01T12:49:54 *** ludxx has quit IRC
1002 2015-10-01T12:50:59 *** wjh has quit IRC
1003 2015-10-01T12:51:19 *** roasbeef has quit IRC
1004 2015-10-01T12:51:26 *** tawster has joined #bitcoin-dev
1005 2015-10-01T12:51:50 *** bedeho has quit IRC
1006 2015-10-01T12:51:53 *** XexorZ has joined #bitcoin-dev
1007 2015-10-01T12:51:53 *** ludx has joined #bitcoin-dev
1008 2015-10-01T12:52:18 *** roasbeef has joined #bitcoin-dev
1009 2015-10-01T12:52:19 *** h3xc0d3r has quit IRC
1010 2015-10-01T12:52:19 *** ludx has quit IRC
1011 2015-10-01T12:52:20 *** ludx has joined #bitcoin-dev
1012 2015-10-01T12:52:52 <XexorZ> Anyone here really understand the inner workings of the blockchain? I've a likely hairbrained idea I'd like to discuss if you're bored and need a laugh.
1013 2015-10-01T12:53:08 *** h3xc0d3r has joined #bitcoin-dev
1014 2015-10-01T12:53:27 *** wjh has joined #bitcoin-dev
1015 2015-10-01T12:55:38 *** richardkiss has quit IRC
1016 2015-10-01T12:55:40 <Luke-Jr> wumpus: ping
1017 2015-10-01T12:55:40 *** bedeho has joined #bitcoin-dev
1018 2015-10-01T12:56:00 <Luke-Jr> wumpus: I am trying to address https://github.com/bitcoin/bitcoin/pull/6349#discussion-diff-35016896 , but I don't see a way to do it.
1019 2015-10-01T12:56:25 <Luke-Jr> GCC doesn't like simply moving it to util.cpp (even removing static and adding an extern in the header)
1020 2015-10-01T12:56:34 <XexorZ> So the blockchain is getting massive. I was thinking, why not just consolodate all current up to the last 100 or so blocks into some sort of prefix-index at an agreed upon time... All sum-zero transactions would go away. Tons of other stuff would go away. I think things would get mighty small then... no? Likely totally worthless idea but I thought I'd ask folks who had a clue.
1021 2015-10-01T12:57:53 <deego> XexorZ: iiuc, that's the first thing anyone proposes. :) But, that's about all i know
1022 2015-10-01T12:57:54 <Luke-Jr> XexorZ: if you want to trust some centralised group, that works
1023 2015-10-01T12:58:33 <XexorZ> Luke-Jr: no need to trust a centralized group, the consolidation index can be hashed too, no?
1024 2015-10-01T12:58:44 <Luke-Jr> XexorZ: if you want to make it a regular thing as part of blocks using the consensus system to keep it secure (ie, make the trusted group "all full nodes"), then it's complicated to implement
1025 2015-10-01T12:58:56 <Luke-Jr> XexorZ: hashing it doesn't prove it is correct
1026 2015-10-01T12:59:54 <XexorZ> Luke-Jr would be a consensus of all full nodes. Would hapen at pre-determined period. Last "N" number of blocks would remain so current transactions could continue (I think). Of course I'm speaking out of my arse - I know very little about all of this and appreciate your thoughts on the same.
1027 2015-10-01T13:00:09 <XexorZ> Luke-Jr Right, but consensus does prove it correct, no?
1028 2015-10-01T13:00:28 <Luke-Jr> XexorZ: no, but it proves a large number of nodes checked it
1029 2015-10-01T13:00:41 <Luke-Jr> I don't think delaying it in groups of N blocks makes it any less complicated
1030 2015-10-01T13:00:48 <Luke-Jr> might actually make it more complicated
1031 2015-10-01T13:01:00 *** DougieBot5000 has quit IRC
1032 2015-10-01T13:01:05 <XexorZ> I figured it would allow for current transactions to complete - perhaps that's foolish.
1033 2015-10-01T13:01:22 <Luke-Jr> XexorZ: well, a one block delay would do that
1034 2015-10-01T13:01:46 <Luke-Jr> but it's undetermined if that's a good idea or not
1035 2015-10-01T13:02:05 *** richardkiss has joined #bitcoin-dev
1036 2015-10-01T13:02:05 <XexorZ> Oh? I had no idea. I thought some low-urgency transactions stalled for hours or days
1037 2015-10-01T13:04:39 <XexorZ> Anywho thanks for your thoughts on the idea. I wanted to get it out before I lost it in case it had some sort of use.
1038 2015-10-01T13:06:27 <maaku> XexorZ: it's been proposed. it is strictly speaking a break from bitcoin's security model
1039 2015-10-01T13:06:49 <maaku> but a variant of that idea is what we'll probably end up with once the block chain gets unreasonably large (fetch utxo set a year back and validate from there)
1040 2015-10-01T13:06:59 *** Logicwax has quit IRC
1041 2015-10-01T13:07:19 <Luke-Jr> (opt-in of course)
1042 2015-10-01T13:07:25 <XexorZ> (y) Thank you Maaku. I assumed someone else thought it up already as it seems so simple to me, but again, I don't grasp 1/100th the details of how things work in the blockchain.
1043 2015-10-01T13:08:01 <berndj> XexorZ, most recently that i'm aware of: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011065.html
1044 2015-10-01T13:09:17 *** Yoghur114 has quit IRC
1045 2015-10-01T13:10:51 <XexorZ> Thank you Berndj, that sounds about what I'm talking about if I understand what is being said there correctly.
1046 2015-10-01T13:12:03 *** noobfikt has quit IRC
1047 2015-10-01T13:12:41 *** Logicwax has joined #bitcoin-dev
1048 2015-10-01T13:12:45 *** BCBot has quit IRC
1049 2015-10-01T13:13:10 *** jtimon has quit IRC
1050 2015-10-01T13:14:32 <maaku> XexorZ: there's a number of reasons it's good to commit to the validaiton state, e.g. the utxo set. and once you do that something like this becomes possible, whether it is a good idea or not..
1051 2015-10-01T13:16:17 *** noobfikt has joined #bitcoin-dev
1052 2015-10-01T13:16:53 *** CheckDavid has quit IRC
1053 2015-10-01T13:17:22 *** dfletcher has quit IRC
1054 2015-10-01T13:17:58 *** richardkiss has quit IRC
1055 2015-10-01T13:18:53 *** twistedline has joined #bitcoin-dev
1056 2015-10-01T13:19:38 *** BCBot has joined #bitcoin-dev
1057 2015-10-01T13:22:13 *** malduron has joined #bitcoin-dev
1058 2015-10-01T13:22:35 *** cryptapus_ has joined #bitcoin-dev
1059 2015-10-01T13:22:35 *** cryptapus_ has joined #bitcoin-dev
1060 2015-10-01T13:22:45 *** btc_panhandler_ has quit IRC
1061 2015-10-01T13:25:07 *** rmwb has quit IRC
1062 2015-10-01T13:25:25 *** rmwb has joined #bitcoin-dev
1063 2015-10-01T13:25:36 *** shaul has quit IRC
1064 2015-10-01T13:28:08 *** dfletcher has joined #bitcoin-dev
1065 2015-10-01T13:29:06 *** bedeho has quit IRC
1066 2015-10-01T13:32:54 *** bedeho has joined #bitcoin-dev
1067 2015-10-01T13:36:34 *** XexorZ has quit IRC
1068 2015-10-01T13:38:55 *** h3xc0d3r has quit IRC
1069 2015-10-01T13:40:31 *** bedeho has quit IRC
1070 2015-10-01T13:40:51 *** richardkiss has joined #bitcoin-dev
1071 2015-10-01T13:40:54 *** d_t has quit IRC
1072 2015-10-01T13:42:53 *** bedeho has joined #bitcoin-dev
1073 2015-10-01T13:44:04 *** d_t has joined #bitcoin-dev
1074 2015-10-01T13:46:27 *** btc_panhandler_ has joined #bitcoin-dev
1075 2015-10-01T13:55:16 *** Sosumi has quit IRC
1076 2015-10-01T13:57:52 *** c0rw|away is now known as c0rw|drnk
1077 2015-10-01T13:59:48 *** c0rw|drnk is now known as c0rw|zZz