Topic: How Open Source Projects Survive Poisonous People - page 6. (Read 29524 times)

Well as a competitor to Bitcoin I would actually very much like Luke-JR to get more power within the leadership group or even just stick around doing what he does......

People think when it comes to software development and protocol improvement the best thing is this massive debate over every small change... I disagree. Bitcoin isn't really at the stage where it just needs a few minor tweaks here and there as it sails off to its magical 21 million coin sunset. If Microsoft had this same "development model" we'd be on Windows 3.11 instead of Windows 7 or 8.

We'll see with SolidCoin in the next month or so, a complete rewrite, thin clients the default transaction method for users and out of the box ease for developers to integrate with their sites. All because we agree on what needs to be done and work towards that goal. Few disputes and if they are people are reasonable and decide what's best for the project.

+1.

I'd be much more in favor of using earlier multisig efforts to classify as IsStandard and creating OP_HASH multisig transactions: https://gist.github.com/39158239e36f6af69d6f or https://gist.github.com/dba89537d352d591eb36

Developing such a large change as P2SH should be reached by consensus after sufficient discussion. Many didn't even hear about P2SH proposals until very recently. Something like P2SH may eventually be necessary for large transactions, I do see a lot of potential value in it (and think the developers put in a lot of good work coding & testing, which is highly commendable), but it is an endeavor that must be developed with sufficient deliberation and consensus. In the meantime, we should begin accepting multisig transactions as soon as possible, with a minimum of code change/risk for miners and users until P2SH has been fully explored. I'd be much more comfortable if there were not been any bugs discovered in P2SH code in the past weeks (let alone months), unfortunately there have been substantial non-trivial bugs in the P2SH code that had to be fixed.

I've switched my hashing power to deepbit.

I'd like to point out that as a benevolent dictator coordinating a project like cgminer, it is much easier for me to selectively take parts of Luke's code and selectively ignore things he tries to push that I disagree with. There is a lot of merit to the leader of a project having that kind of power. This is not a vote either way on this issue by the way. Nor am I suggesting that we should necessarily be giving that power to Gavin. However, it works for Linux Kernel with Linus at lead which is a much bigger project and complex codebase than bitcoin is, and it works for the various projects I work on which are much smaller.

The only reason he could steal the transactions was because the BIP was not active. If it was active, he could not have done it. After he did it, it was a simple matter of enabling the BIP to bypass it. I disagree that a BIP-16-stealing bot would be a lot harder: we already have a "hub mode" patch to connect to a lot of nodes, and all one needs to do is modify the output address for every transaction they relay. I could probably finish it in under 10 minutes, but honestly I have better things to do, and giving people trying to test BIP 16 a hard time isn't my idea of productive since (for both BIPs) it isn't a practical real-world attack.

As I've said before, while BIP 17 is the best solution right now, I have no objections to a similarly clean solution being used. I'm fine with spending more time to address any concerns with it, including a "remake" if that's wanted.


After giving this some thought, I believe I do owe Gavin a public apology for not spending more time proposing BIP 17 earlier, before he spent all that time on BIP 16.

Looks like I have to remind one of my points:

• I don't think that there is any chance of BIP17 winning because it's not supported by any major force besides Eligius (sorry, luke)

I like the fact that it doesn't uses magic cases and serialized form, but it may have drawbacks too. Also, I expect most people to be disappointed if I choose BIP17.
So I'll repeat: I don't think that there is any serious competition between BIP16 and BIP17. The only question is WHEN BIP16 will be adopted (if no other proposals appear soon).

I would immediately support any plain multisig scheme or sane long-address multisig TX proposal as possible first-stage on our way to P2SH to allow people play with it and get more time for preparing P2SH deployment.

Luke,

I have yet to see you address this issue Gavin has pointed out:



Gavin,

I see that you just found a bug in your code the other day and fixed it:


I am sure you are both great programmers but it is reasons like this why I think further testing is needed before we try to push this any further on the main block chain. It is for this reason I have chosen to move back to Deepbit for mining, since they want to delay any hasty implementation. Clearly no one has a consensus among the Bitcoin community as to which one (or neither) to use but I believe since Satoshi essentially anointed Gavin as the head developer I think he should have final say. I would hate to see him leave the project over this.

Is it possible for both of you to scrap your individual BIP's and work together on a single common one? This will take some concessions on both your parts but I think the end result would be a much better and more secure Bitcoin project.

Let me take the time to point out the root words of community. Common Unity = community. There has to be a civilized way to work this out.

Its dangerous to let Luke-Jr have anything to do with code for bitcoin. His recent behaviour of sending a DMCA notice to an alt coin dev shows what he really believes. Which is sending men with guns to your house if you do something he doesnt like.

This sort of action makes it too risky to allow him access to insert code in bitcoin that will allow him to take it down or worse threaten companies. Using your mining pool to bully alt chain devs then if hat doesnt work using the gun in the room is enough to disqualify him imo.
'

"Imagine another bitcoin boom by this summer"
my wet dream

Regarding the time frame, it could be that there are already other things in the pipeline related to scalability of the blockchain that would need to be addressed in a timely manner and that depend on how multisig is implemented.

Imagine another bitcoin boom by this summer and the amount of transactions increases tenfold. You can't really wait another 2 years with this, maybe not even another 3 months. I think the next big thing to focus on is scalability and we need to have multisig settled down right about now.

Seriously, this post needs more love. As a bitcoin saver the way this protocol change has been tried to be rushed through is far more worrying than some potential technical bugs with the implementation. If this will become the precedent for how future protocol changes will be handled then I'm out of bitcoin. Satoshis way of a 2 year plan seem far more conservative and proper.

Perhaps in open source development relationships aren't always cordial.  (That was why in the video Gavin posted the leads of Subversion were venting.)  I do know that most successful for-profit software development shops where one needs to be physically at work tends, for the most part, to be cordial in environment.  Most people don't want to go to work in a hostile environment and people who don't fit in will quit or get fired.

If I were lead I would want to produce an open source environment that is as cordial as possible, even though that may never happen.

That's the way ignores work.  You see a user has posted, but it says that the user has been ignored, so you can't see what they said.  So Luke's post makes sense.

Several people in this thread seem to think the sole issue here is differing opinions on BIP 16 vs BIP 17.  The original post cites that as a single example, and not the entire motivation, behind Gavin deciding that Luke was poisonous.  Maybe Gavin was being disingenuous and it really is about this single issue.  If so, call him out on it.  But lets not turn this discussion into a rehash of BIP 16 vs BIP 17.  That's a different discussion.

Everything I have referred to has been proven BEYOND the shadow of a doubt, on multiple occasions, so do your best.

Also, had I actually been on your ignore list, how did you know that I was commenting about your actions in the first place ?

I am trusting that Tycho will wait for us to all calm down, eventually review this thread, determine that the consensus is clearly with Gavin, and run with it.

Just thought I should note that I am intentionally ignoring znort987, CoinHunter, and bitlane, who have demonstrated themselves to be scammers and trolls in the past. If anyone else thinks I need to respond to anything from them, please say so (do note that a good amount of it is outright lies/FUD).

Not to mention the fact that Luke has tagged the header of EVERY piece of code he has ever laid his hands on, should be a STRONG indication that he is not in this to be a Team Player, but rather to gain as much Solo recognition as possible.

As I said previously, everyone who hasn't yet, really needs to watch the video in the OP, as you would swear that the commentary can be applied 100% to Luke-Jr without ever mentioning his name or the Bitcoin project.

All of the tell-tale signs are there.
- He is childish and throws tantrums (ie. Wiki edits).
- He uses his Pool as leverage against this and other communities.
- He is extremely argumentative.
- He is an attention whore (code tagging etc) and is NOT a team player.
....and the list goes on.

As was said previously, if one person NEEDED TO GO and it came down to Gavin or Luke, my vote would be to keep Gavin.
I to am afraid that Gavin would quit the project if faced with constant battles etc from Luke and others should be as well.

Would YOU trust Luke with the present as well as future of your Bitcoins ?

Should being a Developer and a Pool operator not be considered a conflict of interest, when using your pool to help FORCE things your way ?

Perhaps it's time to show his dedication to the community and retire from 1 of the 2 roles (Pool OP or Dev) ?

Finally got time to actually watch the video, so here are my comments:

• There isn't any constant back-and-forth revision of BIP 17 going on. This was a one-time critical fix to replace a major proposed change with a minor one that does it better.
• I think a clear mission goal would help bitcoind/Bitcoin-Qt tremendously. But let's not get caught up in another debate over what that should be. I suggest Gavin make the first and final decision for bitcoind's goal, and Wladimir the same for Bitcoin-Qt.
• I think this constantly opening new threads for the same topic (I think we have like 10 on P2SH now?) is probably the same as the "filibustering" mentioned. Can we stop doing that? (I subscribe to one to stay up on the topic, and next thing I know there's a new 3-page thread going on about the same thing that I missed!)
• I commend Gavin, sipa, et al with seeking peer review of their own changes despite having direct push access so we don't need the git commit emails. I'm questioning whether this is really on-topic, but that's possibly a flaw of my own speaking
• This whole P2SH thing has been stressing me out a bit, and this "bus factor" thing seems like a good idea. That is, after this is resolved, I intend to at least try to be "hit by a bus" and take a break for a while. (Note: I'll still be reachable if there are problems involving my code that need resolving - ie, I'm not expecting the other developers to deal with bugs I create, if it turns out there are some)
• It would be nice to switch to a more consensus-based approach for development.
• P2SH isn't "voting on everything"; this is the first thing we've had to have any kind of serious vote over.
• I did admittedly start off simply opposing BIP 16 and expecting that someone else would fix it. I noticed this, so I wrote, implemented, and tested BIP 17 to provide a solution (doing something).
• Anyone want to make a wiki page documenting past decisions? I've only been involved for a year, so I'm not sure I'm qualified.
• I think they make a good point about not making decisions on IRC. A common thing put forward for BIP 16 seems to be that it was discussed at the IRC meeting and proposed based on that. But according to these guys, that's when the "real" discussion begins, it shouldn't be treated as a final conclusion.

To conclude, I think this video has a lot of good advice; I don't appreciate Gavin trying to make the P2SH dispute personal and imply the disagreement makes me a problem - that part is a distraction and non-productive.

At first I thought Tycho was being stubborn or taking his fellow pool-operators side out of some kind of loyalty, but I now agree with him that we should give it more time.  Another month or two of testing to calm the FUD is more valuable then getting multisig functionality right now.

Luke is brash and seems a bit arrogant, but I think his heart is in the right place.  I don't think he needs to be excommunicated by any means, but it wouldn't hurt for him to cool down a bit.

I though this was funny ironic anecdote, not proverb? We Russians abandoned a lot of people, and then just honored them as fallen heroes, because it is easier (or because we decided they were traitors).
As for Bitcoin, it is idea, not just a open source program. If Gavin quits, or whole development team disappears, someone else will step up. The only dispute is how quickly the team we do have can work, make new feature, and fix bug, if one member keeps bringing everyone else down.
TL;DR Luke does not seem to be a good comrade.