Trickle charging spare batteries in the van (by )

So, my van is a former "welfare van"; originally the sort of thing that would pull up next to some roadworks, offering a space for the crew to shelter from the rain and have their lunch. The back has four seats (with belts, so people can travel in them, making it a seven-seater overall), a table and a bunch of storage compartments. But it also has a 200Ah deep-cycle battery pack and a bunch of auxiliary electrical accessories. Read more »

Cool things I have worked on: Customer Relationship Management (by )

Continuing my previous series of blog posts about interesting things I've worked on in my career (an analytical database engine and a transactional database engine), I thought it'd be interesting to talk about something I worked on that's less groundbreaking technology, but interesting in other ways. Read more »

The “Mr Redox” Home Energy Reactor (by )

So, I work from home, which means I spend a lot of time in my workshop.

It's a long, thin, building. The door opens into the metalworking area; moving along the building, we get to the electronics bench, then to my desk. As I've previously mentioned, I want to redesign the place a bit, but I'll still be spending a lot of time in here. I have insulated the roof successfully, but the second front in my war against chilliness is my rocket mass heater.

Read more »

It’s time for Bitcoin to die (by )

In my original writings about Bitcoin ( 2011: Bitcoin Security 2013: The Ups and Downs of Bitconi Bitcoin Pseudoonymity The True Value of a Bitcoin On the Unfair Distribution of Capital Bitcoin and Banks Bitcoin: Better than a Euro Bank?), I was pretty positive about the whole thing, but since then I've changed my mind for three reasons:

  1. The Bitcoin community has become dominated by price speculation/investment, obsessing about its current price, rather than about actually doing Internet money properly.
  2. Perhaps because the price has surged so rapidly, it's become very profitable for miners to compete for the mining bounties, leading to enormous amounts of mining hardware being manufactured and consuming enormous amounts of power.
  3. The Bitcoin protocol has struggled to scale to handle high transaction volumes, in part due to it being a difficult technical problem and in part due to politics with various groups fighting over the correct solution (a fight which, to some extent, is fuelled by the vested interests of investors and miners wanting to keep the status quo), leading to transaction fees being unreasonably high as people compete to get their transactions processed.

In the early days, an increasing number of online shops accepted bitcoin; but many have now stopped, and new ones don't seem to be being added any more. Bitcoin's bid to become Proper Internet Money has, sadly, failed. Perhaps the mining energy issue could have been avoided with a different hashing function that's less amenable to economies of scale, or if the mining rewards had been set lower so that mining wasn't so profitable (or would reducing the supply just push prices up further?)... The scaling issues leading to high fees, and the slow transactions, have meant that Bitcoin remains clunky compared to card payments, so it never took off very well as a way of paying for stuff, meaning that its value focussed more and more on being an investment and a way for transferring large sums. Ironically, it did become "digital gold", but not in a good way.

But Bitcoin isn't the only fish in the sea... Discounting all the I-made-my-own-blockchain clones with no real technological differences, there are a few interesting other cryptocurrencies that have arisen.

First worth mentioning would be Ethereum, which extends Bitcoin's transaction processing model to a much more generic distributed computation model, leading to all sorts of interesting (and sometimes hilarious or horrible) things. However, my main conclusion from watching all this is that human software development practices aren't mature enough to write autonomous financial algorithms yet, so Ethereum is, in my mind, an interesting experiment but not practically useful for anything yet. And it's also proof-of-work based, so has the same problem with miners consuming power, and has people speculating on it as an investment, and so on.

But far more interesting to me right now is Nano, which aims squarely at Bitcoin's original goal - being Internet money. The distributed consensus algorithm doesn't involve mining blocks, so is fast and there aren't transaction fees, and there aren't any miners burning CPU cycles to try and win money. I've tried it, and it actually works; you tell your wallet an address to send to and an amount (or scan a QR code) and press "send" and the money is ready to spend in the recipient's wallet in about a second - with no fees deducted. Instead of using hashing power to break ties, the network uses voting power voluntarily assigned; every Nano wallet appoints a "representative" node, and the voting power of a node is the sum of the balance of the wallets appointing it. Wallets can change what node is their representative instantly by sending a message to the network, so the community can easily ensure that the voting weight is widely spread to avoid anybody having too much power, and debates about protocol changes can be resolved by letting users choose which nodes (running different versions of the software) they give their voting weight to.

It's not all perfect, however. As transactions are free and fast, an attacker can spam the system by creating a bunch of wallets and shuffling tiny amounts of money between them, burdening the network with validating and storing those transactions. As part of the countermeasures against that, transactions submitted by wallets need to have a small proof-of-work attached - meaning that you DO need to burn CPU cycles to make transactions. The amount of CPU work needed depends on the load on the network, to automatically raise the cost of transactions based on how many transactions per second the system can sustain; so will rising legitimate demand outpace the improvements in node hardware and hosting, until the proof-of-work cost of a transaction becomes excessive? Will spammers continue to find ways around the limitations and overload the network (as I write this in March 2021, Nano is recovering from a recent spam attack that has delayed transactions for days, while the developers work on some cunning new algorithms to prevent it happening again)?

And, like any currency whose price is set by the market, Nano will attract speculators, leading to price volatility, which as at the very least an inconvenience to its use as an actual currency.

But it's already allowing some interesting applications. WeNano is a... game of sorts? It's a smartphone-based Nano wallet, but its primary feature is that one can create Pokestop-esque "spots" based on geographical locations on Earth, to which people can donate nano, and then people who are within a certain distance of that spot can claim some of it (subject to a rate limit). The spots also have a chat function, and can act as trading hubs for classified ads paid in Nano, and there's some business integration thing for accepting Nano payments I've not looked into. Spots have been created by people wanting to promote Nano, and as a way to send aid to economically unstable countries (you don't need to be near a location to create a spot there or donate money to it); and presumably, if Nano becomes more widespread, businesses will place spots at their locations to attract footfall. Only a payment system with zero fees could make such a system practical, given the small size of the amounts of money involved. And, to my great relief, it's showing takeup in actual payment applications, such as the Wirex debit card and Kappture point-of-sale payment systems.

Nano isn't the only consensus algorithm without mining, though - there's also the Avalanche algorithm, which looks promising but hasn't built the community of people and applications that Nano has. I have high hopes for it, though!

So - Bitcoin must die, as it's failed to become a useful financial system, and is now just wasting resources on mining. The technology of distributed consensus has moved on, and Bitcoin (and its many clones) are just propelled forwards now by sheer inertia.

Lambda bodies in Scheme (by )

So, if you look at a recent Scheme standard such as R7RS, you'll see that the body of a lambda expression is defined as <definition>* <expression>* <tail expression>; zero or more internal definitions, zero or more expressions evaluated purely for their side-effects and the results discarded, and a tail expression whose evaluation result is the "return value" of the resulting procedure.

I used to find myself using the internal definitions as a kind of let*, writing procedures like so:

(lambda (foo) (define a ...some expression involving foo...) (define b ...some expression involving a and/or foo...) ...some final expression involving all three...)

But the nested defines looked wrong to me, and if I was to follow the specification exactly, I couldn't intersperse side-effecting expressions such as logging or assertions amongst them. And handling exceptional cases with if involved having to create nested blocks with begin.

For many cases, and-let* was my salvation; it works like let*, creating a series of definitions that are inside the lexical scope of all previous definitions, but also aborting the chain if any definition expression returns #f. It also lets you have expressions in the chain that are just there as guard conditions; if they return #f then the chain is aborted there and #f returned, but otherwise the result isn't bound to anything. I would sometimes embed debug logging and asserts as side-effects within expressions that returned #t to avoid aborting the chain, but that was ugly:

(and-let* ((a ...some expression...) (_1 (begin (printf "DEBUG\n") #t)) (_2 (begin (assert (odd? a)) #t))) ...)

And sometimes #f values are meaningful to me and shouldn't abort the whole thing. So I often end up writing code like this:

(let* ((a ...) (b ...)) (printf "DEBUG\n") (assert ...) (if ... (let* ((c ...) (d ...)) ...) ...))

And the indentation slowly creeps across the page...

However, I think I have a much neater solution!

Read more »

WordPress Themes

Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales
Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales