Bitcoin Forum

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#L2664
08: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#L2664
10: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#L2747
12: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/versionbits
15: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:versionbits
15: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/6734
15: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....

This is just a wall of text, too long to read at the moment. Can you post a tl;dr for why he was banned? Did he deserve it?

11:17:13 [freenode] -!- hearn [~mike@84-75-195-4.dclient.hispeed.ch]

He isn't banned, at least not on that host.

He isn't banned, at least not on that host.

Perhaps ban was lifted?

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! Smiley
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 Smiley
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 Smiley
18:29   wumpus   then take the hint, and take this away from here
18:29   jgarzik   wumpus is lead merger Smiley
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 :-(

"bitcoin political philosophy list"  :)  yes it is highly desired even here

This is a shameful display of censorship and close mindedness of the Core developers. This just further proves that we need alternative implementations of Bitcoin so that important discussions and issues are not just censored and ignored.

To quote Mike Hearn from this discussion: “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.”

I agree with Mike Hearn on this point and he should not have been banned for saying this. It is completely unjustified and undeserved to ban him for saying this. Having one person deciding on changes within Bitcoin and having five more people with veto power over the development is an untenable position for Bitcoin especially if we want Bitcoin to be truly decentralized. Multiple competing implementations of Bitcoin is the solution to the political problems we are currently experiencing.

deserved.

This is a shameful display of censorship and close mindedness of the Core developers. This just further proves that we need alternative implementations of Bitcoin so that important discussions and issues are not just censored and ignored.

To quote Mike Hearn from this discussion: “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.”

I agree with Mike Hearn on this point and he should not have been banned for saying this. It is completely unjustified and undeserved to ban him for saying this. Having one person deciding on changes within Bitcoin and having five more people with veto power over the development is an untenable position for Bitcoin especially if we want Bitcoin to be truly decentralized. Multiple competing implementations of Bitcoin is the solution to the political problems we are currently experiencing.

Total nonsense, his ideas and intended direction for Bitcoin have been thoroughly rejected by the other developers, the miners and the userbase. For good reasons. Mike is at fault, he continues to attempt to beat this dead horse that no-one is interested in. Deliberately anti-social stuff, and no doubt intended to set the scene for shills like yourself to distort reality, for the umpteenth time. No-one's falling for it, for the umpteenth time.

LOL, months later, you are still spewing this crap all over my screen.

He was banned (and likely temporarily) because, as usual, he is polluting the technical forum with his inane, political badgering. Wasting everyone's time and energy, constantly pushing ideas that no devs want a part of and endlessly crying that the reason for this is the governance structure -- it's not. It's because he is a cancer, and his ideas and code are horrible. The vast majority of miners, users, devs understand this; that you apparently do not is of little concern to anyone.

Go ahead and run your alternative implementation. Go ahead and fork off another. No one is stopping anyone from forking the code. Understand that the vast majority of miners, users and devs will not touch or run shoddy code backed by horrible ideas. That is just a practical reality. It has nothing to do with this perceived "censorship" or "OMG there is only one implementation". It's simple: produce an alternative client that is worth running and developing and people will do so. XT was not that. At all. Give it up.

Just saying that his arguments have no merit because he is a cancer is not a valid argument. It is actually a problem that the developers do not want to defend themselves on political grounds. Since having one person in charge with five other people with veto power over the development of Bitcoin when there is only one main implementation is tantamount to centralization of power and is indefensible in terms of decentralization. I am glad that you can agree with me that we need more implementations of Bitcoin, so far we only have one alternative implementation to Bitcoin Core so to support that because we disagree with Core is most definitely defensible. We should all be united in our opposition of what is happening in Core and we need to realize the danger and problems that this presents.

Just saying that his arguments have no merit because he is a cancer is not a valid argument. It is actually a problem that the developers do not want to defend themselves on political grounds. Since having one person in charge with five other people with veto power over the development of Bitcoin when there is only one main implementation is tantamount to centralization of power and is indefensible in terms of decentralization. I am glad that you can agree with me that we need more implementations of Bitcoin, so far we only have one alternative implementation to Bitcoin Core so to support that because we disagree with Core is most definitely defensible. We should all be united in our opposition of what is happening in Core and we need to realize the danger and problems that this presents.

Devs have been saying for a long damn time that Hearn's role in Core development has been as a "cancer" that saps everyone's energy and constantly delays day-to-day work from being done. At some point, they will have gotten fed up. (Shrug)

Bitcoin is open source, Mike. Go fork off if you're unhappy, and if no one runs your shoddy code, you can fade off into irrelevance. (Oh, you've already begun that process ;))

Proof of those devs?

I maintain that you should apologize to those who traverse this list.
 What you are saying is digging yourself a deeper hole and is not
merely embarrassing but is crossing a threshold in which you have used
words, albeit subtly, to attack a community.

If you refuse to apologize, I get it.  You have not apologized thus
far, and pressing for an apology is unlikely to get an (authentic)
one.  But then, you should voluntarily step back and let others do the
hard work of coming to the consensus that you seem to think is
impossible to accomplish based on how bitcoin is run.

I believe this matter will be resolved, but not with the "help" of
those who make threatening statements (and who are unable to apologize
for having made them).

> On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
>
> > Core is in the weird position where there's no decision making ability at
> > all, because anyone who shows up and shouts enough can generate
> > 'controversy', then Wladimir sees there is disagreement and won't touch the
> > issue in question. So it just runs and runs and *anyone* with commit access
> > can then block any change.

And allegations that the project is "run like wikipedia" or "an edit war" are verifyably untrue.
Check the commit history.
How many reverts do you see? How many of those do you see that are not simply to get rid of unexpected bugs, to be re-merged later?

Not much more than two, in ~5500 commit over six years. I feel sorry for you that `getutxos` was rejected in a messy way, still you are so held up about it and keep repeating it as if it is a daily occurence. Disingenuous, at the least.

Wladimir

I doubt that other bitcoin software maintainers would agree with that sort
of toxic reasoning; contentious hard-forks are basically a weapon of war
that you can use against any other collaborator on any bitcoin project. Why
would anyone want to collaborate on such a hostile project? How would they
even trust each other?

I suppose the word Wladimir used here was "toxic" -- not "cancer." :P

There is plenty more discussion of his antics over time, but I can't be bothered to read through endless badly-organized threads to link to them.

https://i.imgur.com/xywSZXJ.png

http://sourceforge.net/p/bitcoin/mailman/message/34221006/

http://sourceforge.net/p/bitcoin/mailman/message/34219062/

http://sourceforge.net/p/bitcoin/mailman/message/34219655/

His ideas have been widely rejected on technical grounds. His blacklisting/redlisting ideas have also been widely rejected on political grounds. That he is a cancer is not the argument; it's the conclusion. I'm not going to dig through months/years of mailing list discussion because you don't have a grasp of history.

Prove this statement: "Centralization of bitcoin development causes centralization of the bitcoin protocol." Because I only care about the latter. This is a constant red herring. That bitcoin is a decentralized protocol doesn't state anything about its governance structure. The development process has always been centralized, and I don't view that as a problem per se. Please state exactly why it is. If you think the answer is "because BIP101 won't ever be implemented" you would be wrong. Miners' reaction to BIP100 (which was not an implementable code) and the undeniable rejection of miners/users to XT should be enough evidence that it never would have been implemented. It seems that you just want to fight reality as hard as you can.

I'm not united in opposition of "what is happening in Core". Core developers have done incredible work for bitcoin, and I don't see any issues, really. Prove that centralization of development is detrimental. (Do you have any idea how centralized bitcoin development was in 2008-2009?)

The only issue is this false sense of urgency that says we need to increase the block size limit yesterday. Well, blocks don't look full to me, so let's not rush into implementing fixes that lack technical merit. (I have, in the past, stated many reasons why BIP101 lacked technical merit and never received adequate retorts from you on those points. You always return to "governance issues" that don't address the point that we lack an alternative implementation that warrants being run on technical merit.)

Of course, being an "alternative" is not, on its face, a reason to run a client. That's insane.

Here -- I am releasing "Bitcoin 2.0" and raising the total coin supply to 84 million, while quadrupling the current block reward. Want to run my code? It's an alternative implementation! We need alternative implementations!

You realize that's what happened, right? An alternative client was released and it was overwhelmingly rejected on both technical and philosophical grounds? Okay, well let's move on then.

I disagree that BIP101 has been overwhelmingly rejected on both technical and philosophical grounds. It is however irrelevant even if it was, our beliefs should not be based on what the majority believes, it should be based on the result of our own independent reasoning.

That Mike Hearn is a cancer can not possibly be the conclusion of any rational argument.

he's welcome back if he just starts talking about development, instead of questioning the project all the time

If development is centralized then how do we stop the developers from adding centralization to the protocol level?

I would consider development centralization to become an issue if the blocksize is not increased within a reasonable time frame. I think that this has already happened, I would be content with any increase in the blocksize from Core or even just a plan or statement of the intend to increase the blocksize, yet we have not had any of these things come from Core.

I am aware of how centralized development has been during the early days of Bitcoin, however I think as Bitcoin matures development should become more decentralized, this is off political necessity.

Prove this statement: "Centralization of bitcoin development causes centralization of the bitcoin protocol." Because I only care about the latter. This is a constant red herring. That bitcoin is a decentralized protocol doesn't state anything about its governance structure. The development process has always been centralized, and I don't view that as a problem per se. Please state exactly why it is.

We have indeed discussed the merit of BIP101, I felt like you failed to respond to my political arguments which I presume you still do not acknowledge.

I would not support a client that increases the supply of Bitcoin. I would support a client that increases the blocksize, by implementing BIP101. These are two very different things, it is an inaccurate comparison.

I do not think that we should wait before the blocks are full before we do a hard fork to increase the blocksize, doing a hard fork at short notice could cause many problems. If we waited to long to increase the blocksize and there was a spike in adoption transactions could become unreliable and much more expensive, this would not be good for Bitcoin.

I disagree that BIP101 has been overwhelmingly rejected on both technical and philosophical grounds. It is however irrelevant even if it was, our beliefs should not be based on what the majority believes, it should be based on the result of our own independent reasoning.

I do not find any of these quotes to be convincing evidence that there was sufficient grounds for banning Mike Hearn. Considering that these are also all quotes of other people attacking Mike Hearn. It would have been more convincing if you quoted Mike Hearn himself saying something that you think should have been justification for banning him. It does matter what we think of the developers however or even what their beliefs are, it should not be a popularity contest, what matters is what is in the code.

This is a shameful display of censorship and close mindedness of the Core developers. This just further proves that we need alternative implementations of Bitcoin so that important discussions and issues are not just censored and ignored.

To quote Mike Hearn from this discussion: “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.”

I agree with Mike Hearn on this point and he should not have been banned for saying this. It is completely unjustified and undeserved to ban him for saying this. Having one person deciding on changes within Bitcoin and having five more people with veto power over the development is an untenable position for Bitcoin especially if we want Bitcoin to be truly decentralized. Multiple competing implementations of Bitcoin is the solution to the political problems we are currently experiencing.

"Multiple competing implementations of Bitcoin"...
Is this possible, when we need a "vote" of 51% or higher for the network to verify blocks of any particular max size?
(Sorry, if I'm behind on current events)

You completely missed the point. There can be no progress on the code when "every pull [Hearn] touches turns into a cesspool." Bitcoin is a collaborative project. If he refuses to collaborate with the other devs and continues to try to force unpopular opinions in the face of significant criticism, collaboration is impossible. Hence why he forked the code.

Go ahead and continue to ignore other developers' opinions in favor of your own unbacked opinions. But your ignorance of the context of the mailing lists is not compelling.

Here's a few more tidbits on why Hearn has been ostracized:
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvk0ko7
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvjxbb5
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvl1yae
https://www.reddit.com/r/Bitcoin/comments/3n18en/mike_hearn_banned_from_bitcoindev_sept29/cvk1cpx
https://www.reddit.com/r/Bitcoin/comments/3mvq61/scaling_bitcoin_092915/cvj8zf3

None of that means the core devs are right to forestall the block increase, nor does it make their apparent conflict of interest with blockstream any less troubling.  Those very things make any silencing of Hearn suspicious.

An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*.

Matt, I for one do not think that the block size limit should be raised at
this time. Matt Corallo also started the public conversation over this
issue on the mailing list by stating that he was not in favor of acting now
to raise the block size limit. I find it a reasonable position to take that
even if you feel the block size limit should be raised at some time in the
future, there are reasons why now is not the best time to do it.

Please see this post: https://bitcointalk.org/index.php?topic=1197613.msg12576154#msg12576154

If he wants to swallow his pride and learn how to cooperate with other contributors in a collaborative project, that would be another thing. He has merely ostracized himself. That is purely his own doing. Just look at his attitude (https://www.reddit.com/r/Bitcoin/comments/3mvq61/scaling_bitcoin_092915/cvj8zf3). He is excising himself from bitcoin. Not my problem.

Indeed:

Um, by not running such code.

Disagree. Time is irrelevant without technically sound code to run. And Core developers (Adam Back, Jeff Garzik, others) have released several BIPs to address block capacity. You're just fixated on BIP101.

You still neglected to adequately address technical criticisms of BIP101, yet you are here advocating it. Actually, I have responded to your [irrelevant] political arguments (and I am continuing to here, against my better judgment). Feel free to quote such posts, and I will quote my responses.

Not good for bitcoin, eh? I don't think a mass increase in orphaned blocks would be good for bitcoin, either.

Again, time is irrelevant without technically sound code to run.

Further, scaling is not merely limited to the context of block size. Addressing spam is another important issue that must be dealt with. And a hard fork may not be necessary (see Adam Back's proposal from May 2015).

Sounds like a real lonely island. I'll stay on the mainland, but thanks. If a simple majority =/= consensus, a minority isn't gonna do any better.

I haven't seen any compelling arguments as to this supposed conflict-of-interest with Blockstream, to be honest.

Not increasing the blocksize in Core is forestalling and most definitely is a form of inaction. It can only be defined as action once the code is actually implemented. Actions speak louder then words as they say.

PoeEDgar you do realize that we are mostly in agreement, I know that you do not understand or agree with my more pragmatic political position for supporting BIP101, but I suspect that in the long run considering both of our positions we will most likely both end up on the same side of the fork. Try and see the nuance in my position, it is not as unreasonable as you might think. It will still be a long time before January 2016 and I am confident that there will be another alternative implementation that we will both be able to support, whether that be in Core or not, and even if the actual hard fork is scheduled for much later I would still support it, I am a reasonable person.

It's pretty simple.  Blockstream is in the business of off-chain scaling.  Probably both mainchain and offchain scaling is required for Bitcoin.
You can't expect those core devs to be objective.  Because of their business interests, they are going to be slightly to strongly biased
against mainchain scaling, even if that is not in the best interests of the larger community.

I was referring to those quotes in my earlier post, I still do not consider other people saying bad things about Mike Hearn to be evidence of his wrongdoing.

So people should not question the project? More specifically I suppose this relates to questioning the governance of Bitcoin? I would strongly disagree that we should not question the governance of Bitcoin especially considering the problems we are facing and the importance of the questions that need to be answered, who decides is a political question not necessarily a technical one.

I am not as a matter of fact I would support most of the other BIPs, I am somewhat fixated on the need for the code to be implemented however before I can support it in the form of running full nodes or mining. If you think that time is completely irrelevant in relation to increasing the blocksize then you are the one not in touch with reality, time is most definitely relevant to this discussion.

This is the article I wrote on the subject you are welcome to criticize me on the thread that I started:
https://bitcointalk.org/index.php?topic=1164464.0 (https://bitcointalk.org/index.php?topic=1164464.0)

If you would like to continue the discussion we where having last time I believe this is where we left it at last:
https://bitcointalk.org/index.php?topic=1163319.msg12357136#msg12357136 (https://bitcointalk.org/index.php?topic=1163319.msg12357136#msg12357136)

I do not think that increasing the blocksize would lead to a massive increase in orphaned blocks. Since most pools today are already run in high bandwidth data centers which would not be severely effected by increased block propagation times due to an increased blocksize. It would also be unwarranted to think that no increase in the blocksize is technically feasible considering that one megabyte is just an arbitrary number, why not half a megabyte or two megabytes? There is nothing special about the one megabyte blocksize limit it was put there just as a temporary fix after all.

Time is relevant and if we do not have the perfect code by the time does run out then we will just have to choose the lesser of two evils, that is reality.

I can agree with you that scaling should be a meusure of throughput and not just blocksize and that any other means to make throughput more efficient should be implemented, I do not oppose this. However it is impossible to tell the difference between "spam" and legitimate transactions which is why I find most solutions to the "spam problem" problematic, a feature of a permissionless network I suppose.

Not increasing the blocksize in Core is forestalling and most definitely is a form of inaction. It can only be defined as action once the code is actually implemented. Actions speak louder then words as they say.

There is no way to keep the banning enthusiasts on the mainchain. They will be forked off to nirvana.

As far as I am concerned, it is the developers that should be discussing the block size issue. Not every n00b to read some biased article on one side or another.

I agree with this to an extent. But Gavin and Hearn also skipped that discussion by releasing a BIP101-coded client. So there's that.

It's not like they just released it out of nowhere, the discussion has been going on for years. Gavin even posted the question whether or not that approach was a good idea or not back in spring.

It's not like they just released it out of nowhere, the discussion has been going on for years. Gavin even posted the question whether or not that approach was a good idea or not back in spring.

Was then the appropriate response to launch a public appeal to use an alternative client implementing that appraach when everyone else on the Core dev team overwhelmingly rejected it?

Lastly, based on the logs, I really don't like his attitude (though I have nothing against him as a dev, just his attitude based on this IRC log) he seems like he's the type that wouldn't give up the discussion until he wins and everyone agrees with him.

Appealing to the public was the wrong approach. Work it out amongst the developers.

I think that an appeal to the public is the right approach, the Core developers are not and should not be the rulers of Bitcoin.

It is possible as long as the implementations are fully compatible with the Bitcoin protocol. However in the case of a change that is fundamental to the protocol, which makes previous versions incompatible with the new version is a hard fork. Increasing the blocksize will require a hard fork whether it is done by Core or an alternative implementation. Hypothetically it is possible if there was enough disagreement that Bitcoin could split, there would then be two Bitcoins essentially. This should not nesserally be seen as a 51% attack but more as an act of freedom and expression of personal beliefs. This avoids the problem of the tyranny of the majority. Cryptocurreny as a whole will therefore always remain free as long as enough people choose freedom.

I actively entertain the hypothesis that Hearn (and now Andresen to some extent) are associated with the shadowy Conformal entity who has their own clean-slate implementation of the Bitcoin protocol 'btcd'.  For a few months they were pushing pretty hard to have Bitcoin shift over to their implementation with the argument that it is 'better' in some ways (and I personally don't doubt that it is.)  'justusranvier' was most active in pushing it, but he seems to have disappeared from this forum.

If this hypothesis is basically valid then it would make a lot of sense for someone in Hearn's position to try to do as much damage to the 'satoshi-based' protocol support structures as possible on his way out the door.

I actively entertain the hypothesis that Hearn (and now Andresen to some extent) are associated with the shadowy Conformal entity who has their own clean-slate implementation of the Bitcoin protocol 'btcd'.  For a few months they were pushing pretty hard to have Bitcoin shift over to their implementation with the argument that it is 'better' in some ways (and I personally don't doubt that it is.)  'justusranvier' was most active in pushing it, but he seems to have disappeared from this forum.

If this hypothesis is basically valid then it would make a lot of sense for someone in Hearn's position to try to do as much damage to the 'satoshi-based' protocol support structures as possible on his way out the door.

I think the explanation is far easier: Hearn's ego is much greater than his competence. This inevitably leads to rejection of his flawed and dangerous ideas, which in turn induces his ego-compensatory criticism of the entity that rejected his ideas. His ban is well deserved and should persist, because he has proven beyond doubt that he is unwilling to learn.

My hope is that both Hearn and Andresen will vanish entirely from the Core development team, because through their regulatory acquiescence and constant denial of the importance of privacy issues they represent a huge threat to Bitcoin as we know it. Apart from that, BIP101 is by far the worst blocksize-proposal out there, because despite coming from a "lead scientist" it totally lacks scientific scrutiny.

I think the explanation is far easier: Hearn's ego is much greater than his competence. This inevitably leads to rejection of his flawed and dangerous ideas, which in turn induces his ego-compensatory criticism of the entity that rejected his ideas. His ban is well deserved and should persist, because he has proven beyond doubt that he is unwilling to learn.

My hope is that both Hearn and Andresen will vanish entirely from the Core development team, because through their regulatory acquiescence and constant denial of the importance of privacy issues they represent a huge threat to Bitcoin as we know it. Apart from that, BIP101 is by far the worst blocksize-proposal out there, because despite coming from a "lead scientist" it totally lacks scientific scrutiny.

ya.ya.yo!

I think it's a bit premature to write off Gavin as a contributor to Bitcoin. He was the lead maintainer of Bitcoin Core development for a long time, and he has a wealth of skill and

knowledge. He also still has a pair of keys to the vault. {Alert keys}

I would rather have him on the Bitcoin side, as apposed to the competition. {BankCoin / Alt Coin / GovCoin....}  ::)

While I don't agree with their mindless BIPs of raising the blocksize to ridiculous amounts all of a sudden without understand the big consequences in teh severe lack of decentralization that would constitute, I do not condone banning. I haven't seen the entire log tho, so I don't know. Maybe he was straight trolling at some point? or was the admin just having a bad day? who knows.

And like I said, there's nothing wrong with forking the code if Core devs are indeed "compromised." But if the code is not technically sound or is opposed on a philosophical level by most devs, miners and users, it simply won't be adopted. The best chance for a limit increase is to take a much more conservative approach than BIP101, which actually has a chance at reaching consensus. The bolder the scaling regime, the less chance it has. It's as simple as that.

There's this bizarre idea that we have to determine the block size limit (if any) forever, today, partly because people are terrified of the idea of forks down the road. The fact is: of course there will be hard forks in the future. There will be debates about protocol changes in the future that will make this issue pale in comparison. Get used to it, people. I actually believe quite the opposite of most XT supporters on this question -- I think if we conservatively and incrementally increased the limit (to say 2MB) and did not experience serious detriments to security, that it would be unquestionably easier to fork the limit up the second and third times around.

This is how consensus works -- it's messy, painful and takes time, but it's the best damn thing we have. A democracy for bitcoin is the death of bitcoin -- it will simply be co-opted as all governments have been.

Since you are not a Core developer, nor do you read the bitcoin dev list, you would not know. Thus, it sounds like you would not budge regardless of his behavior, or impediment on development. That's not a reasonable position -- it means you give Mike Hearn a free pass no matter what. Ignorance is not an excuse for that.

Of course, people should question everything. I'm a skeptic. But there is a significant difference between that and turning every technical discussion into a political one, and refusing to cede any ground in any argument. At some point, no one will be willing to work with you. That's just a practical reality. Hearn simply cries louder and louder when people reject his ideas, and tries to leverage allegations of character assassination and censorship to rally the user base against those who oppose him. Unfortunately for him, crying might work for babies, but it doesn't work for adults.

You want to change the governance model? Go ahead and propose changes to the BIP model. Do it. And if your ideas are well-reasoned and achievable, you may gain some ground. If not, you can fork the code. That's how this works. Endlessly crying about changing the governance model or the need for alternative implementations will achieve precisely nothing. Take action or don't. Don't complain to me about it. If no one supports your ideas, you're just irrelevant.

Remember, bitcoin already exists, and is chugging along just fine. So until you -- and others that are so disgusted by Core -- come up with alternatives with widespread support, this is a non-issue.

I am not as a matter of fact I would support most of the other BIPs, I am somewhat fixated on the need for the code to be implemented however before I can support it in the form of running full nodes or mining. If you think that time is completely irrelevant in relation to increasing the blocksize then you are the one not in touch with reality, time is most definitely relevant to this discussion.

Why do you constantly ignore everything I say? I said "time is irrelevant without technically sound code to run." Inventing this sense of urgency (yeah, blocks are less than half full, and no, a temporary fee market is not the end of the world) doesn't justify running technically unsound code. Again, feel free to respond to my technical arguments made here:https://bitcointalk.org/index.php?topic=1163319.msg12332549#msg12332549 (https://bitcointalk.org/index.php?topic=1163319.msg12332549#msg12332549)

Produce a workable alternative, and we can talk. Implementing code that a) threatens network security and b) threatens a political civil war that may fracture bitcoin's user base forever, is not a workable alternative. Most people intelligent enough to use bitcoin simply won't fall for that kind of idiocy, no matter how much false urgency you attach to it (and that was made apparent by XT's demise).

Regarding b), you do realize that's what Nick Szabo was getting at re: "civil war," right? Because if the consensus threshold is lowered to an extent that it is a "democratic" decision (majority rules, like 75%), one must have a very elementary understanding of market incentives (and a lack of understanding of game theory) to assume that only one blockchain will survive. Consider that a fork is achieved with 65% of hashing power + a lucky streak. Post-fork, hashing power is split 65-35. Now -- if a miner believes that the Core chain will prevail, then by remaining on the Core chain, he will increase his relative hashing power (and share of mining rewards) by 65%. That is a huge incentive not to cede to the mining majority. Then you have miners who will support one chain or the other purely out of political beliefs. Then you have miners who will do just that, up to a point where economic disincentive (or rather, fear of economic disincentive) becomes too great. Then you have potential attacks (like NotXT) which would make miner support even more opaque leading up to a hard fork. In such a situation, multiple surviving blockchains (and not necessarily just two) is a very real possibility. And if that goes on for long, too much money will have changed hands to ever turn back the clock. Bitcoin will be forever broken into multiple blockchains.

This is the article I wrote on the subject you are welcome to criticize me on the thread that I started:
https://bitcointalk.org/index.php?topic=1164464.0 (https://bitcointalk.org/index.php?topic=1164464.0)

If you would like to continue the discussion we where having last time I believe this is where we left it at last:
https://bitcointalk.org/index.php?topic=1163319.msg12357136#msg12357136 (https://bitcointalk.org/index.php?topic=1163319.msg12357136#msg12357136)

Actually, I'd rather just refute you here. I stopped responding to you in that thread because you repeatedly ignored nearly every argument I made, and continually repeated arguments that I had already addressed. This is the "Mike Hearn" approach. At some point, I'm not going to keep talking to a brick wall. I can't waste my time on that shit.

Regarding "Since most pools today are already run in high bandwidth data centers which would not be severely effected by increased block propagation times due to an increased blocksize" I ask that you provide evidence. I won't accept that at face value. What is your definition of "high bandwidth data center" and you assign this label to what percentage of miners? What proportion of Chinese miners vs. others, and does it matter to you whether Chinese miners are disproportionately affected? (Of course, that point will determine whether you have miner support for any fork ;)) Should the rest of the miners be written off (they should create their own altcoin, as Hearn says)? No increase in orphaned blocks -- at 8MB? 32MB? 1GB? Show me numbers. Show me proof that bandwidth capabilities will keep up with the limit -- hint: you can't. And I highly doubt they will, considering the scaling regime is based on Moore's Law, whose obituary is being written as we speak. We are talking about seconds among multiple peers here. Not minutes. Conservative is the only acceptable approach.

That "you don't think something will happen" isn't an argument. It's quite obvious you are not a developer or engineer. It's pretty well understood from an engineering perspective that conditions at drastically different scales are not similar (thus, not predictable). So much of your understanding of technical issues seems to be little more than "nothing bad can possibly happen." Quite the opposite: the saying goes "everything that can go wrong, will go wrong."

Regarding 1MB -- I'm not arguing for a permanent 1MB limit. But implementing a limit that is unrelated to demand is essentially limitless, and therefore very dangerous. Keep it in line with demand and we can likely simulate the conditions and prevent attack vectors before people lose many millions of dollars over unnecessary recklessness. In the thread I linked above, I laid out one possible attack vector that, with sufficient hashing power, might enable a miner to use spam attacks to increase block size (up to say, 8x or 16x the current limit, whatever the case may be), and subsequently force high-latency miners to SPV mine. With enough hashing power, he could then exploit SPV miners by selfish mining. This is very relevant to the bandwidth capability of Chinese miners.

No, that's a fundamental misunderstanding of consensus. You have it backwards. Time does not run out, and bitcoin remains. Robust as fuck, that bitcoin! The lesser of two evils is the protocol that achieves consensus. Anything less is not bitcoin. So if your alternative doesn't cut the mustard.... sorry. Then the status quo prevails until something better comes along.

Not at all, it's quite simply, really. And it's not a consensus issue, so it's an easy fix. The default Core settings already define outputs < 546 satoshis as spam. Now, it's possible for smaller outputs to be relayed, but only if node operators alter the conf files. In practice, rarely do smaller outputs get relayed. Personally, I don't view the ability to send outputs of fractions of a cent on the main blockchain to be important, and would be quite happy to see such spammers penalized for bloating the chain. As it stands, the cost of their bloat is being socialized among all bitcoin users transacting on the blockchain. We could raise the dust threshold and/or have the default Core settings require additional fees based on dust outputs to disincentivize spam.

Again, this isn't how engineering and software development work..... If you were preparing a new release of a major, acclaimed video game, would you release it as buggy, scarcely-audited code? Or would you do it right? Indeed, actions speak louder than words.

Everything he touches I post becomes a political flame fest and diverges focus of other developers from important technical work.

Which suggests that the public should be consulted about any and all changes to the code, which makes the development team redundant. It's your inability to comprehend such basics of observable reality that make you look like a shill (as well as making the outcome of every post exchange "...and the answer appears to be BIP101.")

Dude has been going around routinely making sly remarks and straight up disrespecting Wladimir's position and competence.

Everything he touches becomes a political flame fest and diverges focus of other developers from important technical work.

Well after reading some things about him, including the IRC logs, he goes on questioning Wladimir's competence on being a lead dev. It's funny how he continues to bring up leadership/decision matters in a middle of a conversation. It's fun to watch lol.

Bitcoin is a form of democracy

I have already responded to most of the [technical] issues you have raised there and you do not acknowledge my counter arguments because they are political in nature.

I do not think that BIP101 threatens network security, and the t[h]reat of a political civil war should not sufficient reason to not support a contentious fork.

I think that fifty one percent is enough to justify a fork

miners will not be effected by an increase in the block size

Your mempool limiting technique creates a cheap network bandwidth DoS attack.

The problem is Gavin's patch evicts random transactions (and their descendants) from the mempool without regard to what fees anything paid; in Bitcoin we use paying fees to limit DoS attacks, so anytime a transaction can be broadcast without having a high probability of eventually paying the fee is very bad. Evicted transactions aren't recorded, so if a peer rebroadcasts them to you you'll redownload them. Equally that makes up a bunch of space for different rebroadcasted transactions respending UTXO's that were previously spent. Either way, bandwidth is being used that isn't being paid for.

This is all very well known stuff, and dealing with it is most of the reason why Core is actively working towards implementing a mempool sorted by fees. That you quickly merged Gavin's patch is a sign you don't have much peer review, given that a multiple simpler, working, alternatives exist if you just want something fast to implement. (e.g. the feerate tier idea discussed on IRC/github)

Bitcoin is a form of democracy where the economic majority decides, whether you like it or not this has always been the case.

The way he does it as if Wladimir is somehow absent from the discussion when he can actually read everything Mike writes shows total lack of respect.

Agreed, or must I say that he wants lead dev control that's why they're forcing BIP 101 in our asses? ::) He brings a lot of talks in regards with leadership and decision-making.

The way he does it as if Wladimir is somehow absent from the discussion when he can actually read everything Mike writes shows total lack of respect.

no one's forcing anything.  You're free to run XT, Core, whatever you want.

I don't want something that is being forced upon. End of story.

or Blockstream  ;) no-one's forcing you to use that either, are they jonald?
 

Correct. 

The difference is that there is a certain entrenchment of the existing consensus rules based on the history and usage of the core repository. 
As is evidenced by miners voting on scalability with their block signatures, the core consensus rules are no longer satisfactory for everyone.

what?

no one's forcing anything.  You're free to run XT, Core, whatever you want.

In other word, no one is satisfied that the consensus rules among Core devs only leads to no decision making.

In other word, no one is satisfied that the consensus rules among Core devs only leads to no decision making.

I don't think that's an accurate representation. If the decision-making rules are insufficient, what do you propose -- exactly? Has anyone actually attempted to amend the BIP process and bring the question to the Core devs?

As I've told you before, your responses are by and large insufficient. In most cases, you are merely saying "I disagree..." or "I think that..." or "I don't think that..." I cannot refute an opinion if you provide nothing to support it. Your discussion of orphaned blocks is completely absent of facts or proof; it is just tortured logic. When your arguments repeatedly boil down to mere opinion rather than logic based in facts, there is little point in arguing. My points still stand.

And seriously, I just explained how spam is already defined by the Core software and how it can be individually set. And still it's impossible to identify spam? This isn't about fees; it's about blockchain and UTXO bloat and maximizing efficiency/minimizing unnecessary throughput. You think it's more important to forego other methods of scaling so that we have to subsidize people who want to send cents, fractions of cents? Subsidize spam like Coinwallet? Not interested. You need to lose this one-track mindset.

And political commentary, by definition, cannot address technical flaws, nor the issue of ignoring engineering standards. The premise that politics can override technical knowledge and expertise is absolutely unacceptable. If that is the case, then by definition, breaking the protocol is acceptable for political reasons. WTF is the point of supporting bitcoin, then, if its procotol is constantly at the whims of a political majority? Why do you think "consensus" was established as a principle in the first place?

Your arguments about governance, again, fall on deaf ears. It's meaningless hot air. Show me alternative implementations with widespread support. No go? Build them yourself. I don't see anything here to talk about. Again, you say you think the BIP process is a problem? Then provide your primer on what the governance model is supposed to look like. Bring it to the devs, see if anyone supports anything you are saying. Because if the only major code contributors on your side are Gavin and Hearn, you've already lost. What I see from you is all complaints, no action.

Bitcoin is a form of democracy

I have already responded to most of the [technical] issues you have raised there and you do not acknowledge my counter arguments because they are political in nature.

I do not think that BIP101 threatens network security, and the t[h]reat of a political civil war should not sufficient reason to not support a contentious fork.

I think that fifty one percent is enough to justify a fork

miners will not be effected by an increase in the block size

On a fundamental level, I completely disagree with the first four statements. (The last is a technical point which you have not sufficiently proven.) You believe bitcoin is a democracy, and that 51% (aka a 51% attack through argument) is sufficient to hard fork. I believe your position is at odds with the ideas of "valid blocks" and the "consensus mechanism" stated in the whitepaper.

You've basically conceded that a civil war with multiple surviving blockchains is not only acceptable -- but it almost seems as if you think it's an optimal solution. If you think bitcoin is worth fracturing along the lines of something so insignificant as block size, this is another fundamental impasse.

And re XT being buggy? Yes, it is. That's what happens with little to no peer review. Irresponsible to release the code as such. One recent example:

More importantly, though, BIP101 breaks the consensus mechanism and introduces a scaling regime with completely unknown conditions.

In other word, no one is satisfied that the consensus rules among Core devs only leads to no decision making.

This is the point that I have been making as well, very well stated in bold. :)

BIP101 does not break the consensus mechanism, seventy five percent consensus is consistent with Bitcoin, since fifty one percent consensus would be as well.

fifty one percent consensus

Im no 8mber let alone 20mber but im still not convinced over blockstream to be honest. So all transactions that don't go through the blockchain will go throught a private company that is basically paypal 2.0? what's the point then? isn't this centralization again? how does this work like, there will be servers of blockstream that process payments? I don't fully understand the mechanism.

@VeritasSapere

This kindergarten shit is a complete waste of my time. Repackaging the same arguments you've repeatedly made, which are backed by nothing but opinion -- this is not worth responding to. I hate to pat myself on the back, but I've completely ripped everything you've said to shreds. You're still quoting everything I said and merely responding with variations of "no, I don't think so" repeatedly without evidence. Often it seems that you are happy to produce endless meaningless fluff just to be able to say that you responded.

And for someone that endlessly complains about the governance structure, all you can say when asked to define an optimal governance structure is "the economic majority decides by choosing between alternative implementations of Bitcoin?" Seriously? That is not an adequate response to the question of how to amend the BIP process and improve decision-making. Apply those standards to XT as well as Core -- how do you expect decisions to be made? What is the formal process? Stop complaining until you at least have a proposal. (Then see if anyone actually supports it, or if you are still just speaking to yourself.)

Repeating "economic majority" like a buzz word doesn't accomplish what you think it does. It's a cheap excuse to redefine the consensus mechanism. Nobody is falling for that.


Please reconcile this with bitcoin's historical hard forks. I'm waiting.

I am not on your side. I couldn't be further from it. You emphasize "increasing block size limit" above all else (including other methods of scaling) -- consensus, decentralization, security. You've stated yourself that achieving this on political grounds is more important than any technical considerations. I couldn't imagine a position that is less logical, or less concerned with retaining value in bitcoin. You would fracture bitcoin many times over to get your political way. That's disgusting.

It's so obvious in these threads who has real money on the line here, and who doesn't.

I completely disagree with what you are saying here, it seems like you do not understand how consensus should work.

fifty one percent consensus

You are also being overly polarizing when we could all be much more united on this issue.

So we should just accept everything you propose, for reasons that you cannot adequately frame?

You've got only one answer to every and any question, and yet you're the one complaining about others taking a fractious position? The hypocrisy is out of this world.

That is not what I am saying at all, you are again misrepresenting my views.

You've argued your points well.  I suggest you no longer waste your time and energy on
people that are more interested in arguing than anything else.  Let them beat their
anti-XT, anti-Gavin, anti-Hearn, anti-blockincrease drums as loud and as long as
they want. 

Everything's been said.

Miners are signing blocks. 

Companies are signing statements.

That is not what I am saying at all, you are again misrepresenting my views.

 the BIP101 bible thumpers will do and say anything, with no shame or compunction, in order to impress an alternate reality on Bitcoin. You're sociopaths.

Carlton... take a deep breath... let it out slowly...  relax...

We're just talking in a forum.

Nobody is thumping any bibles or "doing" anything.

 :P

To be fair it can be unnerving to deal with blatantly dishonest shills of your kind  :-\

To be fair it can be unnerving to deal with blatantly dishonest shills of your kind  :-\

You, jonald, knight22 and the rest of the BIP101 bible thumpers will do and say anything, with no shame or compunction, in order to impress an alternate reality on Bitcoin. You're sociopaths.

[10:53:12] <Naphex> wumpus: that hearnban was best thing all month / grats
[10:56:07] <wumpus> Naphex: yeah, it was about time

You give them too much credit; they are none of those things.

It's true, sociopathy is supposedly a learnt form of psychopathy, and it's pretty obvious that learning is not their strong suit.

So Hearn got banned
Haven't been paying much attention to the dev stuff guess I have no opinion other than dev unity seems low.

anyone who is in favor of bip101 is a psychopath.  sounds legit.

sounds about right to me

So Hearn got banned
Haven't been paying much attention to the dev stuff guess I have no opinion other than dev unity seems low.

Gmax might complain about social strokes, but throwing Hearn (and Garzik?) under the bus had the desired salubrious clarifying effects.

Has Garzik been misbehaving too?

he's been the one pretending to be somehow offended with hearn's ban from the logs. real drama queen, pretending hearns ideas are somehow worth anything for a start..

but then again coming from someone working for the fail of a company that bitpay is makes it even more ironic..

oh and not even mention his bip100 fraud.. ::)

he's been the one pretending to be somehow offended with hearn's ban from the logs. real drama queen, pretending hearns ideas are somehow worth anything for a start..

but then again coming from someone working for the fail of a company that bitpay is makes it even more ironic..

oh and not even mention his bip100 fraud.. ::)

+1

Jeff is a troll at this point. Always stepping in between lines trying to hurt no feelings and coming out with the most retarded miner voting BIPS.

I've read alot of your exchanges, and you've done incredibly well to maintain your composure in the face of such relentless and willful illogic.

I hope you can now agree that this behaviour cannot be anything but entirely conceited. Dishonest participants, who will do or say anything, no matter the internal contradictions, to force their position on the issue. All while complaining that they're being censored and oppressed.

What's next, Hearn and Andresen complaining to some authority figure or other about how their great idea is being oppressed by the people who are not clever enough to choose it freely?

Hearn is barely a BTC dev.  His important contributions are miniscule, as he mostly focused on SPV schemes to destroy trustlessness.

Actual dev unity is very high, especially after all the team building fun at the #ScalingBitcoin confab.

Gmax might complain about social strokes, but throwing Hearn (and Garzik?) under the bus had the desired salubrious clarifying effects.

Hearn is one of those devs you hear a lot about along with Gavin, Maxwell etc.

Narrow code-warring aside, Garzik is not ideologically aligned Team Cypherpunk.  He's retweeting hand-waving "Why won't Someone do Something" posts (https://twitter.com/george_chen/status/650031512906153984) in favor of grabbing guns.

Not a True Libertarian confirmed.   :P

It's just name recognition
Hearn is one of those devs you hear a lot about along with Gavin, Maxwell etc.
I'll believe you though Ice on unity.

While I'm also "not a true Libertarian" myself, Jeff is obviously a little bit confused about which country he lives in and it's culture. Other gun cultures do not have the same problems that the USA has, and so their problem isn't as simple as adding further firearms controls; other countries with fewer controls have less (indeed, zero) mass shooting incidents.