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

[paraipan]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?


Patches:

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

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383



This situation is aggravating with every day that passes!

Please make sure you understand the issue discussed in this thread before commenting.

[justusranvier]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

[paraipan]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

[greyhawk]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

[paraipan]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

Why should I redo the work of others? The features are already built and waiting to be merged in the main client. Or your answer was a sarcastic one?

Where is Satoshi when you need him...

[speeder]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

Why should I redo the work of others? The features are already built and waiting to be merged in the main client. Or your answer was a sarcastic one?

Where is Satoshi when you need him...

You won't be redoing anything.

You will fork the main client, merge the changes, and release it, that is it.

If it becomes more popular than the main client, probably the main devs will merge on the official client too, and then you won.

[ionux]

I know everyone isn't a developer, but this is the beauty of open source software.  Grab the sources and learn how to hack in the changes you want personally.  If you think they might be helpful to the rest of the community, submit back your changes to the main developers.  I'm sure they are swamped and any help would be appreciated.

I'll start and show you how to do this.  If you click on the link for the "let users select their wallet" request, you'll see that a patch has already been submitted.  If you click on the "Files Changed" tab, you'll see exactly which 4 files were updated and exactly which lines of code were changed.  The lines with the "-" were removed and the lines with the "+" were added.  Using your favorite text editor, you can make these changes.

So, for the first file, for example, the source code file "src/init.cpp" had one line added near the top of the file:

Code:

        "  -wallet=<file>         " + _("Specify wallet file (within data directory)") + "\n" + 

This line is part of the command-line help that's printed out.

Next, on line 908, this code is removed:  "pwalletMain = new CWallet("wallet.dat"); " and two new lines are added in its place:

Code:

    strWalletFile = GetArg("-wallet", "wallet.dat");
    pwalletMain = new CWallet(strWalletFile.c_str()); 

(Don't add the + or - signs at the beginning of those lines, by the way.  They are there just to show you that it has been added or removed.)

Next up, on line 971, this line was removed: "CWalletDB walletdb("wallet.dat"); " and this line was added in its place:

Code:

CWalletDB walletdb(strWalletFile.c_str()); 

Ok, follow the same directions for the next three files that need to be changed: src/main.cpp, src/main.h,  src/qt/optionsmodel.cpp

After you make all of the changes, you'll have to compile it to make it an executable program.  The file ./bitcoin/doc/readme-qt.rst has the simple instructions for doing this (you can read it online at this link: https://github.com/bitcoin/bitcoin/blob/master/doc/readme-qt.rst)

When you compile it with the "qmake && make" commands, it will tell you if you made any errors adding the lines above.  If you see any "Warnings", you can safely ignore those.  The program will still compile and work correctly, they are compiler warnings.  Any "fatal" errors, however, will stop it from compiling.

There you have it.  Keep in mind that you are now using your own custom bitcoin client.  Any updates that you need to do, like official security updates, may break it and you'll have to grab the new source, add your changes and recompile.  So there is that caveat.

Hope that helps.  It's a bit arcane for non-developers, I understand.  Bit the more you get your hands dirty, so to speak, the easier making these changes for yourself will become.

[Luke-Jr]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?

Oh please...

"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.8). Hopefully it will make it into 0.9.

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

Too short-sighted. sipa and CodeShark have been working on true multi-wallet support for a while, and that will hopefully be ready for 0.9.

"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 stealing coins from newbies? Power users can already import private keys using the debug console.

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


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

[paraipan]

...

Thank ionux, much appreciated, this is not the point though.

Imagine you've been using Bitcoin for a few years and want to have a few useful features that you've seen missing. You probably already know that Gavin et all incentive people to help them out (https://bitcointalk.org/index.php?topic=4571.10) and submit patches or new features. You start working on it and complete all the steps like a champ, but this is where things start to get complicated and main developers could select your feature, or not, to be merged with the mainstream client. They can leave your submission waiting for a few months too, effectively rendering your work useless because you have to re-base (adapt) your feature or patch to the new client versions.

Here is an example from 11 months ago Re-issue getblocks to the next suitable peer when the previously selected one disappears, the patch was practically abandoned rendering the original work useless!!!

[paraipan]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?

Oh please...

"Oh please", but you didn't address either one...

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

Nice to hear that, didn't know.

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

Too short-sighted. sipa and CodeShark have been working on true multi-wallet support for a while, and that will hopefully be ready for 0.9.

Nice to hear that too, didn't know.

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

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

[Gavin Andresen]

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.

[Mike Hearn]

I've been involved with open source projects for over a decade, so know this issue well.

Usually, if you dig in, there's a reason why some patch is left in limbo. These issues are sometimes not what you want to hear: it's buggy, it's not obviously buggy but seems "risky" and maybe not worth the cost, it solves an issue in a short term way but a long term solution is wanted, etc.

For a lot of these patches, when I dig in, the issue seems like one of those. For instance "re-issue getblocks to the next available peer when one disappears" got superseded by some other patch, and rebroad then said that the other patch wasn't actually ready to be merged. So I can see why it might have got stuck.

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

Again, same thing for "dust limit and filtered addresses". If you know enough about Bitcoin to know what this is about, you don't need a GUI to set them. It's not something that regular users should be thinking about.

As pointed out, sometimes people will disagree on these sorts of things. That's open source - the solution is for you to fork the project and maintain your own version with these features merged in. If you aren't a developer, find someone who agrees with you who is, or pay someone to do it.  That's how open source has always worked. If you refuse to do it, then you're refusing the very nature of open source itself!

[paraipan]

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.

[Mike Hearn]

paraipan, if you think there needs to be a power user fork, it's up to you or someone else to make one. Not Gavin.

If you can't do it yourself, Luke-Jr actually does maintain a "next test" fork where he merges in lots of features together. Maybe you could convince him to do one.

[paraipan]

I agree with most of the points you make Mike, but...

...
For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.
...

... why you would want to know that? Is not your responsibility or problem. Software has been know to be used in many more ways that initial developers designed it for. Google is your friend, no pun intended.

[justusranvier]

"Bitcoin-QT Poweruser" fork,

There's already a client specifically for power users. It's called Armory.

[christop]

Translation of OP:

I paid nothing for some Free software and demand that its main developers add some features instead of doing it myself or paying someone else to do so.

The features are available to anyone interested and skilled enough to add them, and others in this thread have posted reasonable reasons for rejecting those features in the reference client at this time.

If you can apply the patches for those features and then build it yourself, why don't you? Otherwise, you can hire somebody else who can, so why don't you? Complaining in this thread won't change the valid reasons for excluding the features from the reference client.

[JTurner]

As the reference client, I can sure understand that devs may be reluctant to introduce patches without a lot of testing first. If a released were to introduce some nasty bug, it could quickly create a nice chaos given that most people just run and update the official client without asking themselves many questions (which is understandable, the official client, being "official", is supposed to be stable and running out of the box).

That said:

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

Using the console for this is good enough to me (it's not as if this was a very frequent operation), but it would be nice though if the client was able to dump encrypted private keys... It's a bit sad that the official client provides a way to encrypt a wallet but no way to decrypt it... (and it doesn't really help switching from one client to another)

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

Well, GUI coin control would actually make Bitcoin easier for anyone needing coin control... A basic design which looks useful to me would be:
1. a list of balance per address
2. from this list, allow to pick one (or optionally several) addresses to spend from
And to avoid clogging the main GUI, it can just be buried somewhere into the menu

[paraipan]

...

You missed the whole point, please re-read thread.

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.

[Mike Hearn]

... why you would want to know that? Is not your responsibility or problem. Software has been know to be used in many more ways that initial developers designed it for. Google is your friend, no pun intended.

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?