On Thu, Dec 8, 2016 at 8:57 PM, Joel Shprentz <[email protected]> wrote:
> Beancount looks like it can track Bitcoin transactions, which require
> eight decimal places. In my experiments with Beancount 2.0b13 running on
> Ubuntu 12.0.4, the Bitcoin balances looked okay, but the dollar balances
> were presented with too many decimal places. Perhaps I missed some
> Beancount option.
>
> This small sample Beancount file shows the structure of my accounts and
> two sample transactions. I wrote a small script to write Beancount
> transactions from a CSV file exported from my Bitcoin wallet.
>
> option "operating_currency" "USD"
> option "inferred_tolerance_default" "USD:0.01"
> option "experiment_booking_algorithm" "FULL"
>
> 2016-11-01 commodity USD
> 2016-11-01 commodity BTC
> 2016-11-01 open Assets:Wallet BTC "FIFO"
> 2016-11-01 open Income:BitcoinMining
> 2016-11-01 open Income:CapitalGains
> 2016-11-01 open Expenses:MiningRental
>
>
> 2016-12-05 * "Big Mining Pool" "Mining pool income"
> Assets:Wallet 0.24304715 BTC {}
> Income:BitcoinMining -182.72 USD
>
> 2016-12-06 * "Fast Mining Rentals" "Mining rental service"
> Assets:Wallet -0.16090000 BTC {}
> Expenses:MiningRental 121.84 USD
> Income:CapitalGains
>
> Following the IRS guidelines, Bitcoins received from mining activity is
> treated as income. The Bitcoin wallet reports the number of Bitcoins
> received and the equivalent dollar amount. Beancount can infer Bitcoin
> prices from the transaction. The inferred prices look reasonable.
>
> When spending Bitcoins, for mining rental expense in the example, any
> increase or decrease in Bitcoin value must be tracked as a capital gain or
> loss. With the recent FIFO booking algorithm, Beancount can select the
> earliest Bitcoin lots from the wallet account, infer their price, and
> compute the capital gain. This appears to work.
>
> As I experiment with more and more transactions, the wallet and capital
> gains USD account balances increase from two decimal places to 27 decimal
> places. For example,
>
> - 10 transactions: 10.97
> - 100 transactions: 51.32000000000000000000000000 USD
> - 1000 transactions: 6675.575739409965261575154249 USD
>
> I haven't found the exact tipping point. All transactions are structured
> like the examples.
>
> What am I doing wrong?
>
Beancount infers its precision from the numbers present in the input file,
and normally this excluded interpolated numbers (e.g., in your example, the
cost is omitted). If you look at the cost using the "bean-doctor linked"
command you will see that those USD numbers should have a large number of
decimal places when filled in.
Normally these shouldn't affect the inferred precision (in the
DisplayContext object, in the source code). If it does, it could be a bug,
unless you have more explicitly large-digited numbers in your input than
otherwise. If you can produce input and a command that reproduces the
problem clearly, please file a ticket.
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/CAK21%2BhMD%3D3O5D21oYayBVA5e2%2Bz2ZwnWe6nCU_a4pFaSbrCaZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
