1 2015-09-06 00:31:41 <jamesob> Luke-Jr does 6613 entail making some modifications to this class (https://github.com/bitcoin/bitcoin/blob/master/src/txdb.h#L37-L41), or am I off track?
  2 2015-09-06 00:32:48 <Luke-Jr> jamesob: probably, but I am not certain
  3 2015-09-06 01:49:02 <jamesob> maybe a stupid question: where does the text used to generate Doxygen's class reference doc live? I don't see any comments that correspond with, say, the doc on a method
  4 2015-09-06 02:12:08 <jtimon> gmaxwell: why is bitcoin-incubator only for softforks?
  5 2015-09-06 02:13:36 <gmaxwell> jtimon: because we have no good mechenism to test them and need one as we talk about more complex soft forks and more in-flight softforks. They're also inherently compatible with each other.
  6 2015-09-06 02:14:00 <gmaxwell> There isn't any reason to have other things testing hardforky stuff, especially boring hardforky stuff.
  7 2015-09-06 02:14:04 <jtimon> why not test hardforks there as well?
  8 2015-09-06 02:15:03 <gmaxwell> Just compatiblity.  If someone wanted a repo to test uncontroversial hardfork feature then I wouldn't mind creating repos for those.
  9 2015-09-06 02:15:31 <jtimon> I mean, there could be non-boring hardfork stuff in the future
 10 2015-09-06 02:16:10 <jtimon> still not sure why they would necessarily need to be separated but thanks for the answers
 11 2015-09-06 02:18:17 <gmaxwell> Yea no problem.  Wrt seperation, because it should be merge ready for bitcoin core.  I don't even think it's necessarily the case that there would be only one incubator for soft-forks, but wasn't going to worry about making more until a need arose.
 12 2015-09-06 02:47:50 <CodeShark> let's just do one hard fork - one that allows efficient cross-chain transfers. and then use that mechanism from then on :p
 13 2015-09-06 02:48:03 <gmaxwell> you don't need a hardfork for that.
 14 2015-09-06 02:48:24 <CodeShark> even for the efficient part?
 15 2015-09-06 02:49:10 <CodeShark> I guess the first instance doesn't need to be super efficient
 16 2015-09-06 02:49:21 <gmaxwell> Even for the efficient part, at least if you're willing to tolerate some kinds of uglyness.
 17 2015-09-06 02:49:37 <CodeShark> it's a bootstrapping process...
 18 2015-09-06 02:49:48 <CodeShark> the first instance doesn't have to be efficient - it's like a cross compiler
 19 2015-09-06 02:49:54 <gmaxwell> e.g. the biggest source of inefficiency you get from not hardforking is the requirement that additional commitments be at the bottom of the transaction merkle tree.
 20 2015-09-06 02:50:13 <gmaxwell> CodeShark: if you imagine that these change are mergemined... there is a problem there that boostrapping cannot fix.
 21 2015-09-06 02:50:35 <gmaxwell> well 'problem' is too strong, but an inefficiency.
 22 2015-09-06 02:53:04 <CodeShark> yeah, the second chain would have to have deep knowledge of the original chain's merkle structure and coinbase transaction...argh
 23 2015-09-06 02:54:35 <CodeShark> but regardless of how horribly ugly your approach, it cannot possibly be worse than namecoin's :p
 24 2015-09-06 02:55:50 <CodeShark> the good thing is that done right, this wart can be nicely encapsulated so we almost never have to look at ugly code
 25 2015-09-06 02:57:37 <CodeShark> and once the old chain has been emptied, perhaps we can start mining directly on the new one
 26 2015-09-06 02:58:41 <CodeShark> I guess it technically breaks existing mining infrastructure to change block header formats
 27 2015-09-06 02:59:19 <CodeShark> but it isn't so dire - the merkle root can be reinterpretted as an extension header hash
 28 2015-09-06 02:59:28 <CodeShark> and the extension header can contain the merkle root
 29 2015-09-06 02:59:52 <CodeShark> in any case, on the new chain we'll probably want to commit to individual inputs and outputs
 30 2015-09-06 03:02:57 <CodeShark> point is such a mechanism inherently would tend to reflect "economic consensus" and would get around issues pertaining to how we establish this in a hard fork
 31 2015-09-06 03:07:39 <CodeShark> not that this is new or anything...just a bit puzzled at the hesitation :)
 32 2015-09-06 03:10:45 <CodeShark> if we can build a "hard fork" mechanism that is opt-in and carries with it all the other benefits of a potential hard fork, why would anyone oppose it?
 33 2015-09-06 03:10:50 <CodeShark> unless they want to destroy bitcoin?
 34 2015-09-06 03:11:39 <CodeShark> it seems like a no brainer
 35 2015-09-06 03:13:27 <CodeShark> the only real technical downside I see is what you mentioned - merged mining will have a wart
 36 2015-09-06 03:18:24 <gmaxwell> "more complicated"
 37 2015-09-06 03:18:49 <CodeShark> packet switched networks are also "more complicated" than circuit switched networks - lol
 38 2015-09-06 03:18:50 <gmaxwell> also, my reason-- hides the real risks of the proposed hard fork.
 39 2015-09-06 03:19:44 <gmaxwell> (e.g. the logic you're giving is the logic for Adam's Extension blocks-- and I dislike it because it hides the damage done by overly large blocks.)
 40 2015-09-06 03:21:07 <CodeShark> but in the end there are likely to be many "hard fork" proposals that are dangerous...and unless switching chains is entirely opt-in, we need a governance mechanism
 41 2015-09-06 03:21:50 <CodeShark> if users decide to switch to a chain that does something risky despite being warned and they lose, that's part of the price they pay for being able to make the decision for themselves
 42 2015-09-06 03:22:23 <gmaxwell> Yes, welcome to my position a year ago; followed by a decision to make progress towards doing something about it! :)
 43 2015-09-06 03:23:26 <CodeShark> the real issue here isn't a specific hard fork - it's the precedent
 44 2015-09-06 03:23:44 <CodeShark> as soon as we allow one hard fork where users cannot opt in, we've opened up the door to a destruction of bitcoin from the inside
 45 2015-09-06 03:25:27 <gmaxwell> That might be a little too extreme of a view-- if a tree falls in the forest, ... ; but its a risk I am very concerned about, indeed.  Basically if there is a hard fork that is unobjectionable and unobjected to... that seems fine to me.
 46 2015-09-06 03:25:36 <gmaxwell> Even in theory someone couldn't have opted out.
 47 2015-09-06 03:25:59 <CodeShark> right, if there's near 100% agreement on it, it doesn't carry that much risk
 48 2015-09-06 03:26:18 <CodeShark> but even if there's a small percentage that vehemently disagrees, it's extremely dangerous
 49 2015-09-06 03:26:34 <gmaxwell> or at least unobjected to in ways that were not procedural. Like, someone objecting because they'd also like some _extra_ change made also doesn't trigger my concern.
 50 2015-09-06 03:26:57 <CodeShark> things that change the economics in particular are deeply problematic
 51 2015-09-06 03:27:07 <CodeShark> because they almost surely will imply winners and losers
 52 2015-09-06 03:27:34 <gmaxwell> It can be very hard to distinguish economic changes. But right, there is a spectrum-- if something creates winners and losers its on one extreme side of the situation.
 53 2015-09-06 03:28:46 <CodeShark> right, I guess even fixing the retargetting issue has economic consequences
 54 2015-09-06 03:29:06 <gmaxwell> though its tricky, a hardfork that removes a weakness in the POW that some miners were exploiting (and maybe patented their exploit), which created winners and losers.. whats that?
 55 2015-09-06 03:30:32 <gmaxwell> At least in the case of the timewarp thing one can point to the absense of any effect from it. E.g. if it creates a loser, its only some future timewarp attacker. "I do not have much sympathy", but pedantically you could say it was an economic change.
 56 2015-09-06 03:30:51 <gmaxwell> so it seems impossible to draw a bright line.
 57 2015-09-06 03:31:19 <gmaxwell> So my hope is to just releave 95% of the pressure... and if thats successful, we don't have to have good answers.
 58 2015-09-06 03:31:20 <CodeShark> right, I raise it as an example of a change that could have economic consequences...but probably nobody really was exploiting the flaw to begin with
 59 2015-09-06 03:32:06 <CodeShark> I don't think percentage is the only important metric, though
 60 2015-09-06 03:32:13 <CodeShark> contentiousness is probably a more serious one
 61 2015-09-06 03:32:19 <gmaxwell> I'm okay with things like "at a minimum someone would be forced to speak up to stop a change against their interest"-- we don't need to worry to much about accidentally harming someone. It's their responsibility to speak up.
 62 2015-09-06 03:32:47 <CodeShark> 60/40 on an issue where the minority isn't particularly set in their position probably isn't as dangerous as 95/5 where the 5% is vehemently opposed
 63 2015-09-06 03:33:56 <CodeShark> and this is even more the case if that 5% represents a substantial amount of blockchain wealth
 64 2015-09-06 03:34:23 <gmaxwell> Right, there are screwy challenges here.. like what if the 5% is opposed because they want Bitcoin to fail?
 65 2015-09-06 03:34:59 <gmaxwell> (e.g. because they're all big FooCoin investors---- and this can be true even if they also own a lot of Bitcoin.)
 66 2015-09-06 03:35:21 <gmaxwell> Surely we have minimal obligation to preserve the interest of people who want Bitcoin to fail.
 67 2015-09-06 03:37:12 <CodeShark> so I just don't see any sort of voting scheme that can objectively represent interests here and decide in ways that can almost guarantee network stability
 68 2015-09-06 03:37:37 <CodeShark> it's that one edge case that can kill bitcoin :p
 69 2015-09-06 03:38:34 <gmaxwell> This even flips the other way-- for example, I recently had someone tell me that they invest in "all the cryptos", and they don't care if Bitcoin fails or not in the long run, they want its value to rocket as fast as possible. E.g. a variance play, not a value play. If we had diminished obligations to someone outright trying to kill the thing, do we also have diminished obligations to someone who wan
 70 2015-09-06 03:38:40 <gmaxwell> ts to take a huge risk that might have a payoff but doesn't care if its very likely to kill it?
 71 2015-09-06 03:40:20 <CodeShark> and since the spectrum of how much a change produces winners and losers doesn't necessarily have clear-cut boundaries, it's better to just make all "hard forks" opt in
 72 2015-09-06 03:41:11 <CodeShark> it gets rid of the need for a corruptibly governance process
 73 2015-09-06 03:41:16 <CodeShark> *corruptable
 74 2015-09-06 03:42:07 <CodeShark> so even things like timewarp or other stupid bugs should probably be fixed by such an opt-in process
 75 2015-09-06 03:42:21 <CodeShark> it gets rid of the potential for errors of judgment
 76 2015-09-06 03:43:11 <CodeShark> or we'd have to set some strict criteria for what constitutes uncontroversial
 77 2015-09-06 03:45:10 <CodeShark> i.e. fixing the merged mining wart might qualify :)
 78 2015-09-06 03:46:27 <CodeShark> you said earlier this is seen as "more complicated" - but TBH, I think the need for a governance model in making these decisions is WAAAAY more complicated :p
 79 2015-09-06 03:46:54 <CodeShark> and far more fragile
 80 2015-09-06 03:48:16 <CodeShark> and it introduces considerable centralization
 81 2015-09-06 03:49:50 <CodeShark> and is prone to hostile unilateral hard forks
 82 2015-09-06 03:55:32 <CodeShark> so I say let's give the bitcoin community a sidechain that supports 20MB blocks or whatever but changes nothing else, strongly recommend against using it, and let it be attacked and fall to pieces :)
 83 2015-09-06 03:57:10 <CodeShark> then 1) nobody can say we were trying to obstruct anything, 2) nobody can say we didn't warn them, 3) the results will be there for everyone to plainly see
 84 2015-09-06 03:57:54 <CodeShark> and 4) those of us who didn't make the jump wouldn't be negatively affected
 85 2015-09-06 03:59:21 <CodeShark> oh, and unless the failure of this bigger block chain is sudden and catastrophic, users would still perhaps be able to change their minds before it's too late
 86 2015-09-06 04:01:54 <CodeShark> meanwhile, those of us who are actually thinking more than a few weeks ahead could continue working on *real* improvements to bitcoin without all this noise and distraction :)
 87 2015-09-06 04:05:50 <CodeShark> the ability to change one's mind is actually a HUGE plus here. with "voting" mechanisms that lock in changes, it will be a mess if after we transition we realize it was a dumb decision
 88 2015-09-06 04:07:29 <CodeShark> so again, seems like a no-brainer
 89 2015-09-06 04:11:54 <CodeShark> yes, it's easier to remove the building's column without having to build any temporary supporting structure to bear the load...but it also means the building will collapse. so it seems stupid to not build the temporary supporting structure
 90 2015-09-06 04:19:43 <CodeShark> oh, and if it turns out our fears about bigger blocks are unfounded, great! we can have our cake and eat it too :p
 91 2015-09-06 04:19:55 <jcorgan> +1
 92 2015-09-06 05:07:58 <hypermist> I know this is bitcoin-dev but is there any altcoin dev channel ?
 93 2015-09-06 05:08:12 <jcorgan> ##altcoin-dev
 94 2015-09-06 05:08:42 <hypermist> thank you jcorgan :)
 95 2015-09-06 08:20:31 <gmaxwell> Oh miniupnpc bump.
 96 2015-09-06 08:20:57 <gmaxwell> last one of those I noticed I reviewed the updates in miniupnpc and returned unhappy about using it. :P
 97 2015-09-06 09:15:28 <wumpus> upnp support is kind of important to have connectable nodes
 98 2015-09-06 09:17:14 <gmaxwell> haha indeed, indeed.
 99 2015-09-06 09:22:18 <wumpus> (could use a different library ofcourse, but I'm not sure there are better ones)
100 2015-09-06 09:37:18 <Diablo-D3> http://www.businessinsider.com.au/spacex-satellite-program-brings-global-internet-access-2015-9
101 2015-09-06 10:08:37 <BlueMatt> gmaxwell: its upnp....everything is absolute complete shit because upnp itself is absolute complete shit
102 2015-09-06 10:09:05 <BlueMatt> can someone pm me cdecker's email?
103 2015-09-06 10:09:13 <BlueMatt> I'm sure I have it somewhere, but cant seem to find it....
104 2015-09-06 10:09:26 <BlueMatt> wait, nope, found it
105 2015-09-06 10:33:22 <wumpus> the upnp code could pretty easily run in a separate process, there's only very little interaction with the rest
106 2015-09-06 10:34:25 <wumpus> (and heavily sandboxed)
107 2015-09-06 10:41:36 <gmaxwell> weird, for some reason its taking tens of minutes just to copy my .bitcoin directory on my laptop...  I hope this doesn't mean my ssd is failing.
108 2015-09-06 10:42:14 <phantomcircuit> gmaxwell, lack of discard/TRIM
109 2015-09-06 10:42:39 <gmaxwell> maybe on the kernel blacklist.
110 2015-09-06 10:43:05 <phantomcircuit> gmaxwell, apparently the blacklist is stupid and there was just a bug in the raid0 driver
111 2015-09-06 10:43:47 <gmaxwell> the copy appears to be running at about 14MB/s. :(
112 2015-09-06 10:43:49 <phantomcircuit> gmaxwell, also if you've got dmcrypt setup then likely you need to specify the discard option
113 2015-09-06 10:43:59 <phantomcircuit> if you have lvm then also for that
114 2015-09-06 10:44:02 <phantomcircuit> and for the filesystem
115 2015-09-06 10:44:08 <gmaxwell> phantomcircuit: discard is set. Don't use lvm.
116 2015-09-06 10:44:08 <phantomcircuit> you can see if it's working with fstrim
117 2015-09-06 10:44:44 <phantomcircuit> try `fstrim -av`
118 2015-09-06 10:49:40 <phantomcircuit> gmaxwell, i bet it doesn't work :P
119 2015-09-06 11:03:14 <midnightmagic> What's the -a option on fstrim?
120 2015-09-06 11:10:45 <gmaxwell> hm. someone remind me why we need a reindex to _disable_ txindex?
121 2015-09-06 11:13:09 <wumpus> easier to implement
122 2015-09-06 11:14:23 <wumpus> wiping the txindex data on the fly from the blockindex db would be a shortcut, but that's extra code and extra testing
123 2015-09-06 11:17:33 <gmaxwell> Not exactly a frequent operation in any case.
124 2015-09-06 11:18:07 <wumpus> (just as it would - in theory - be possible to build a transaction index without rebuilding the utxo set or block index, but these things are maybe unnecessarily intertwined)
125 2015-09-06 11:19:02 <wumpus> right
126 2015-09-06 11:20:33 <wumpus> ideally there would be a blockchain data provider and the different independent indexers would subscribe to that and build their own dbs
127 2015-09-06 11:21:28 <gmaxwell> txindex would be obscenely large though if it were really intependant of the rest though.
128 2015-09-06 11:22:13 <wumpus> even more obscenely large as it is now?
129 2015-09-06 11:23:02 <wumpus> is there some kind of space-saving going on? I know it's all stashed in the block index db, but not by heart what format is used
130 2015-09-06 11:25:03 <gmaxwell> wumpus: yes the txindex is (according to my highly lossy memory) just a map of txids to blocks, so that actual data is just the block data.
131 2015-09-06 11:25:54 <wumpus> that makes sense - though there's no fundamental reason why a more independent indexer couldn't use the same format
132 2015-09-06 11:26:33 <gmaxwell> Yes, though it wouldn't be independant of the blockstorage.
133 2015-09-06 11:27:23 <wumpus> unless it needs to work with pruning it doesn't need to be, I mean just not intertwined in the process, the block database and its inner loops
134 2015-09-06 11:30:09 <wumpus> bitcoind could offer efficient access to its block storage, for example the REST interface is pretty low overhead, although currently it doesn't support extents to get only part of a block that defines e.g. a transaction
135 2015-09-06 13:51:54 <jonasschnelli> *highlight: [14:05:59] <jgarzik:#bitcoin-dev> jonasschnelli, FYI, moved tests and lib into sub-directories, in jgarzik/univalue
136 2015-09-06 13:53:47 <jonasschnelli> ---> perfect: will do the number parse namespacing (and remove of the facultative compiling/linking) tomorrow.
137 2015-09-06 20:33:07 <rusty> gmaxwell: thinking about versionbips timeouts.  Indeed, timeout for start is marginally better than timeout for end, but then you need to pick two values (start timeout, and duration).  I think I vaguely prefer a single "end" timeout, at granularity of 1 year, suggesting +3 years at BIP drafting.  Will provide a table of year-start to seconds in BIP itself.
138 2015-09-06 20:45:02 <btcdrak> +1 rusty
139 2015-09-06 21:45:06 <chris13243> does anyone know of a python implementation of bip38 ec-multiply?
140 2015-09-06 21:45:52 <rusty> https://gist.github.com/rustyrussell/47eb08093373f71f87de sipa, gmaxwell that's as simple as it can get.  Basically, it's back to the original, with more specification on timeout, assessment only on retarget periods, and a single period fallow delay.
141 2015-09-06 21:53:12 <CodeShark_> I like it rusty. A thing that worries me a little is code getting really ugly as we add more and more conditionals to account for soft forks...so perhaps there should be some provision for how to clean up the code once the delay period is over
142 2015-09-06 21:53:53 <CodeShark_> not necessarily as part of the BIP...but just in general
143 2015-09-06 21:55:52 <rusty> CodeShark I'm tempted to actually code it in bitcoin core, so they all stay in one place and not get spread throughout.
144 2015-09-06 21:56:23 <CodeShark_> yeah
145 2015-09-06 21:59:57 <CodeShark_> all the forking decisions should take place in one unit - but then we'll still need to intersperse stuff into the consensus code to account for the rule changes...but perhaps we can do something like: if (UseRule(rule, blockheight)) { ... }
146 2015-09-06 22:01:51 <rusty> CodeShark: indeed.
147 2015-09-06 22:12:03 <jtimon> CodeShark_: rusty: yeah, I really like using the block height, once the changes are sufficiently buried, we can do things like #5966
148 2015-09-06 22:20:05 <CodeShark> I highly dislike the use of stuff like IsSuperMajority inside the consensus code itself :)
149 2015-09-06 22:20:18 <CodeShark> it should be isolated to the fork detection unit
150 2015-09-06 22:21:02 <CodeShark> I mean, fork selection unit
151 2015-09-06 22:21:52 <CodeShark> and I absolutely ABHOR including any of this stuff in CMainParams - lol
152 2015-09-06 22:22:17 <CodeShark> well...
153 2015-09-06 22:22:22 <CodeShark> hmm...
154 2015-09-06 22:22:40 <CodeShark> I guess it somewhat makes sense
155 2015-09-06 22:22:47 <gmaxwell> jonasschnelli: I hope you don't take my auth comments on the PR personally!
156 2015-09-06 22:23:25 <gmaxwell> jonasschnelli: Interestingly, I was googling to see if anyone had noticed the apparent replay problem in bitauth and found this discussion https://botbot.me/freenode/bitcoin-wizards/2015-07-21/?page=3
157 2015-09-06 22:24:00 <CodeShark> I take it back - I don't abhor it...I just intuitively feel there's probably an even cleaner approach
158 2015-09-06 22:24:44 <CodeShark> I'm actually not sure we should get rid of the UseRule calls
159 2015-09-06 22:24:49 <CodeShark> the less we have to touch the consensus code, the better
160 2015-09-06 22:25:32 <CodeShark> the idea is to incorporate these rules into the consensus code in a way that can be left permanently without making for ugly code, making it clear what the logic is
161 2015-09-06 22:26:08 <gmaxwell> CodeShark: we actually remove old softforks once they are burried.
162 2015-09-06 22:26:23 <CodeShark> but how do you validate older blocks, then?
163 2015-09-06 22:26:30 <gmaxwell> And change them into simple  height > x checks as needed.
164 2015-09-06 22:26:39 <CodeShark> right, that's totally unclear
165 2015-09-06 22:26:45 <gmaxwell> (if needed... e.g. if there never was a violation in the chain)
166 2015-09-06 22:26:50 <CodeShark> it's much clearer to have if (UseRule(rule, blockheight))
167 2015-09-06 22:27:03 <gmaxwell> It's documented. And it's simpler and safer than some crazy ass indirection.
168 2015-09-06 22:27:27 <CodeShark> crazy ass? :)
169 2015-09-06 22:27:37 <gmaxwell> sometimes we actually have to enforce the rule elsewhere.
170 2015-09-06 22:28:07 <gmaxwell> see, for example fEnforceBIP30  in main.cpp.
171 2015-09-06 22:28:20 <CodeShark> the main advantage I see to if (height > x) is faster execution :)
172 2015-09-06 22:28:28 <CodeShark> which I don't think is really an issue here
173 2015-09-06 22:30:29 <CodeShark> I also am not a big fan of using global flags everywhere :)
174 2015-09-06 22:30:52 <CodeShark> it makes it a bitch to figure out where they are set or modified later on
175 2015-09-06 22:31:01 <CodeShark> generally speaking, that is
176 2015-09-06 22:32:13 <gmaxwell> ... it's not a global flag.
177 2015-09-06 22:33:23 <gmaxwell> Most of the global flags in the bitcoin core codebase are violations of the languages' concurrency model and are unsafe. You won't see me advocate them.
178 2015-09-06 22:34:14 <gmaxwell> It's just the definition of the rule, and right where the rule is defined, the exceptions are defined too-- as part of the rule.
179 2015-09-06 22:34:28 <gmaxwell> Along with the rationale for it, and citations for more information.
180 2015-09-06 22:34:51 <gmaxwell> I think this is much more cohearent than spreading the effective rule (which includes where it does and doesn't apply) across many files.
181 2015-09-06 22:42:49 <btcdrak> rusty: i like the proposal. are you going to take a stab at implementation too?
182 2015-09-06 22:43:53 <CodeShark> gmaxwell: we can have a set of constants defined for the switchover heights once they are buried as part of the fork selection unit - but I do see the argument for including it in the chain params
183 2015-09-06 22:44:37 <CodeShark> however, I still would prefer to avoid interspersing stuff like if (height > x) in the consensus code itself
184 2015-09-06 22:49:34 <CodeShark> for legibility reasons, for the sake of better abstraction/encapsulation, and to avoid having to modify consensus code as much as possible
185 2015-09-06 22:51:06 <CodeShark> i.e. perhaps one day we decide on a rule that applies to only even blocks :p
186 2015-09-06 22:51:27 <CodeShark> not that I can think of any that makes sense - but UseRule(rule, blockheight) would still support that
187 2015-09-06 22:53:32 <CodeShark> more reasonably, perhaps, would be a rule with an expiration height
188 2015-09-06 22:54:08 <CodeShark> it would be hideous to have to start doing stuff like if (height >= x && height < y) in the consensus code
189 2015-09-06 22:57:31 <CodeShark> these kinds of poor habits are how the consensus code got so intermeshed with everything else in the first place :p
190 2015-09-06 22:58:18 <CodeShark> one extra level of indirection is a tiny price to pay, IMHO
191 2015-09-06 22:59:36 <CodeShark> if we have a function that checks this condition in multiple places, we can always set local variables at the beginning
192 2015-09-06 23:00:19 <CodeShark> bool bUseBIP1000 = UseRule(RULE_BIP100, height);
193 2015-09-06 23:01:06 <CodeShark> I mean RULE_BIP1000 :p
194 2015-09-06 23:03:46 <CodeShark> then it's absolutely clear where the consensus rule forks are in the consensus code - you can always grep for UseRule
195 2015-09-06 23:04:06 <CodeShark> and we never have to touch that code again