I have been a full time Free Software developer since the 90's. I worked on the Linux Kernel, where I wrote ipchains, iptables, and rewrote the module subsystem, along with many other things. I changed careers in 2015 to work on Bitcoin full time, and was the first person to implement Lightning: I then chaired the Lightning Protocol Spec effort for several years, and that's my current job and hobby.
After each release, we remove the features and options which were EOL in the previous one (we give one release during which features can be re-enabled by the i-promise-to-fix-broken-api-user option).
This is an “eat your veggies!” talk, which is an indepth review of an excellent PR by @dovgopoly. When someone first submits a PR, I like to explain every detail of how I would have done it, so they have some guidance about what the process looks like.
After the previous aside on a gossip bug, I realized I should do a tour of each daemon. I started with gossipd because it’s my favorite, having changed so much from what it originally did into something which now mainly exports the “gossip_store” file for other subdaemons and plugins to use.
I stumbled over a bug while doing some work on gossipd, so I decided to record myself tracking it down.
This post is all about tal repostory, which is the CCAN module which I consider compulsory for any program which ever explicitly frees memory (you can write some very complex programs which don’t do that, FWIW!).
This is the start of a one-per-workday video series, introducing Core Lightning Development to already-fluent C programmers.
This post is all about the CCAN repostory, which contains all kinds of useful C routines which we use all over Core Lightning. It lives, these days, on GitHub.
In my previous posts I’ve been carefully considering what bitcoin Script improvements we might want if we had introspection. Script was hobbled back in v0.3.1 due to denial-of-service issues: this has been a long-ongoing source of regret, but functions like OP_TXHASH bring Script limitations into clear focus.
BIP-341 defines Taproot outputs as either a single key, or a key and some script info. You use a dummy key if you only want to use the script. This “tapscript” is currently very similar to Segwit v0 P2WSH, but carefully defined to be easily upgradable.
As I explore the use of Bitcoin Script for introspection, I am not overly concerned with total script size, because if common usage patterns emerge those can be soft-forked into new opcodes, or new address types. But I have been concerned with constructions which require the use of Child-Pays-For-Parent for fee paying, as that makes the transaction significantly more expensive than using inline…