1 2015-09-29 01:40:39 <skyzer> Greetings everybody, tried asking in main channel but no response. Quick question, why does bitcoin core sometimes counts 0 confirmation transactions into balance, and sometimes not? this messes up accounting. Any reason behind it or how to know which 0 confirmation is included into bitcoin core balance and which one not?
  2 2015-09-29 01:41:25 <sipa> if it was sent by yourself, it is counted
  3 2015-09-29 01:41:43 <sipa> because it trusts itself :)
  4 2015-09-29 01:41:44 <skyzer> But it wasn't... It is sent by random people
  5 2015-09-29 01:42:14 <sipa> then by default it won't be counted
  6 2015-09-29 01:42:39 <skyzer> I was wondering that if i'm sending out and the change has still 0 confirmations, would it include or not in the balance. In this case it would since it was indeed sent by myself.
  7 2015-09-29 01:42:40 <sipa> there is a minconf parameter to some RPC calls that you can set to 0
  8 2015-09-29 01:43:12 <skyzer> Version currently is 0.10.2. I will check the minconf parameters thanks
  9 2015-09-29 01:49:38 <CodeShark_> I see the versionbits BIP has been merged
 10 2015-09-29 01:50:28 <CodeShark_> I'm hoping to have an implementation ready tomorrow
 11 2015-09-29 01:51:02 <CodeShark_> Will that be added to the BIP doc? Or what's the general procedure?
 12 2015-09-29 01:56:53 <sipa> CodeShark_: you can PR a change to add a link to the implementatiom
 13 2015-09-29 01:58:35 <kanzure> you?
 14 2015-09-29 01:58:38 <kanzure> whoops
 15 2015-09-29 01:58:44 <kanzure> irc failure.
 16 2015-09-29 02:03:07 <sipa> 2nd person singular pronoun, english
 17 2015-09-29 02:08:40 <CodeShark_> Nominative and accusative
 18 2015-09-29 02:09:29 <CodeShark_> (Pronouns are the only words that still have declensions in English)
 19 2015-09-29 02:12:19 <CodeShark_> It also used to be the formal form, the informal being thee
 20 2015-09-29 02:16:11 <sipa> and thou
 21 2015-09-29 02:16:17 <sipa> no?
 22 2015-09-29 02:17:17 <CodeShark_> Thou was nominative, thee accusative, thy genitive (I think)
 23 2015-09-29 02:17:56 <sipa> i believe that's correct
 24 2015-09-29 02:22:48 <maaku> sipa: ping for review of #6312 -- just pushed a fix for what we talked about
 25 2015-09-29 02:22:51 <maaku> also get some sleep!
 26 2015-09-29 02:23:03 <sipa> cool, will review later
 27 2015-09-29 02:23:11 <sipa> i fail to sleep
 28 2015-09-29 03:43:13 <CodeShark> anyone here (besides sipa) intimately familiar with how the block index DB works? :)
 29 2015-09-29 08:35:50 <wumpus> well I know a thing or two about it
 30 2015-09-29 08:35:58 <CodeShark_> How are we planning on deploying versionbits? As a soft fork requiring nVersion to start with the bits 011 after a particular height subject to IsSuperMajority()?
 31 2015-09-29 08:37:24 <CodeShark_> err, I mean starting with the bits 001
 32 2015-09-29 08:39:44 <wumpus> versionbits has a stealth bip, it's not linked to in the index:  https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#Mechanism  . Although I don't see anything about initial deployment.
 33 2015-09-29 08:43:35 <CodeShark> Right, wummpus - it doesn't seem specified
 34 2015-09-29 08:43:40 <CodeShark> *wumpus
 35 2015-09-29 08:44:47 <CodeShark> so if we do not use IsSuperMajority to deploy it, presumably miners and clients will have to know something about this mechanism to be able to appropriately issue warnings to users
 36 2015-09-29 08:45:30 <CodeShark> using IsSuperMajority allows us to at least measure acknowledgement of version bits in miners
 37 2015-09-29 08:45:49 <CodeShark> but all clients should be upgraded as well
 38 2015-09-29 08:50:12 <CodeShark> i.e. right now we don't seem to complain in ContextualCheckBlockHeader if nVersion is larger than anything we recognize: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2664
 39 2015-09-29 08:51:10 <CodeShark> so is it safe to just suddenly go from nVersion == 0x3 to nVersion == 0x20000000 ?
 40 2015-09-29 08:51:52 <CodeShark> surely at least we should define a transition height
 41 2015-09-29 08:52:26 <sipa> CodeShark: versionbits has no deployment; it's just a mechanism other softforks can use to deploy
 42 2015-09-29 08:52:47 <sipa> CodeShark: or do you feel there is a use for formally deploying it?
 43 2015-09-29 08:52:48 <CodeShark> yes, but implementations need to be aware of it to handle things appropriately
 44 2015-09-29 08:53:16 <sipa> how so?
 45 2015-09-29 08:53:24 <CodeShark> if someone were to mine a block right now with version 0x20000000 would most nodes accept it as valid?
 46 2015-09-29 08:53:38 <sipa> of course
 47 2015-09-29 08:53:42 <sipa> it has to be
 48 2015-09-29 08:53:59 <sipa> otherwise we couldn't do versionbits as a softfork!
 49 2015-09-29 08:54:14 <sipa> not most nodes
 50 2015-09-29 08:54:18 <sipa> *all* nodes
 51 2015-09-29 08:54:35 <CodeShark> yes, but presumably once we start using versionbits, blocks that do not start with bits 001 should not be accepted beyond a certain height, no?
 52 2015-09-29 08:55:22 <CodeShark> there needs to be a cutoff point
 53 2015-09-29 08:55:46 <sipa> why not?
 54 2015-09-29 08:55:57 <CodeShark> so how shall that cutoff point be determined?
 55 2015-09-29 08:55:58 <sipa> maybe we want to back out of versionbits at some point
 56 2015-09-29 08:56:36 <CodeShark> I thought "backing out" meant going to 010
 57 2015-09-29 08:57:19 <sipa> i think anything not starting with 001 should be treated as having versionbits all zeroes
 58 2015-09-29 08:57:54 <CodeShark> so once a change is locked in, that would make such versions invalid, no?
 59 2015-09-29 08:58:00 <sipa> CodeShark: one exicit goal of versionbits was not permanently losing nVersion value space
 60 2015-09-29 08:58:30 <sipa> so no, no rule that forces 001 or higher
 61 2015-09-29 08:58:51 <sipa> or we're throwing away 12.5% of the space
 62 2015-09-29 08:59:07 <CodeShark> ok
 63 2015-09-29 08:59:33 <sipa> sure, during the deployment of a particular softfork there may be a need to have versionbitsed blocks
 64 2015-09-29 08:59:54 <sipa> but after the deadline passed, we could in theory go back again
 65 2015-09-29 09:00:29 <CodeShark> hmm, according to the current spec, once a soft fork is locked in, miners should stop setting the bit
 66 2015-09-29 09:00:56 <sipa> hmm, i wonder whether first bits 010 or 011 should be treated as versionbits infinity
 67 2015-09-29 09:01:21 <sipa> otherwise we effectively can't ever uograde as long as there are non-deployed versions
 68 2015-09-29 09:01:34 <sipa> CodeShark: i think we should discuss this thursday in the meeting
 69 2015-09-29 09:01:39 <CodeShark> the spec isn't entirely clear on whether miners *should* stop setting the bit or miners *must* stop setting the bit
 70 2015-09-29 09:01:51 <sipa> this is a part of the design that is insufficiently thought out, i must admit
 71 2015-09-29 09:02:17 <sipa> CodeShark: if they don't, the warning mechanism will trigger
 72 2015-09-29 09:03:08 <CodeShark> shouldn't the lock-in period require setting the bit? to ensure that for 2016 blocks all miners effectively have acknowledged the rule change
 73 2015-09-29 09:03:17 <CodeShark> then once activated, we reset the bit
 74 2015-09-29 09:04:54 <CodeShark> moreover, once the bit is reset, we must require miners to no longer set it so it's free to be used for another soft fork
 75 2015-09-29 09:05:05 <CodeShark> no?
 76 2015-09-29 09:05:41 <CodeShark> I think the spec should actually start with a set of parameters that define a soft fork deployment
 77 2015-09-29 09:06:41 <sipa> CodeShark: why require setting the bit?
 78 2015-09-29 09:07:04 <sipa> if you do that, the fork effectively happens the moment that requirement occurs
 79 2015-09-29 09:07:15 <sipa> because everyone not setting it will be forked off
 80 2015-09-29 09:07:54 <CodeShark> yeah - but there's a problem here...because miners that did not acknowledge the rule change should not have their blocks accepted once it activates
 81 2015-09-29 09:08:18 <CodeShark> so after activation we should still enforce some check to ensure miners are acknowledging it
 82 2015-09-29 09:08:37 <sipa> i don't understand
 83 2015-09-29 09:09:04 <CodeShark> in other words, we cannot currently distinguish between a miner that voted with the minority and lost (and knows it) and a miner that simply was never aware of the change in the first place
 84 2015-09-29 09:09:49 <sipa> there is something to say about that
 85 2015-09-29 09:10:56 <sipa> i'm not sure... maybe non-upgraded miners are fine (in some softforks, using the post-softfork feature is intentionally non-standard before the rollout)
 86 2015-09-29 09:11:33 <sipa> sometimes, i guess you want them to be immediateoy aware
 87 2015-09-29 09:12:28 <CodeShark> yes - and we need to take into account as part of the process the way we initially advertise new soft fork proposals and set deadlines for support
 88 2015-09-29 09:13:00 <CodeShark> of course, miners that simply fail to impose the rule are likely to have their blocks ignored by others
 89 2015-09-29 09:13:35 <CodeShark> so they'll start to wonder sooner or later, I suppose
 90 2015-09-29 09:13:47 <CodeShark> I'm actually more concerned about clients
 91 2015-09-29 09:14:51 <CodeShark> if 5% of hashing power gets wasted, it's not such a huge deal I suppose...but clients will be able to warn the user the moment they see an nVersion they do not recognize
 92 2015-09-29 09:15:34 <CodeShark> however, I still think it would be a good idea to require miners to explicitly acknowledge the change
 93 2015-09-29 09:16:18 <CodeShark> deployment of clients is something we simply cannot measure, currently
 94 2015-09-29 09:16:48 <CodeShark> I guess we can sort of measure it...assuming nobody is deliberately trying to cheat
 95 2015-09-29 09:21:36 <CodeShark> the reuse of bits also means that the definitions of the forks must be posted somewhere...and I don't think we have a decentralized mechanism for making these specifications available ;)
 96 2015-09-29 09:22:01 <CodeShark> we really need to consider the entire process...not just the activation/failure mechanism
 97 2015-09-29 09:22:14 <sipa> deciding consensus rules is inherently not decentralized
 98 2015-09-29 09:22:43 <CodeShark> indeed...but I think we need a more formal process
 99 2015-09-29 09:22:46 <sipa> this is just to safely trigger them
100 2015-09-29 09:23:01 <sipa> it's called BIPs, and them being implemented
101 2015-09-29 09:23:21 <sipa> please just stick to the technical oroblem, that'a already hard enough :)
102 2015-09-29 09:23:46 <CodeShark> the technical problems are actually the easy part ;)
103 2015-09-29 09:24:09 <sipa> CodeShark: i guess whatbwe coukd say is that miners SHOULD keep setting the version bit between lockin and activation
104 2015-09-29 09:24:23 <sipa> and that the first block with the rule activated MUST set the bit
105 2015-09-29 09:24:40 <sipa> that will immiediately fork off all miners who are nkt aware
106 2015-09-29 09:24:56 <CodeShark> right
107 2015-09-29 09:25:08 <sipa> and then after that, SHOULD NOT set the bit anymore
108 2015-09-29 09:25:44 <CodeShark> that seems to make more sense than the current spec
109 2015-09-29 09:26:51 <CodeShark> another issue the spec should probably make more concrete is minimum height or timestamp before a soft fork proposal is live
110 2015-09-29 09:27:12 <sipa> there is the option of keeping the inbetween bits SHOULD NOT
111 2015-09-29 09:27:33 <sipa> keeping them set has the disadvantage of possibly missing testing
112 2015-09-29 09:27:56 <sipa> things may look like they work, but they're actually triggering on the wrong set bits
113 2015-09-29 09:28:14 <sipa> i like the "only set as many bits as needed" approach
114 2015-09-29 09:28:28 <CodeShark> not sure I follow
115 2015-09-29 09:28:47 <sipa> someone may implement versionbits incorrectly in software
116 2015-09-29 09:29:14 <sipa> but it is likely it will keep working if miners keep setting the bits after lockin
117 2015-09-29 09:29:23 <sipa> it's a minor point
118 2015-09-29 09:29:40 <CodeShark> hmm...to fully address all these things we might need two bits per soft fork ;)
119 2015-09-29 09:29:55 <sipa> the point in favor is of course that do setting it gives free monitoring of further deployment past 95%
120 2015-09-29 09:30:33 <CodeShark> we max out at 14 parallel soft forks...but we can then fully detect each transition
121 2015-09-29 09:31:37 <sipa> i'm not following
122 2015-09-29 09:31:45 <sipa> why do we need 2 bits?
123 2015-09-29 09:32:09 <CodeShark> you set 00 to vote against, 01 to vote for. once locked in, you must do 10. then once activated, one block must have 11 before turning both back off
124 2015-09-29 09:33:02 <Belxjander> CodeShark: don't you only need 2 bits for "protocol" discussion of the soft-fork...other bits can then be what ? one bit per soft-fork ?
125 2015-09-29 09:33:49 <CodeShark> Belxjander: each soft fork can activate independently, no?
126 2015-09-29 09:34:37 <CodeShark> I suppose we could also add support for multistage stuff
127 2015-09-29 09:34:38 <Belxjander> CodeShark: wouldn't that be identifying each soft-fork with an individual bit for which way each miner votes..with 2 bits for "soft-fork in progress" operations ?
128 2015-09-29 09:34:54 <CodeShark> but the 2 bits cannot identify which soft fork is in progress
129 2015-09-29 09:35:02 <CodeShark> unless each soft fork has its own 2 bits
130 2015-09-29 09:35:27 <Belxjander> CodeShark: thats why you also need the "select" set...where one bit is each soft-fork... check for "in progress" and then read the "selection range" ?
131 2015-09-29 09:36:05 <CodeShark> point is for each soft fork to be able to signal independently of each transition we need two bits for each
132 2015-09-29 09:36:29 <CodeShark> i.e. SF1 might be locking in while SF2 is activating
133 2015-09-29 09:36:34 <CodeShark> on the same block
134 2015-09-29 09:36:42 <Belxjander> ahhh
135 2015-09-29 09:37:14 <CodeShark> multistage soft forks might afford a single signal bit
136 2015-09-29 09:37:26 <CodeShark> for all the stages
137 2015-09-29 09:37:56 <Belxjander> basically counting the stages
138 2015-09-29 09:38:15 <Belxjander> and putting a group of soft-fork counters side-by-side bitwise ?
139 2015-09-29 09:38:35 <CodeShark> possibly...or perhaps simply reusing the bit immediately for the next stage
140 2015-09-29 09:38:42 <sipa> CodeShark: there is no point in a 'voting against', it is not a vote, it is a trigger mechanism
141 2015-09-29 09:39:07 <CodeShark> sipa: right, I guess more accurately one could call it "hoping for it to timeout"
142 2015-09-29 09:39:28 <Belxjander> sipa so all "soft-fork" material only needs to identify which soft-forks are changing?
143 2015-09-29 09:39:54 <sipa> Belxjander: i don't follow; have you read bip9m
144 2015-09-29 09:39:59 <sipa> bip 9?
145 2015-09-29 09:41:01 <Belxjander> sorry...wandered in half dead after a long day...so my memory of whether I have or not is pretty shot...
146 2015-09-29 09:41:58 <CodeShark> so sipa, the question is whether it's worth using up two bits per soft fork for better signaling
147 2015-09-29 09:42:44 <CodeShark> so we can represent each state unambiguously
148 2015-09-29 09:43:00 <sipa> CodeShark: i still don't see the point
149 2015-09-29 09:43:37 <CodeShark> it would force miners to acknowledge lock-in and activation unambiguously
150 2015-09-29 09:44:08 <CodeShark> making it less likely that a buggy implementation continues to signal incorrectly
151 2015-09-29 09:44:32 <sipa> meh
152 2015-09-29 09:45:11 <CodeShark> my biggest concern, actually, is miners "acknowledging" a rule change but then not enforcing it
153 2015-09-29 09:45:45 <sipa> how will you prevent that?
154 2015-09-29 09:46:17 <sipa> "once locked in, you must do 10" -> that is a fork on itself
155 2015-09-29 09:46:41 <CodeShark> yes, but it doesn't affect transactions
156 2015-09-29 09:47:06 <CodeShark> its sole purpose is to sample miners
157 2015-09-29 09:47:07 <sipa> if that already forks, why do we have a time between lockin and activation?
158 2015-09-29 09:47:15 <sipa> the 5% are already gone after that point
159 2015-09-29 09:47:47 <sipa> or yiu mean that second bit is purely informational?
160 2015-09-29 09:47:57 <CodeShark> yes
161 2015-09-29 09:48:25 <CodeShark> by "informational" are you suggesting miners not be required to set it?
162 2015-09-29 09:48:25 <sipa> what is the effect of not setting it?
163 2015-09-29 09:48:36 <CodeShark> if that's the case then I'm not sure I mean that
164 2015-09-29 09:48:49 <sipa> if it is required, you are already forking, and there is no need to wait for the next 2016 muktiple etc
165 2015-09-29 09:48:59 <sipa> if it is not required, it is informational
166 2015-09-29 09:49:06 <sipa> and it has no effect on consensus
167 2015-09-29 09:49:13 <CodeShark> but the lock-in phase doesn't require enforcement of the rule, correct?
168 2015-09-29 09:49:21 <sipa> indeed
169 2015-09-29 09:49:52 <sipa> the lock-in period is there to give the 5% time to uograde after the 95% have decided that no matter what, they will start enforcing
170 2015-09-29 09:50:12 <sipa> and to make the trigger time more predictable
171 2015-09-29 09:50:36 <sipa> if you fork at the moment 95% is crossed, you are removing that entirely
172 2015-09-29 09:50:48 <CodeShark> ok, I see your point
173 2015-09-29 09:50:48 <sipa> and the lockin time becomes dead weight
174 2015-09-29 09:51:14 <CodeShark> well...
175 2015-09-29 09:51:29 <CodeShark> consider that during lock-in it is still optional to either do 00 or 10
176 2015-09-29 09:51:41 <CodeShark> then once activation is reached, one block must have 11
177 2015-09-29 09:51:43 <CodeShark> then back to 00
178 2015-09-29 09:51:59 <sipa> you can do that with 1 bit
179 2015-09-29 09:52:19 <CodeShark> yes, but it doesn't explicitly measure whether miners are aware it's locked in or not
180 2015-09-29 09:52:20 <sipa> just require the vereion bit to be set to 1 in the first block that has the rule activated
181 2015-09-29 09:52:39 <CodeShark> I'm not too concerned about that, I suppos
182 2015-09-29 09:52:39 <sipa> so your second bit is purely informational
183 2015-09-29 09:52:48 <CodeShark> yeah, in this example it would be
184 2015-09-29 09:52:49 <sipa> there is no point in that, i think
185 2015-09-29 09:53:18 <sipa> there is no reason why miners would not incorrectly set that bit if they are already incorrectly setting the other
186 2015-09-29 09:53:29 <CodeShark> in the end, what matters is not really whether or not miners acknowledge the version change...what matters is whether they enforce the new rule
187 2015-09-29 09:53:44 <sipa> yes, and you can't measure that in a softfork
188 2015-09-29 09:54:03 <sipa> in a hardfork you can require the forking block to be explicitly incompatible with the old rules
189 2015-09-29 09:55:41 <CodeShark> with BIP66, imagine what would have happened if miners would have been able to continue mining version 2 blocks after the rule change...
190 2015-09-29 09:56:18 <sipa> yes, that's why i think forcing a fork is good
191 2015-09-29 09:56:33 <CodeShark> there were two things at play - 1) whether miners were enforcing the version rule, 2) whether miners were enforcing BIP66
192 2015-09-29 09:56:58 <sipa> oh
193 2015-09-29 09:57:02 <sipa> you can't force a fork
194 2015-09-29 09:57:04 <sipa> i was wrong
195 2015-09-29 09:57:15 <sipa> not in any useful way
196 2015-09-29 09:57:39 <CodeShark> so then this boils down to a problem of miner incentives
197 2015-09-29 09:57:49 <sipa> only informationally
198 2015-09-29 09:58:22 <CodeShark> well, we can't really enforce the spec...but we can make it unattractive for miners to stray from it (unless they have a very substantial fraction of total hashing power)
199 2015-09-29 10:00:28 <CodeShark> with BIP66, miners that failed to enforce BIP66 only lost out after either 1) someone mined a version 2 block or 2) someone mined a version 3 block with at least one transaction that failed BIP66
200 2015-09-29 10:00:52 <sipa> we could say something like it is suggestes to keep setting the bit for one 2016-window period activation
201 2015-09-29 10:01:46 <sipa> or even musr
202 2015-09-29 10:01:49 <sipa> must
203 2015-09-29 10:01:54 <CodeShark> right...so then in that case, we add one more state for that 2016 activation window
204 2015-09-29 10:02:12 <CodeShark> DEFINED, LOCKED_IN, ACTIVATED, FINAL
205 2015-09-29 10:02:14 <CodeShark> or something like that
206 2015-09-29 10:02:47 <CodeShark> FINAL means the bits should no longer be set
207 2015-09-29 10:02:53 <CodeShark> or *must* no longer be set, rather
208 2015-09-29 10:03:26 <CodeShark> setting the bit is still optional during the LOCKED_IN state
209 2015-09-29 10:03:36 <CodeShark> it's manditory during the ACTIVATED state
210 2015-09-29 10:03:47 <CodeShark> and it's prohibited during the FINAL state
211 2015-09-29 10:04:48 <CodeShark> or rather, after the FINAL state, the bit is completely free to reuse
212 2015-09-29 10:05:05 <CodeShark> if it's set at that point, there must be another defined soft fork that uses it
213 2015-09-29 10:05:11 <sipa> indeed
214 2015-09-29 10:05:49 <sipa> we should discuss with rusty and petertodd and greg and #bitcoin-dev :)
215 2015-09-29 10:10:29 <CodeShark> sipa, couldn't we get rid of the pindexPrev parameter in ContextualCheckBlockHeader and ContextualCheckBlock by just setting the member in block?
216 2015-09-29 10:10:31 <CodeShark> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2664
217 2015-09-29 10:10:49 <CodeShark> passing it as a separate parameter seems really ugly
218 2015-09-29 10:12:09 <sipa> CodeShark: no, absolutely not - CBlock is just the primitive data structure (and even things like fChecked or the merkle tree data don't belong there)
219 2015-09-29 10:12:15 <sipa> CodeShark: however!
220 2015-09-29 10:12:25 <sipa> a CCheckedBlock wrapper would be neat
221 2015-09-29 10:12:37 <sipa> which could have a known pindex pointer
222 2015-09-29 10:12:50 <sipa> which would be local to validation code
223 2015-09-29 10:13:39 <CodeShark> so struct CCheckedBlock { CBlockIndex* pindex; CBlockIndex* pindexPrev; }; ?
224 2015-09-29 10:14:01 <sipa> yes, but please don't do that in the versionbits code
225 2015-09-29 10:14:16 <sipa> as that will likely need to be easily backportable to other versions
226 2015-09-29 10:14:27 <CodeShark> well, of course - I'm doing my best to alter main as little as possible
227 2015-09-29 10:14:29 <sipa> which makes it hard to depend on refactors
228 2015-09-29 10:15:11 <CodeShark> but this means I must temporarily take on the technical debt in my unit...which is fine...I just want to have a clear TODO for when we improve main
229 2015-09-29 10:16:00 <sipa> CodeShark: i mean struct CheckBlock { CBlock block; CBlockIndex *pindex; }
230 2015-09-29 10:16:13 <sipa> no need for pindexPrev, you can use pindex->pprev
231 2015-09-29 10:17:37 <CodeShark> I suppose I could define a struct for my functions that gets set inside of the ContextualCheck functions
232 2015-09-29 10:17:50 <sipa> CodeShark: your code shouldn't ever need CBlock... it can reason entirely based on the CBlockIndex structure
233 2015-09-29 10:18:00 <CodeShark> it isn't using CBlock
234 2015-09-29 10:18:07 <sipa> so?
235 2015-09-29 10:18:12 <sipa> then where is the technical debt?
236 2015-09-29 10:18:32 <sipa> i mean, there certainly is a lot of technical debt
237 2015-09-29 10:18:53 <CodeShark> the issue here is IsSuperMajority...which I'm encapsulating within exposed functions IsValidVersion() and UseRule()
238 2015-09-29 10:19:10 <CodeShark> I'd like to just pass the CBlockIndex object to both of these
239 2015-09-29 10:19:24 <sipa> so, why can't you?
240 2015-09-29 10:19:36 <CodeShark> but I need to pass through the pindexPrev value to IsSuperMajority
241 2015-09-29 10:20:07 <sipa> i don't understand, but i can't look at the code now
242 2015-09-29 10:20:16 <sipa> pindexPrev is the CBlockIndex
243 2015-09-29 10:20:32 <sipa> (of the previous block)
244 2015-09-29 10:21:01 <CodeShark> yes, which could in principle be set in the block structure. block.pprev = pprevIndex;
245 2015-09-29 10:21:11 <CodeShark> block is a CBlockIndex reference
246 2015-09-29 10:21:18 <sipa> CodeShark: that is always the case
247 2015-09-29 10:21:32 <sipa> the pprev pointer is set whenever the CBlockIndex object os created
248 2015-09-29 10:21:36 <sipa> *is
249 2015-09-29 10:22:09 <sipa> ok, taking off
250 2015-09-29 10:22:48 <CodeShark> doesn't seem to be set until AddToBlockIndex
251 2015-09-29 10:22:57 <CodeShark> which gets called after the ContextualCheck functions
252 2015-09-29 10:22:57 <sipa> yes
253 2015-09-29 10:23:04 <sipa> oh, i see
254 2015-09-29 10:23:37 <sipa> right, the problem is that there is no CBlockIndex yet for the to-be-added block header
255 2015-09-29 10:23:59 <sipa> ok, need to go
256 2015-09-29 10:24:01 <sipa> ttyl
257 2015-09-29 10:24:02 <CodeShark> right - but couldn't we still set the pprev field after we find the hash of the previous block in our map?
258 2015-09-29 10:24:04 <CodeShark> ok, later
259 2015-09-29 12:07:06 <ploopkazoo> BIP 0050 (March 2014 hardfork) says that while 0.7 used Berkeley DB, 0.8 used LevelDB. Why is it that Bitcoin Core, which is newer than Qt/d 0.8, uses Berkeley DB?
260 2015-09-29 12:07:47 <sipa> pl
261 2015-09-29 12:08:04 <sipa> all consensus code uses LevelDB
262 2015-09-29 12:08:04 <sipa> only the wallet iuses BDB
263 2015-09-29 12:08:19 <ploopkazoo> ah
264 2015-09-29 12:08:27 <sipa> until 0.7, BDB was used for everything
265 2015-09-29 12:15:17 <ploopkazoo> oh, that was 2013
266 2015-09-29 12:15:19 <ploopkazoo> goddamn
267 2015-09-29 12:19:12 <wumpus> configure --disable-wallet will make it compile without bdb dep
268 2015-09-29 12:24:46 <ploopkazoo> wumpus: yeah, I had to do that on freebsd for the time being because despite bdb (and apparently the right version) being installed it can't seem to find it
269 2015-09-29 12:28:05 <CodeShark> Would the sky come crashing down if we added a block.pprev = pindexPrev; right after this line? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2747
270 2015-09-29 12:29:40 <wumpus> ploopkazoo: at least on openbsd I just built it from source, https://github.com/laanwj/bitcoin/blob/2015_09_openbsd_build_guide/doc/build-openbsd.md#building-berkeleydb
271 2015-09-29 12:30:35 <wumpus> (then again, had to, because of the compiler version conflict)
272 2015-09-29 12:35:13 <sipa> CodeShark: i think that is safe
273 2015-09-29 12:35:33 <sipa> CodeShark: i finally get what you're after, after looking at the code :)
274 2015-09-29 12:36:42 <CodeShark> there's one other place where ContextualCheckBlockHeader is called - TestBlockValidity
275 2015-09-29 12:40:52 <CodeShark> I suppose we could set pprev inside ContextualCheckBlockHeader to make sure the call to IsValidVersion (which calls IsSuperMajority) doesn't require pindexPrev...which isn't super pretty, but I don't really think that AcceptBlockHeader should be setting this directly
276 2015-09-29 12:41:26 <CodeShark> if anything, we should have a separate call that checks the index map and assigns the value
277 2015-09-29 12:43:46 <CodeShark> i.e. CheckBlockHeader can check to see whether the member is assigned already - if not it looks for it in the map and assigns it - and if it can't be found in the map, it returns an error
278 2015-09-29 12:46:11 <CodeShark> then we can get rid of pindexPrev in that entire call stack
279 2015-09-29 12:49:55 <CodeShark> but this latter approach changes far more functionality...so in the interest of making it easy to review, I could just make sure it is assigned right before all my calls to IsValidVersion
280 2015-09-29 12:50:26 <CodeShark> we're going to have to clean up main.cpp sooner or later :p
281 2015-09-29 12:50:39 <CodeShark> 7 years on and it's still a pig sty :p
282 2015-09-29 12:51:25 <CodeShark> perhaps it's best to force the minimal number of changes on it for versionbits - and defer the main cleanup :)
283 2015-09-29 12:55:25 <CodeShark> I'm still curious about the history - who thought it was a good idea to call a file main.cpp when the entry point is actually in bitcoind.cpp which calls AppInit() which calls AppInit2() ?
284 2015-09-29 12:55:39 <CodeShark> that's just so weird :p
285 2015-09-29 12:56:38 <CodeShark> and the second question is...why was it left that way? :)
286 2015-09-29 12:56:53 <CodeShark> I understand now...it's hard to change without some downstream pushback
287 2015-09-29 12:57:20 <CodeShark> but back then?
288 2015-09-29 12:59:15 <CodeShark> by the time I got involved there were already a number of forks...and it was already messed up...but surely there must have been a point in its history prior to that where all of this could have been easily avoided
289 2015-09-29 12:59:36 <moa> 2009?
290 2015-09-29 12:59:39 <CodeShark> lol
291 2015-09-29 13:00:46 <CodeShark> I mean, I can continue to work around it - it's just bizarre, though...sort of reminds me of the BASIC programs I used to write as a kid :p
292 2015-09-29 13:01:10 <moa> goto 2010
293 2015-09-29 13:01:14 <CodeShark> :)
294 2015-09-29 13:01:14 <wumpus> it's really no use complaining in here, you're preaching to the choir
295 2015-09-29 13:01:26 <CodeShark> I'm not really complaining - just curious
296 2015-09-29 13:01:38 <CodeShark> as I said, I can continue to work around it
297 2015-09-29 13:01:49 <wumpus> I heard somewhere that bitcoin core was open source...
298 2015-09-29 13:02:16 <CodeShark> yes, which ironically makes it even harder to fix stuff now that everyone has their own fork
299 2015-09-29 13:02:40 <CodeShark> that's to say, to fix something and actually have the fix applied across the board
300 2015-09-29 13:02:46 <wumpus> excuses, excuses :)
301 2015-09-29 13:02:57 <CodeShark> no, I see it as a challenge
302 2015-09-29 13:03:00 <sipa> CodeShark: if the cost of review and breaking pull requests and derived codebases wasn't songreat, i think the code would be refactored in no time - plenty of people who want to improve
303 2015-09-29 13:03:46 <sipa> so yes, you're preaching to the choir :)
304 2015-09-29 13:04:05 <CodeShark> I'm not really preaching - I'm curious how it got that way in the first place :)
305 2015-09-29 13:04:18 <sipa> git log is your friend :p
306 2015-09-29 13:04:46 <wumpus> main.cpp and init.cpp have existed for very long, maybe since the beginning
307 2015-09-29 13:05:39 <sipa> init.cpp existed when i first looked at the code base at least
308 2015-09-29 13:06:24 <wumpus> although the separate entry points in src/qt/bitcoin.cpp, src/bitcoind.cpp were split off later. main, AppInit, Appinit2 used to be all in one file
309 2015-09-29 13:07:03 <sipa> the AppInit functions were for compatibility with wx, i think
310 2015-09-29 13:08:14 <sipa> init.cop didn't exist in 0.1.5
311 2015-09-29 13:09:10 <wumpus> I don't really care much about the function naming. My main gripe with main.cpp is that it has  both network logic, and the part that manages the chain (including consensus code)
312 2015-09-29 13:09:57 <gavinandresen> doc/build-unix.md doesn't mention ZMQ -- what package do I need to install to compile with it?
313 2015-09-29 13:10:19 <sipa> wumpus: agree
314 2015-09-29 13:10:32 <sipa> gavinandresen: libzmq-dev?
315 2015-09-29 13:10:40 <sipa> (that's a guess)
316 2015-09-29 13:10:56 <wumpus> yes the release notes and build-XXX need to be updated for zmq
317 2015-09-29 13:11:09 <gavinandresen> sipa: that seems to work, thanks!
318 2015-09-29 13:14:16 <CodeShark> it's actually quite instructive to look through the history :)
319 2015-09-29 13:23:44 <CodeShark> so main.cpp was there from the beginning as a huge file containing all the core data structures - but all the UI stuff was mixed in with the rest of the logic
320 2015-09-29 13:23:55 <CodeShark> CMyApp already had an Init and an Init2 method
321 2015-09-29 14:59:27 <btcdrak> CodeShark: sipa: was reading the previous discussion, I think where we say "should" and "must" in BIP-9 we should refer to RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) as it makes it unambiguous
322 2015-09-29 15:03:28 <CodeShark> yeah, seems like those definitions are pretty good
323 2015-09-29 15:10:12 <CodeShark> let's say we "shall" refer to RFC 2119 ;)
324 2015-09-29 15:21:24 <jcorgan> wumpus: i'll get a PR to you today on zmq
325 2015-09-29 15:22:05 <CodeShark> this is the basic framework I have so far for the versionbits implementation: https://github.com/CodeShark/bitcoin/tree/versionbits
326 2015-09-29 15:22:15 <wumpus> jcorgan: awesome
327 2015-09-29 15:23:54 <CodeShark> oops, I accidentally dropped in one of your commits into that with the net thing, wumpus :p
328 2015-09-29 15:27:02 <CodeShark> argh...I messed it up even more :p
329 2015-09-29 15:27:35 <wumpus> eh that doesn't sound good :p
330 2015-09-29 15:28:11 <CodeShark> how do I take out the first commit from a compare?
331 2015-09-29 15:28:21 <CodeShark> https://github.com/bitcoin/bitcoin/compare/master...CodeShark:versionbits
332 2015-09-29 15:28:31 <CodeShark> why is it using the first commit on there from fanquake?
333 2015-09-29 15:28:47 <CodeShark> must have done something strange with rebasing
334 2015-09-29 15:31:27 <CodeShark> ok, I reverted back - now it just shows your one liner net.cpp change
335 2015-09-29 15:32:02 <CodeShark> how do I make it not show your commit, wumpus?
336 2015-09-29 15:33:20 <wumpus> make sure you're rebased on top of it? my guess would be that that compare simply goes up the tree and starts with the first commit that two branches have in common
337 2015-09-29 15:35:15 <CodeShark> I tried rebasing on top of it...removing your commit...but that just made the commit before yours appear instead...and made it unmergeable :p
338 2015-09-29 15:35:48 <wumpus> what is your branch based on? current master?
339 2015-09-29 15:36:00 <CodeShark> no
340 2015-09-29 15:44:07 <CodeShark> btcdrak: I'll end up restructuring all the commits in the very near future...so chances are this is not what will make it into the PR
341 2015-09-29 15:48:36 <gavinandresen> To save somebody else a bunch of time, maybe:  apt-get install libzmq-dev  gives me version 2.2.0 of ZeroMQ. Which is ancient and doesn't work, apparently.
342 2015-09-29 15:48:59 <CodeShark> did you apt-get update? :)
343 2015-09-29 15:49:56 <CodeShark> oh, hmm
344 2015-09-29 15:50:00 <gavinandresen> CodeShark: still gives me version 2.2.0 after apt-get update....
345 2015-09-29 15:50:02 <wumpus> gavinandresen: yea :/ see https://github.com/bitcoin/bitcoin/issues/6734
346 2015-09-29 15:51:13 <gavinandresen> wumpus: ah, so I have to apt-get install libzmq3-dev ....
347 2015-09-29 15:51:27 <wumpus> hopefully there's a package for that
348 2015-09-29 15:51:49 <gavinandresen> Latest version if 4.1.3, maybe libzmq3-dev will work.....  I hope....
349 2015-09-29 15:52:00 <gavinandresen> What version is Travis running? Or how would I tell?
350 2015-09-29 15:52:30 <wumpus> depends/packages/zeromq.mk seems 4.0.4
351 2015-09-29 15:52:31 <jcorgan> libzmq3-dev is the right one
352 2015-09-29 15:53:07 <jcorgan> which is an unfortunate name, as it is the ZMQ 4.x API
353 2015-09-29 15:53:22 <gavinandresen> .....    of course it is .......
354 2015-09-29 16:12:43 <kanzure> gavinandresen: yep, when i reported the libzmq stuff, libzmq-dev gave me 2.2.0 as well
355 2015-09-29 16:12:58 <kanzure> debian experimental has libzmq5 i hear
356 2015-09-29 16:13:50 <kanzure> jcorgan: oh that's weird, perhaps you could add a note about that to the zmq.md file? that was not obvious to me (re: libzmq3 is zmq 4.x api)
357 2015-09-29 16:14:20 <jcorgan> sure, working on it now
358 2015-09-29 16:15:06 <jcorgan> i think it is the debian package policy for naming to use sequential numbers for changes in ABI
359 2015-09-29 16:32:00 <maaku> jcorgan: for what it's worth it's because zmq3 was a breaking api change, zmq4 was not.. so it reuses the same package name
360 2015-09-29 16:32:11 <maaku> not sure who to blame, zmq or debian package maintainers
361 2015-09-29 16:35:22 <jcorgan> i knew it was something like that
362 2015-09-29 16:59:43 <buZz> anyone here able to tell me which github has the bitcoin txindex patchset?
363 2015-09-29 16:59:51 <buZz> that lets me see all tx to all addresses
364 2015-09-29 16:59:52 <buZz> hmm
365 2015-09-29 17:00:28 <buZz> cant seem to find it ;(
366 2015-09-29 17:10:07 <jcorgan> quick question--my editor is set to remove whitespace on whitespace only lines, but that results in changesets that have whitespace changes in addition to actual changes
367 2015-09-29 17:10:33 <jcorgan> what do you prefer?
368 2015-09-29 17:11:02 <buZz> i prefer no spaces on empty lines
369 2015-09-29 17:11:09 <buZz> but my coworkers dont like that i do
370 2015-09-29 17:12:51 <jcorgan> for PR requests (wumpus)?
371 2015-09-29 17:12:58 <maaku> jcorgan: minimal diffs
372 2015-09-29 17:13:10 <maaku> whitespace can be removed during the refactoring week
373 2015-09-29 17:13:37 <maaku> but please don't introduce useless whitespace in your commits
374 2015-09-29 17:13:43 <maaku> (wumpus, correct if necessary)
375 2015-09-29 17:13:51 <jcorgan> right, that's why i have that feature turned on
376 2015-09-29 17:14:12 <jcorgan> but if i edit an existing file (like configure.ac), it cleans that up too
377 2015-09-29 17:15:22 <jcorgan> i'd really prefer not to have to disable that when editing bitcoin code
378 2015-09-29 17:28:34 <jcorgan> what should go into doc/release-process.md regarding zmq?  i'm not familiar with gitian or whether the zmq part is build in that environment
379 2015-09-29 17:47:23 <kanzure> gavinandresen: re: 2 or more chains after a hard-fork, one of the steps to prevent your transactions from appearing on the other chain would be to taint all of your utxos with at least 1 satoshi BTC from a post-fork coinbase output.
380 2015-09-29 17:52:00 <deego> Is it normal for htop to show "bitcoin -server" N times as N different processes? where N is the number of cpu's?
381 2015-09-29 17:52:25 <TD-Linux> yes, htop shows each thread by default
382 2015-09-29 17:52:30 <michagogo> deego: yes, that's threads
383 2015-09-29 17:52:38 <deego> ah, thanks
384 2015-09-29 17:52:49 <michagogo> One of htop's options lets you show them highlighted differently or something to make it more clear
385 2015-09-29 17:53:56 <gavinandresen> kanzure: off-topic for here
386 2015-09-29 17:54:41 <deego> michagogo: ah, H?
387 2015-09-29 17:54:45 <kanzure> oh
388 2015-09-29 17:55:29 <michagogo> deego: don't remember
389 2015-09-29 17:59:26 <jcorgan> #6736 for zmq update
390 2015-09-29 18:00:13 <wumpus> jcorgan: whitespace changes on lines you're touching anyway are fine; but as maaku says, it should not introduce useless diffs
391 2015-09-29 18:00:56 <jcorgan> got it
392 2015-09-29 18:01:08 <wumpus> (although in documents it's much less serious than in code)
393 2015-09-29 18:07:39 <jgarzik> +1
394 2015-09-29 18:12:15 <CodeShark_> We're already getting pushback for the "no philosophy nor politics in the bitcoin-dev mailing list" - this will not work until we've created a functioning bitcoin political philosophy list and can have more of a "we think you'll find more relevant discussion there" attitude rather than a "we don't want you here" attitude
395 2015-09-29 18:13:13 <jgarzik> CodeShark_, don't be overly sensitive.  push back is inevitable.  the list needs to be productive for productive contributors.
396 2015-09-29 18:13:17 <wumpus> someone else could also create a bitcoin political philosophy list, why would 'we' (whoever that is) have to do everything
397 2015-09-29 18:14:02 <jgarzik> CodeShark_, the two-step plan is sound
398 2015-09-29 18:14:11 <wumpus> what matters for us is a useable development list
399 2015-09-29 18:14:29 <stonecoldpat> i heard there was a bitcoin mailing list that exists already?
400 2015-09-29 18:14:37 <kanzure> jgarzik: fwiw i think your summary of the preivous conversations was less good than your usual summaries. you missed a lot!
401 2015-09-29 18:15:28 <kanzure> CodeShark_: yes i think that's a reasonable approach, but also one quick way around that is to nominate recent threads for inclusion for pre-seeding (or re-play)
402 2015-09-29 18:15:33 <CodeShark_> I've already offered to help create this list, wumpus
403 2015-09-29 18:15:36 <jgarzik> kanzure, That should motivate you to reply with a better summary!  :)
404 2015-09-29 18:16:16 <CodeShark_> Moreover, warren had requested bitcoin-discuss from linuxfoundation
405 2015-09-29 18:17:16 <kanzure> jgarzik: hardly; i think you could do better by just linking to the recent conversations in the irc logs instead.
406 2015-09-29 18:17:55 <jgarzik> kanzure, burden of searching is too high.  they are poorly organized and annoying to link to
407 2015-09-29 18:18:56 <CodeShark_> jgarzik: it's not about being overly sensitive - it's about keeping everyone happy as best we can so that we can all continue doing what we like to do
408 2015-09-29 18:18:56 <kanzure> what would make that easier for you/others?
409 2015-09-29 18:19:55 <jgarzik> CodeShark_, That is the goal.  But like perfection it is unattainable, only approached.  My point was that there will always be complaints from somebody; those complaints need to be weighted.
410 2015-09-29 18:20:36 <CodeShark_> moreover, I think bitcoin political philosophy deserves to be discussed...and I think we can accomplish two objectives here
411 2015-09-29 18:21:03 <kanzure> not sure if linuxfoundation will want to host a mailing list that essentially amounts to cypherpunks- but great if they're okay with that
412 2015-09-29 18:21:05 <jgarzik> "already getting pushback" is therefore a bit over-stated.  There was one complaint from a non contributor, assuming you exclude hearn's not-really-related reply.
413 2015-09-29 18:21:26 <hearn> how was it not related
414 2015-09-29 18:22:23 <jgarzik> hearn, conflates Bitcoin Core and list admin & policy, and mistakenly paints Wladimir as a leader rather than a collator-of-already-ACKd-PRs
415 2015-09-29 18:22:31 <hearn> i don't even see the issue,really. looking at the recent threads they all appear to be related to proposed protocol changes, libbitcoinconsensus, meetings, BIPs, etc
416 2015-09-29 18:23:07 <hearn> jgarzik: see the issue? i replied pointing out an alternative solution to the problem you see and you already consider my reply to be somewhat offtopic?
417 2015-09-29 18:23:34 <CodeShark_> it comes down to tact :)
418 2015-09-29 18:24:00 <jgarzik> Anybody, even a bot, could execute the Bitcoin Core leadership model.  if (have_ACKS) merge else dont.   Disagreeing with that philosophy is fine...   But it is incorrect to paint or try and saddle Wladimir with "leader of Bitcoin Core" mantle, and then blame Wladimir for some perceived lack of action.
419 2015-09-29 18:24:17 <morcos> Thank you jgarzik
420 2015-09-29 18:24:22 <hearn> jgarzik: that's clearly not the case, and you know it. otherwise BIP101 would be merged already. i'd ack it, gavin would ack it, a few others would - done
421 2015-09-29 18:24:23 <jgarzik> I did one of the Bitcoin Core releases
422 2015-09-29 18:24:52 <kanzure> jgarzik: wladimir has on a number of occassions taken action by not merging something, but this can be perceived as inaction in some cases
423 2015-09-29 18:24:56 <jgarzik> Wladimir is release manager and - god bless him - the main person that manages the morass of github PRs - doing our collective jobs for us
424 2015-09-29 18:25:03 <morcos> hearn are you really unable to translate "(have)
425 2015-09-29 18:25:09 <jgarzik> IMO Wladimir does too much PR'ing and the rest should pitch in
426 2015-09-29 18:25:14 <jgarzik> and free him for real coding
427 2015-09-29 18:25:24 <wumpus> right, list policy has nothing to do with bitcoin core's codebase. Even if I felt like it, I don't have the time to get involved with moderation there.
428 2015-09-29 18:25:38 <morcos> sorry..  "(have_ACKS)" as short hand for "have ACKS and no significant NACKS"
429 2015-09-29 18:25:39 <CodeShark_> of the core committers, I'd say Wladimir is the least political
430 2015-09-29 18:25:45 <maaku> kanzure: I believe warren got some pushback from LF regarding the mailing list split. not sure the details of that though
431 2015-09-29 18:25:59 <hearn> morcos: that's not what jeff just said. with such a rule you suddenly need a definition of "significant" and the job cannot be done by a bot
432 2015-09-29 18:26:03 <hearn> i mean come on. this is absurd.
433 2015-09-29 18:26:08 <wumpus> "has ACKs and doesn't have the entire community in a fight"
434 2015-09-29 18:26:10 <jgarzik> hearn, I understand -- and even agree in some cases -- how inaction translate into a decision or action.
435 2015-09-29 18:26:11 <kanzure> maaku: i still think "direct all the excess mailing list traffic to cypherpunks" is a good plan, heh
436 2015-09-29 18:26:14 <jgarzik> hearn, that has problems
437 2015-09-29 18:26:15 <hearn> maintainership is not automatable. technical management is a skill
438 2015-09-29 18:26:19 <jgarzik> and deserves criticism
439 2015-09-29 18:26:27 <jgarzik> nonetheless, it's not wladimir's fault or responsibility
440 2015-09-29 18:27:07 <hearn> i'm sorry but you cannot have a situation where there is only one implementation, where that implementation has one guy making the decisions, and then expect people to not engage in argument and debate about decisions being made or not made
441 2015-09-29 18:27:30 <jgarzik> hearn, sure
442 2015-09-29 18:27:34 <maaku> hearn: wumpus does not make all the decisions here
443 2015-09-29 18:27:35 <hearn> look at how many block size threads there are. obviously a lot of people believe (rightly or wrongly) that by engaging in discussion they can affect the outcome
444 2015-09-29 18:27:36 <CodeShark_> see why we need a bitcoin political philosophy forum?
445 2015-09-29 18:27:37 <jgarzik> hearn, and that has nothing to do with list admin
446 2015-09-29 18:27:38 <wumpus> anyhow, please get a room for the meta-level discussion, it is off-topic here. This channel is about bitcoin core development and nothing more.
447 2015-09-29 18:27:49 <hearn> if this is not wanted, he can end these threads by saying "I have made a decision, it isn't going to change, further discussion is pointless"
448 2015-09-29 18:28:02 <hearn> people would take the hint
449 2015-09-29 18:28:12 <maaku> hearn: that wouldn't end the discussion
450 2015-09-29 18:28:18 <hearn> it would move it elsewhere
451 2015-09-29 18:28:20 <jgarzik> hearn, list admins were going to be me, btcdrak, and a couple others, don't recall who.  the idea is __not__ the same set of bitcoin.git commiters but mix it up.
452 2015-09-29 18:28:32 <CodeShark_> There are many unresolved issues that are not technical...and until they are resolved we'll continue suffering incursions
453 2015-09-29 18:28:32 <maaku> hearn: yeah, it would eject wumpus as lead developer
454 2015-09-29 18:28:59 <hearn> maaku: what would?
455 2015-09-29 18:29:10 <jgarzik> sipa is lead developer :)
456 2015-09-29 18:29:13 <wumpus> then take the hint, and take this away from here
457 2015-09-29 18:29:16 <jgarzik> wumpus is lead merger :)
458 2015-09-29 18:29:17 <maaku> hearn: him throwing his weight around and deciding controversial issues
459 2015-09-29 18:30:54 <jgarzik> wumpus, oh good grief, don't escalate dude
460 2015-09-29 18:30:58 <CodeShark_> boo
461 2015-09-29 18:31:00 <jgarzik> wumpus, just when things had quieted down
462 2015-09-29 18:31:10 <jgarzik> wumpus, Please remove ban.
463 2015-09-29 18:31:17 <wumpus> and stop this personal talk about me.
464 2015-09-29 18:31:31 <jgarzik> wumpus, unavoidable
465 2015-09-29 18:31:41 <CodeShark_> Please remove ban, wumpus
466 2015-09-29 18:35:38 <zooko> sigh
467 2015-09-29 18:37:48 <wumpus> he's welcome back if he just starts talking about development, instead of questioning the project all the time
468 2015-09-29 18:48:10 <jcorgan> well, if his goal was to disrupt the normal goings on in here and bring things to a halt, he succeeded :-(
469 2015-09-29 18:55:32 <kanzure> /win 3
470 2015-09-29 18:55:35 <kanzure> whoops. irc fail.
471 2015-09-29 19:32:08 <jcorgan> so, of course, everyone knows that development conversations don't stop, they just move elsewhere more conducive it to it.  so we've now seen both forums used by the core devs overrun by political bullshit.  i wouldn't be surprised if they went off and formed their own secret area just to get back to work :(
472 2015-09-29 19:34:37 <jcorgan> congratulations, hearn, you've won twice now.
473 2015-09-29 19:34:47 <kgreenek> join #Juce
474 2015-09-29 19:34:55 <kgreenek> oops
475 2015-09-29 22:19:25 <warren> Heard back from LF, they were just super busy, I have a short call with them to clarify some details soon.
476 2015-09-29 22:20:02 <jgarzik> +1
477 2015-09-29 22:20:08 <btcdrak> +1 warren
478 2015-09-29 23:20:40 <evoskuil> I recall seeing discussion of public key wallet import formats. Can someone pls direct me to what if anything has been done?
479 2015-09-29 23:31:34 <maaku> jgarzik: Can I badger you into reviewing #6312?
480 2015-09-29 23:43:14 <jgarzik> maaku, Yes, I do need to review BIP-68: Mempool-only sequence number constraint verification #6312
481 2015-09-29 23:43:43 <jgarzik> maaku, in general I'm loosely in favor, but feel the need to understand the use cases and historical behavior before diving into the code itself
482 2015-09-29 23:44:02 <jgarzik> maaku, My projects use sequence numbers actively & differently, soo....