Main developers don't give a damn about us, bitcoiners!

[Jackten]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

[johnyj]

I think miners should pay developers so that they can get more people to do test, is it possible to implement this in pools?

[ShadowOfHarbringer]

@developers

paraipan does not represent the opinion of us bitcoiners.

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

[paraipan]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think he got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gavin. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

[ShadowOfHarbringer]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think it got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gaving. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

1. The blockchain split was only mildly serious bug. AFAIK nobody lost their money.
2. The increase of block size was done to ensure scalability of the network ! So it is stability we are getting.
3. The problem existed not because of bug in Bitcoin, but because of bug in BerkeleyDB. Which was used by Satoshi himself, not by Gavin.

Coincontrol and such is a fancy new feature which is not critically necessary to proper functioning of the network. But proper block size is. So it got addressed more quickly, like it should. I don't see anything unusual about that.

[gweedo]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think it got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gaving. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

1. The blockchain split was only mildly serious bug. AFAIK nobody lost their money.
2. The increase of block size was done to ensure scalability of the network ! So it is stability we are getting.
3. The problem existed not because of bug in Bitcoin, but because of bug in BerkeleyDB. Which was used by Satoshi himself, not by Gavin.

1) Actually some miners lost coins, and Gavin being the such the nice guy :/ gave them the coins to cover up his mistake (He should just done more testing)

2) Actually we aren't even hitting the current limit so they are just arbitrary upping the limit.

3) No, they didn't configure it correctly in bitcoin program, so cause Satoshi didn't see the limit getting hit by bitcoin blocks we should blame him LMAO. Gavin is maintaining it he should have seen it being hit WITH TEST. No test was performed. So that is completely 1000000000% Gavin's fault.

Honestly the core developers view's are so different from real bitcoiners. It is impossible to run a full node with out aligning your views with them, thank god for armory for allowing me to continue to help the bitcoin network and be trust-less.

[mrdavis]

Honestly the core developers view's are so different from real bitcoiners

Please, explain the views of "real bitcoiners" Or at least tell me who real bitcoiners are if it's not the people that have been maintaining the code base for longer than most have even known of the existence of bitcoin. Or by "real bitcoiners" did you mean you? If that's the case, I can breathe a sigh of relief that the devs views differ.

[gweedo]

Honestly the core developers view's are so different from real bitcoiners

Please, explain the views of "real bitcoiners" Or at least tell me who real bitcoiners are if it's not the people that have been maintaining the code base for longer than most have even known of the existence of bitcoin. Or by "real bitcoiners" did you mean you? If that's the case, I can breathe a sigh of relief that the devs views differ.

I define real bitcoiners as people who everyday are trying to push bitcoins, trying their hardest to make it stand out in the outside world. Just power users in the sense that everyday they are head deep in bitcoin 24/7. The core developers don't have time for that, or they say they don't. Views of those people are keeping these core values of bitcoin which I think each day, the core development team is moving farther and farther from some of them. With certain aspects of the where the client is going, you can see that views are changing to something that I find not what I would consider the official bitcoin client.

Now I know everyone is going to say build your own then, I have tried and let me tell you it takes more time then I can spend doing it. There is no documentation and the little documentation is out dated. I recently tried again and I got some blocks to download when just connecting to my own bitcoind node, and no one else. They need to real start looking more like an open source team then a team that is hiding behind the foundation. I honestly can't believe the lead developer is head of the foundation, and 2 business that complement each other are together.

So the views will never align with real bitcoiners, and I don't count newbies views, cause they are learning and sucking in information. When I was a newbie I didn't really form my opinion about things I just took the information researched it for validity and accepted it. Now I am very well informed and can my own opinions and know how everything works in the community.

[ShadowOfHarbringer]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.


Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

Why are you relying on your nanny-state oppressor to provide the fork you want when you can make one yourself and let people submit to their heart's desire? That is what is supposed to happen (see https://bitcointalk.org/index.php?topic=22434.0)

Galvin is gaining credibility amongst the community by not including every patch/feature people request.

Gavin is including very, very few patches and features people have requested. Even extremely well-tested ones, like coin control.

[Citation needed]

Also, he is probably frightened of breaking something. I know i would be in his situation.
We're talking hundereds millions of dollars, this is no joke.

[gmaxwell]

Gavin is including very, very few patches and features people have requested. Even extremely well-tested ones, like coin control.

It would be nice if people didn't outright lie here. The original coincontrol patches were a somewhat broken kludge. The address grouping parts were merged after a bunch of fixes (and even still— a crash bug crept through and I didn't find it until the next release), but no one was willing to step up and fix the problems that were pointed out in the GUI part on review.

There is a new coin control patch now which is a complete rewrite and not based on the old stuff— it's based on some coin selection modification things that Jeff subsequently wrote. It's my opinion that something along these lines should eventually go in. Though I think Jeff and Gavin would like to see more of these things done externally— because we can get more "feature velocity" if feature can be moved away from the really sensitive parts of the codebase.

[ShadowOfHarbringer]

@gweedo, @Wolf0, @paraipan

Do you actually fully understand seriousness of this situation  ? Because I don't think you do.

Gavin and other devs either are or will be under enormous pressure when they manage a code that manages **1 billion of USD worth**. And it will only get worse as the market grows.
I surely know that i wouldn't merge just any code into the main branch if i was in his situation. Do you think anybody wants to be responsible for people losing hundered millions $$$ ? Nope, one does not.

Do you know that banks and large corporations, even today, use code that has been written 10, 20, 30 and MORE years ago ? Do you know why ? Because it has been thoroughly tested, it is 100% stable and it just works.

So not only is the "slow way" the good way, but the ONLY ACCEPTABLE way. Keep all the new cool and funky stuff out of the mainline client, until there is absolute certanity that it is stable.

[gweedo]

@gweedo, @Wolf0, @paraipan

Do you actually fully understand seriousness of this situation  ? Because I don't think you do.

Gavin and other devs either are or will be under enormous pressure when they manage a code that manages **1 billion of USD worth**. And it will only get worse as the market grows.
I surely know that i wouldn't merge just any code into the main branch if i was in his situation. Do you think anybody wants to be responsible for people losing hundered millions $$$ ? Nope, one does not.

Do you know that banks and large corporations, even today, use code that has been written 10, 20, 30 and MORE years ago ? Do you know why ? Because it just works.

So not only is the "slow way" the good way, but the ONLY ACCEPTABLE way. Keep all the new cool and funky stuff out of the mainline client, until there is absolute certanity that it is stable.

You didn't read my post or even understand it clearly. First off if they released better documentation then I think most companies would roll there own bitcoind, but today it is very hard to do that. So then Gavin is forcing us to use bitcoind and have code that is managing $1billion USD of worth. Why not put some of the pressure off to other developers. I mean bitcoin's core value is decentralized so this would only farther help it. Second I think you are wrong about the banks, I seen some bank backends and they are fairly modern to keep up with security breaches and combat cyber-attacks. So again another lie. Also when do we blame the core development team for issues? Never? I mean come on a Berkley configuration issue, and we blame the Berkley db? Come on WHEN DOES THE BLAME GO TO THE DEVELOPMENT TEAM? This is why issues will never be solved or have head way.

[benjamindees]

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

Paraipan, I agree with your concerns.  And I want to say "thank you" for stepping up to voice them.  I am also concerned about any trend towards needlessly re-writing or rejecting submitted patches for no reason other than consolidating copyright claims, which as many of us know is a common tactic used to close open source projects.

And I'd like to see useful features like coin control added as much as anyone.

BUT, the reference client is a lot like Linux in this respect:  it needs to be stable and boring.  The fun stuff really should happen elsewhere.

Also, that address filtering thing is concerning.

So let's all try to keep reminding ourselves that, for a market the size of Bitcoin,

"move slow" is the right answer.

But if you don't want to promote a more avant garde client like Armory or something, perhaps a plugin system could be developed?  I'm not sure how feasible that is.  Just throwing that out there as a possible solution.

[wumpus]

the same way you chided the bitcoind devs, i am now chiding you: who do you think you are to dictate what a bunch of (presumably) unpaid open source developers choose to contribute to a project they hack on and maintain? i somehow doubt you have compensated any of the devs in such a way that it would justify your acute agitation.

Couldn't have worded it better, thanks for the sanity. I work on this in my very limited free time because it interests me, and unless you pay me to work on stuff I'm the only one that decides what I'm going to do.

i do think there is some merit to your claim that the devs exercise an unusually large amount of control over the project when there should be a (well) documented standard protocol.

Luckily, this is free software, so it's not like I'm holding a critical part of the pie for myself and am unwilling to share it. If you're serious about developing on bitcoin, or want to maintain a 'bleeding edge' fork (I actually wanted to spearhead this in the beginning, but I don't have time for it), you can always ask me questions about the code or how things work and I'll try to help.

I'd love to see some more activity around the bitcoin code base, but the 'official' bitcoin repository is likely not the place for it, as the software that runs the largest part of the network things have to be checked and tested carefully to not break the network etc...

Having said that, I chuckle a bit when I see "Main developers don't give a damn about us" and a few words later we're accused of being nannies and overprotective. So, do we care too little or care too much...  

It's a shame that the wonderful Bitcoin project is controlled by neckbeards whose values are so completely at odds with commercial success as to be laughable.

I love this one too. How do you propose we make this a "commercial success". Sell licenses? Charge a fee for every transaction and send it to Gavin's pocket? Add banners and commercials to the client? Sell statistics about client usage? Maybe we should start a bank! j/k...
Any action aimed at commercializing will inevitably result in lock-ins and centralization. So, be happy we're just a bunch of idealistic neckbeards eh...

[Isokivi]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

+1
This a hundred times this.

[ShadowOfHarbringer]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

+1
This a hundred times this.

Ohhhh yes.

You are not forced to use main developer's client. Change the code, make one yourself. Or pay somebody to do it. It is that simple.

Actually I have a say in this, because I already did so when I didn't like just ONE decision of the devs.

[behindtext]

the same way you chided the bitcoind devs, i am now chiding you: who do you think you are to dictate what a bunch of (presumably) unpaid open source developers choose to contribute to a project they hack on and maintain? i somehow doubt you have compensated any of the devs in such a way that it would justify your acute agitation.

Couldn't have worded it better, thanks for the sanity. I work on this in my very limited free time because it interests me, and unless you pay me to work on stuff I'm the only one that decides what I'm going to do.

ppl taking a tack similar to paraipan are all over every open source project, it is a real drag sometimes. complain, complain, complain but they ultimately contribute nothing. to quote theo deraadt "shut up and hack!"

i do think there is some merit to your claim that the devs exercise an unusually large amount of control over the project when there should be a (well) documented standard protocol.

Luckily, this is free software, so it's not like I'm holding a critical part of the pie for myself and am unwilling to share it. If you're serious about developing on bitcoin, or want to maintain a 'bleeding edge' fork (I actually wanted to spearhead this in the beginning, but I don't have time for it), you can always ask me questions about the code or how things work and I'll try to help.

I'd love to see some more activity around the bitcoin code base, but the 'official' bitcoin repository is likely not the place for it, as the software that runs the largest part of the network things have to be checked and tested carefully to not break the network etc...

you are right to point out that the protocol pieces can be extracted from the bitcoind code, but it takes a fair amount of work.

[r.willis]

Yeah, change the code and core developers would whine "do you want to cause chain fork?". If code of bitcoind is the spec, then any non-trivial change is breaking the spec.
Great news: there would be "bitcoin payment protocol" in 0.9. Where is the BIP?

Bitcoin Foundation standardizes, protects and promotes the use of Bitcoin cryptographic money for the benefit of users worldwide.

(emphasis mine)
So, would BF chime in and halt inclusion of bitcoin payment protocol into mainline client before it goes through BIP procedure? May be Chief Scientist Gavin Andresen could enlighten us? (oh wait, he is the author of proposal in question). I see problem here.

[2112]

Having said that, I chuckle a bit when I see "Main developers don't give a damn about us" and a few words later we're accused of being nannies and overprotective. So, do we care too little or care too much...  

Please John! Nitpicking on somebody's grammar is not a way to show that you are a great thinker. Let me restate the complaint in a more unambiguous way: core development team cares for some idealized mentaly deficient user, politely expressed as Gavin's grandma. Out-of-core developers and users care mostly for acceptance amongst knowledgeable IT geeks and innovative financial people. There is a serious disconnect right here.

I hope that this disconnect soon will be quantitatvely measured by the sales of Trezor. Originally it was conceived for the "grandma" market. After I and other people applied little presure on the designers there will be two versions: for "grandmas" and for "geeks", the second one being an unlocked device that doesn't use jail and doesn't require jailbreak.

https://bitcointalk.org/index.php?topic=122438.msg1496928#msg1496928

It's a shame that the wonderful Bitcoin project is controlled by neckbeards whose values are so completely at odds with commercial success as to be laughable.

I love this one too. How do you propose we make this a "commercial success". Sell licenses? Charge a fee for every transaction and send it to Gavin's pocket? Add banners and commercials to the client? Sell statistics about client usage? Maybe we should start a bank! j/k...
Any action aimed at commercializing will inevitably result in lock-ins and centralization. So, be happy we're just a bunch of idealistic neckbeards eh...

This strawman is not yet completely burnt, so lets dissect what had left of it.

A simple definition of "commercial success" would be that the sum total of income of everyone involved in the enterprise is positive and increases as the product adoption increases.

A simple example of "commercial failure" would be an enterprise where the "accounts receivable" department gets all the bonuses, "accounts payable" department is constantly getting laid off and the "research and development" department lives on the handouts received openly and the bribes delivered in secret. Do you recognize it? This type of operation is sometimes called "asset stripping".

The original ideal of Bitcoin was that every peer would be its own accounts payable, accounts receivable and some of the peers will do R&D on the side while doing accounting. It didn't work out that way: the accounts receivable function broke out of the ranks and concentrated into the mining pools. This destroyed the balance of the original design. The balance needs to be restored by some compromise.

Being a businessman is an art of forging compromises.

So I'll finish burning the strawman with the following: tax the miners with proceeds going to at least two pockets, one of them Gavin's and Bitcoin Foundation and one in escrow for another R&D and implementation effort. Just don't repeat the devcoin mistake and set the tax rate to 90%.

[phelix]

[...]

"coin control / less change / refactor coin selection" - https://github.com/bitcoin/bitcoin/pull/1017

For a popular feature, nobody was willing to take the effort required to address problems with it, until very recently (too late for 0.. Hopefully it will make it into 0.9.
[...]

that's good news. thanks for the other facts, too.

Sounds like I need to get around to spinning a 0.8-based next-test release, though...

+1  


About coin control
It obviously is about privacy. As somebody pointed out above it shows everybody how bitcoin addresses get all linked together if you are not careful.
In bitcoin-qt it is an option that is deactivated by default. Also bitcoin-qt is no good for newbies.