Andrew Poelstra

We can add these if they make derives more convenient (I think `Default` makes sense, at least as much as it makes sense for every std numeric type, though `Ord`...

Reading through the codebase it looks like you have a ton of custom checksummed-data-parsing code that should be able to be removed entirely and replaced with calls into the new...

Ah, ok, because LN invoices have fields which are 5-bit aligned you probably do want to work with `Fe`s, at least during parsing and serialization. But I don't think you...

@optout21 so, after having worked on this for a few days I've nearly converted the serialization logic to the new bech32 library. I think this issue is really nontrivial. Essentially,...

lightning-invoices have a bech32 checksum on them. This requires field properties and is exactly what `rust-bech32` is designed for. As far as I can tell, every other use of `u5`s...

FYI I have a branch where I've been working on this https://github.com/apoelstra/rust-lightning/tree/2024-08--new-bech32 Though it is a bit of a mess; it needs https://github.com/lightningdevkit/rust-lightning/pull/3234

You need to use boost 1.75 for 22.x. In Nix you can do this with `boost = nixpkgs.boost175;`. On Arch IIRC I would spin up an old Debian VM :P.

If "how it runs on X" means "how it runs with the default version of all dependencies provided by X" then it pretty-much doesn't run anywhere :).

Actually let me double-check on this. It looks like elements 0.21 worked for me with boost 1.81 (and does *not* work with 1.75).

re dependencies, I was able to build elements 22.1.1 with clang and ``` db 4.8.30 boost 1.75.0 zlib 1.3.1 zeromq 4.3.5 miniupnpc 2.2.7 protobuf 25.4 libevent 2.1.12 ``` But as...