TL;DR - Hearn banned because Wumpus didn't like Hearn questioning development practices..
Decide for yourself if he deserved it or not.
Transcript for ##bitcoin-dev 2015/09/29
01:40 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?
01:41 sipa if it was sent by yourself, it is counted
01:41 sipa because it trusts itself
01:41 skyzer But it wasn't... It is sent by random people
01:42 sipa then by default it won't be counted
01:42 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.
01:42 sipa there is a minconf parameter to some RPC calls that you can set to 0
01:43 skyzer Version currently is 0.10.2. I will check the minconf parameters thanks
01:49 CodeShark_ I see the versionbits BIP has been merged
01:50 CodeShark_ I'm hoping to have an implementation ready tomorrow
01:51 CodeShark_ Will that be added to the BIP doc? Or what's the general procedure?
01:56 sipa CodeShark_: you can PR a change to add a link to the implementatiom
01:58 kanzure you?
01:58 kanzure whoops
01:58 kanzure irc failure.
02:03 sipa 2nd person singular pronoun, english
02:08 CodeShark_ Nominative and accusative
02:09 CodeShark_ (Pronouns are the only words that still have declensions in English)
02:12 CodeShark_ It also used to be the formal form, the informal being thee
02:16 sipa and thou
02:16 sipa no?
02:17 CodeShark_ Thou was nominative, thee accusative, thy genitive (I think)
02:17 sipa i believe that's correct
02:22 maaku sipa: ping for review of #6312 -- just pushed a fix for what we talked about
02:22 maaku also get some sleep!
02:23 sipa cool, will review later
02:23 sipa i fail to sleep
03:43 CodeShark anyone here (besides sipa) intimately familiar with how the block index DB works?
08:35 wumpus well I know a thing or two about it
08:35 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()?
08:37 CodeShark_ err, I mean starting with the bits 001
08:39 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.
08:43 CodeShark Right, wummpus - it doesn't seem specified
08:43 CodeShark *wumpus
08:44 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
08:45 CodeShark using IsSuperMajority allows us to at least measure acknowledgement of version bits in miners
08:45 CodeShark but all clients should be upgraded as well
08:50 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#L266408:51 CodeShark so is it safe to just suddenly go from nVersion == 0x3 to nVersion == 0x20000000 ?
08:51 CodeShark surely at least we should define a transition height
08:52 sipa CodeShark: versionbits has no deployment; it's just a mechanism other softforks can use to deploy
08:52 sipa CodeShark: or do you feel there is a use for formally deploying it?
08:52 CodeShark yes, but implementations need to be aware of it to handle things appropriately
08:53 sipa how so?
08:53 CodeShark if someone were to mine a block right now with version 0x20000000 would most nodes accept it as valid?
08:53 sipa of course
08:53 sipa it has to be
08:53 sipa otherwise we couldn't do versionbits as a softfork!
08:54 sipa not most nodes
08:54 sipa *all* nodes
08:54 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?
08:55 CodeShark there needs to be a cutoff point
08:55 sipa why not?
08:55 CodeShark so how shall that cutoff point be determined?
08:55 sipa maybe we want to back out of versionbits at some point
08:56 CodeShark I thought "backing out" meant going to 010
08:57 sipa i think anything not starting with 001 should be treated as having versionbits all zeroes
08:57 CodeShark so once a change is locked in, that would make such versions invalid, no?
08:58 sipa CodeShark: one exicit goal of versionbits was not permanently losing nVersion value space
08:58 sipa so no, no rule that forces 001 or higher
08:58 sipa or we're throwing away 12.5% of the space
08:59 CodeShark ok
08:59 sipa sure, during the deployment of a particular softfork there may be a need to have versionbitsed blocks
08:59 sipa but after the deadline passed, we could in theory go back again
09:00 CodeShark hmm, according to the current spec, once a soft fork is locked in, miners should stop setting the bit
09:00 sipa hmm, i wonder whether first bits 010 or 011 should be treated as versionbits infinity
09:01 sipa otherwise we effectively can't ever uograde as long as there are non-deployed versions
09:01 sipa CodeShark: i think we should discuss this thursday in the meeting
09:01 CodeShark the spec isn't entirely clear on whether miners *should* stop setting the bit or miners *must* stop setting the bit
09:01 sipa this is a part of the design that is insufficiently thought out, i must admit
09:02 sipa CodeShark: if they don't, the warning mechanism will trigger
09:03 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
09:03 CodeShark then once activated, we reset the bit
09:04 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
09:05 CodeShark no?
09:05 CodeShark I think the spec should actually start with a set of parameters that define a soft fork deployment
09:06 sipa CodeShark: why require setting the bit?
09:07 sipa if you do that, the fork effectively happens the moment that requirement occurs
09:07 sipa because everyone not setting it will be forked off
09:07 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
09:08 CodeShark so after activation we should still enforce some check to ensure miners are acknowledging it
09:08 sipa i don't understand
09:09 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
09:09 sipa there is something to say about that
09:10 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)
09:11 sipa sometimes, i guess you want them to be immediateoy aware
09:12 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
09:13 CodeShark of course, miners that simply fail to impose the rule are likely to have their blocks ignored by others
09:13 CodeShark so they'll start to wonder sooner or later, I suppose
09:13 CodeShark I'm actually more concerned about clients
09:14 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
09:15 CodeShark however, I still think it would be a good idea to require miners to explicitly acknowledge the change
09:16 CodeShark deployment of clients is something we simply cannot measure, currently
09:16 CodeShark I guess we can sort of measure it...assuming nobody is deliberately trying to cheat
09:21 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
09:22 CodeShark we really need to consider the entire process...not just the activation/failure mechanism
09:22 sipa deciding consensus rules is inherently not decentralized
09:22 CodeShark indeed...but I think we need a more formal process
09:22 sipa this is just to safely trigger them
09:23 sipa it's called BIPs, and them being implemented
09:23 sipa please just stick to the technical oroblem, that'a already hard enough
09:23 CodeShark the technical problems are actually the easy part
09:24 sipa CodeShark: i guess whatbwe coukd say is that miners SHOULD keep setting the version bit between lockin and activation
09:24 sipa and that the first block with the rule activated MUST set the bit
09:24 sipa that will immiediately fork off all miners who are nkt aware
09:24 CodeShark right
09:25 sipa and then after that, SHOULD NOT set the bit anymore
09:25 CodeShark that seems to make more sense than the current spec
09:26 CodeShark another issue the spec should probably make more concrete is minimum height or timestamp before a soft fork proposal is live
09:27 sipa there is the option of keeping the inbetween bits SHOULD NOT
09:27 sipa keeping them set has the disadvantage of possibly missing testing
09:27 sipa things may look like they work, but they're actually triggering on the wrong set bits
09:28 sipa i like the "only set as many bits as needed" approach
09:28 CodeShark not sure I follow
09:28 sipa someone may implement versionbits incorrectly in software
09:29 sipa but it is likely it will keep working if miners keep setting the bits after lockin
09:29 sipa it's a minor point
09:29 CodeShark hmm...to fully address all these things we might need two bits per soft fork
09:29 sipa the point in favor is of course that do setting it gives free monitoring of further deployment past 95%
09:30 CodeShark we max out at 14 parallel soft forks...but we can then fully detect each transition
09:31 sipa i'm not following
09:31 sipa why do we need 2 bits?
09:32 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
09:33 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 ?
09:33 CodeShark Belxjander: each soft fork can activate independently, no?
09:34 CodeShark I suppose we could also add support for multistage stuff
09:34 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 ?
09:34 CodeShark but the 2 bits cannot identify which soft fork is in progress
09:35 CodeShark unless each soft fork has its own 2 bits
09:35 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" ?
09:36 CodeShark point is for each soft fork to be able to signal independently of each transition we need two bits for each
09:36 CodeShark i.e. SF1 might be locking in while SF2 is activating
09:36 CodeShark on the same block
09:36 Belxjander ahhh
09:37 CodeShark multistage soft forks might afford a single signal bit
09:37 CodeShark for all the stages
09:37 Belxjander basically counting the stages
09:38 Belxjander and putting a group of soft-fork counters side-by-side bitwise ?
09:38 CodeShark possibly...or perhaps simply reusing the bit immediately for the next stage
09:38 sipa CodeShark: there is no point in a 'voting against', it is not a vote, it is a trigger mechanism
09:39 CodeShark sipa: right, I guess more accurately one could call it "hoping for it to timeout"
09:39 Belxjander sipa so all "soft-fork" material only needs to identify which soft-forks are changing?
09:39 sipa Belxjander: i don't follow; have you read bip9m
09:39 sipa bip 9?
09:41 Belxjander sorry...wandered in half dead after a long day...so my memory of whether I have or not is pretty shot...
09:41 CodeShark so sipa, the question is whether it's worth using up two bits per soft fork for better signaling
09:42 CodeShark so we can represent each state unambiguously
09:43 sipa CodeShark: i still don't see the point
09:43 CodeShark it would force miners to acknowledge lock-in and activation unambiguously
09:44 CodeShark making it less likely that a buggy implementation continues to signal incorrectly
09:44 sipa meh
09:45 CodeShark my biggest concern, actually, is miners "acknowledging" a rule change but then not enforcing it
09:45 sipa how will you prevent that?
09:46 sipa "once locked in, you must do 10" -> that is a fork on itself
09:46 CodeShark yes, but it doesn't affect transactions
09:47 CodeShark its sole purpose is to sample miners
09:47 sipa if that already forks, why do we have a time between lockin and activation?
09:47 sipa the 5% are already gone after that point
09:47 sipa or yiu mean that second bit is purely informational?
09:47 CodeShark yes
09:48 sipa what is the effect of not setting it?
09:48 CodeShark by "informational" are you suggesting miners not be required to set it?
09:48 CodeShark if that's the case then I'm not sure I mean that
09:48 sipa if it is required, you are already forking, and there is no need to wait for the next 2016 muktiple etc
09:48 sipa if it is not required, it is informational
09:49 sipa and it has no effect on consensus
09:49 CodeShark but the lock-in phase doesn't require enforcement of the rule, correct?
09:49 sipa indeed
09:49 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
09:50 sipa and to make the trigger time more predictable
09:50 sipa if you fork at the moment 95% is crossed, you are removing that entirely
09:50 CodeShark ok, I see your point
09:50 sipa and the lockin time becomes dead weight
09:51 CodeShark well...
09:51 CodeShark consider that during lock-in it is still optional to either do 00 or 10
09:51 CodeShark then once activation is reached, one block must have 11
09:51 CodeShark then back to 00
09:51 sipa you can do that with 1 bit
09:52 CodeShark yes, but it doesn't explicitly measure whether miners are aware it's locked in or not
09:52 sipa just require the vereion bit to be set to 1 in the first block that has the rule activated
09:52 sipa so your second bit is purely informational
09:52 CodeShark I'm not too concerned about that, I suppos
09:52 CodeShark yeah, in this example it would be
09:52 sipa there is no point in that, i think
09:53 sipa there is no reason why miners would not incorrectly set that bit if they are already incorrectly setting the other
09:53 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
09:53 sipa yes, and you can't measure that in a softfork
09:54 sipa in a hardfork you can require the forking block to be explicitly incompatible with the old rules
09:55 CodeShark with BIP66, imagine what would have happened if miners would have been able to continue mining version 2 blocks after the rule change...
09:56 sipa yes, that's why i think forcing a fork is good
09:56 CodeShark there were two things at play - 1) whether miners were enforcing the version rule, 2) whether miners were enforcing BIP66
09:56 sipa oh
09:57 sipa you can't force a fork
09:57 sipa i was wrong
09:57 sipa not in any useful way
09:57 CodeShark so then this boils down to a problem of miner incentives
09:57 sipa only informationally
09:58 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)
10:00 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
10:00 sipa we could say something like it is suggestes to keep setting the bit for one 2016-window period activation
10:01 sipa or even musr
10:01 sipa must
10:01 CodeShark right...so then in that case, we add one more state for that 2016 activation window
10:02 CodeShark DEFINED, LOCKED_IN, ACTIVATED, FINAL
10:02 CodeShark or something like that
10:02 CodeShark FINAL means the bits should no longer be set
10:02 CodeShark or *must* no longer be set, rather
10:03 CodeShark setting the bit is still optional during the LOCKED_IN state
10:03 CodeShark it's manditory during the ACTIVATED state
10:03 CodeShark and it's prohibited during the FINAL state
10:04 CodeShark or rather, after the FINAL state, the bit is completely free to reuse
10:05 CodeShark if it's set at that point, there must be another defined soft fork that uses it
10:05 sipa indeed
10:05 sipa we should discuss with rusty and petertodd and greg and #bitcoin-dev
10:10 CodeShark sipa, couldn't we get rid of the pindexPrev parameter in ContextualCheckBlockHeader and ContextualCheckBlock by just setting the member in block?
10:10 CodeShark
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L266410:10 CodeShark passing it as a separate parameter seems really ugly
10:12 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)
10:12 sipa CodeShark: however!
10:12 sipa a CCheckedBlock wrapper would be neat
10:12 sipa which could have a known pindex pointer
10:12 sipa which would be local to validation code
10:13 CodeShark so struct CCheckedBlock { CBlockIndex* pindex; CBlockIndex* pindexPrev; }; ?
10:14 sipa yes, but please don't do that in the versionbits code
10:14 sipa as that will likely need to be easily backportable to other versions
10:14 CodeShark well, of course - I'm doing my best to alter main as little as possible
10:14 sipa which makes it hard to depend on refactors
10:15 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
10:16 sipa CodeShark: i mean struct CheckBlock { CBlock block; CBlockIndex *pindex; }
10:16 sipa no need for pindexPrev, you can use pindex->pprev
10:17 CodeShark I suppose I could define a struct for my functions that gets set inside of the ContextualCheck functions
10:17 sipa CodeShark: your code shouldn't ever need CBlock... it can reason entirely based on the CBlockIndex structure
10:18 CodeShark it isn't using CBlock
10:18 sipa so?
10:18 sipa then where is the technical debt?
10:18 sipa i mean, there certainly is a lot of technical debt
10:18 CodeShark the issue here is IsSuperMajority...which I'm encapsulating within exposed functions IsValidVersion() and UseRule()
10:19 CodeShark I'd like to just pass the CBlockIndex object to both of these
10:19 sipa so, why can't you?
10:19 CodeShark but I need to pass through the pindexPrev value to IsSuperMajority
10:20 sipa i don't understand, but i can't look at the code now
10:20 sipa pindexPrev is the CBlockIndex
10:20 sipa (of the previous block)
10:21 CodeShark yes, which could in principle be set in the block structure. block.pprev = pprevIndex;
10:21 CodeShark block is a CBlockIndex reference
10:21 sipa CodeShark: that is always the case
10:21 sipa the pprev pointer is set whenever the CBlockIndex object os created
10:21 sipa *is
10:22 sipa ok, taking off
10:22 CodeShark doesn't seem to be set until AddToBlockIndex
10:22 sipa yes
10:22 CodeShark which gets called after the ContextualCheck functions
10:23 sipa oh, i see
10:23 sipa right, the problem is that there is no CBlockIndex yet for the to-be-added block header
10:23 sipa ok, need to go
10:24 sipa ttyl
10:24 CodeShark right - but couldn't we still set the pprev field after we find the hash of the previous block in our map?
10:24 CodeShark ok, later
12:07 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?
12:07 sipa pl it doesn't
12:08 sipa only the wallet iuses BDB
12:08 sipa all consensus code uses LevelDB
12:08 ploopkazoo ah
12:08 sipa until 0.7, BDB was used for everything
12:15 ploopkazoo oh, that was 2013
12:15 ploopkazoo goddamn
12:19 wumpus configure --disable-wallet will make it compile without bdb dep
12:24 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
12:28 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#L274712:29 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-...
12:30 wumpus (then again, had to, because of the compiler version conflict)
12:35 sipa CodeShark: i think that is safe
12:35 sipa CodeShark: i finally get what you're after, after looking at the code
12:36 CodeShark there's one other place where ContextualCheckBlockHeader is called - TestBlockValidity
12:40 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
12:41 CodeShark if anything, we should have a separate call that checks the index map and assigns the value
12:43 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
12:46 CodeShark then we can get rid of pindexPrev in that entire call stack
12:49 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
12:50 CodeShark we're going to have to clean up main.cpp sooner or later :p
12:50 CodeShark 7 years on and it's still a pig sty :p
12:51 CodeShark perhaps it's best to force the minimal number of changes on it for versionbits - and defer the main cleanup
12:55 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() ?
12:55 CodeShark that's just so weird :p
12:56 CodeShark and the second question is...why was it left that way?
12:56 CodeShark I understand now...it's hard to change without some downstream pushback
12:57 CodeShark but back then?
12:59 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
12:59 moa 2009?
12:59 CodeShark lol
13:00 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
13:01 moa goto 2010
13:01 CodeShark
13:01 wumpus it's really no use complaining in here, you're preaching to the choir
13:01 CodeShark I'm not really complaining - just curious
13:01 CodeShark as I said, I can continue to work around it
13:01 wumpus I heard somewhere that bitcoin core was open source...
13:02 CodeShark yes, which ironically makes it even harder to fix stuff now that everyone has their own fork
13:02 CodeShark that's to say, to fix something and actually have the fix applied across the board
13:02 wumpus excuses, excuses
13:02 CodeShark no, I see it as a challenge
13:03 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
13:03 sipa so yes, you're preaching to the choir
13:04 CodeShark I'm not really preaching - I'm curious how it got that way in the first place
13:04 sipa git log is your friend :p
13:04 wumpus main.cpp and init.cpp have existed for very long, maybe since the beginning
13:05 sipa init.cpp existed when i first looked at the code base at least
13:06 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
13:07 sipa the AppInit functions were for compatibility with wx, i think
13:08 sipa init.cop didn't exist in 0.1.5
13:09 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)
13:09 gavinandresen doc/build-unix.md doesn't mention ZMQ -- what package do I need to install to compile with it?
13:10 sipa wumpus: agree
13:10 sipa gavinandresen: libzmq-dev?
13:10 sipa (that's a guess)
13:10 wumpus yes the release notes and build-XXX need to be updated for zmq
13:11 gavinandresen sipa: that seems to work, thanks!
13:14 CodeShark it's actually quite instructive to look through the history
13:23 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
13:23 CodeShark CMyApp already had an Init and an Init2 method
14:59 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
15:03 CodeShark yeah, seems like those definitions are pretty good
15:10 CodeShark let's say we "shall" refer to RFC 2119
15:21 jcorgan wumpus: i'll get a PR to you today on zmq
15:22 CodeShark this is the basic framework I have so far for the versionbits implementation:
https://github.com/CodeShark/bitcoin/tree/versionbits15:22 wumpus jcorgan: awesome
15:23 CodeShark oops, I accidentally dropped in one of your commits into that with the net thing, wumpus :p
15:27 CodeShark argh...I messed it up even more :p
15:27 wumpus eh that doesn't sound good :p
15:28 CodeShark how do I take out the first commit from a compare?
15:28 CodeShark
https://github.com/bitcoin/bitcoin/compare/master...CodeShark:versionbits15:28 CodeShark why is it using the first commit on there from fanquake?
15:28 CodeShark must have done something strange with rebasing
15:31 CodeShark ok, I reverted back - now it just shows your one liner net.cpp change
15:32 CodeShark how do I make it not show your commit, wumpus?
15:33 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
15:35 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
15:35 wumpus what is your branch based on? current master?
15:36 CodeShark no
15:44 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
15:48 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.
15:48 CodeShark did you apt-get update?
15:49 CodeShark oh, hmm
15:50 gavinandresen CodeShark: still gives me version 2.2.0 after apt-get update....
15:50 wumpus gavinandresen: yea :/ see
https://github.com/bitcoin/bitcoin/issues/673415:51 gavinandresen wumpus: ah, so I have to apt-get install libzmq3-dev ....
15:51 wumpus hopefully there's a package for that
15:51 gavinandresen Latest version if 4.1.3, maybe libzmq3-dev will work..... I hope....
15:52 gavinandresen What version is Travis running? Or how would I tell?
15:52 wumpus depends/packages/zeromq.mk seems 4.0.4
15:52 jcorgan libzmq3-dev is the right one
15:53 jcorgan which is an unfortunate name, as it is the ZMQ 4.x API
15:53 gavinandresen ..... of course it is .......
16:12 kanzure gavinandresen: yep, when i reported the libzmq stuff, libzmq-dev gave me 2.2.0 as well
16:12 kanzure debian experimental has libzmq5 i hear
16:13 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)
16:14 jcorgan sure, working on it now
16:15 jcorgan i think it is the debian package policy for naming to use sequential numbers for changes in ABI
16:32 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
16:32 maaku not sure who to blame, zmq or debian package maintainers
16:35 jcorgan i knew it was something like that
16:59 buZz anyone here able to tell me which github has the bitcoin txindex patchset?
16:59 buZz that lets me see all tx to all addresses
16:59 buZz hmm
17:00 buZz cant seem to find it ;(
17:10 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
17:10 jcorgan what do you prefer?
17:11 buZz i prefer no spaces on empty lines
17:11 buZz but my coworkers dont like that i do
17:12 jcorgan for PR requests (wumpus)?
17:12 maaku jcorgan: minimal diffs
17:13 maaku whitespace can be removed during the refactoring week
17:13 maaku but please don't introduce useless whitespace in your commits
17:13 maaku (wumpus, correct if necessary)
17:13 jcorgan right, that's why i have that feature turned on
17:14 jcorgan but if i edit an existing file (like configure.ac), it cleans that up too
17:15 jcorgan i'd really prefer not to have to disable that when editing bitcoin code
17:28 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
17:47 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.
17:52 deego Is it normal for htop to show "bitcoin -server" N times as N different processes? where N is the number of cpu's?
17:52 TD-Linux yes, htop shows each thread by default
17:52 michagogo deego: yes, that's threads
17:52 deego ah, thanks
17:52 michagogo One of htop's options lets you show them highlighted differently or something to make it more clear
17:53 gavinandresen kanzure: off-topic for here
17:54 deego michagogo: ah, H?
17:54 kanzure oh
17:55 michagogo deego: don't remember
17:59 jcorgan #6736 for zmq update
18:00 wumpus jcorgan: whitespace changes on lines you're touching anyway are fine; but as maaku says, it should not introduce useless diffs
18:00 jcorgan got it
18:01 wumpus (although in documents it's much less serious than in code)
18:07 jgarzik +1
18:12 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
18:13 jgarzik CodeShark_, don't be overly sensitive. push back is inevitable. the list needs to be productive for productive contributors.
18:13 wumpus someone else could also create a bitcoin political philosophy list, why would 'we' (whoever that is) have to do everything
18:14 jgarzik CodeShark_, the two-step plan is sound
18:14 wumpus what matters for us is a useable development list
18:14 stonecoldpat i heard there was a bitcoin mailing list that exists already?
18:14 kanzure jgarzik: fwiw i think your summary of the preivous conversations was less good than your usual summaries. you missed a lot!
18:15 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)
18:15 CodeShark_ I've already offered to help create this list, wumpus
18:15 jgarzik kanzure, That should motivate you to reply with a better summary!
18:16 CodeShark_ Moreover, warren had requested bitcoin-discuss from linuxfoundation
18:17 kanzure jgarzik: hardly; i think you could do better by just linking to the recent conversations in the irc logs instead.
18:17 jgarzik kanzure, burden of searching is too high. they are poorly organized and annoying to link to
18:18 kanzure what would make that easier for you/others?
18:18 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
18:19 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.
18:20 CodeShark_ moreover, I think bitcoin political philosophy deserves to be discussed...and I think we can accomplish two objectives here
18:21 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
18:21 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.
18:21 hearn how was it not related
18:22 jgarzik hearn, conflates Bitcoin Core and list admin & policy, and mistakenly paints Wladimir as a leader rather than a collator-of-already-ACKd-PRs
18:22 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
18:23 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?
18:23 CodeShark_ it comes down to tact
18:24 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.
18:24 morcos Thank you jgarzik
18:24 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
18:24 jgarzik I did one of the Bitcoin Core releases
18:24 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
18:24 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
18:25 morcos hearn are you really unable to translate "(have)
18:25 jgarzik IMO Wladimir does too much PR'ing and the rest should pitch in
18:25 jgarzik and free him for real coding
18:25 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.
18:25 morcos sorry.. "(have_ACKS)" as short hand for "have ACKS and no significant NACKS"
18:25 CodeShark_ of the core committers, I'd say Wladimir is the least political
18:25 maaku kanzure: I believe warren got some pushback from LF regarding the mailing list split. not sure the details of that though
18:25 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
18:26 hearn i mean come on. this is absurd.
18:26 wumpus "has ACKs and doesn't have the entire community in a fight"
18:26 jgarzik hearn, I understand -- and even agree in some cases -- how inaction translate into a decision or action.
18:26 kanzure maaku: i still think "direct all the excess mailing list traffic to cypherpunks" is a good plan, heh
18:26 jgarzik hearn, that has problems
18:26 hearn maintainership is not automatable. technical management is a skill
18:26 jgarzik and deserves criticism
18:26 jgarzik nonetheless, it's not wladimir's fault or responsibility
18:27 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
18:27 jgarzik hearn, sure
18:27 maaku hearn: wumpus does not make all the decisions here
18:27 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
18:27 CodeShark_ see why we need a bitcoin political philosophy forum?
18:27 jgarzik hearn, and that has nothing to do with list admin
18:27 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.
18:27 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"
18:28 hearn people would take the hint
18:28 maaku hearn: that wouldn't end the discussion
18:28 hearn it would move it elsewhere
18:28 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.
18:28 CodeShark_ There are many unresolved issues that are not technical...and until they are resolved we'll continue suffering incursions
18:28 maaku hearn: yeah, it would eject wumpus as lead developer
18:28 hearn maaku: what would?
18:29 jgarzik sipa is lead developer
18:29 wumpus then take the hint, and take this away from here
18:29 jgarzik wumpus is lead merger
18:29 maaku hearn: him throwing his weight around and deciding controversial issues
18:30 jgarzik wumpus, oh good grief, don't escalate dude
18:30 CodeShark_ boo
18:31 jgarzik wumpus, just when things had quieted down
18:31 jgarzik wumpus, Please remove ban.
18:31 wumpus and stop this personal talk about me.
18:31 jgarzik wumpus, unavoidable
18:31 CodeShark_ Please remove ban, wumpus
18:35 zooko sigh
18:37 wumpus he's welcome back if he just starts talking about development, instead of questioning the project all the time
18:48 jcorgan well, if his goal was to disrupt the normal goings on in here and bring things to a halt, he succeeded :-(
18:55 kanzure /win 3
18:55 kanzure whoops. irc fail.
19:32 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
19:34 jcorgan congratulations, hearn, you've won twice now.
19:34 kgreenek join #Juce
19:34 kgreenek oops
22:19 warren Heard back from LF, they were just super busy, I have a short call with them to clarify some details soon.
22:20 jgarzik +1
22:20 btcdrak +1 warren
23:20 evoskuil I recall seeing discussion of public key wallet import formats. Can someone pls direct me to what if anything has been done?
23:31 maaku jgarzik: Can I badger you into reviewing #6312?
23:43 jgarzik maaku, Yes, I do need to review BIP-68: Mempool-only sequence number constraint verification #6312
23: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
23:44 jgarzik maaku, My projects use sequence numbers actively & differently, soo....
