2023 Mar 25

• git clean -fdx - get rid of untracked files (force, directories, ignored files)

• Cryptopals challenge 30. Same MAC length extension but with MD4. MD4 and SHA1 share a lot of similarities. They use the same bitwise operators while scrambling, merkle damgard construction (which is why simple secret prefix MACs based on this suffer from length extension attacks), and pad to multiple of 512 bits and operate on 64-byte chunks. Main differences: SHA1 used big endian for any encoding/decoding while MD4 uses little endian, and some variation in the scrambling.

• What happens if you get a payment (you’re the final node), then when trying to resolve the HTLC, the immediate downstream node goes offline and now you want to fail it. Can you still communicate to the other nodes to fail the HTLC back so they aren’t stalled?

• PTLCs are so cool! Did not actually understand how they works in a full multi-hop payment flow, just the general idea, but went back to review today.

  • They use adaptor signatures to ensure that no downstream channel partner can claim the payment until their upstream partner has claimed (which is how it works in the normal case for HTLCs, but it’s possible for downstream nodes to claim if they have the preimage, but in PTLCs it requires an adaptor signature directly from their upstream node). This also allows for a sender to include an extra adaptor secret and send it in the onion for the sender so that for a malicious lnurl situation where an LSP reuses an invoice, each payment has some secret that is essentially unique to that payment (even if the invoice was the same) and the LSP couldn’t steal funds.

  • I didn’t realize that the Point in PTLC doesn’t mean a public key, but the adaptor secret (which are “masked” as points basically), i.e. the adaptor secret is what locks and is revealed for claiming, not like ephemeral keys or something.

• Reviewed the async payment proposal again and it makes a lot of sense now. My takeaways (basically rewriting the main points in my own words):

  • Receiver gives their LSP pre-made invoices, LSP holds the payment for sender, sender sends message to receiver LSP, receiver comes back online and pings their LSP to ping sender LSP, payment goes through. To prevent malicious LSP reusing invoices, sender includes an extra adaptor secret and sends in onion so there’s a unique secret per payment.

  • This results in no liquidity lock up except for the sender, and no one being able to steal funds.