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

[paraipan]

...

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?

[1714697806]

1714697806

[1714697806]

1714697806

[1714697806]

1714697806

[1714697806]

1714697806

[1714697806]

1714697806

[Luke-Jr]

"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.

What? Please listen to yourself. The answer is yes, people can and will take care for themselves.

I was missing a word: "stealing".
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.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

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.
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.

[christop]

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.

[John (John K.)]

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.

[paraipan]

...

Get some sleep, your off by a mile.

...

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.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

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.
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.

[2112]

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.

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.

[Luke-Jr]

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.

But it isn't the start of such a feature. It's the end. The start needs to come before the end.

"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.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

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.

Nobody is deciding this for you, except yourself. If you choose to go with Gavin or someone else's decision, that is still your choice to do so. You can just as easily decide to ignore Gavin on this, and merge the branches yourself, as everyone has been trying to tell you.

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.
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.

Satoshi isn't a god. Testing is the main issue. One person testing is not sufficient, no matter what the change is.
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.

[paraipan]

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.

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...

[paraipan]

...

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!

[gweedo]

I will leave this right here https://bitcointalk.org/index.php?topic=156334.msg1671697#msg1671697

[Gavin Andresen]

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"

[greyhawk]

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....

[paraipan]

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.

[justusranvier]

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?

Is it ok to grumble a bit about emails that were never acknowledged?

[klaus]

@developers

paraipan does not represent the opinion of us bitcoiners.

[mikeg]

I'm a member of the Bitcoin Foundation, hence paying your salary, so I demand an explanation to all this.

With friends like these...

[🏰 TradeFortress 🏰]

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 don't you make a bitcoin fork, but not a network fork?

[maqifrnswa]

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.

[misterbigg]

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.

[behindtext]

paraipan,

you are being such an open source troll, it is very annoying. i am reminded of why i unsubscribed from misc@openbsd.org several years ago when i read your posts.

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.

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. i believe this is done on purpose to facilitate centralization of power and make it difficult to create a working alternative to bitcoind.