Bitcoin accounting: controlling precision of inferred values

[Joel Shprentz]

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?

[Martin Blais]

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.