Jack Coulter
My feedback
1 result found
-
360 votes
An error occurred while saving the comment An error occurred while saving the comment Jack Coulter
commented
@John Ralls
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.
[1] http://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html
[2] http://ledger-cli.org/An error occurred while saving the comment Jack Coulter
commented
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.
Jack Coulter
supported this idea
·
> 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.
Thanks for all your work on this project :)