One of the joys of calling yourself a “junior developer” is that you give yourself the freedom to make silly mistakes and learn from them.
I learned this trick from one of the smartest and kindest people I’ve ever worked with, Tom Copeland. (Fun fact: I worked with him outside of work at one job briefly about ten years before I worked with him directly inside work.)
I’ve written recently about being open and assertive about learning from other people, but sometimes you have to learn things the hard way on your own. If not necessarily the hard way, you have to give yourself that facepalm moment.
Do a Thing When Something Interesting Happens
This entire domain name came about in 2021 when I had a silly idea. “What if Dogecoin had webhooks?” In other words, “What if, whenever a wallet received a transaction, something could happen?”
That could be sending an email or Tweeting a tweet, flashing a neon “GOOD NEWS, EVERYONE” sign in your rumpus room, posting a random Giphy image in Slack or Discord, or any of a thousand other things. In other words, IFTTT for the tipping blockchain.
That code isn’t ready yet (although), but I’ve been testing it on my own for a while, because I don’t want to be tied to a laptop or desktop machine running a full node to see if something has happened.
If you were, for example, trying to run an arcade with cryptocurrency payments you might also find such a thing useful. This isn’t the only way to achieve these results, but it could be a way to achieve these results.
Anyhow, I found a bug.
Double-Entry Accounting
In the second job where I worked with Tom Copeland, we had an application that calculated payments to salespeople and our suppliers. This application had lots of bugs that had to be fixed, and ultimately that meant sitting down with our users, the financial operations people, to understand accounting.
There’s a lot to learn about accounting, but the most useful trick of all is that every transaction should equal zero. At least, that’s the lesson I took away from double-entry accounting.
Suppose I have 50 Doge in a wallet from two deposits of 25 Doge each, and I think minty made a really cool image and I want to tip 42 Doge in appreciation. Support the arts!
If you follow the principles of double-entry accounting and blockchain principles, I need to consume the inputs that put 50 Doge in my wallet and produce outputs that account for all of those 50 Doge going somewhere.
In simplest terms, assuming zero transaction fees, 42 Doge go to minty’s wallet and 8 go back into mine.
All of the input transactions get consumed to produce a transaction with two outputs: 42 to minty and 8 back to me. Fold up that five and three ones and stash them away for Taco Tuesday!
Anyhow, this showed me a bug.
I Am Not a GDP of One
Here’s the problem.
I immediately received an email saying “Cool, your wallet just received a payment!”
“What?” I said. “I just sent a payment. That’s backwards!”
This forehead-slapping moment is the best and worst part of debugging. It’s the best because you realize what the bug is and, often, how to fix it. It’s the worst because you realize you totally could have figured it out beforehand and never written the bug in the first place.
If you take $10 out of your wallet and spin in a circle and put $10 back in your wallet, how much money do you have in your wallet? The same as when you started. You know this. I know this. My code didn’t know this.
The good news is that I have code in a branch that lays the groundwork to fix this problem by tracking the source of the transaction. If it’s the same as the destination wallet, assume the Doge going into the destination is change and don’t treat it as a new input.
It’s simple when you phrase it that way, isn’t it?
It’ll be simple to code too, but it’s kind of a funny story anyhow.
