pig-monkey.com - finance

Better Payments with Privacy.com

2022-02-24T00:00:00-08:00

Privacy.com is an excellent service with a terrible name. They provide merchant-locked virtual debit cards. I’ve been using them for about three years. Around 90% of my online transactions go through them (the other 10%-ish is PayPal).

When one of their card numbers is first used, it becomes locked to that merchant. The card will reject transactions from anyone else. This immediately eliminates the problem of stolen card numbers. If a random ecommerce website leaks my card details, I don’t care, because nobody other than the original merchant can place a charge on the card.

When generating cards, Privacy.com also allows you to set dollar limits, either in total or for a period of time. This eliminates the problem of unreliable subscription services. For example, the card tied to my Amazon Web Services account has a monthly usage limit slightly higher than my average monthly bill. If AWS tries to double my bill one month, the transaction will be rejected.

Cards can also be paused. While I use the periodic dollar limit feature for things like subscription services with regular payments, other cards in my Privacy.com account stay paused when not in use. A paused card rejects all new transactions. Before making a purchase on a website, I login to the Privacy.com website and unpause the associated card. I then make the purchase as usual. Placing an order usually results in the merchant immediately placing an authorization on the card for the purchase amount. Existing authorizations can still be captured on a paused card, so at this point I can switch back to my Privacy.com tab and re-pause the card, preventing the merchant from taking any more money than the agreed upon authorization.

Cards can also be closed. Effectively this is the same as pausing a card, except that it is permanent. This is useful for signing up for free trials that still require a method of payment. When the trial is up, if you choose to not continue using the service, inform the provider and simply close the card.

Privacy.com offers software you can install on your telephone. I’ve never used it. I don’t trust my phone enough for it to touch money in any way. They also offer browser extensions, which I also have never used. Their website works great, and I see no need for locally installed software of any sort.

Over my few years of using Privacy.com, I’ve never had a problem with their service. I’ve never had to contact their customer support, so I have no idea how that works. I’ve had merchants issue refunds to my Privacy.com cards half a dozen or so times, and those have always come through and landed in my bank account without drama (even when the original charge was on a card that at the time of refund was paused or closed.

Last year, Swift Silent Deadly posted an in-depth overview of Privacy.com. This provides a good overview of the service. What he wrote matches my experience, with one glaring exception. He mentions giving Privacy.com access to your bank account. I don’t know if he is referencing some shady Plaid bullshit or if he simply means providing them with routing and account numbers and going through ACH. I did neither. When I signed up, Privacy.com allowed me to add my real bank debit card as a funding source. That is the only way Privacy.com has to push or pull funds from me. If they ever become untrustworthy, I can just cancel my real debit card, and Privacy.com will loose all access to my money.

The debit card that I use for this is tied to the checking account that I previously used only for PayPal. This provides an additional layer of defense, in that there isn’t much money hanging around in that account for someone to steal. I usually keep around $100 in it for incidental purchases, and transfer more in from my real accounts when I plan to make a larger purchase.

Privacy.com has free and paid tiers. I am on the free tier. Apparently it has some limitations in terms of number of cards generated per month and total monthly spend. I have never run into these limitations so I have no idea what they are. They claim that they make enough money on us low-volume free tier users by collecting the transaction fees that merchants pay to process debit cards. I would be very unhappy to return to participating in the electronic commerce market without a service like this, so they would probably have a pretty easy time convincing me to move to a paid plan if they ever decided to eliminate the free tier.

I’ve heard some banks offer virtual card numbers somewhat similar to Privacy.com, but perhaps without the merchant-locking and spend limits. While I refer to my “bank” accounts, my accounts are actually with credit unions. Credit unions tend not to be at the forefront of technology, so I need a third-party to provide this functionality.

Privacy.com says that they offer merchant masking to their paying customers. This means that transactions show up in your bank account as “Privacy.com” instead of including the name of the merchant. I suspect this may be where their business name comes from. I suppose that is great if you have a joint bank account and want to hide your Porn Hub subscription from your spouse. But it is not a problem I have, so I maintain that their name is dumb and has nothing to do with their excellent service. If anything they reduce my privacy, since they are now an additional party involved in all of my online purchases. But I’m good with that trade-off.

Tracking My Phone Bill with Ledger

2020-08-12T00:00:00-07:00

Back in 2013 I bought my first smartphone and signed up for a T-Mobile prepaid plan, referred to at the time as the “Walmart Plan”. The plan cost $30 per month, was intended for new customers only, and was supposed to only be available to those who purchased the SIM card at a Walmart. It offered a small amount of voice minutes and a large amount of data, which struck me as what one would want with one of these newfangled computer-phones. I bought a SIM card, figured out how to get T-Mobile to sign me up on the plan despite not stepping foot into a Walmart, and haven’t looked back since.

One of the things that appeals to me about the setup is the level of separation it gives me from the service provider. I purchased the phone from the manufacturer and the SIM card I bought with cash. I fund the plan by purchasing refill cards from third-party vendors. I have never provided T-Mobile with any financial information. They have no ability to take any money from me, except what I give them when trading in the refill cards. Obviously, the primary business of any mobile communications provider is location tracking, so I can’t refer to my relationship with them as “privacy preserving”, but I like to think it does allow me to retain some level of agency that is lost in a more traditional relationship.

If there is a downside to this setup, it is that it can be difficult to understand what I actually pay per month. The plan costs $30. There is some limit to the number of SMS messages, but I have no idea what it is. Data is “unlimited”, which means throttled over 4GB, but I don’t think I’ve ever approached even half that limit. Minutes are limited, and if I go over the allotment I’m charged a higher rate, but the service continues as long as the balance of the account remains positive.

I always want to keep more than $30 in the account, in case I do go over the allotted minutes. So I buy $50 refill cards. They have $50 of value, and are supposed to cost me $50. But the vendor I tend to by them from charges a $1 service fee, offers a points program that sometimes results in a discount being applied, and frequently has sales that offer a couple dollars off. So I end up paying something like $48-51. If I do exceed the limits of the plan, I may end up buying a $50 card one month and the next. More often, I buy a $50 card one month and have enough left over in the account that I do not need to refill it the following month. My plan renews on the 5th of the month, so some months I may end up spending $100 by buying one refill card on the first day of the month and another on the last in anticipation of the following month’s renewal.

All of that is to say that it is difficult to have an intuitive feel for what my average monthly phone expense is, but it’s important that I can get that number so that I can determine if the plan is still working or if I should look for a better offer. Fortunately, this is a thing that Ledger makes extremely simple.

Whenever I purchase a refill card, I log the transaction in the Expenses:Utilities:Phone account. With that done, I can ask Ledger to report on all transactions in that account, grouped by month, with a running average in the final column.

$ ledger register utilities:phone --monthly --average --begin 2019-08
2019-09-01 - 2019-09-30     Expenses:Utilities:Phone    $48.50      $48.50
2019-10-01 - 2019-10-31     <None>                      0           $24.25
2019-11-01 - 2019-11-30     Expenses:Utilities:Phone    $46.50      $31.67
2019-12-01 - 2019-12-31     <None>                      0           $23.75
2020-01-01 - 2020-01-31     Expenses:Utilities:Phone    $51.00      $29.20
2020-02-01 - 2020-02-29     <None>                      0           $24.33
2020-03-01 - 2020-03-31     Expenses:Utilities:Phone    $48.50      $27.79
2020-04-01 - 2020-04-30     <None>                      0           $24.31
2020-05-01 - 2020-05-31     Expenses:Utilities:Phone    $48.50      $27.00
2020-06-01 - 2020-06-30     Expenses:Utilities:Phone    $46.50      $28.95
2020-07-01 - 2020-07-31     <None>                      0           $26.32
2020-08-01 - 2020-08-31     Expenses:Utilities:Phone    $51.00      $28.38

Over the past 12 months, I have spent an average of $28.38 per month on phone service. I’m ok with that.

Adding Metadata to Ledger

2020-08-07T00:00:00-07:00

As mentioned previously, two of the primary reasons I use Ledger are the intimate awareness it provides of how money is moving, and its timely representation of current balances. The third primary reason I use the tool is for the activity history it provides.

Recording almost every transaction I make (excepting only some small petty cash) allows me to look at years past and build an accurate picture of what I was doing. Most activities leave some sort of financial record, even if the transaction is only tangential to the activity itself. This is the sort of information that I would be extremely uncomfortable providing to a third-party, but is quite useful to have myself.

Storing receipts provides an additional layer of detail to the history created in the Ledger journal. As an intermediate between the full receipt and the basic journal entry, I find it is extremely valuable to use comments and tags within the journal. Almost every transaction in my Ledger journal that is not for food has a comment describing what goods or service was purchased.

In Ledger, comments begin with a semicolon. I store them below the first line of the transaction. When placed here, Ledger refers to these comments as notes. When purchasing goods, I add one comment – or note – for each unique item on the transaction. For instance, I might buy socks:

2018-07-02=2018-07-01 * Socks Addict
    ; Darn Tough Light Cushion No Show Tab, Black/Grey, Large, 2x
    Expenses:Clothing:Footwear                $33.40
    Liabilities:Bank:Visa

The comment tells me exactly what was purchased. More importantly, it tells me the model name, the color, and the size of the item. If I want to purchase another pair of identical socks, I can do so easily. This seems like a minor thing, but when it is applied to everything I buy, it is hard to overstate how greatly this ability has improved my quality of life over the past decade.

In Ledger, comments are searchable. Say I want to list every transaction where I purchased a pair of Darn Tough socks. I buy them from different retailers, so I can’t filter by the payee. All the transactions are in the Expenses:Clothing:Footwear category, but that category includes socks from other manufacturers and well as other things that go on my feet, so I can’t filter by that. But I can query all transactions with a note which includes the string “darn tough”.

$ ledger register note darn tough

A tag is a special kind of comment. Tags are useful if you have the foresight to realize that a particular transaction should be grouped with other transactions, but that transactions within the group will likely have different payees or accounts. Tags start and end with a :. Multiple tags can be chained together.

I use tags for vacations. Expenses related to any vacation are tagged with two tags: a generic :vacation: tag, and a tag specific to the vacation. This allows me to easily see what I spend on vacations in general, or any one vacation specifically. For example, in 2018 I took a 24-hour trip to Las Vegas to see Nine Inch Nails. That trip included numerous transactions in unrelated accounts: concert tickets, airline tickets, accommodations, ground transport, food, etc. All transactions were tagged with :vacation: and :nin-vegas-2018:. As an example, here is the transaction for purchasing the concert tickets:

2018-03-30=2018-03-28 * AXS
    ; Nine Inch Nails at The Joint, Las Vegas
    ; :nin-vegas-2018:vacation:
    Expenses:Entertainment:Performance        $95.50
    Assets:Bank:Checking

Ledger makes it easy to see all the expenses associated with that trip, both in total and broken out into different expense accounts.

$ ledger balance expense and %nin-vegas-2018

I also use tags to indicate transactions that occur via the same merchant system but have different payees. Specifically, things I buy on Etsy are tagged :esty: and things I buy on eBay are tagged :ebay:. Without these tags I would have no way to list all the Etsy purchases I have made, since I send the money to individual sellers and not Etsy itself.

I also use tags to indicate transactions related to keeping my apartment. Rent goes to the Expenses:Rent account. Electricity charges go to Expenses:Utilities:Electric. Gas charges go to Expenses:Utilities:Gas. My cell phone payment goes to Expenses:Utilities:Phone. The first three charges I consider apartment expenses. My cell phone is not. By tagging the first three with :apt: I can easily see the total monthly cost of keeping my apartment, without a bunch of complicated querying to exclude things like the cell phone bill.

My final use for tags is indicating transactions that I think should be deducted from my taxes. Some people do this with accounts, but I find that with the account structure that makes sense to me I often end up with a mix of deductible and non-deductible transactions within a single account. Tagging deductible transactions with :deduct: makes it easy to dump a list of all transactions that should be considered when completing yearly taxes.

Reconciling Ledger

2020-08-06T00:00:00-07:00

For me, one of the primary appeals of using Ledger – or really any accounting system – is that it let’s me know how much money I have (or don’t have) right now. Other people’s records lag behind reality.

If I submit an order for a $50 widget on a website today, I consider that $50 gone, even though the vendor likely didn’t collect the money immediately. They probably placed a hold on the funds, but will not actually capture the money until they ship the order, which may take a couple days. When they do capture the funds, it may still be another day or two until that action posts to my online bank statement. Were I dependent on the bank, I could go a week thinking that I have $50 more than I actually have.

It is important to me that I log transactions without waiting for them to appear elsewhere, but at some point I do want to reconcile my records against what my bank believes. I accomplish this with auxiliary dates.

Were I to submit that order for a $50 widget today, I would create the entry using today’s date. Even if it takes me a few days to actually record the entry, I will still use the date the order was submitted.

2020-08-06 Acme, Inc
    Expenses:Misc                             $50.00
    Assets:Bank:Checking

Periodically, I will manually reconcile every transaction in my journal against my bank’s online statements. Usually this happens every other week or so. Many people will simply dump a CSV from their bank and use a script to parse and import the results into their journal. I prefer to do it manually. This rarely takes more than 30 minutes, and for me it is one of the other primary appeals of using Ledger: it forces me to be intimately aware of how money is flowing in my life, and makes it extremely easy to spot problems or errors. It is difficult to accomplish that reliably without manually touching every transaction.

So a week or two later I’ll login to the bank and make sure there is a $50 payment to Acme, Inc. If the date listed by the bank for that transaction is different from what I recorded – which for online transactions is almost always the case – I’ll prepend that date to my entry.

2020-08-10=2020-08-06 Acme, Inc
    Expenses:Misc                             $50.00
    Assets:Bank:Checking

When there are two dates, Ledger considers the date to the left of the = to be the primary date. The other date is the auxiliary date. Previously, when only one date was listed, it was the equivalent to 2020-08-06=2020-08-06. By using the bank’s date as the primary date, I know that the default output from a report like ledger register assets:bank:checking will match the bank’s statements. If I want to report on what I consider to be the real dates of the transactions, I can pass the --aux-date flag.

The journal files themselves I edit manually in vim, with a little help from vim-ledger. I have <leader>t mapped to set today’s date as the primary date of the current transaction. Because I usually only reconcile two or three times a month, today’s date is often not the date I actually want, but this shortcut allows me to immediately insert a new date in the correct format. I can then quickly change the day number to whatever it should actually be.

I consider the transaction to be cleared once the bank statement and the Ledger journal file agree on the date, payee, and dollar amount. In Ledger, transactions are marked as cleared by inserting an * between the date and the payee. In vim I map this to <leader>c. A complete transaction thus looks like this:

2020-08-10=2020-08-06 * Acme, Inc
    Expenses:Misc                             $50.00
    Assets:Bank:Checking

Ledger defaults to including all transactions in its reporting and calculations. By passing the --cleared flag it will only include transactions that have been marked as cleared. So after I think I’m done reconciling all transactions against my bank statement, I will run ledger balance assets:bank:checking --cleared and verify that the resulting balance matches what the bank shows. If I want to know how much money I actually have in that account, I will run ledger balance assets:bank:checking. The output of this will likely include transactions that the bank hasn’t caught on to yet.

If for some reason Ledger’s output of the cleared balance does not agree with the bank, my first step will be to make sure that all transactions are sorted by their primary date. If I already have the file open in vim, I have a shortcut for that. Otherwise I keep a one-liner script called ledger-sort that takes the name of a ledger file as input, sorts it, and shows me the diff.

#!/bin/sh

ledger -f $1 print --sort d > $1.sort && mv $1{.sort,} && git diff

Checking the diff of the sorted output before continuing is important. Sometimes I’ll make a silly mistake like typing the wrong year when entering the transaction. This sort of mistake is obvious when looking at the diff.

Once the file is sorted, I’ll run ledger register assets:bank:checking --cleared. The final column in this output is a running total of the account balance. The only difference between the output and my bank statement should be the ordering of transactions within a day, which I do not care about.

I’ll know that I last cleared my journal around a certain date, and that the account balance was accurate as of that date.¹ If I was doing this on 2020-08-06, I might say to myself “I know I cleared Ledger sometime in mid-July, so let’s look at my account balance at end of day on 2020-07-15”. If the bank and Ledger both agree on the balance at the end of day on that date (regardless of the ordering of the multiple transactions that may have occurred on the day), I’ll know that the error is somewhere between 2020-07-16 and 2020-08-06. Next I’ll jump to another random day in that period – maybe 2020-07-22 – and perform the same exercise. This is repeated until I find the first day where the two systems disagree on the ending balance. Then I look at every transaction on that day and find the error. Usually it will be a simple data entry error, such as me typing $12.10 instead of $12.01. Having my receipts stored allows me to verify that I did indeed agree to pay $12.10 and that the error is mine rather than the payee’s. This whole process of finding errors rarely requires more than two minutes, and occurs maybe once every three months.

Though I don’t use CSV exports from my banks for anything, I do like to periodically download and archive them. When I generate the exports I ask for one file per month. I refer to these as “bank dumps” and store them in directory named dump. Each file is named for the account and month it represents. For example, an account named Assets:Bank:Savings will have last month’s dump stored at dump/assets-bank-savings-202007.csv. I pretty much never open these files, but I like having them archived. They allow me to see how much money a bank thought I had at any point in time, even if the account is no longer open, and provide assurance that I can always true my records if I somehow mess them up.

Notes

↵ Ledger has the ability to record assertions. I have never used this feature, but I probably should.

Receipts and Ledger

2020-08-05T00:00:00-07:00

As previously mentioned, I store receipts in the same repository as my Ledger data files.

Purchasing something online automatically generates a receipt; it’s just a simple matter of saving the confirmation web page or email as a PDF and moving it into the proper directory with the proper filename. That’s a low enough bar that I cannot justify not storing them. I have a receipt for every digital transaction I have made since I began using Ledger in 2012.

I’m less strict about storing receipts for transactions that occur in meatspace. These transactions usually result in a paper receipt (which may not be initially even be offered), which then requires scanning or photographing. That is just enough effort that I don’t always want to do it. I’ll store the receipt for a meatspace transaction if the amount is greater than $100, or if I think it might be tax deductible, or if I think I might make a warranty claim. But if the transaction is a $10 sandwich for lunch, I probably won’t bother storing the receipt.

My naming scheme for the receipt files consists of the date of the transaction, the amount, and the payee. This is enough information to go from a Ledger journal entry to a receipt, or from a receipt to a Ledger journal entry. For example, consider a transaction with a journal entry like this:

2020-07-14 Acme Widgets
    Expenses:Bicycle:Parts                    $23.72
    Assets:PayPal

The receipt for that transaction will be at receipts/20200714_23.72-acme_widgets.pdf.

When I first began using Ledger and came up with this file naming scheme, I figured I would write some sort of script that would parse the components of a journal entry and generate the expected receipt filename so that I could quickly jump from one to the other. What I found is that the scheme is simple enough to make such a script unnecessary. When I look at a journal entry I intuitively know what the receipt filename is, and when I look at a receipt filename I intuitively know what the journal entry is. Writing a simple script to generate one from the other would take more energy than I have collectively spent over the past eight years solving the problem manually. So I never wrote it.

I also store invoices in the same repository, in a directory creatively named invoices. These are invoices that vendors send me – primarily things like rent statements and utility bills – not invoices that I send to people. The naming scheme is the same as what I use for receipts, except in this case the date in the filename is the date the vendor included on the invoice rather than the date I received it or paid it. I chose this because if I ever need to dispute a charge or a payment, this date is an easy way for both the vendor and I to quickly verify that we are discussing the same thing. Each invoice will of course have an associated receipt in the receipts directory after I pay it, and the date on this file will be the date on which I submitted the payment.

Every now and then I need to write someone an old-fashioned paper check. These get scanned and stored in a checks directory. The file naming scheme for these is similar to that of receipts, except that in addition to the date, amount and payee, I also include the check number. Ledger supports including the check number in the journal entry, so including it in the filename provides another way to link the two things. For example, back in 2015 I renewed my passport book and bought a passport card:

2015-11-09=2015-10-31 * (#1047) US Department of State
    ; Passport Book Renewal
    ; Passport Card Purchase
    Expenses:Travel:Documentation            $140.00
    Assets:Bank:Checking

The scan of the check from that transaction lives at checks/20151031_140.00-1047-us_department_of_state.pdf.

Tracking Cash with Ledger

2020-08-04T00:00:00-07:00

In a double-entry accounting system like Ledger, money always moves from one account to another. Money cannot be magicked in or out of existence.

Previously I mentioned that I sometimes do not track cash transactions. If the transaction is less than $20 and is not related to a category of expense I care about, I may not bother with it. At first glance, this may seem like it conflicts with the inability to magically disappear money. If I take cash out of my checking account, I have to represent that withdrawal or else the balance of the account will be screwy and I’ll never be able to reconcile it against the bank’s statement. Transforming money from electrons in a bank account to Federal Reserve Notes in my pocket has no impact on its value, so one’s initial thought may to represent the cash as an asset account.

2020-07-13 ATM
    Assets:Cash                               $40.00
    Assets:Bank:Checking

This would be technically correct, and the best way to do things if every last penny of that cash was going to be tracked. But logging the withdrawal that way will not work if, over some period of time, I spend the $40 cash in a serious of small, untracked transactions. In that case, my Assets:Cash account would show that I have $40 more than reality. When asset accounts are not accurate, the world ends.

The solution is to treat cash as an expense account. The balance of an expense account is less important. It tells you how much money you’ve spent on that category of thing, but it doesn’t represent money that you hold. Effectively, this is saying that the $40 was spent when it was withdrawn at the ATM. It no longer contributes to assets or net worth.

2020-07-13 ATM
    Expenses:Cash                             $40.00
    Assets:Bank:Checking

The transaction would look similar if I asked for cash back while buying groceries.

2020-03-20 Lucky Dragon Markets
    Expenses:Food:Groceries                   $58.89
    Expenses:Cash                             $40.00
    Assets:Bank:Checking

But the trick is that money doesn’t have to move between an expense account and an asset account. Money can move between any accounts, including two expense accounts. I am strict about tracking food related expenses, so if I buy a burrito with that cash, I’ll want to log it. I can do that like this:

2020-07-18 A Taqueria
    Expenses:Food:Dining:Lunch                 $8.23
    Expenses:Cash

If part of your savings are in cash – in a safe deposit box, stuffed in your mattress, buried in the hills, whatever – you would want to treat it as an asset so that you can track the balance.

2020-08-30 ATM
    Assets:Mattress                          $100.00
    Assets:Bank:Checking

To illustrate the degree to which I do track cash: Ledger currently reports the balance of Expenses:Cash to be $3797.29. I’ve certainly dealt with significantly more cash than that since 2012. The balance of that account is simply the amount of cash I have acquired but failed to log as spent.

Organizing Ledger

2020-08-03T00:00:00-07:00

Ledger is a double-entry accounting system that stores data in plain text. I began using it in 2012. Almost every dollar that has passed through my world since then is tracked by Ledger.¹

Ledger is not the only plain text accounting system out there. It has inspired others, such as hledger and beancount. I began with Ledger for lack of a compelling argument in favor of the alternatives. After close to a decade of use, my only regret is that I didn’t start using earlier.

My Ledger repository is stored at ~/library/ledger. This repository contains a data directory, which includes yearly Ledger journal files such as data/2019.ldg and data/2020.ldg. Ledger files don’t necessarily need to be split at all, but I like having one file per year. In January, after I clear the last transaction from the previous year, I know the year is locked and the file never gets touched again (unless I go back in to rejigger my account structure).

The root of the directory has a .ledger file which includes all of these data files, plus a special journal file with periodic transactions that I sometimes use for budgeting. My ~/.ledgerrc file tells Ledger to use the .ledger file as the primary journal, which has the effect of including all the yearly files.

$ cat ~/.ledgerrc
--file ~/library/ledger/.ledger
--date-format=%Y-%m-%d

$ cat ~/library/ledger/.ledger
include data/periodic.ldg
include data/2012.ldg
include data/2013.ldg
include data/2014.ldg
include data/2015.ldg
include data/2016.ldg
include data/2017.ldg
include data/2018.ldg
include data/2019.ldg
include data/2020.ldg

Ledger’s include format does support globbing (ie include data/*.ldg) but the ordering of the transactions can get weird, so I prefer to be explicit.

The repository also contains receipts in the receipts directory, invoices in the invoices directory, scans of checks (remember those?) in the checks directory, and CSV dumps from banks in the dump directory.

$ tree -d ~/library/ledger
/home/pigmonkey/library/ledger
├── checks
├── data
├── dump
├── invoices
└── receipts

5 directories

The repository is managed using a mix of vanilla git and git-annex.² It is important to me that the Ledger journal files in the data directory are stored directly in git. I want the ability to diff changes before committing them, and to be able to pull the history of those files. Every other file I want stored in git-annex. I don’t care about the history of files like PDF receipts. They never change. In fact, I want to make them read-only so I can’t accidentally change them. I want encrypted versions of them distributed to my numerous special remotes for safekeeping, and someday I may even want to drop old receipts or invoices from my local store so that they don’t take up disk space until I actually need to read them. That sounds like asking a lot, but git-annex magically solves all the problems with its largefiles configuration option.

$ cat ~/library/ledger/.gitattributes
*.ldg annex.largefiles=nothing

This tells git-annex that any file ending with *.ldg should not be treated as a “large file”, which means it should be added directly to git. Any other file should be added to git-annex and locked, making it read-only. Having this configured means that I can just blindly git annex add . or git add . within the repository and git-annex will always do the right thing.

I don’t run the git-annex assistant in this repository because I don’t want any automatic commits. Like a traditional git repository, I only commit changes to Ledger’s journal files after reviewing the diffs, and I want those commits to have meaningful messages.

Notes

↵ I do not always track miscellaneous cash transactions less than $20. If a thing costs more than that, it is worth tracking, regardless of what it is or how it was purchased. If it costs less than that, and it isn't part of a meaningful expense account, I'll probably let laziness win out. If I buy a $8 sandwich for lunch with cash, it'll get logged, because I care about tracking dining expenses. If I buy a $1 pencil erasure, I probably won't log it, because it isn't part of an account worth considering.
↵ I bet you saw that coming.

Experience at the Bitcoin ATM

2019-08-27T00:00:00-07:00

Recently I had need of Bitcoin. For a thing.

I decided to use this need as an excuse to try a Bitcoin ATM. I’d noticed them appearing throughout town over the past few years but never had a reason to use one.

The liquor store that I chose had a General Bytes BATMTwo. It was simple to use, but slow. After selecting the button to begin, it sat at a loading screen for a good minute. After loading, it showed me the current exchange rate for BTC (there was no option for a different currency) and asked if I wanted to deposit more or less than $1000 USD. I selected less. It then asked me to input a phone number where it could send an SMS. After giving it my number I waited around for about another minute until it sent me a message with a 5 digit number. I entered that number into the ATM, after which it allowed me to proceed.

It next prompted me to scan a QR code for an existing destination wallet, or to hit another button if I did not yet have a wallet created. I didn’t see any option to manually enter an address. I assumed it would want a QR code, so before I embarked on this journey of discovery I had generated a new wallet on my computer, saved its address as both a QR code and as plain text, and copied those files to my phone. Getting it scan the QR code from my phone screen took a few seconds of finagling, but this is typical of reading any barcode from a phone in my experience. After it read the code it took me to the next screen and prompted me to insert bills. This screen also showed the destination address, how much fiat currency I had deposited, and what the amount of Bitcoin received would be. I opened the text file on my phone where I had saved the wallet address and verified that this matched what it had decoded from the QR code.

I wanted to deposit multiple bills, but it did not indicate if I should feed all of them in at once or one at time. I decided to insert them one at a time. As I did this it correctly displayed the amount of money I had deposited. It read all the bills successfully. However, the BTC amount stayed at 0, and it displayed a loading message in one corner of the screen. This began another wait, again of about 60 seconds, until it calculated the amount of BTC I would receive. I suppose it was fetching the current exchange rate, though if it gets an updated rate at this stage I’m not sure why it wasted time fetching the exchange rate back in the initial step.

Once it had showed me the amount of BTC I would receive I hit the button indicating I was done inserting bills. It immediately displayed a confirmation screen that said the transaction was complete, with a confirmation of the USD deposited, the BTC received, and a transaction ID. At this point it asked me if I was done or if I wanted a receipt. I selected the receipt option to see what it would look like. It asked if I would like a receipt via SMS or email. Since it already had my phone number, I selected SMS. It immediately said that the receipt was sent, and then a few seconds later when back to its idling screen for the next customer. About a minute later the SMS receipt arrived. The message included the transaction ID, localized timestamp, USD deposited, BTC purchased, and destination wallet address.

I didn’t get back to my computer until about 45 minutes later. When I checked the funds were in my wallet, but I’m not sure how immediately they appeared.

The ATM claimed to impose no fees, but the exchange rate it offered is substandard. At the time I completed the transaction I believe the price on Coinbase was about $10,123.47. Given the amount of BTC that ended up in my wallet, the price the machine offered me was about $12,208.17.

Still, the process was simple, and the results quick. This is the first time I purchased Bitcoin with cash since circa 2012, when there was a service that would allow you to make a cash deposit into a random Wells Fargo account in exchange for Bitcoin. I used this service half a dozen times or so and never had a bad experience, but the whole transaction took a few hours to complete – and I remember hearing that the person who ran it was later arrested for something or other. The ATM experience certainly felt less shady.

From a privacy standpoint, the only personal information required by the ATM was a phone number that was able to receive a SMS. I’m not sure what General Bytes feels they are accomplishing by going through the steps for the SMS token, but it is a requirement that is easy enough to satisfy.

Lately I've had trouble finding prepaid debit cards in denominations greater than $50.

2016-04-19T00:00:00-07:00

It’s 2016, and stuffing cash in an envelope and mailing it to a small island nation is sometimes still the best way to move money with some degree of privacy.

This is not the cyberpunk dystopia I was promised.

I stopped worrying and embraced the security freeze.

2016-02-28T00:00:00-08:00

A credit security freeze denies access to your credit file. I first learned about it last summer from Brian Krebs, but didn’t implement it until a couple months later. It took me about 45 minutes and $20 to activate the freeze with the five major credit bureaus. This goes a long way to reducing the threat of identify theft, with very little energy expenditure required. A proactive defense is superior to reactive monitoring services. If you need your credit pulled monthly or more frequently, constantly freezing and unfreezing your file would probably be an annoying inconvenience. For the rest of us, I’m not sure if there is any good reason not to enable the freeze.

Financial Defense Through Proxies

2015-12-29T00:00:00-08:00

Brian Krebs’ recent experience highlights PayPal’s insecurity. The convenience and ease of use of PayPal give them a wide customer base, but their inherent untrustworthiness has long been reason for concern. For as long as I’ve used the service, I’ve been concerned about external attacks, like what Krebs experienced, as well as the internal threat – PayPal themselves have a history of freezing and diverting their users’ funds. Both of these concerns can be addressed via a proxy bank.

In 2008 I opened an online checking account with a new bank, completely separate from the financial institutions I normally use. The account has no “overdraft protection” or any line of credit. As with my PayPal account, I keep no money in the checking account. This checking account is the only account I associate with PayPal. When I want to make a purchase via PayPal, I transfer the needed funds from my primary financial institution to the checking account at the proxy bank. Since banks still subscribe to the archaic notion of “business days”, this transfer can sometime take up to week, but more frequently completes within 2-3 days.

The brief wait period is acceptable to me (it certainly reduces the ability to impulse buy) and gives me a level of security that otherwise cannot be achieved with PayPal. If someone breaks into my PayPal account, there’s nothing for them to steal. Even PayPal themselves have limited ability to steal funds. If an attacker is lucky, they may gain access to the account when I’m transferring funds in preparation for a purchase. My PayPal transactions are typically low-value, so at most this lucky attacker will acquire $100 or so. That’s an acceptable risk for the convenience of PayPal.

In the past I used this multilayer approach for all online purchases. A debit card from a proxy checking account at a different bank with no access to my primary accounts was the only thing I would use to make online purchases. When the account was compromised, the wait period for a new card wasn’t the inconvenience it normally is, since it had no impact on my day-to-day spending with my primary accounts. I think this type of security is required for shopping online, but responsible use of a credit card can offer acceptable protection for non-PayPal transactions without the hassle of a proxy account.

I wrote an article about anonymous debit cards on ITS Tactical.

2013-04-23T00:00:00-07:00

I have previously mentioned prepaid debit cards. On ITS I discuss using prepaid debit cards for anonymous, cash-like digital transactions a bit more in-depth.

Gwern offers an excellent overview of Silk Road.

2013-02-23T00:00:00-08:00

In the essay he introduces the website and describes his experience as a user purchasing illegal drugs. It is well worth the read. I’ve spent hours on his website perusing his other works.

Simon provides anonymous debit cards.

2012-11-09T00:00:00-08:00

Their prepaid Visa and American Express gift cards can be purchased with cash at any Simon mall. No identification is required. To use the card with online merchants, you will likely need to register the card with an address so that it can pass AVS checks. This can be done through Tor with fake information.

Bitcoins are not a value-store.

2012-10-17T00:00:00-07:00

When I first learned about the Bitcoin currency a few years ago, it didn’t excite me. A purely digital currency tied to no material good seemed an interesting project, but I didn’t see that it could have the practical value of, say, a digital gold currency. When the media blitz occurred last year I took another look and reached the same conclusion. A few months later I realized I was looking at the currency all wrong: bitcoins are not a value-store, they’re a means of exchange.

It doesn’t matter that Bitcoins are the digital equivalent of a fiat currency, with no inherent value. It doesn’t matter if their value fluctuates in relation to other currencies. There’s no reason to store wealth in Bitcoins (unless you’re a gambler). When you need to send money, purchase some Bitcoins and send them. When you need to receive money, accept Bitcoins and exchange them immediately for another currency. The value of the bitcoins only need to remain stable for the amount of time it takes to complete a transaction.

Bitcoins are not insecure.

2012-10-03T00:00:00-07:00

I’m no Bitcoin evangelist. I have my reservations about the currency. But one common critique that consistently angers me is that bitcoins are not secure because there have been instances of theft. This is equivalent to claiming that Federal Reserve Notes are insecure because people get mugged. Secure your shit.