Feature requests for Bitcoin-Qt

[Loozik]

1. There is a website https://github.com/bitcoin/bitcoin/issues?milestone=11&state=open where people submit:
a) information on bugs (for fixing), and
b) feature requests (for increasing efficiency and expanding user experience).

2. I am not sure, but I seems only a few and experienced experts can post there. They have the necessary technical knowledge and jargon to describe what they want.

3. How about a thread for non-techies in which feature requests might be submitted?

4. My feature request is:

PLEASE move / duplicate the commands that are available after typing in ''help'' (in Help tab -> Debug window) to a new tab called e.g. ''Action''. The commands should be available in this tab in a scroll down like fashion. The rationale for this feature request is this: why should one type long commands like ''listreceivedbyaddress'' or remember to use a square brackets or know where to put a comma, if one can simply click the command name and insert the necessary values in a dialogue window? It would be much simpler and time-and-nerve-saving for non-technical users.

For easier use (because the number of commands is considerable and will probably grow) the commands can be grouped somehow, e.g.
a) into the ones requiring and not requiring a wallet opening, or
b) into the ones that are for wallet management / transaction management, etc.

5. I do realize that I request for bells and whistles, especially given the early stage of Bitcoin-Qt's development (I know developers have other important stuff to code), so please do not rant about my post. I am just a newbie who would like this client to be more user friendly.

What do you think about this feature request?

Thanks

[1714864481]

1714864481

[1714864481]

1714864481

[wumpus]

PLEASE move / duplicate the commands that are available after typing in ''help'' (in Help tab -> Debug window) to a new tab called e.g. ''Action''. The commands should be available in this tab in a scroll down like fashion. The rationale for this feature request is this: why should one type long commands like ''listreceivedbyaddress'' or remember to use a square brackets or know where to put a comma, if one can simply click the command name and insert the necessary values in a dialogue window? It would be much simpler and time-and-nerve-saving for non-technical users.

It sounds like a good suggestion for making the console more user friendly; however, the debug console is meant for developers, not non-technical users. So making it more user friendly is not really a priority, and can even be contra-productive, as we'll get more reports of clueless users messing up by entering random commands.

[Sukrim]

Also the texts in there can be also just viewed on the wiki for example in a browser window in the background. Alternatively (e.g. you're offline) you could just view them in a console window.

[Loozik]

however, the debug console is meant for developers, not non-technical users

Yes. It is definitely not for non-technical users.

So making it more user friendly is not really a priority

If there ever comes time that developers have nothing to do (in two or three years from now) maybe they could consider it, I hope.

and can even be contra-productive, as we'll get more reports of clueless users messing up by entering random commands.

John, I disagree. How many times did you mistake ''Warn me when closing multiple tabs'' with ''Block Pop-up Windows'' in your Firefox? Never. Now, how many times did you make a typo in your command or put space instead of a bracket or a comma? I would argue that dialogue windows lower the risk of using commands (compared to using them from console).

Implementing dialogue windows for commands and their inputs would add-value Bitcoin-Qt. There are already dialogue windows for some actions like interface language change or transaction fee amount setting. Why not extending this practical approach to other aspects of using Bitcoin-Qt in the future?

[gmaxwell]

Implementing dialogue windows for commands and their inputs would add-value Bitcoin-Qt. There are already dialogue windows for some actions like interface language change or transaction fee amount setting. Why not extending this practical approach to other aspects of using Bitcoin-Qt in the future?

Sure, and more will be added in the future— but _just_ putting a dialog on something doesn't make it user-friendly, sometimes it gives the appearance of friendliness and safety even when it isn't.

Part of the reason the gui-console exists is so that we can expose functionality for developers and power-users for things like debugging/troubleshooting and emergency recovery ... as well as things that aren't quite ready for primetime or are dangerous if you don't understand them.  When something doesn't have a GUI it's not because anyone is unaware that a GUI interface is useful, it's because the feature not ready for the general public, not intended for normal users, or because someone hasn't gotten around to it.

[Zeilap]

Also, you're going to need a better example than "listreceivedbyaddress" because all of its functionality is already provided in the transactions tab.

[Loozik]

Sure, and more will be added in the future— but _just_ putting a dialog on something doesn't make it user-friendly, sometimes it gives the appearance of friendliness and safety even when it isn't.

gmaxwell, just think how much peoples' money would have been saved if there had been an ''Action'' tab with a command e.g. ''Show all addresses that have money''. Newbies wouldn't have thought they were robbed (change addresses). Wouldn't you consider it a safety improvement?

Part of the reason the gui-console exists is so that we can expose functionality for developers and power-users for things like debugging/troubleshooting and emergency recovery ... as well as things that aren't quite ready for primetime or are dangerous if you don't understand them. 

People will understand, if there is easy-to-understand non-techie documentation. They are smart creatures

My hope is Bitcoin will go mainstream one day and majority of users will be non-geeks. Non-geeks need an easy-to-operate interface. I have zero knowledge of computers - I write song lyrics for living (not in English) and I find it very hard to make use of even basic operations of  Bitcoin-Qt (Shit I am even afraid to use it - there are valuable functionalities, but I am afraid to make a typo in command and blow up the computer). Very soon the forum will be flooded with non-techies like me asking tons of unnecessary questions that noone will have time to answer.

When something doesn't have a GUI it's not because anyone is unaware that a GUI interface is useful, it's because the feature not ready for the general public, not intended for normal users, or because someone hasn't gotten around to it.

I wasn't aware of this. Thank you.

[Loozik]

Also, you're going to need a better example than "listreceivedbyaddress" because all of its functionality is already provided in the transactions tab.

importprivkey <bitcoinprivkey> [label] [rescan=true] Is this one okay?

[Loozik]

I recently spoke to a few businesses in my region. The owners (1 cinema and 2 restaurants) want to run a trial that will look like this:

1. I am sitting home.

2. Businesses send me an e-mail with the bill amount, e.g. $3 or $25.

3. I generate the QR code (on my Bitcoin-Qt) for the amount on the bill (using the current rate of exchange at MtGox) and send the QR code to the business.

4. A customer scans the QR Code and pays in Bitcoins (the customer must include a transaction fee so that the transaction is confirmed quickly - this is what this feature request is all about).

5. I (i) either keep the Bitcoins for myself or (ii) sell them on MtGox.

6. The next day or the same day I put cash (in national currency) into the businesses cash registers.

7. If the trial / experiment is successful, these businesses will look for a professional Bitcoin payment processor.

[Sukrim]

Maybe take a look into the suggested payment standard from gavin iirc.

[Loozik]

Maybe take a look into the suggested payment standard from gavin iirc.

Gavin Andresen? Where should I look for the info?

[bezzeb]

4. A customer scans the QR Code and pays in Bitcoins (the customer must include a transaction fee so that the transaction is confirmed quickly - this is what this feature request is all about).

Fees in QR code: I've seen the notion of letting a recipient specify fees (for example in a QR code) discussed, and i sort of mentally dropped the idea because someone pointed out that it could be abused.  Eg. someone sets a fee of 10BTC, and the dude spending hasn't had his caffeine for the morning yet and doesn't notice before signing the transaction.  Poof, 10BTC gift to the miners.  Useless for theft, but effective for inflicting damage upon unwary users.

I think a more robust solution is 2 parts:

Step 1. As Gavin has stated many times - better fee calculation in the client based on dynamic reckoning methods rather than hard coded values.  In essence, recommend the smallest possible fee to the buyer that will ensure smooth processing.  Because of the way the miners prioritize transactions, as I understand it, the fees could vary quite a lot - from zero on big old bitcoins to a few cents if a lot of small young tx are being merged.  The client program would enter nirvana if it could have a standardized way to reckon what is fair and reliable thus over time as trust in the method grows - removing this issue from the end users worry.

Step 2. Recipient confirmation should include not only verification that a transaction in the right amount has entered the queue for processing, but also that the fee is realistic based upon how the transaction looks in reference to the above reckoning method in point 1.  If I were a Point of Sales terminal developer, I would see it as very important to make sure the fee looks good before you let the customer walk out the door with the goods (so to speak), otherwise you open yourself to what amounts to shoplifting if a payment is never processed.

I know 1 is in the works now.  Once 1 is in place then it will be trivial for merchants to compare if the actual fee meets the recommended network fee thus accomplishing step 2.  Without point 1, then 2 is gonna kinda suck as the only way to judge if someones fee is good enough is subjective and open to argument / voodoo / personal belief.

If a fair floating fee reckoning mechanism gets implemented into the main client, it would be an incredible step forward.

Debug window feature:  Your first request was for this and I agree with the other posters that we don't want to make it easy for noobs to use the debug window as they can do silly (verging on dangerous) things over there.  If it were my prerogative, I'd hide the debug interface completely with a well documented, easy, but not obvious activation method so developers can turn it on if they need it.  Most users are scared by the debug window and quickly close it, and others only know enough to be dangerous.  Relatively few know enough to use it fruitfully.

[Sukrim]

Maybe take a look into the suggested payment standard from gavin iirc.

Gavin Andresen? Where should I look for the info?

Googling for gavin payment gives this as first result: https://github.com/gavinandresen/paymentrequest
First link in the readme: https://gist.github.com/gavinandresen/4120476 

[Loozik]

Googling for gavin payment gives this as first result: https://github.com/gavinandresen/paymentrequest
First link in the readme: https://gist.github.com/gavinandresen/4120476 

As I understand from this https://gist.github.com/gavinandresen/4120476

What about a merchant-pays-fee feature?

It is desireable to allow a merchant to pay the cost of any Bitcoin network transaction processing fees, so if a customer is paying for a 1 BTC item they pay exactly 1 BTC.

The consensus is to change the transaction selection code used by Bitcoin miners so that dependent transactions are considered as a group. Merchants or payment services with one or more unconfirmed zero-fee transaction from customers will periodically create a pay-to-self transaction with a large enough fee to get the transactions into a block.

the idea is that the merchant would cover transaction fees. I think this could be a solution. I do not necessarily like it, but this feature in the system would be helpful. Thanks for the links.

[Loozik]

Fees in QR code: I've seen the notion of letting a recipient specify fees (for example in a QR code) discussed, and i sort of mentally dropped the idea because someone pointed out that it could be abused.  Eg. someone sets a fee of 10BTC, and the dude spending hasn't had his caffeine for the morning yet and doesn't notice before signing the transaction.  Poof, 10BTC gift to the miners.  Useless for theft, but effective for inflicting damage upon unwary users.

I think a more robust solution is 2 parts:

Step 1. As Gavin has stated many times - better fee calculation in the client based on dynamic reckoning methods rather than hard coded values.  In essence, recommend the smallest possible fee to the buyer that will ensure smooth processing.  Because of the way the miners prioritize transactions, as I understand it, the fees could vary quite a lot - from zero on big old bitcoins to a few cents if a lot of small young tx are being merged.  The client program would enter nirvana if it could have a standardized way to reckon what is fair and reliable thus over time as trust in the method grows - removing this issue from the end users worry.

Step 2. Recipient confirmation should include not only verification that a transaction in the right amount has entered the queue for processing, but also that the fee is realistic based upon how the transaction looks in reference to the above reckoning method in point 1.  If I were a Point of Sales terminal developer, I would see it as very important to make sure the fee looks good before you let the customer walk out the door with the goods (so to speak), otherwise you open yourself to what amounts to shoplifting if a payment is never processed.

I know 1 is in the works now.  Once 1 is in place then it will be trivial for merchants to compare if the actual fee meets the recommended network fee thus accomplishing step 2.  Without point 1, then 2 is gonna kinda suck as the only way to judge if someones fee is good enough is subjective and open to argument / voodoo / personal belief.

If a fair floating fee reckoning mechanism gets implemented into the main client, it would be an incredible step forward.

1. You know, there is a risk on merchants' end of transactions not getting confirmed, if the merchants are not using a professional Bitcoin payment processor (like Bitpay).

2. The idea behind this feature request was to mitigate the risk of being paid but not receiving the funds. Sure, if this feature was to be implemented the way I proposed, another risk would be created, i.e. excessive transaction fees attached / enforced by pranky merchants. This risk could be however mitigated by a mechanism (devised by smart people like you) that would prevent sending excessive fees; e.g. Bitcoin-Qt would detect the smallest accepted fee by a pool and simply add this smallest accepted fee and generate the appropriate QR code.

3. Another idea behind this feature request would be to create a new job type (introducing agent to Bitcoin payment processors) in the Bitcoin business for people like me who are able to convince local businesses to start accepting Bitcoin payments. This could work like this:
a) I create (over a certain period of time) a pool of e.g. 10 - 20 local businesses who regularly generate a turnover that Bitcoin payment processors find attractive
b) then I transfer this pool to a Bitcoin payment processor
c) the Bitcoin payment processor pays me a commission for a certain period of time.

Why I think this job type is needed for Bitcoin? 99% about Bitcoin is and was written in English. Bitcoin needs a bridge to non-English speaking markets. This job could thrive in regional non-English speaking markets and would speed up Bitcoin adoption process. It is just my opinion.

Debug window feature:  Your first request was for this and I agree with the other posters that we don't want to make it easy for noobs to use the debug window as they can do silly (verging on dangerous) things over there.  If it were my prerogative, I'd hide the debug interface completely with a well documented, easy, but not obvious activation method so developers can turn it on if they need it.  Most users are scared by the debug window and quickly close it, and others only know enough to be dangerous.  Relatively few know enough to use it fruitfully.

My argument is that noobs will experiment with Debug window anyway (not with all commands)- this will be more detrimental. I think that those safer commands should be availed to users in a non-command version. Well, this is where we disagree 

[bezzeb]

1. You know, there is a risk on merchants' end of transactions not getting confirmed, if the merchants are not using a professional Bitcoin payment processor (like Bitpay).

This risk of not including sufficient fees should (and hopefully soon will be) mitigated at the core protocol level.  Bitpay like processors will still be vital for developing the specialized POS software and backend systems plus the services of managing transactions and the resulting sales data so that sales tax, GL accounting and corporate privacy are maintained.

But for the casual situation you describe of inserting fees into QR codes, it is not far more reliable to just check the transaction when it appears in the chain queue to see that the fee is good?  Inserting into the QR code is no guarantee that someone won't override the fee and do what they feel like.  You need to spot insufficient fees in the chain - easy as pie to monitor today by the way as fees are public in the chain like everything else.  The floating fee reckoning described in my prior post is to remove ambiguity over what the fee should be in the first place.  This will go a VERY LONG way towards solving this problem as right now there is no good rule to judge fees by and everyone is just doing what they feel like doing with no science to back it.

2. The idea behind this feature request was to mitigate the risk of being paid but not receiving the funds. Sure, if this feature was to be implemented the way I proposed, another risk would be created, i.e. excessive transaction fees attached / enforced by pranky merchants. This risk could be however mitigated by a mechanism (devised by smart people like you) that would prevent sending excessive fees; e.g. Bitcoin-Qt would detect the smallest accepted fee by a pool and simply add this smallest accepted fee and generate the appropriate QR code.

I'm not sure how smart I am, but thanks for the compliment.  ;-)  I'd recommend you give it another think with an open mind to really grok the problem.  The currently under construction feature would aim to solve both problems (over or under paid fees) in one go by just working out what's fair at a protocol level and do it in a way that is still super cheap (orders of magnitudes cheaper than conventional banks) and fair.  Otherwise see my prior comment under point 1.  Look in the chain to check the fee is proper, QR code won't help ensure fees are paid as you can always alter the amount and fee after scanning before you pay.  One simply must check a service like blockchain.info (i'm sure bitpay and the rest will also monitor the chain) to see if the customer has paid properly - fees in QR codes will not help you know for sure if things look right as there are many wallets which are diverse in how they handle fees.  The floating fee reckoning feature would unify the clients and take the mystery away from everyone while providing an easy measuring stick by which you can judge if fees are sufficient.

3. Another idea behind this feature request would be to create a new job type (introducing agent to Bitcoin payment processors) in the Bitcoin business for people like me who are able to convince local businesses to start accepting Bitcoin payments. This could work like this:
.......

No argument!  Bitcoin is a bonanza of opportunity at all levels of society IMHO, so i wish you the best in your efforts to assist merchants!  But as an FYI, there is a massive amount of VC being poured into this area so expect competition.    May the best merchant assistance services with the best offerings and lowest merchant overhead costs win.  Just keep in mind that if the Bitcoin merchant services aren't cheaper and better than what banks now offer for conventional POS systems, then they're dead on arrival.  One must always take things to the next level.

Debug window feature:  Your first request was for this and I agree with the other posters that ....

My argument is that noobs will experiment with Debug window anyway (not with all commands)- this will be more detrimental. I think that those safer commands should be availed to users in a non-command version. Well, this is where we disagree 

99.999% of the population of earth does not give a darn about the debug window.  They just want to buy shoes and fill their car with gas so to speak, and have a life which includes no time for poking into the bitcoin protocol.  Good news - it's a big planet so 00.001% is still a LOT of people.  Bad news - I don't think adding the "easy debug" buttons will help someone who knows what they're doing.  It also won't significantly lower the bar for noobs due to the heavy learning curve one must invest in before anything makes sense.  We'll agree to disagree - my tip is to try autohotkey.  I use it to reduce the amount of random syntax my brain must hold when debugging - it's awesome, a whole funky UI automation scripting world of its own.  But you need to read the docs as there are no buttons or GUI features to help with commands and syntax.  (LOL)

[Loozik]

This risk of not including sufficient fees should (and hopefully soon will be) mitigated at the core protocol level. 

Hopefully soon.

The currently under construction feature would aim to solve both problems (over or under paid fees) in one go by just working out what's fair at a protocol level and do it in a way that is still super cheap (orders of magnitudes cheaper than conventional banks) and fair.

To your knowledge, is there estimated point of arrival / milestone for this feature?

[bezzeb]

To your knowledge, is there estimated point of arrival / milestone for this feature?

I wish!  I've been kind of following activity on github and listening to interviews / reading articles with Gavin, but no commitments yet.

[Loozik]

I wish!  I've been kind of following activity on github and listening to interviews / reading articles with Gavin, but no commitments yet.

It is a pity, cause I have extended the list of businesses wishing to participate in this trial of mine. I added two bicycle shops located in my town. So I have now 5 outlets in my pool