The developers have more in common with Richard Stallman than they do Joe Bitcoin. Case in point, they shut down the whole #bitcoin channel on Freenode, voicing only a few individuals, so they could make a dog and pony show of some M of N signature transaction feature nonsense. Why didn't they just do it in #bitcoin-dev?
But looking at the bigger picture, are these really the most important features? We still don't have an official 1.0 release and these people are still saying that after four and a half years "Bitcoin isn't ready for people to use yet." The arrogance and condescension this projects is enormous.
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.
Topic: Main developers don't give a damn about us, bitcoiners! - page 3. (Read 6585 times)
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.
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://bitcointalksearch.org/topic/update-2015-05-10-bitcoin-core-soft-fork-no-forced-tx-fee-v0101-available-22434)
Galvin is gaining credibility amongst the community by not including every patch/feature people request.
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.
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 don't you make a bitcoin fork, but not a network fork?
@developers
paraipan does not represent the opinion of us bitcoiners.
paraipan does not represent the opinion of us bitcoiners.
Please explain how your views, other than we all want to see bitcoin succeed, align with the developers if you pay close attention that right now is not currently possible.
Quote
I'm a member of the Bitcoin Foundation, hence paying your salary, so I demand an explanation to all this.
With friends like these...
@developers
paraipan does not represent the opinion of us bitcoiners.
paraipan does not represent the opinion of us bitcoiners.
As usual, Gavin descends upon us and then disappears mysteriously, again...
So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?
As usual, Gavin descends upon us and then disappears mysteriously, again...
So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?
"okey dokey"
We're both humans and have our time constraints, but what you say doesn't compute.
Where did I complain about you, or developers close to you, not working on the project? If you have read something that I said in OP, and many other posts, the issue lies with your "thick skin" when ignoring or rendering useless many developments to reference client. Addressing them with a "NAK" or having a "nanny" attitude doesn't do any good.
Bitcoin is a protocol and the reference client is it's main support at this moment, so your help is needed to build a healthy ecosystem. With the attitude you have right now you're successfully forcing people to use alternate wallets, insecure and faulty sometimes, so you achieve exactly the opposite of that. The main client/protocol isn't properly documented so compatible clients can't be built from scratch, you keep pushing for changes that break things and make documenting even harder. How we're supposed to work together in this situation?
Edit: I'm a member of the Bitcoin Foundation, hence paying your salary, so I demand an explanation to all of this.
As usual, Gavin descends upon us and then disappears mysteriously, again...
So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?
"okey dokey"
Clearly we need a solutions for that. If you would step in the cloning vat for just a second....
As usual, Gavin descends upon us and then disappears mysteriously, again...
So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?
"okey dokey"
I will leave this right here https://bitcointalksearch.org/topic/m.1671697
...
Coin control is a beautiful example of anti-paternalistic stance and how it aggravates anyone who is a paternalist and wants to treat every user like a potential "grandma" or whatever else is the current polite word for "mentally deficient".
I think the Bitcoiner emancipation movement is getting formed here and now.
Coin control is a beautiful example of anti-paternalistic stance and how it aggravates anyone who is a paternalist and wants to treat every user like a potential "grandma" or whatever else is the current polite word for "mentally deficient".
I think the Bitcoiner emancipation movement is getting formed here and now.
+1 nicely put!
I have read through the thread, and as somebody who uses Armory extensively for the coin control feature plus others, I have to disagree respectfully to paraipan. To cut it short, the reference client should be improved slowly and steadily, thus decreasing the potential vector of attacks as possible. Also, Mike does make a good point up there - spending from a single address isn't paramount to the client, and I'd like to have as few features as possible just for the ease of use to newbies. At the end of the day, anyone wanting the advanced features (or 'graduate') from the reference client can simply use other clients like Armory or even the test-qt by Luke.
John, you're free to use whatever client suits your needs. As I understand you probably use Armory allot, but I don't and my reasons are straight forward, I don't want to use a fancy GUI when the reference client already has one that can be improved.
Push for improvements happens daily but at slower pace than before because few people that are in charge decide is not "safe" for us to control certain things. How is that sounds?
...
Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves.
Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves.
Guess you didn't got any help or support but you keep defending the un-defendable, whatever dude.
As usual, Gavin descends upon us and then disappears mysteriously, again...
The correct solution is to implement the sweep function, and make that easily accessible.
Ok, so ignoring smaller previous pull requests that could be the start of such feature is a solution? I remind you that Bitcoin is still beta software."Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383
I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?
You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.
I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
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.
Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.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.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.
Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves.
Because coin control is a complex way to achieve any given goal. It requires you to understand the transactional nature of the Bitcoin protocol. Fine for super-fans who don't mind studying, a bit of a pain for anyone who isn't. Look at how confused even some developers get about the relationships between addresses, balances and transactions.
So if coin control exists, what that means is people who aren't power users can't solve whatever problem the power users are solving with it. It'd be better to find solutions to the underlying problems, and then everyone can benefit. And often, I bet we can find fully automatic solutions, so it can be more convenient for power users too.
Making Bitcoin usable by everyone is an important goal, and thus so is understanding what people do with it. That's why I'm interested to know what people want coin control for. It's not a "I want to invade your privacy" thing, it's a "how can the software be better designed for everyone" thing.
Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?
Actually coin control GUI would be an excellent teaching tool to help the beginning users and developers understand the Bitcoin protocol.So if coin control exists, what that means is people who aren't power users can't solve whatever problem the power users are solving with it. It'd be better to find solutions to the underlying problems, and then everyone can benefit. And often, I bet we can find fully automatic solutions, so it can be more convenient for power users too.
Making Bitcoin usable by everyone is an important goal, and thus so is understanding what people do with it. That's why I'm interested to know what people want coin control for. It's not a "I want to invade your privacy" thing, it's a "how can the software be better designed for everyone" thing.
Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?
At the same time this is exactly why people who think like Mike Hearn oppose it: they oppose educating people about the inner working of the machinery. The key to control the people is to make them believe that they really need somebody more knowledgeable to ensure their safety.
Coin control is a beautiful example of anti-paternalistic stance and how it aggravates anyone who is a paternalist and wants to treat every user like a potential "grandma" or whatever else is the current polite word for "mentally deficient".
I think the Bitcoiner emancipation movement is getting formed here and now.
...
Get some sleep, your off by a mile.
...
The correct solution is to implement the sweep function, and make that easily accessible.
The correct solution is to implement the sweep function, and make that easily accessible.
Ok, so ignoring smaller previous pull requests that could be the start of such feature is a solution? I remind you that Bitcoin is still beta software.
"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383
I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?
You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.
Pardon me, but people have authority when things get done through them, or not? So if someone decides over a matter you imply they don't have any authority. I respect Gavin and team for this and because they reached there with allot of hard work and learning, but I don't agree with their "nanny" attitude towards bitcoiners. Hope I make myself understood and you don't beat the subject around the bush.
I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
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.
Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.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.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.
Don't give me that "testing" crap, you know very well the same thing we're discussing here happened to you and many other people. Testing is non-issue when you've already tested all known cases. Unknown are to be discovered, just like the recent database fork that even Satoshi himself couldn't foresee.
I have read through the thread, and as somebody who uses Armory extensively for the coin control feature plus others, I have to disagree respectfully to paraipan. To cut it short, the reference client should be improved slowly and steadily, thus decreasing the potential vector of attacks as possible. Also, Mike does make a good point up there - spending from a single address isn't paramount to the client, and I'd like to have as few features as possible just for the ease of use to newbies. At the end of the day, anyone wanting the advanced features (or 'graduate') from the reference client can simply use other clients like Armory or even the test-qt by Luke.
You missed the whole point, re-read the whole thread.
I didn't miss the whole point. The point is that you don't want to do anything to fix the situation you're in. You would rather complain about it here.I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
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.
No, you do not have to depend on the main developers for any new feature. It's Free (as in freedom) software, after all. You can have a Bitcoin-qt client with those features if you would just put some effort into it.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.
"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050
Too dangerous for easy access - do you really want to enable people coins from newbies? Power users can already import private keys using the debug console.Importing private keys that others might have makes you vulnerable to theft.
Newbies could easily be fooled into this kind of an attack.
Advanced users can still do it via the debug console.
The correct solution is to implement the sweep function, and make that easily accessible.
"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383
I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?
You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.
I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.
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.
Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.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.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.
...
Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?
Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?
Yes, spending from a single address would be nice. Does that sound too complicated?
Jump to: