I suggest you ...

Make it easier for users to work with alternative/non-ISO/private currencies.

As I recall reading on the GnuCash mailing list(s), developers will not include support for currencies that do not meet ISO requirements. Therefore, to use the likes of Ithaca hours or bitcoins, users have to rather inappropriately treat them as stocks, virtually exchanging them for an official currency before conducting real transactions. Either that or users must rely on the XXX placeholder currency, which has its own limitations.

I propose that GnuCash include some functionality for users to define custom currencies that behave just like regular official ones. This functionality would allow for users to point GnuCash to where it can find exchange rates with other currencies or to manually specify them. It would also allow for users to peg the value of their custom currencies to officially recognized ones.

Until we get the extra decimal places I'm thinking about recording my bitcoin balances in what I call BTCC, as in bitcoinCENTs. So, 1 BTC = 100 BTCC. That gives the extra 2 places of precision. My wallet has 5.23472183BTC and is recorded at 534.472183BTCC.

I have it listed as a stock type. When paying expenses with bitcoin I plan to sell coin to a wash/suspense account and recording the expense in there.

> Yes, we'll be able to support smaller fractions than 10E-6 in 2.8. That's what I'm working on now.
Great to hear :)

> I do expect that more of them will do so in the next two years, and I predict that most OECD countries will follow the US lead.

Remains to be seen, but I can understand taking the conservative approach in the interim.

> The relevant code is scattered about the UI as well as the engine, and the major focus of this development cycle to fix that and get a properly layered database-driven application that will make it feasible to change the basic rules in the future.

That eases my concerns on this matter substantially. Perhaps once said rework is complete then I, and many others, can consider migrating back from Ledger.

Yes, we'll be able to support smaller fractions than 10E-6 in 2.8. That's what I'm working on now.

Duh, of course there are countries besides the US. But AFAIK none of them have issued rules about how to account for "virtual currency" transactions. Accounting is about rules, not arithmetic: The arithmetic is easy.

If you live in the USA, you *must* account for your bitcoin (or any other "virtual currency" that you use) in the way already supported by GnuCash. If you live anywhere else, you probably *should* account for them the same way, simply because that's what's least likely to get you in trouble, until your country's tax and accounting authorities get around to publishing their own rules. I do expect that more of them will do so in the next two years, and I predict that most OECD countries will follow the US lead.

I don't at present know all of the things that will have to change in GnuCash to support treating currencies and commodities the same. The relevant code is scattered about the UI as well as the engine, and the major focus of this development cycle to fix that and get a properly layered database-driven application that will make it feasible to change the basic rules in the future.

There do in fact, exist countries besides the US. It's not knowable how every country will legislate Bitcoin, many have yet to make a statement one way or the other, some may decide to treat cryptocurrencies as securities, some may consider them currencies. Personally, I can't see the harm in simply allowing your users to make their own decision, appropriate to the laws of their jurisdiction. Ideally, through implementing a currency editor much like the existing security editor.

Failing that, an alternative could be to improve the existing securities functionality. Presently, this functionality is unsuitable for cryptocurrency use for two main reasons:

* Insufficient precision. Bitcoin is divisible down to fractions of 1E-8. Currently, Gnucash cannot represent fractions smaller than 1E-6. Thankfully, it seems that this concern may be addressed one way or another, if the "Rethinking Numeric"[1] thread is anything to go by.

* Inability to denominate income/expense accounts in securities. Around many cryptocurrencies, but particularly in the case of Bitcoin, exists a growing ecosystem of products and services denominated directly in cryptocurrencies. Right now, expense/income accounts can only be denominated in units from the "CURRENCY" namespace. I see no logical reason why it should not be possible for such accounts to be denominated directly in cryptocurrencies, especially considering a number of extremely large retailers (Dell, Newegg, Overstock) now directly accept Bitcoin for purchases. Likewise, a growing number of people/organisations offer services directly in exchange for Bitcoin, such as server hosting and contract jobs (programming and web development tasks are particularly common here).

I find it difficult to understand the hostility this topic has been received with each and every time it's been raised. There's quite clearly demand for better cryptocurrency support in FOSS accounting software. I'd posit that the only reason Gnucash hasn't yet been forked is that the technical-minded users who have the knowledge and expertise to do such a thing, simply take the path of least resistance, and switch (like I have) to Ledger[2], as it handles this use-case seamlessly. As it stands though, Ledger's not really an appropriate solution for the average, non-technical masses.

Regardless of your personal views, it's hard to deny that cryptocurrencies are a growing, global phenomena. Sooner or later, it should become apparent that listening to your users is a prerequisite to remaining relevant. As applies to any complex, organised system, regardless of whether the nature of that system is economic, social, biological or technological, there exists a simple choice: adapt, or fade into obscurity.

I'd love this too. While you can, as a workaround, define cryptocurrencies as securities, this is less than ideal. Cryptocurrency-only markets are becoming increasingly common, and as far as I can tell, Gnucash doesn't allow you to define the price of one security in terms of another (e.g, some smaller/newer cryptocurrencies, like Monero (XMR), are mainly traded for bitcoins/litecoins (BTC/LTC) - they don't have well defined prices in any national/traditional currencies. Beyond that, you can't use cryptocurrencies defined as stocks for Income/Expense accounts.

Simply allowing custom currencies to be defined with a similar UI to that used for defining securities would go a long way to making Gnucash more usable to those increasingly involved in cryptofinance.

I need LTC and BTC and i really do not care about that ISO code. It's not the ISO code that makes the currency important or useful.
It is just like any other currency and automated price quote is unimportant.

I agree - in my case I need to add ZMW which is the new ISO code for the rebased Zambian currency as from 1st January 2013.
I need to be able to identify the 2013 Kwacha as different from the 2012 Kwacha, which has been reduced by a factor of 1000.
Until this is sorted out I am having to use Malawi Kwacha (MWK)!