2023 Feb 05

• It’s interesting the balance of having a strict and lax filter for content/ideas. I’ve recently been intaking more stuff by Peter Zeihan who wrote this popular book lately. On one hand, he’s gotten me to think and understand connections I would get from few other places, and even before I’d known his background, I just thought he was some random guy, and having that low barrier for considering his ideas was valuable. But at the same time, he seems to just talk with little consideration, as in he states things as fact that he might not necessarily know for sure (and seldom acknowledges his uncertainty), e.g. he said something about blockchain the other day that was really stupid, and it made me question everything else he’s said. If I were to filter out all of the kinds of content that do something like this, I may be led to read only the greatest texts and go directly to the source, which would maybe be worthwhile in its own right.

• Building with LDK

  • I’ve realized that ldk-sample > getting started docs. It’s kept up to date very well.

    • I’ve also realized few people are probably going to start building a node or something from scratch, and instead will fork ldk-sample. I got a little bit of an idea of what are the components that come together from trying this out, but it wasn’t as helpful as I thought. I’m still sort of aimless in what I want to build, which I think has been holding me back.

    • Idea: turn ldk-sample into a daemon + CLI, integrate with a BDK wallet, use BIP 157/158 as chain source (contribute to BDK?), use rapid gossip sync, figure out async payments, slap it on mobile

      • End goal: self-custodial lightning on mobile. If I’m building something let’s just go for that out the gate and see where it takes us

    • I think I will have better luck building and learning if I just try to adapt ldk-sample to what I want to do instead of building from scratch. In the meantime I’ll pick up another issue because I don’t think I’m going to make too much progress building something on my own at this very moment, but I can help out on smaller stuff in the meantime.

• Attack surface: I saw there is a setting for manually_accept_inbound_channels and the default is false. It made sense to me that it’d be false, because what harm is there in having someone provide you with inbound liquidity and pay to open a channel? But if it’s someone you don’t know/trust, you may end up using this channel to pay or be paid. If you’re not careful, just from someone having a channel open with you could lead to: channel jamming by routing through you, involving you in an attack where they force many channel parties to have to broadcast on-chain at the same time, they could making routing more difficult if they know you’re relying on them, probably more things.

  • A bit ago when I gave the part 2 of my Bitcoin talk, someone asked “doesn’t lightning reintroduce that reliance of trust” getting at that it’s contradictory to the ethos of Bitcoin. I answered saying how lightning is designed to still be trust minimizing, and at the time I felt that on aggregate lightning was still pretty much trustless, that at the end of the day whatever your counterparty does, you can always get your funds back. But it’s more nuanced than that. First, it’s not totally trustless (much more than fiat, but much less than on-chain payments) (at the moment), it definitely does bring a bit of trust back in, but importantly, that’s a part of how a layered money system works. It brings some trust back in, but allows for fast and cheap payments.

• Trying pick up this issue. Looks fun.