2023 Feb 22

• Cool well produced videos explaining Bitcoin concepts.

• I feel like I’m in a weird spot where I’m probably not helping thaat much

  • Nah. I’m basically still new the repo. Can still help out with public docs, but can also ask more conceptual questions about code. Go through PR looking through these things primarily. Don’t need to comment on random stuff, just things that actually stand out.

  • Still would definitely benefit from building some other stuff in Rust to grow more opinions about how it’s used. I can get this from reviewing and making PRs, but I think I’ll get it a lot faster through a side project.

• Open sourcing code is sort of like peer review in research. A very small portion of the people who use the product or information found from research are reading the code or the paper, but other engineers and researchers will review it and point out if there’s something wrong. Just because something is open source doesn’t mean it’s totally secure (and just because something isn’t open source doesn’t mean it’s insecure), but it’s necessary to ensuring publicly that things are right.

• Why does everyone comment “needs rebase” on other people’s PRs? Shouldn’t it be understood to intermittently rebase as a PR author?

• When reviewing PRs in local branch - use git diff --merge-base main (or better replace main with FETCH_HEAD after fetching main to avoid having to git pull) to see changes in case it needs rebase. Add --stat to end of git diff to just get the number of line changes to each file.

• Git stuff is all 80 char limits.

• * goes to next occurrence of the word currently under the cursor, # goes back!

• Review

  • When are these params deserialized/why would they be? They are included in events, and events are serialized because they are persisted in case of a crash. So in this case, RouteParameters are serialized, because they are included in Event::PaymentFailed as they’re needed in order to possibly retry a payment. All events are serializable, but this one is important to be persisted because in case of a crash, a node would still want to know to respond to this event either to retry or abandon a payment upon starting up again (and all the necessary information to do so).

  • Generally I’m realizing a lot of the difficulty of a lightning implementation is that your node could crash at literally any point, and you 1. should not lose your funds because of it and 2. your node should be able to resume whatever it was doing previous to crashing (as a part of not losing funds, but also for general UX). For non-custodial lightning the responsibility of maintaining all this data is on you/your node, so it’s important that your node’s software can automate this and make it as seamless as possible.

  • You can define generics in a trait such that you can implement the trait with a function that accepts a different type for a parameter, e.g.

    pub trait FooTrait<P> {
    	fn read<R: Read>(reader: &mut R, params: P) -> Result<..>;
    }
    
    // impl
    impl FooTrait for Bar {
    	fn read<R: Read>(reader: &mut R, number: u32) -> Result<..> {}
    }
    

  • The tt Token Tree is basically a “match anything” fragment specifier.

  • ? along with * and + are used similar to regex for matching in macros, 0|1, 0..inf, 1..inf respectively.

• How to store PGP keys safely?

• Didn’t know about keystone, looks very solid.

• Simple bitcoin inheritance: send to script that’s spendable by your heir’s key after a certain time, otherwise spendable by you until that time. Extend the time as you continue to live.

• Can probably change cryptopals idea to just be a CLI that runs locally

  • Can just take input or commands from stdin and run tests locally