Request. Standardize naming of RPC Calls (bounty)

[TangibleCryptography]

So I am doing some programming and a minor thing that bugs me is the "weird" naming convention of a minority of the RPC calls.

Code:

bitcoind help

addmultisigaddress <nrequired> <'["key","key"]'> [account]
backupwallet <destination>
createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}
decoderawtransaction <hex string>
dumpprivkey <bitcoinaddress>
getaccount <bitcoinaddress>
getaccountaddress <account>
getaddressesbyaccount <account>
getbalance [account] [minconf=1]
getblock <hash>
getblockcount
getblockhash <index>
getblocktemplate [params]
getconnectioncount
getdifficulty
getgenerate
gethashespersec
getinfo
getmininginfo
getnewaddress [account]
getpeerinfo
getrawmempool
getrawtransaction <txid> [verbose=0]
getreceivedbyaccount <account> [minconf=1]
getreceivedbyaddress <bitcoinaddress> [minconf=1]
gettransaction <txid>
getwork [data]
help [command]
importprivkey <bitcoinprivkey> [label]
keypoolrefill
listaccounts [minconf=1]
listaddressgroupings
listreceivedbyaccount [minconf=1] [includeempty=false]
listreceivedbyaddress [minconf=1] [includeempty=false]
listsinceblock [blockhash] [target-confirmations]
listtransactions [account] [count=10] [from=0]
listunspent [minconf=1] [maxconf=9999999]  ["address",...]
move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
sendfrom <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]
sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
sendrawtransaction <hex string>
sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]
setaccount <bitcoinaddress> <account>
setgenerate <generate> [genproclimit]
settxfee <amount>
signmessage <bitcoinaddress> <message>
signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] [sighashtype="ALL"]
stop
submitblock <hex data> [optional-params-obj]
validateaddress <bitcoinaddress>
verifymessage <bitcoinaddress> <signature> <message>
walletlock
walletpassphrase <passphrase> <timeout>
walletpassphrasechange <oldpassphrase> <newpassphrase>

Generally procedure calls have a "verb".  It is a command you are asking the system (any system) to do something.  Getbalance ... instructing the bitcoind to get something, get what?  the balance.  The call getbalance is self documenting.  It is clear that the call will be returning information and the information returned is the balance.  Names which lack a verb are not self describing.  Most of the RPC calls follow this convention, the list above can be summarized as the following verbs

Code:

add
backup
create
decode
dump
get
import
list
move
send
set
sign
stop
submit
validate
verify

There are four calls which break with that convention:

Code:

keypoolrefill
walletlock
walletpassphrase <passphrase> <timeout>
walletpassphrasechange <oldpassphrase> <newpassphrase>

Of the four "walletpassphrase" is the worst.  It lacks any verb and thus the call itself isn't self documenting at all (walletpassphrase what?).  I suggest the four calls be renamed to fit with the standard set by the other RPC calls (verb + object of verb)

Code:

refillkeypool
lockwallet
unlockwallet <passphrase> <timeout>
setpassphrase <oldpassphrase> <newpassphrase>

To avoid breaking compatibility with existing code the current RPC calls can be made deprecated aliases to the newly named ones.  I know it is relatively minor but it just bugs me every time I am doing some bitcoind coding.  I don't have the time to do the modifications and pull request so I am offering a bounty.  2BTC for a completed pull, and 3 BTC more when integrated into the mainline.

[1538086897]

1538086897

[1538086897]

1538086897

[1538086897]

1538086897

[kjj]

These are pretty easy changes.

https://github.com/kjj2/bitcoin/commit/c82fa0b722b0aec843e4538b1f21f5298fb2fee6

I changed the names of the functions too, so I'm running a full recompile to make sure I didn't typo anything.

This isn't worth 5 BTC by the way.  If this gets accepted, either give the bounty to some worthy cause, or hold onto it until you have a more difficult change request.

[kjj]

I had to rebase this against the latest master.  New link is:

https://github.com/kjj2/bitcoin/commit/4ba9b0603e235c2579622e3fc4d554da8507f345

[Herbert]

While I like the idea we have to make sure to stay backwardscompatible. So we can not just rename the commands and break all sorts of things that rely on the existing commands.
Better would be to add new commands and mark the old ones as "deprecated" and remove them only after some intermediate releases are done.

[kjj]

While I like the idea we have to make sure to stay backwardscompatible. So we can not just rename the commands and break all sorts of things that rely on the existing commands.
Better would be to add new commands and mark the old ones as "deprecated" and remove them only after some intermediate releases are done.

You didn't actually look at my commit, did you? 

[Herbert]

You didn't actually look at my commit, did you? 

How embarassing  I DID click on the commit, skimmed the first few lines that showed removal of existing commands and went back to comment here. Please forgive my ignorance 

[kjj]

You didn't actually look at my commit, did you? 

How embarassing  I DID click on the commit, skimmed the first few lines that showed removal of existing commands and went back to comment here. Please forgive my ignorance 

No worries.  It happens.

Since everything goes through a dispatch table, it was easy enough to put duplicate entries in so that the old commands would keep working.  The catch is that the list of commands that you get from typing "bitcoind help" is generated from that table, and I wasn't sure how to prevent duplicates.  Turned out that the problem had already come up before and someone else had fixed it so I didn't have to.

[TangibleCryptography]

You didn't actually look at my commit, did you? 

How embarassing  I DID click on the commit, skimmed the first few lines that showed removal of existing commands and went back to comment here. Please forgive my ignorance 

No worries.  It happens.

Since everything goes through a dispatch table, it was easy enough to put duplicate entries in so that the old commands would keep working.  The catch is that the list of commands that you get from typing "bitcoind help" is generated from that table, and I wasn't sure how to prevent duplicates.  Turned out that the problem had already come up before and someone else had fixed it so I didn't have to.

That was a nice implementation.  If the pull is integrated in the mainline all that is required is updated docs on sites like the wiki and unless new developers look at the source the old variants will be invisible, yet will still retain backwards compatibility. 

Backwards compatibility and forward standardization a win-win scenario.

Thanks.