Topic: Bitcoin needs to be simplified for the stupid. - page 4. (Read 7603 times)

Agreed. We certainly don't want to accept every wild-eyed request, but focus on some important projects that have community and developer consensus.

Good.


I agree + the major devs (prior to putting a price tag by a given developer) should have an internal discussion and decide (i) whether the requested feature makes sense, (ii) whether the requested feature is safe, etc. It wouldn't be sensible to pay for the feature, then get it done and not being able to incorporate into Bitcoin-Qt because other developers object.


I agree.

I don't know about making things simple but whatever you do could be explained a lot better, there have been years or months I've spent arguing with people to give better explanations from all professions not just people using cryptographic currencies. Someone just needs to get off their arses and write a very simple tutorial for mining the alternate currencies for example, then there's the fucking programming tutorials where they leave bits out and don't explain why they've told you to do something and so on.

Like I said, I'm not asking you guys to simplify anything, I think Bitcoin has actually been explained quite well which I suspect is why most people use it but good luck with the other stuff, it amazes me that people went and made stuff like Litecoin and didn't think about how the average person was going to use it. Just make sure that when you do something or you ask them to change a setting etc. you explain why, or for example you can give absolute beginner explanations for people just starting out rather than assuming everyone knows how to code already.

As embarrassing as it is I must have spent a good few months trying to figure out why my photoshop paintings were so damn blurry then I discovered it was just the brush hardness because none of the painting tutorials I followed mentioned that's what you need to get nice clear images. That and a high enough resolution that wouldn't break your computer and cause photoshop to freeze, all just because people forgot to mention things like that to beginners.

Yes, the basic idea sounds fair.

Before embarking on a project the requirements should be really clear to the developer and everyone contributing money to it should agree on them (to prevent disagreements later on). I also think an important requirement is to perform the work in the open, so that people can see what is happening and keep true to the open source spirit.

A % of the money should probably be held in escrow until the feature is fully integrated and reviewed in the context of safety. Payout schedule should at least be discussed beforehand.

It could work like this:

1. People submit their feature requests like in this project management site http://www.multicharts.com/pm/ (loads slowly).
2. Then developers put a price tag for requests they can handle + specify time they agree to complete the task.
3. Then people commit to pay the whole price (it will take a week or two if the feature is desired or years if the feature is unwanted)
4. When 100% of the price from the price tag is paid to a particular developer's address, the developer starts coding.
5. The feature is added to Bitcoin-Qt (e.g. documentation) after reviewing by other developers in context of safety.

Thanks

Another community funding idea. Maybe for an artistic tool which people really love someone will write a nice documentation out of love, but that's not going to happen for something as abstract as Bitcoin.
We'd need to find a technical writer with a track record of writing good software documentation, and employ that person to write a manual for Bitcoin-Qt (with community input).

Maybe something like the pypy donation drive could work, let people donate to certain subprojects and execute them when they are funded: http://pypy.org/ (and return the funds if something isn't funded by a certain deadline, or doesn't pan out).

Marcus, Bitcoin is a disruptive technology. I feel it. But understanding the mechanics (change addresses, algorithims of calculating the fees, e.g. why should older coins be better rewarded than new ones? - I still don't get this logic, but accept the way it works, etc.) are a novelty in the whole world. Please do not get surprised people give blank stares.

One day you too might give a blank stare in a field you do not know.

The OP's intentions were clear: to ease the learning proccess for ''the stupid'' thus allowing Bitcoin to go mainstream.

John, reading through the wiki is not easy. You read an article which mentions say 30 geeky terms like ''JSON-RPC API''. Shit, then you spend 2 hours understanding these terms. But to understand these terms you have to dig deeper.

I can understand wiki should work this way, but at least there should be an easy to understand Bitcoin-Qt documentation for grandmas / surgeons / movie makers / non-geeks written in easy English.

... quite right ... some guy posted something about his circle of friends giving him blank stares whenever he mentioned bitcoin and looked up at the title of the OP ... 2+2= ??

Sounds like a good idea. In any case, we can't rely on the Bitcoin Foundation to fund GUIs and user-friendly features. That's not their ballpark.

If somehow the community could fund active development in features and improvements that *they* want that'd be great.

There is: http://bitcoinbounties.com/  which can attach bounties to github issies. I'm not sure how well it works and/or how trustable it is though. But we have one data point: https://github.com/bitcoin/bitcoin/issues/2480 .

In any case, if we could get some community-funded initiative going I (and other devs) would be much more motivated to work on the bitcoin project, maybe even full time.

My point is: not everybody who doesn't understand intricacies of Bitcoin and / or is unwilling to learn this not-easy-stuff should be labelled ''stupid''.

WHY would they want to understand that? Either they are very interested and put some of their brain capacity into learning it (geek out), or they don't. Either way, they're not hurt right?

Specialization is a good thing in this complex world. I wouldn't know where to start implanting organs, and if I spent my time learning that (if I could at all) then I cannot spend that time into learning to write better software. So we have this thing called trade... and hey, we're on the bitcoin forums, our aim is to make that easier

 ... yeah I'm pretty sure a surgeon doesn't need to know about rawtransactions unless he's had a change of heart and is looking for a career change ... what's your real point here?

I have a colleague who is a surgeon + researcher on 3D printed organs. He makes magical stuff and is definitely not stupid. He works 16h a day. He could devote 1 hour a week to learn bitcoin. Imagine him trying to understand what raw transactions are: https://en.bitcoin.it/wiki/Raw_Transactions

People want to learn, but the stuff is described in a way too hard for non-geeks to understand within their lifetime.

When a developer feels like implementing it and has time to do it. There is not really a timeline as we're working on this on our spare time. All help is appreciated.
Yes. Using a different client won't protect you against those risks, although I'm not up to date on how Armory handles it, maybe it does a "sweep" already. I refered to Armory because it has a built-in "use case" for offline/paper wallets, which may make it somewhat safer for users as they're told what (and what not) to do. Which is better than randomly fiddling around with RPC commands found on a wiki, for example.

This ''sweep'' feature is nice. Do you have an idea when it might be implemented?


My guess is that a natively supported import of private keys in Armory also potentially leads to existing private keys in multiple places?

It will support "sweep", ie, "send me all coins from this private key", without adding the key to the wallet. This is superior for all cases that involve paper wallets, as unlike a naive "add to wallet" it does not encourage keys to exist in multiple places, potentially leading to all kinds of problems for the unaware.

And also it will still work for Hierarchical Deterministic (HD) wallets in which all keys are generated from one seed, so naive importing isn't even possible.

ok .. it was half tongue in cheek but it has flushed out some of the truth of the matter ... they do not want to learn then?

I do not need it. Importing private key was just an example of how ''grandmas'' or ''the stupid'' will think.

BTW, is there a reason why Bitcoin-Qt would not support (in future) a native feature of private key importing?