1 2016-08-05T00:00:28  <sipa> sdaftuar, luke-jr, gmaxwell, wumpus: i believe that downgrading from 0.13.1 to 0.13.0 will just work
  2 2016-08-05T00:00:49  <sipa> sdaftuar: even in case of a reorg that takes you back into witness-enabled code
  3 2016-08-05T00:00:55  <sipa> s/code/blocks/
  4 2016-08-05T00:01:16  <luke-jr> well, that's good, I think
  5 2016-08-05T00:01:16  *** Chris_Stewart_5 has quit IRC
  6 2016-08-05T00:01:43  <sipa> the test that no witness data is present in non-witness blocks is only done in AcceptBlock, not in ConnectBlock
  7 2016-08-05T00:02:01  <sipa> so we enforce it when receiving the block from somewhere, but not afterwards
  8 2016-08-05T00:02:06  <sipa> which i think is exactly right
  9 2016-08-05T00:02:44  <gmaxwell> sipa: what happens if you downgrad then upgrade again?
 10 2016-08-05T00:03:33  <sipa> gmaxwell: newly added blocks will be rewinded
 11 2016-08-05T00:15:14  *** fengling has joined #bitcoin-core-dev
 12 2016-08-05T00:20:06  *** fengling has quit IRC
 13 2016-08-05T00:33:32  *** jtimon has quit IRC
 14 2016-08-05T00:41:39  *** TomMc has quit IRC
 15 2016-08-05T00:49:42  <morcos> sipa: luke-jr: sorry, but i'm not sure i understand sipa's suggested compromise in 8459.  sorry i don't remember exactly what the first version was, but i think it makes sense to explain that you don't NEED to specify both size and weight, otherwise its just confusing as to how you are supposed to set things up
 16 2016-08-05T00:50:56  <morcos> as to making a recommendation whether or not to set size...  i'm not sure why you say its not worse than 0.12, we don't know that.  my guess is that it isn't significantly worse now, but it certainly could be post segwit, when you are trying to fit the last tx in a block and you keep trying EVERYTHING b/c the limit thats stopping you isn't the consensus limit
 17 2016-08-05T00:51:52  <morcos> i do apologize for not testing at least the serialization effect (the other would be tricky to test), but i've been too caught up in trying to figure out why waking up threads is so abysmally slow
 18 2016-08-05T00:52:14  <luke-jr> it doesn't serialise any more than without maxsize AFAIK.
 19 2016-08-05T00:52:21  <luke-jr> GetSerializeSize doesn't serialize
 20 2016-08-05T00:54:00  <morcos> ah so its expected that GetSerializeSize is fast?  well that explains why anecdotally its not slower
 21 2016-08-05T00:54:01  <luke-jr> morcos: I thought it was obvious the options were optional.. but if you disagree, I can add perhaps: "Both of these are optional, but at least blockmaxsize ought to be assigned by miners, to determine the largest block they are willing to create."
 22 2016-08-05T00:54:25  <morcos> luke-jr: i assume you make suggestions like that on purpose
 23 2016-08-05T00:54:25  <luke-jr> morcos: GetSerializeSize is literally just adding the sizes of each field
 24 2016-08-05T00:54:48  <luke-jr> morcos: ?
 25 2016-08-05T00:55:44  <sipa> i expect getserializesize time to be dominated by just memory access of iterating all vectors
 26 2016-08-05T00:56:07  <morcos> luke-jr: you are against what you see as advice in the notes to use weight, but surely you understand that all of us are against advice to limit based on bytes?  if any of us believed that was an issue, we'd be opposed to segwit
 27 2016-08-05T00:56:33  <luke-jr> morcos: it is clearly an issue today. I am shocked that anyone would disagree.
 28 2016-08-05T00:56:53  <luke-jr> 0.13 will hopefully change that with CB, but it isn't deployed yet.
 29 2016-08-05T00:58:10  <sipa> luke-jr: my view is that at worst it may make block propagation slightly worse, but at the same time it improves utxo storage incentives, which i'm much more concerned about long term
 30 2016-08-05T00:58:26  <morcos> how about language along the lines of "If a miner wishes to limit the actual size of a block in bytes (as opposed to the consensus weight limit) then it is necessary to specify a blockmaxsize explicitly.  If a miner does not wish to do that, it would be better to only specify a blockmaxweight"
 31 2016-08-05T00:58:41  <sipa> a small constant factor was never something i opposed for block size. an expectation of it being increased under whatever perceived pressure is
 32 2016-08-05T00:59:00  <luke-jr> morcos: that suggests miners ought not to limit size
 33 2016-08-05T00:59:08  <sipa> i think miners ought not to limit size
 34 2016-08-05T00:59:11  <morcos> something like that, not exactly "as opposed to" b/c that sounds like you're not enforcing the consensus limit
 35 2016-08-05T00:59:19  <sipa> because it's unreasonable that all of them will
 36 2016-08-05T00:59:54  <morcos> luke-jr: why does that language suggest they ought not limit size.   its just saying that if you dont' care about a limit on actual size, then its better to not set blockmaxsize.
 37 2016-08-05T00:59:59  <morcos> which is TRUE
 38 2016-08-05T01:00:24  <luke-jr> if they don't care, they should set it based on someone's recommendation, but not necessarily the big blocker recommendation
 39 2016-08-05T01:01:03  <luke-jr> if they care about Bitcoin (but not per se enough to research their own opinion on block size limits), they should follow recommendations to set it lower.
 40 2016-08-05T01:01:22  <sipa> luke-jr: as a collective, perhaps
 41 2016-08-05T01:01:26  <luke-jr> brb
 42 2016-08-05T01:01:41  <sipa> luke-jr: there could be a gentlemen's agreement not to set it to the maximum immediately
 43 2016-08-05T01:01:44  *** jtimon has joined #bitcoin-core-dev
 44 2016-08-05T01:01:56  <sipa> but i believe that's unrealistic at this point
 45 2016-08-05T01:02:29  <morcos> "If a miner wishes to limit the actual size of a block in bytes then it is necessary to specify a  blockmaxsize explicitly.  If a miner wishes only to limit block creation by weight (BIP141) regardless of how large in bytes the block is they should only specify a blockmaxweight"
 46 2016-08-05T01:02:52  <luke-jr> sipa: every time I brought this up before, I was asked to "wait for the segwit release notes"; now I'm told it's too late?
 47 2016-08-05T01:02:53  <morcos> i'm trying to make it as neutral as possible, while explaining the difference
 48 2016-08-05T01:02:56  <luke-jr> (still brb mode)
 49 2016-08-05T01:03:32  <morcos> what i don't want is a bunch of miners trying to mine max blocks and having a blockmaxsize set (especially after segwit).  and we have to explain in detail enough for that to happen.  i have no objection if they actually want to limit bytes
 50 2016-08-05T01:03:54  <sipa> luke-jr: i can't remember ever recommending to wait for release notes. i have told you many times that if you disagree that weight is the limiting factor on the network, you should oppose segwit
 51 2016-08-05T01:05:33  <morcos> sipa: want to think about something different an arcane for a second?   in those checkqueue graphs i presented you, the scriptthreads were busyspinning waiting for work
 52 2016-08-05T01:05:50  *** Ylbam has quit IRC
 53 2016-08-05T01:05:58  <sipa> morcos: i heard
 54 2016-08-05T01:06:08  <morcos> it slows down the whole thing quite a bit (about 5ms per block) but still a big improvement, if you wake up the scripthreads only when there is work
 55 2016-08-05T01:06:39  *** fengling has joined #bitcoin-core-dev
 56 2016-08-05T01:06:51  <morcos> even though it takes only about 100us for them all to wake up, and you can make that happen as early as the start of ConnectTip so they are all awake and busy spinning well before work comes in
 57 2016-08-05T01:07:10  <morcos> i'm assuming its the fact that their caches have been blown away, but doesn't 5ms seem like a lot?
 58 2016-08-05T01:08:20  <morcos> just wondering if you had any thoughts..  we're still working on it (mostly jeremy, i'm mostly just testing)
 59 2016-08-05T01:09:07  <sipa> morcos: is the slowdown as significant when you have fewer threads?
 60 2016-08-05T01:09:28  <morcos> sadly i didn't test that
 61 2016-08-05T01:10:14  <morcos> yet
 62 2016-08-05T01:11:44  <sipa> and this is 5ms clock time, not cpu time?
 63 2016-08-05T01:13:04  <morcos> yes, 5ms clock time.  it appears from debugging that the scriptthreads are just slower to run.
 64 2016-08-05T01:13:53  *** spudowiar has quit IRC
 65 2016-08-05T01:16:42  <sipa> i guess if there are many memory locations to access one by one for script validation to run, the effect of not running could be many ram latencies
 66 2016-08-05T01:16:53  <sipa> but i'm not sure whether than makes sense
 67 2016-08-05T01:18:01  <morcos> ok, don't worry about it.. its mostly just bugging me.  i realize that it doesn't make sense to micro optimize for one architecture anyway, but just trying to understand the effect
 68 2016-08-05T01:22:51  *** belcher has quit IRC
 69 2016-08-05T01:41:58  *** arowser has joined #bitcoin-core-dev
 70 2016-08-05T01:42:33  *** arowser has left #bitcoin-core-dev
 71 2016-08-05T01:43:07  *** arowser has joined #bitcoin-core-dev
 72 2016-08-05T01:57:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 73 2016-08-05T02:22:37  *** arowser has quit IRC
 74 2016-08-05T02:28:04  *** Chris_Stewart_5 has quit IRC
 75 2016-08-05T03:09:11  *** Alopex has quit IRC
 76 2016-08-05T03:10:17  *** Alopex has joined #bitcoin-core-dev
 77 2016-08-05T03:10:59  <PatBoy> thx dev for all ur hard work !
 78 2016-08-05T03:11:21  <luke-jr> sipa: I do not believe that opposing segwit is a serious suggestion.
 79 2016-08-05T03:12:40  <luke-jr> morcos: then in the segwit announcement, we can re-evaluate and make recommendations that make sense given the new network conditions
 80 2016-08-05T03:13:11  <luke-jr> (which might or might not include removing blockmaxsize depending on CB effectiveness and real-world testing)
 81 2016-08-05T03:15:08  <sipa> luke-jr: miners will set block and weight likely to the maximum... that may be suboptimal, but it's inevitable that this is what will happen if segwit goes through
 82 2016-08-05T03:15:53  <sipa> people can suggest to not do that... but for centralization risk (which is a long term effect), the important question is now what people do, but what they could do
 83 2016-08-05T03:16:00  <sipa> *not
 84 2016-08-05T03:16:06  <luke-jr> sipa: we don't know that yet, and our recommendations should always be what is sane even if they get ignored.
 85 2016-08-05T03:18:12  <sipa> luke-jr: that's a reasonable position... but the code is written from a viewpoint that we will get weight-limited block construction
 86 2016-08-05T03:18:28  <sipa> luke-jr: and the release notes should describe the code
 87 2016-08-05T03:19:26  <luke-jr> then the code is broken (sabotaged, it sounds like) and fixing it should be considered a blocker for any release.
 88 2016-08-05T03:19:56  <sipa> if that is your viewpoint, then it is segwit that is sabotaged
 89 2016-08-05T03:20:25  <sipa> i disagree strongly with that
 90 2016-08-05T03:20:45  <luke-jr> sipa: do you disagree strongly with 29000050e575a26b7f7c853cbccdb6bc60ddfdd9 for 0.13?
 91 2016-08-05T03:21:22  <sipa> i think it's pointless
 92 2016-08-05T03:21:45  <sipa> we're doing busy work to avoid stating reality in release notes
 93 2016-08-05T03:21:56  <sipa> the reality is that segwit will mean that blocks go over 1 MB
 94 2016-08-05T03:22:02  <luke-jr> reality is that blockmaxsize should be used for today and the near future
 95 2016-08-05T03:22:11  <sipa> i disagree with that
 96 2016-08-05T03:22:28  <gmaxwell> luke-jr: I think you are not paying attention to reality. Virtually all miners make blocks as large as they can. If at any point they make a block smaller than maximum, angry mobs show up and demand them to make maximum size blocks. Not wanting to deal with such nonsense, they simply do it.
 97 2016-08-05T03:22:36  <sipa> or rather, i would agree with that if there was a reasonable chance that the entire ecosystem will self limit in that way
 98 2016-08-05T03:22:39  <sipa> it won't
 99 2016-08-05T03:22:57  <gmaxwell> this is the existing behavior in the network, and has been for a long time-- more or less since we made it configurable at all.
100 2016-08-05T03:23:21  <luke-jr> sipa: the entire ecosystem doesn't need to; why is it all or nothing?
101 2016-08-05T03:23:44  <luke-jr> gmaxwell: that's with 1 MB blocks. who knows if it will work out the same with 3 MB
102 2016-08-05T03:24:21  <gmaxwell> it especially will work out that way, with CB and relay mitigating orphaning effects.
103 2016-08-05T03:24:27  <luke-jr> I know that if miners start doing >1 MB blocks before the network is ready, I will intentionally NOT use a segwit wallet, to do my small part in preventing them from bloating the blocks. I think a lot of the community could be convinced to do the same.
104 2016-08-05T03:24:40  <gmaxwell> luke-jr: and if you want to posit a change in how things work you should suggest how.
105 2016-08-05T03:25:08  <gmaxwell> luke-jr: nothing held back blocksizes from growing from 250k to 1mb... not even the defaults in bitcoin core-- or large increases in orphaning rates.
106 2016-08-05T03:25:17  <sipa> luke-jr: smaller blocks will always be better for propagation relay effects, and larger blocks will always be worse
107 2016-08-05T03:25:30  <sipa> luke-jr: there is no 'ready' here; just a compromise that is acceptable
108 2016-08-05T03:25:49  <sipa> segwit shifts the relay effects one way, but shifts other incentives the other way
109 2016-08-05T03:27:37  <luke-jr> ugh, even IF miners will end up doing terrible things, it doesn't mean we need to sabotage miners who WANT to do what is best for the network.
110 2016-08-05T03:28:19  <gmaxwell> its not a question of "want to do what is best"; most people don't want to decide and do not have the time to do so in any case.
111 2016-08-05T03:28:28  <gmaxwell> You're thinking in terms of pixie unicorn miners.
112 2016-08-05T03:28:35  <sipa> the only way miners can do something that is good for the network is by making themselves replacable
113 2016-08-05T03:28:44  <gmaxwell> Go look at the actual blocks. The miners you're expecting just don't exist at a meaningful level.
114 2016-08-05T03:30:19  <sipa> luke-jr: moreover, we're not removing the ability to limit the block size
115 2016-08-05T03:31:22  <sipa> reality is that the code is optimized for limiting by weight, and segwit is designed with the assumption that that is what will happen... your suggestions seem to be that we should hide that
116 2016-08-05T03:31:51  <sipa> block size limiting is supported, and we should explain how to use it for those who want to
117 2016-08-05T03:32:01  <luke-jr> gmaxwell: yes, pixie unicorn miners who actually exist, despite being ignored by Core
118 2016-08-05T03:32:42  <luke-jr> sipa: either blockmaxsize has a notable cost or it doesn't. if it doesn't, there is no reason to claim it does.
119 2016-08-05T03:32:51  <sipa> luke-jr: so, benchmark
120 2016-08-05T03:32:52  <luke-jr> if it does, then it's sabotaging miners who use it
121 2016-08-05T03:33:25  <gmaxwell> luke-jr: they don't exist in a meaningful sense. a miner that gets a block a day is not making a meaningful dent in the systems' survivability.
122 2016-08-05T03:33:42  <sipa> luke-jr: limiting by block size is already taking a cut. fee income will be suboptimal if you limit by size
123 2016-08-05T03:33:49  <sipa> luke-jr: that's as much sabotaging
124 2016-08-05T03:33:51  <luke-jr> gmaxwell: so that justifies ignoring the requests of such miners, and sabotaging them with (allegedly) bad performance?
125 2016-08-05T03:34:15  <sipa> limiting by weight is a design decision which has costs
126 2016-08-05T03:34:18  <gmaxwell> 'sabotaging' after I had to jump up and down and yell for over a month to get eligius to upgrade to 0.12 even though it made a _tens of fold_ increase in createnewblocktime?
127 2016-08-05T03:34:40  <gmaxwell> This is such bullshit.
128 2016-08-05T03:34:40  *** gmaxwell has left #bitcoin-core-dev
129 2016-08-05T03:35:46  <luke-jr> ignoring that 0.12 broke numerous things Eligius provided that were left unmerged in Core since 0.6..
130 2016-08-05T03:36:22  <sipa> such as?
131 2016-08-05T03:36:25  <luke-jr> CPFP
132 2016-08-05T03:37:22  <sipa> i never trusted that code enough to merge
133 2016-08-05T03:37:25  *** gmaxwell has joined #bitcoin-core-dev
134 2016-08-05T03:37:29  <sipa> and i think i was not alone
135 2016-08-05T03:37:53  <gmaxwell> I am fed up with this.
136 2016-08-05T03:38:09  <luke-jr> same here.
137 2016-08-05T03:38:24  <gmaxwell> luke-jr: you are abusive towards me and the other contributors.
138 2016-08-05T03:38:30  <gmaxwell> you are obsessing over minutia on top of minutia.
139 2016-08-05T03:38:48  <gmaxwell> You are wasting countless hours exhausting all patience.
140 2016-08-05T03:39:54  <gmaxwell> Over matters which _do_ _not_ _matter_.  The few obscure miners which will set non-defaults even though they get abusive and threatening contact from users (which drives away their hashpower); can _still_ do so. If it's slightly slower? so what--- the latest software is dozens of times faster to creates blocks than older software and they hardly cared to upgrade.
141 2016-08-05T03:40:55  <gmaxwell> it litterally makes no difference in the world, and yet you force people to spend hours and hours debating these things.
142 2016-08-05T03:41:28  <gmaxwell> and I get to spend my time asking others to not leave the project because they are exhausted by you; but it even exhausts me too.
143 2016-08-05T03:45:27  <gmaxwell> The last block from eligius was 64 hours ago.  It contained _NO_ transactions.  I would say that createnew block being merely 29.5 times faster than the old code it was running until recently instead of 30x faster won't matter. ... except it won't even see that difference when it mines empty blocks with no transactions at all.
144 2016-08-05T03:47:48  <gmaxwell> When it does actually include transactions-- it appears to produce maximum size blocks just like everyone else: https://blockchain.info/block/0000000000000000050631b932ed81eb9de6267f1cb8b8a353dd59365fd07fd5
145 2016-08-05T04:53:06  *** fengling has quit IRC
146 2016-08-05T05:22:23  *** jtimon has quit IRC
147 2016-08-05T05:30:20  *** fengling has joined #bitcoin-core-dev
148 2016-08-05T05:42:35  *** d_t has joined #bitcoin-core-dev
149 2016-08-05T05:49:26  *** fengling has quit IRC
150 2016-08-05T06:17:23  *** zooko has joined #bitcoin-core-dev
151 2016-08-05T06:19:42  *** gabridome has joined #bitcoin-core-dev
152 2016-08-05T06:27:19  *** randy-waterhouse has quit IRC
153 2016-08-05T06:29:33  *** fengling has joined #bitcoin-core-dev
154 2016-08-05T06:32:14  *** gabridome has quit IRC
155 2016-08-05T06:33:15  *** Silence_ has joined #bitcoin-core-dev
156 2016-08-05T06:35:20  *** d_t has quit IRC
157 2016-08-05T06:35:29  *** d_t has joined #bitcoin-core-dev
158 2016-08-05T06:45:03  *** BashCo has quit IRC
159 2016-08-05T06:45:54  *** zooko has quit IRC
160 2016-08-05T07:05:48  *** Cory has quit IRC
161 2016-08-05T07:06:39  *** Pasha has joined #bitcoin-core-dev
162 2016-08-05T07:13:33  *** Pasha is now known as Cory
163 2016-08-05T07:14:04  *** laurentmt has joined #bitcoin-core-dev
164 2016-08-05T07:16:09  *** BashCo has joined #bitcoin-core-dev
165 2016-08-05T07:18:13  *** LaudaM has quit IRC
166 2016-08-05T07:31:11  *** Guyver2 has joined #bitcoin-core-dev
167 2016-08-05T07:38:28  *** jgarzik has quit IRC
168 2016-08-05T07:43:27  *** d_t has quit IRC
169 2016-08-05T07:50:30  *** Giszmo has joined #bitcoin-core-dev
170 2016-08-05T07:53:02  *** Giszmo has quit IRC
171 2016-08-05T07:59:27  *** Evel-Knievel has quit IRC
172 2016-08-05T08:01:34  *** Evel-Knievel has joined #bitcoin-core-dev
173 2016-08-05T08:20:12  *** Guyver2 has quit IRC
174 2016-08-05T08:23:45  *** kadoban has quit IRC
175 2016-08-05T08:39:07  *** jtimon has joined #bitcoin-core-dev
176 2016-08-05T08:40:23  *** rubensayshi has joined #bitcoin-core-dev
177 2016-08-05T08:40:50  *** rubensayshi has quit IRC
178 2016-08-05T08:41:38  *** rubensayshi has joined #bitcoin-core-dev
179 2016-08-05T09:02:05  *** spudowiar has joined #bitcoin-core-dev
180 2016-08-05T09:09:55  *** Ylbam has joined #bitcoin-core-dev
181 2016-08-05T09:30:16  *** jtimon has quit IRC
182 2016-08-05T09:37:57  *** shesek has joined #bitcoin-core-dev
183 2016-08-05T10:40:02  <jonasschnelli> I think "memusage.h" should include "prevector.h"
184 2016-08-05T10:46:31  *** arubi_ has joined #bitcoin-core-dev
185 2016-08-05T10:50:15  *** arubi has quit IRC
186 2016-08-05T10:55:26  *** fengling has quit IRC
187 2016-08-05T10:56:08  <GitHub83> [bitcoin] jonasschnelli closed pull request #7865: [RPC] Add bumpfee command. (master...2016/04/rbf_combined) https://github.com/bitcoin/bitcoin/pull/7865
188 2016-08-05T11:03:43  *** arubi__ has joined #bitcoin-core-dev
189 2016-08-05T11:07:03  *** arubi_ has quit IRC
190 2016-08-05T11:23:29  *** AaronvanW has joined #bitcoin-core-dev
191 2016-08-05T11:25:50  *** Ylbam has quit IRC
192 2016-08-05T11:33:36  *** spudowiar has quit IRC
193 2016-08-05T11:37:02  *** Alopex has quit IRC
194 2016-08-05T11:38:07  *** Alopex has joined #bitcoin-core-dev
195 2016-08-05T12:03:25  *** Lauda has quit IRC
196 2016-08-05T12:03:25  *** Lauda has joined #bitcoin-core-dev
197 2016-08-05T12:11:32  *** cryptapus_afk is now known as cryptapus
198 2016-08-05T12:22:31  <wumpus> jonasschnelli: you'd say so, as the type is used; but does any compiler complain about this in practice? it's in a template, so it could be that you only need it at instantiation time
199 2016-08-05T12:22:45  <wumpus> I'm a little rusty on the exact rules there though
200 2016-08-05T12:23:16  <jonasschnelli> wumpus: I just added some stats stuff and included memusage.h, compiler was then complaining about the missing type prevector...
201 2016-08-05T12:24:02  <jonasschnelli> memusage.h is directly using (in a template but directly) prevector
202 2016-08-05T12:24:23  <jonasschnelli> But anyways... far away from important. :)
203 2016-08-05T12:24:38  <wumpus> does the data structure that you're trying to measure include a prevector
204 2016-08-05T12:24:41  <wumpus> ?
205 2016-08-05T12:25:16  <jonasschnelli> no. I just want to measure a vector of structs... but mempool.h refers to prevector
206 2016-08-05T12:25:39  <jonasschnelli> I guess all other places where mempool.h is included, prevector was previously already included
207 2016-08-05T12:26:05  <wumpus> there is no mempool.h? I guess you mean memusage.h?
208 2016-08-05T12:26:19  <jonasschnelli> argm. memusage.h
209 2016-08-05T12:26:28  <wumpus> indeed, if including memusage.h forces you to include prevector.h then it should be included there
210 2016-08-05T12:26:38  <jonasschnelli> static inline size_t DynamicUsage(const prevector<N, X, S, D>& v
211 2016-08-05T12:27:03  <jonasschnelli> It's a nitpick and I'll try to cover that fix in one of my stats releated commits.
212 2016-08-05T12:28:07  <wumpus> sometimes the c/c++ dependency management is a bit unfortunate, very easy to accidentally have something creep into your scope so you forget that direct dependencies exist but have no include, then it turns up later when the header happens to be used independently
213 2016-08-05T12:28:12  <wumpus> right
214 2016-08-05T12:29:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
215 2016-08-05T12:29:31  <wumpus> unlike missing prototypes in C, at least this cannot lead to ugly type-unsafety bugs, you either have to include it somewhere or it just won't compile :)
216 2016-08-05T13:04:37  *** Chris_Stewart_5 has quit IRC
217 2016-08-05T13:08:11  *** BashCo has quit IRC
218 2016-08-05T13:08:36  *** BashCo has joined #bitcoin-core-dev
219 2016-08-05T13:19:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
220 2016-08-05T13:33:58  *** laurentmt1 has joined #bitcoin-core-dev
221 2016-08-05T13:35:52  *** laurentmt has quit IRC
222 2016-08-05T13:35:52  *** laurentmt1 is now known as laurentmt
223 2016-08-05T13:47:05  *** TomMc has joined #bitcoin-core-dev
224 2016-08-05T13:48:27  *** arubi_ has joined #bitcoin-core-dev
225 2016-08-05T13:49:27  *** Chris_Stewart_5 has quit IRC
226 2016-08-05T13:51:52  *** arubi__ has quit IRC
227 2016-08-05T13:55:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
228 2016-08-05T14:19:56  *** arubi__ has joined #bitcoin-core-dev
229 2016-08-05T14:22:30  *** spudowiar has joined #bitcoin-core-dev
230 2016-08-05T14:23:18  *** arubi_ has quit IRC
231 2016-08-05T14:54:11  *** Chris_Stewart_5 has quit IRC
232 2016-08-05T14:58:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
233 2016-08-05T15:00:52  *** d_t has joined #bitcoin-core-dev
234 2016-08-05T15:03:31  *** Ylbam has joined #bitcoin-core-dev
235 2016-08-05T15:06:06  *** jtimon has joined #bitcoin-core-dev
236 2016-08-05T15:21:22  *** zooko has joined #bitcoin-core-dev
237 2016-08-05T15:29:50  *** mmortal03 has joined #bitcoin-core-dev
238 2016-08-05T15:39:09  *** BashCo has quit IRC
239 2016-08-05T15:45:10  *** Chris_Stewart_5 has quit IRC
240 2016-08-05T15:52:35  *** laurentmt has quit IRC
241 2016-08-05T16:04:29  <GitHub89> [bitcoin] Mirobit closed pull request #8283: Move AdvertiseLocal debug output to net category (master...master) https://github.com/bitcoin/bitcoin/pull/8283
242 2016-08-05T16:09:13  *** Sosumi has quit IRC
243 2016-08-05T16:12:44  *** rubensayshi has quit IRC
244 2016-08-05T16:14:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
245 2016-08-05T16:15:35  *** d_t has quit IRC
246 2016-08-05T16:23:46  *** Chris_Stewart_5 has quit IRC
247 2016-08-05T16:36:43  *** laurentmt has joined #bitcoin-core-dev
248 2016-08-05T16:37:31  *** laurentmt has quit IRC
249 2016-08-05T16:38:21  <GitHub188> [bitcoin] Mirobit opened pull request #8462: Move AdvertiseLocal debug output to net category (master...advertiselocal) https://github.com/bitcoin/bitcoin/pull/8462
250 2016-08-05T16:51:03  *** kvnn has joined #bitcoin-core-dev
251 2016-08-05T16:51:06  <kvnn> Can anyone tell me how much disk space testnet currenty takes?
252 2016-08-05T17:04:39  <GitHub149> [bitcoin] MarcoFalke opened pull request #8463: [qt] Remove Priority from coincontrol dialog (master...Mf1608-qtPrio) https://github.com/bitcoin/bitcoin/pull/8463
253 2016-08-05T17:13:31  *** AaronvanW has quit IRC
254 2016-08-05T17:16:37  <GitHub47> [bitcoin] JeremyRubin opened pull request #8464: "Lockfree" Checkqueue Implementation (master...lockfree-checkqueue-squashed) https://github.com/bitcoin/bitcoin/pull/8464
255 2016-08-05T17:19:02  *** AaronvanW has joined #bitcoin-core-dev
256 2016-08-05T17:19:03  *** AaronvanW has quit IRC
257 2016-08-05T17:19:03  *** AaronvanW has joined #bitcoin-core-dev
258 2016-08-05T17:19:17  <jeremyrubin> (forgot to mark as WIP fyi)
259 2016-08-05T17:21:15  <btcdrak> you can edit the title
260 2016-08-05T17:21:26  <btcdrak> jeremyrubin
261 2016-08-05T17:22:42  <btcdrak> jeremyrubin: it's quite useful to use markdown task lists in the PR body, as those show up in lists and references on other tickets/PRs https://github.com/blog/1825-task-lists-in-all-markdown-documents and it also has the side benefit of making the WIP status clear
262 2016-08-05T17:27:43  <jeremyrubin> btcdrak: what are the tasks?
263 2016-08-05T17:27:59  <btcdrak> your todo list.
264 2016-08-05T17:28:00  <jeremyrubin> btcdrak: the only stuff really remaining is more testing.
265 2016-08-05T17:28:27  <jeremyrubin> btcdrak: actually I can think of two things
266 2016-08-05T17:28:40  <sipa> jeremyrubin: if all that remains is testing, i wouldn't call it WIP :)
267 2016-08-05T17:30:14  <btcdrak> sipa: exactly! if it's marked WIP no-one will test it.
268 2016-08-05T17:31:46  <jeremyrubin> sipa: oh ok... I'll un WIP it then, it's ready for testing
269 2016-08-05T17:33:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
270 2016-08-05T17:33:05  <jeremyrubin> sorry was unclear at what point I should WIP/vs non WIP, thanks for the guidance
271 2016-08-05T17:35:05  <jeremyrubin> I'm going to be awk for a little bit, but will respond to more things later.
272 2016-08-05T17:35:18  <jeremyrubin> sipa: you may just want to view the whole diff rather than commit by commit
273 2016-08-05T17:41:36  *** zooko` has joined #bitcoin-core-dev
274 2016-08-05T17:42:51  *** zooko has quit IRC
275 2016-08-05T17:42:55  <sipa> jeremyrubin: i tend to review per commit, as i think every commit should logically make sense... the combination into a pull request is there to see the bigger picture
276 2016-08-05T17:48:46  *** kadoban has joined #bitcoin-core-dev
277 2016-08-05T17:52:33  <jeremyrubin> yep I agree, each commit should compile and run on this PR but is maybe not fully documented ;)
278 2016-08-05T17:53:42  *** Greybits has joined #bitcoin-core-dev
279 2016-08-05T17:54:03  *** [Author] has quit IRC
280 2016-08-05T18:07:33  *** [Author] has joined #bitcoin-core-dev
281 2016-08-05T18:09:27  *** Chris_Stewart_5 has quit IRC
282 2016-08-05T18:09:33  *** mmortal03 has quit IRC
283 2016-08-05T18:12:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
284 2016-08-05T18:16:24  *** arubi__ is now known as arubi
285 2016-08-05T18:24:56  *** kvnn has quit IRC
286 2016-08-05T18:38:58  <bsm117532> wizkid057, the exploding bitcoin spammer, somehow got op permissions on #bitcoin-wizards and is banning people.  Can someone here take care of him?
287 2016-08-05T18:41:27  <jonasschnelli> jeremyrubin: impressive PR... my review will take a while. :)
288 2016-08-05T18:42:28  *** Guyver2 has joined #bitcoin-core-dev
289 2016-08-05T18:44:35  <pigeons> he's not banning people, just kicked you only and its not the spammer it really is wizkid. probably just a mistake
290 2016-08-05T18:45:45  <bsm117532> sorry, don't know who wizkid is.
291 2016-08-05T19:03:17  <GitHub178> [bitcoin] sipa opened pull request #8465: [0.13] Document reindexing changes (0.13...docreindex) https://github.com/bitcoin/bitcoin/pull/8465
292 2016-08-05T19:07:43  <GitHub185> [bitcoin] paveljanik opened pull request #8466: [Trivial] Do not shadow variables in networking code (master...20160805_Wshadow_net) https://github.com/bitcoin/bitcoin/pull/8466
293 2016-08-05T19:17:09  <sipa> i feel that 'New mempool information RPC calls' could move to 'Low-level RPC changes' in the release notes
294 2016-08-05T19:17:14  <jtimon> thoughts on https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1 NicolasDorier btcdrak sipa should I open a PR?
295 2016-08-05T19:18:00  <jtimon> this doesn't touch the script flags and doesn't move anything out of contextualCheckBlock like the previous one
296 2016-08-05T19:18:41  <jtimon> it could be 1 or a few commits, but I kept it extremely separated just in case
297 2016-08-05T19:22:00  <GitHub153> [bitcoin] paveljanik opened pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
298 2016-08-05T19:22:51  *** belcher has joined #bitcoin-core-dev
299 2016-08-05T19:32:07  <sdaftuar> sipa: ack
300 2016-08-05T19:33:36  <sdaftuar> sipa: more generally i think if you're going to clean up further, perhaps reordering the Notable Changes section might be called for.  eg hd wallet support, segwit, cpfp mining, and compact blocks strike me as more important to highlight than c++11 code modernizations
301 2016-08-05T19:36:14  <sipa> maybe a section that aggregates all non-user-visible code changes
302 2016-08-05T19:36:25  <sipa> that would even include segwit, i guess
303 2016-08-05T19:42:39  <sdaftuar> sure.  fyi the mining stuff references segwit, so if you move those around relative to each other, the text might need some edits
304 2016-08-05T19:55:04  <GitHub14> [bitcoin] paveljanik opened pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
305 2016-08-05T20:04:47  *** zooko`` has joined #bitcoin-core-dev
306 2016-08-05T20:06:13  *** zooko` has quit IRC
307 2016-08-05T20:13:11  <Chris_Stewart_5> Is this entire block of code inside of bloom.cpp basically so that we can match redeemScript/pubkey hashes in scriptPubKeys?
308 2016-08-05T20:13:14  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/bloom.cpp#L163-LL177
309 2016-08-05T20:16:34  <jonasschnelli> sipa: how do I get the DynamicUsage from a struct?
310 2016-08-05T20:16:43  <jonasschnelli> MallocUsage(size_t alloc) is inline...
311 2016-08-05T20:17:13  <sipa> jonasschnelli: sum the dynamic usages of its member fields
312 2016-08-05T20:18:45  <jonasschnelli> sipa: what about MallocUsage(sizeof(mystruct))?
313 2016-08-05T20:18:47  <jonasschnelli> +allow external calls to MallocUsage
314 2016-08-05T20:19:04  <sipa> jonasschnelli: are you mallocing your stuct?
315 2016-08-05T20:19:41  <jonasschnelli> sipa: ... ah... no.
316 2016-08-05T20:19:55  <sipa> then you shouldn't be using either of them
317 2016-08-05T20:20:04  <jonasschnelli> I guess std::vector<mystruct> is on the stack
318 2016-08-05T20:20:17  <sipa> DynamicUsage is not how much memory a struct uses. It's how much _dynamic_ memory it uses. The static memory you find just using sizeof.
319 2016-08-05T20:20:36  <sipa> jonasschnelli: use DynamicUsage on the vector.
320 2016-08-05T20:20:51  <sipa> The vector is allocated on the stack. Its entries are allocated on the heap.
321 2016-08-05T20:21:07  <sipa> DynamicUsage(vector) will tell you how much memory that vector malloced.
322 2016-08-05T20:21:13  <jonasschnelli> sipa: yes. I'll do that. But i'd like to know how many elements i have to remove from the vector to match a usage target... therefore I need to calculate the size of a single element.
323 2016-08-05T20:21:30  <sipa> jonasschnelli: use sizeof.
324 2016-08-05T20:21:42  <sipa> also, removing elements from a vector does not reduce its memory usage.
325 2016-08-05T20:21:48  <sipa> you need to call shrink_to_fit
326 2016-08-05T20:21:50  <jonasschnelli> okay... but aren't the element malloced?
327 2016-08-05T20:22:05  <sipa> yes?
328 2016-08-05T20:22:11  <sipa> but not individually
329 2016-08-05T20:22:23  <sipa> a vector has a single allocated block with all its elements in it
330 2016-08-05T20:22:47  <jonasschnelli> Okay. I'll use sizeof(struct) and good point about shrink_to_fit!
331 2016-08-05T20:22:50  <jonasschnelli> thanks.
332 2016-08-05T20:27:50  <jonasschnelli> sipa: sizeof(struct) = 32, memusage::DynamicUsage(vector)/size = 52?!
333 2016-08-05T20:28:34  <jonasschnelli> calculating the amount of items to remove based on sizeof(struct) is not precise to get the memory usage target
334 2016-08-05T20:28:44  <sipa> jonasschnelli: look at vector.capacity)(
335 2016-08-05T20:28:51  <sipa> instead of size
336 2016-08-05T20:29:10  <sipa> vectors allocate more than what is requested, so that they don't need to reallocate whenever a new element is added
337 2016-08-05T20:29:52  <sipa> jtimon: i think it's very ugly to have a single set of flags that contains both block level validation rules and script level validation rules
338 2016-08-05T20:30:35  <jonasschnelli> sipa: /vector.capacity() == sizeof(struct) ... thanks!
339 2016-08-05T20:31:03  <jtimon> sipa: the script flags are hidden behind ScriptFlagsFromConsensus() I thought that was what you wanted
340 2016-08-05T20:31:17  <sipa> jtimon: https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1#diff-cefdf710ea5108806289afadb6cf8717R13
341 2016-08-05T20:32:09  <jtimon> sipa: so how many sets of flags do we want to expose in libconsensus?
342 2016-08-05T20:32:18  <sipa> jtimon: one for every layer
343 2016-08-05T20:32:31  <jtimon> is locktime a layer?
344 2016-08-05T20:32:35  <sipa> there will be a script validation API and a block validation API, right?
345 2016-08-05T20:32:42  <sipa> maybe a transaction validation API as well
346 2016-08-05T20:32:55  <sipa> i think it's wrong to make them share flags
347 2016-08-05T20:33:32  <sipa> what if there was a script change that only applied to transactions with nVersion>=5... you'd have a block level flag to enable the soft fork, but it wouldn't map one-to-one to the script flag
348 2016-08-05T20:33:35  <jtimon> maybe a header validation API too, I think that would be the easiest thing to expose and discuss abstractions from storage
349 2016-08-05T20:34:36  <jtimon> sipa:yeah, now they don't need to map, the non-script consensus flags don't need to be in the internal script flags
350 2016-08-05T20:34:53  <jtimon> and some internal script flags are not exposed
351 2016-08-05T20:36:12  <jtimon> I don't undesrtand your txversion>5 example
352 2016-08-05T20:36:31  <jtimon> the flag would be used at the tx validation level either way, no?
353 2016-08-05T20:37:11  <jtimon> oh, I see what you mean
354 2016-08-05T20:37:27  <sipa> say we had a new OP_CHECKSIGAWESOME, but only enabled in UTXOs created by transactions with nVersion >= 5
355 2016-08-05T20:38:04  <sipa> there would be SCRIPT_VERIFY_CHECKSIGAWESOME, and a BIP9 deployment AWESOME
356 2016-08-05T20:38:07  <sipa> you'd pass AWESOME to the block validation functions
357 2016-08-05T20:38:25  <jtimon> yes, you're saying that you would do the consensus-to-internal-script conversion outside of the conversion function and inside, say verifyTx
358 2016-08-05T20:38:45  <sipa> right... there is not necessarily a clean mapping between the two
359 2016-08-05T20:39:02  <sipa> what flags the script code is called with is block level logic
360 2016-08-05T20:39:07  <jtimon> well, what we're exposing in libconsensus are the BIP9/older_sf flags, no?
361 2016-08-05T20:39:24  <sipa> for the script layer, sure
362 2016-08-05T20:39:28  <sipa> wait, no
363 2016-08-05T20:39:34  <jtimon> for all layers, no?
364 2016-08-05T20:39:35  *** Chris_Stewart_5 has quit IRC
365 2016-08-05T20:39:39  <sipa> i'm confused :)
366 2016-08-05T20:39:54  <sipa> i'm assuming there will be a enum for block level validation flags
367 2016-08-05T20:40:04  <jtimon> the flags we expose in libconsensus right now are a subset of the script internal ones
368 2016-08-05T20:40:15  <sipa> and an enum (which already exists) for script level validation flags
369 2016-08-05T20:40:30  <sipa> for some softforks there will be a flag in both
370 2016-08-05T20:40:48  <jtimon> there's no flag for say bip68 and bip113, because thouse would be needed for verifyTx, but not for verifyScript
371 2016-08-05T20:41:00  <sipa> right
372 2016-08-05T20:41:49  <jtimon> well, the "block level" flags include all the "script level" flags, right?
373 2016-08-05T20:42:00  <sipa> not necessarily
374 2016-08-05T20:42:32  <jtimon> how do you tell verifyblock to verify p2sh otherwise?
375 2016-08-05T20:43:06  <jtimon> I mean, verifytx
376 2016-08-05T20:43:38  <jtimon> verifyblock could call getflags internally I guess, but that's not the point
377 2016-08-05T20:44:53  <sipa> i'd expect verifyblock to have something like BLOCK_VERIFY_CSV, and verifyscript to have something like SCRIPT_VERIFY_CHECKSEQUENCEVERIFY
378 2016-08-05T20:45:00  <jtimon> say I want to call verifytx specifying that I want p2sh and bip113 validated
379 2016-08-05T20:45:26  <sipa> sure, CSV implies that CHECKSEQUENCEVERIFY is passed to script
380 2016-08-05T20:45:30  <sipa> but CSV does much more than that
381 2016-08-05T20:45:37  <sipa> it also enabled nsequence behaviour
382 2016-08-05T20:45:43  <sipa> which has nothing to do with script
383 2016-08-05T20:46:20  <jtimon> so BLOCK_VERIFY_CSV is mapped into bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH and then bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH into SCRIPT_VERIFY_P2SH
384 2016-08-05T20:46:43  <jtimon> do we need also a TX_VERIFY_P2SH for exposing verifyTx ?
385 2016-08-05T20:47:34  <sipa> i'd keep the tx-level flags and block-level flags the same
386 2016-08-05T20:47:36  <sipa> but script flags seem separate
387 2016-08-05T20:47:52  <jtimon> well, the flags for BIP68 and for BIP112 are separated in that branch
388 2016-08-05T20:48:09  <sipa> that's just my opinion, btw... maybe other people feel that script and block flags should be combined
389 2016-08-05T20:48:51  <jtimon> they are separated: there's "all consensus flags" and "all consensus flags related to script plus some more script specific flags"
390 2016-08-05T20:49:47  <jtimon> well, from previous talks I thought this was exactly what you wanted, still not sure what would you prefer
391 2016-08-05T20:49:53  <sipa> yes, i feel they should be completely separate
392 2016-08-05T20:49:59  <sipa> not one being an extension of the other
393 2016-08-05T20:50:18  <jtimon> like not repeating p2sh in both of them? I don't undesrtand
394 2016-08-05T20:50:20  <sipa> but maybe others disagree... that's fine
395 2016-08-05T20:50:31  <sipa> yes, P2SH would be in both
396 2016-08-05T20:50:35  <jtimon> in this case one is not an extension of the other, what do you mean?
397 2016-08-05T20:50:45  <jtimon> they share some (they currently share)
398 2016-08-05T20:51:34  <sipa> https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1#diff-cefdf710ea5108806289afadb6cf8717R13
399 2016-08-05T20:51:43  <sipa> you're just copying the script flags there
400 2016-08-05T20:51:48  <sipa> and then adding other things
401 2016-08-05T20:51:56  <sipa> just make it a completely independent enum
402 2016-08-05T20:52:14  <jtimon> not from the script, see https://github.com/bitcoin/bitcoin/commit/82bf11faf9a1d915eb0fc40ea6db10da9908df2a
403 2016-08-05T20:52:22  <paveljanik> cfields, thanks for review!
404 2016-08-05T20:52:24  <jtimon> I'm just adding new non-script flags there
405 2016-08-05T20:52:42  <sipa> bitcoinconsensus_BIP16, bitcoinconsensus_BIP66, bitcoinconsensus_BIP65, bitcoinconsensus_BIP68, ... for example
406 2016-08-05T20:52:55  <jtimon> the script ones were already exposed in libconsensus
407 2016-08-05T20:53:11  <sipa> and BIP16 would map to script verify P2SH
408 2016-08-05T20:53:42  <jtimon> they already do by hardcoding the same bit positions in both, I'm trying to solve that
409 2016-08-05T20:54:09  <jtimon> that's what ScriptFlagsFromConsensus() is supposed to solve
410 2016-08-05T20:54:40  <sipa> well why do you have both LOCKTIME_VERIFY_SEQUENCE and bitcoinconsensus_SCRIPT_FLAGS_VERIFY_CHECKSEQUENCEVERIFY in the same enum?
411 2016-08-05T20:54:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
412 2016-08-05T20:54:52  <sipa> at the block level they're the same thing
413 2016-08-05T20:56:00  <jtimon> because I'm not creating a new enum for libconsensus, there's currently one for libconsensus and another for scripts, I'm keeping it that way, just decoupling each other from the bit positions having to match
414 2016-08-05T20:56:40  <sipa> to verifyblock you would just pass "CSV is enabled", and it would trigger all necessary things... including locktime nsequence checking and script checksequenceverify
415 2016-08-05T20:56:49  <jtimon> let's say in libconsensus the "block level" flags would be reused for verifyTx and verfiyScript, does that make sense?
416 2016-08-05T20:57:09  <sipa> i don't know what you mean by that
417 2016-08-05T20:57:44  <jtimon> I see, you want the block level ones to correspond with deployments, ie bip68 and bip112 go together
418 2016-08-05T20:58:13  <sipa> well if there is a reason why they would be implemented separately, they can be separate
419 2016-08-05T20:58:46  <sipa> it's about abstraction... the caller of blockverify shouldn't need to know what every softfork corresponds to internally
420 2016-08-05T20:59:07  <jtimon> but you don't want verifyScript to receive a CSV_bip68_bip112 flag that it internally maps to SCRIPT_VERIFY_CHECKSEQUENCEVERIFY (ignoring bip68 because at the script level it doesn't care)
421 2016-08-05T20:59:07  <sipa> that enum you have there feels to me like you want to expose all internal choices to the caller... that isn't necessary
422 2016-08-05T20:59:49  <sipa> right... have block validation flags that correspond to deployments/softforks, and script validation flags that correspond to script rules
423 2016-08-05T20:59:51  <jtimon> yeah they can be separated, we could also have a bool param for every option
424 2016-08-05T21:00:09  <sipa> some block validation flags will correspond to one or more script flags... some may not
425 2016-08-05T21:00:20  <sipa> but the caller shouldn't need to know that
426 2016-08-05T21:00:56  <sipa> again... all of that is just my opinion
427 2016-08-05T21:00:58  <sipa> i'd like to hear some others too
428 2016-08-05T21:01:01  <jtimon> agree on what you said about the caller, disagree that I want to expose more details than necessary to the caller, I'm happy to merge bip68 and bip112 flags, that seems orthogonal
429 2016-08-05T21:01:20  <sipa> just the naming of your flags is exposing things :)
430 2016-08-05T21:01:21  <jtimon> the main question is how many enums do we want and what should it be in them
431 2016-08-05T21:01:44  <jtimon> oh, come on, I expect people to bike-shedd
432 2016-08-05T21:02:02  <jtimon> don't tell me that's the main complain
433 2016-08-05T21:02:10  <sipa> at the block/tx level, you'd have bip16, bip34, bip66, bip65, bip68_112_113, bip141
434 2016-08-05T21:02:12  <cfields> paveljanik: np. the serialization one will require more effort.
435 2016-08-05T21:02:18  <sipa> at the script level, you'd have what already exists
436 2016-08-05T21:02:26  <jtimon> asume you fully decide the names in the enum
437 2016-08-05T21:02:50  <cfields> paveljanik: imo changing the name for those would be helpful, the version serialization is quite confusing as-is
438 2016-08-05T21:02:51  <sipa> jtimon: i don't care about the name... i care about the fact that it's mixing several layers!
439 2016-08-05T21:02:53  <jtimon> why are bip68_112_113 together?
440 2016-08-05T21:03:10  <jtimon> bip113 was deployed separately
441 2016-08-05T21:03:25  <sipa> because someone calling verifyblock shouldn't need to know that part of it is a script rule and part of it is not
442 2016-08-05T21:03:26  <jtimon> for the libconsensus caller, all he cares about is deployments, no?
443 2016-08-05T21:03:55  <sipa> IMHO, there should not be any flags at all, and you just give it the block headers :)
444 2016-08-05T21:04:02  <sipa> but i understand we're not there yet
445 2016-08-05T21:04:07  <jtimon> with my approach all they need to know is that each flag is a deployment
446 2016-08-05T21:04:25  <sipa> ok, i don't like it, sorry
447 2016-08-05T21:04:28  <sipa> that's not a NACK
448 2016-08-05T21:04:37  <sipa> but i'm tired of discussing it
449 2016-08-05T21:04:38  <jtimon> well, we can expose consensus::getflags
450 2016-08-05T21:04:45  *** sipa has left #bitcoin-core-dev
451 2016-08-05T21:05:00  <jtimon> but are you saying that verifyTx should call getflags internally?
452 2016-08-05T21:05:50  *** Ylbam has quit IRC
453 2016-08-05T21:05:57  <paveljanik> cfields, yes. I took me a lot of time to get it done. This was my third attempt to do so.
454 2016-08-05T21:06:11  <cfields> paveljanik: understood. it's much appreciated.
455 2016-08-05T21:06:32  <paveljanik> cfields, I have more huge task... LOCK inside LOCK
456 2016-08-05T21:06:33  <cfields> paveljanik: one high-level request: if the param isn't used, please just leave the var unspecified
457 2016-08-05T21:06:43  *** sipa has joined #bitcoin-core-dev
458 2016-08-05T21:07:07  <paveljanik> cfields, I thought about it too (esp. nVersion...) but this would make review more difficult.
459 2016-08-05T21:07:28  <cfields> paveljanik: otherwise we're not getting any closer to being able to enable -Wunused-parameter :)
460 2016-08-05T21:07:35  <cfields> paveljanik: how so?
461 2016-08-05T21:08:10  <paveljanik> every reviewer must read the whole function code...
462 2016-08-05T21:08:53  <paveljanik> without this change, it is almost enough to read the context
463 2016-08-05T21:10:08  <cfields> ok, fair enough
464 2016-08-05T21:10:41  *** molly has joined #bitcoin-core-dev
465 2016-08-05T21:12:23  <paveljanik> of course the compilation can find problems there...
466 2016-08-05T21:13:40  *** molz has quit IRC
467 2016-08-05T21:14:16  *** english- has joined #bitcoin-core-dev
468 2016-08-05T21:16:06  <paveljanik> BTW - LOCK inside LOCK problem: LOCK macro defines a local variable CCriticalBlock criticalblock. And thus LOCK inside LOCK shadows it.
469 2016-08-05T21:16:36  <paveljanik> I do not want to make the change in the syntax of LOCK, so I have to change the macro.
470 2016-08-05T21:16:39  <gmaxwell> thats presumably why there are LOCKN macros?
471 2016-08-05T21:17:26  <paveljanik> yes, but... LOCK2 at the beginning of the function grabs both at the beginning.
472 2016-08-05T21:17:32  <paveljanik> I do not think this is wanted.
473 2016-08-05T21:18:03  <paveljanik> I had an idea to change the name of the variable somehow - e.g. criticalblockLINENR or so.
474 2016-08-05T21:18:39  <paveljanik> but implementing this in the preprocessor's ## ## ## is currently above my knowledge ;-)
475 2016-08-05T21:19:18  <paveljanik> see e.g. ProcessGetData in main.cpp.
476 2016-08-05T21:19:24  <sipa> paveljanik: use the file number in the name of the variable :)
477 2016-08-05T21:19:33  <sipa> eh, line number
478 2016-08-05T21:19:56  <paveljanik> that was my plan :-) But not so easy to write it 8)
479 2016-08-05T21:20:49  <sipa> i'll try
480 2016-08-05T21:23:11  <cfields> can't you just use the incoming param's name?
481 2016-08-05T21:25:09  <sipa> cfields: what do you if it's called pnode->buf[(int)(sin(x)*35)].cs?
482 2016-08-05T21:25:32  <NicolasDorier> jtimon: I think we shoudl talk about that in ##libconsensus on my side I'm still not decided whther I prefer the one flag approach of my approach (https://github.com/bitcoin/bitcoin/pull/8339/commits/a59f79dfb7a996e9b309aa43d699499339b1a7c4)
483 2016-08-05T21:25:59  <jtimon> NicolasDorier: sure we can move there
484 2016-08-05T21:28:05  <cfields> sipa: heh, ok. that's a stretch, though :)
485 2016-08-05T21:28:36  <paveljanik> cfields, self-assing: good catch. Look like I do not even understand the original code 8) https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L289
486 2016-08-05T21:28:52  *** BashCo has joined #bitcoin-core-dev
487 2016-08-05T21:30:55  <sipa> paveljanik:
488 2016-08-05T21:31:12  <sipa> #define LOCK(cs) CCriticalBlock criticalblock ## __LINE__(cs, #cs, __FILE__, __LINE__)
489 2016-08-05T21:31:15  <sipa> does that not work?
490 2016-08-05T21:31:50  *** jannes has quit IRC
491 2016-08-05T21:31:51  <paveljanik> IIRC I have already tried this. Will try again
492 2016-08-05T21:33:21  *** d_t has joined #bitcoin-core-dev
493 2016-08-05T21:33:22  <cfields> sipa: (on one line) std::mutex m1; std::mutex m2; LOCK(m1); LOCK(m2);
494 2016-08-05T21:33:45  <sipa> cfields: ?
495 2016-08-05T21:34:05  <paveljanik> both variables will be named the same.
496 2016-08-05T21:34:26  <sipa> ah.
497 2016-08-05T21:34:27  <paveljanik> main.cpp:6543:28: note: previous declaration is here
498 2016-08-05T21:34:27  <paveljanik>             CCriticalBlock criticalblock__LINE__(pto->cs_inventory, "pto->cs_inventory", "main.cpp", 6543);
499 2016-08-05T21:34:55  <sipa> ok, that looks wrong
500 2016-08-05T21:34:55  <cfields> sipa: only because you poked a hole in mine first :)
501 2016-08-05T21:35:15  <sipa> cfields: well use LOCK2 in that case
502 2016-08-05T21:35:38  <paveljanik> :-)
503 2016-08-05T21:36:59  <sipa> paveljanik: bip112
504 2016-08-05T21:37:00  <sipa> eh
505 2016-08-05T21:37:09  <sipa> paveljanik: http://stackoverflow.com/a/1597129
506 2016-08-05T21:37:33  <sipa> __COUNTER__ looks even nicer
507 2016-08-05T21:39:41  <paveljanik> I'll see.
508 2016-08-05T21:40:02  <sipa> #define paste1(a,b) a ## b
509 2016-08-05T21:40:08  <sipa> #define paste(a,b) paste1(a,b)
510 2016-08-05T21:40:42  <sipa> #define LOCK(cs) CCriticalBlock paste(criticalblock,__COUNTER__)(cs, #cs, __FILE__, __LINE__)
511 2016-08-05T21:40:51  <paveljanik> #define TOKENPASTE(x, y) x ## y
512 2016-08-05T21:40:52  <paveljanik> #define TOKENPASTE2(x, y) TOKENPASTE(x, y)
513 2016-08-05T21:40:52  <paveljanik> #define LOCK(cs) CCriticalBlock TOKENPASTE2(criticalblock, __LINE__)(cs, #cs, __FILE__, __LINE__)
514 2016-08-05T21:40:55  <paveljanik> seems to work
515 2016-08-05T21:41:07  <sipa> \o/
516 2016-08-05T21:41:09  <paveljanik> will try COUNTER here
517 2016-08-05T21:42:25  <paveljanik> works as well
518 2016-08-05T21:43:06  *** tunafizz has joined #bitcoin-core-dev
519 2016-08-05T21:45:09  <paveljanik> thank you sipa!
520 2016-08-05T21:45:16  <paveljanik> Looks like I need some sleep 8)
521 2016-08-05T21:46:01  <sipa> night
522 2016-08-05T21:47:10  *** zooko`` has quit IRC
523 2016-08-05T21:50:10  *** english- has quit IRC
524 2016-08-05T21:51:32  *** Ylbam has joined #bitcoin-core-dev
525 2016-08-05T22:02:14  *** spudowiar has quit IRC
526 2016-08-05T22:03:41  *** spudowiar has joined #bitcoin-core-dev
527 2016-08-05T22:07:53  *** spudowiar has quit IRC
528 2016-08-05T22:12:58  *** spudowiar has joined #bitcoin-core-dev
529 2016-08-05T22:21:19  *** dvsdude has joined #bitcoin-core-dev
530 2016-08-05T22:28:51  *** Guyver2 has quit IRC
531 2016-08-05T22:30:45  *** spudowiar has quit IRC
532 2016-08-05T22:31:44  *** cryptapus is now known as cryptapus_afk
533 2016-08-05T22:33:10  *** spudowiar has joined #bitcoin-core-dev
534 2016-08-05T22:39:32  *** spudowiar has quit IRC
535 2016-08-05T22:40:24  *** spudowiar has joined #bitcoin-core-dev
536 2016-08-05T22:43:00  *** jgarzik has joined #bitcoin-core-dev
537 2016-08-05T22:51:01  *** dvsdude has left #bitcoin-core-dev
538 2016-08-05T22:52:40  *** jgarzik has quit IRC
539 2016-08-05T22:54:23  *** jgarzik has joined #bitcoin-core-dev
540 2016-08-05T22:54:23  *** jgarzik has joined #bitcoin-core-dev
541 2016-08-05T22:58:37  *** cryptapus_afk is now known as cryptapus
542 2016-08-05T22:59:01  *** Alopex has quit IRC
543 2016-08-05T23:00:07  *** Alopex has joined #bitcoin-core-dev
544 2016-08-05T23:00:40  *** TomMc has quit IRC
545 2016-08-05T23:05:05  *** cryptapus is now known as cryptapus_afk
546 2016-08-05T23:24:37  *** d_t has quit IRC
547 2016-08-05T23:28:26  *** randy-waterhouse has joined #bitcoin-core-dev
548 2016-08-05T23:28:49  *** goregrind has quit IRC
549 2016-08-05T23:51:36  *** randy-waterhouse has quit IRC
550 2016-08-05T23:51:37  *** Chris_Stewart_5 has quit IRC
551 2016-08-05T23:53:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev