BOLT 2's guide on setting cltv deltas is also helpful.

Thanks, that was very helpful!

I started reading it from the beginning and got stuck on a question about revocation yesterday:

In Part 2, the revocation key system was described as follows:

1. Alice generates a temporary private key dA1 and its corresponding public key PA1 and sends the public key to Bob.
2. Then Alice creates a commitment transaction where the to_local_output output has a spending path that is immediately spendable by Bob if he has the private key dA1.
3. If Alice and Bob agree to update their channel state, then the private keys for the previous state will be swapped (ie: Alice will send Bob dA1).

For some reason, I assumed that Alice would sign her commitment transaction with dA1 if she ever wants to broadcast it. But when she gives dA1 to Bob later to revoke this commitment transaction, I thought Bob could simply create, sign and broadcast her commitment transaction himself and then penalize her for it, taking all the funds of the channel. I think I had essentially the same question as someone had here.

The answer is that since all commitment transactions spend the same multisig output of the funding transaction, the commitment transactions need a signature from these private keys. And Bob does never receive Alice's private key for that signature. He can create the commitment transaction but not Alice's signature.

It's funny how stuff becomes obvious after you struggled with it for a few hours.

these professional escrow providers might have a centralized backend

And they might not. If someone decides "hey I will run a website!" that does not make a protocol centralized. That website might get taken down, and the escrow might get arrested, but the protocol is still fine and works perfectly well without that particular escrow or their website. Though I do need to implement a backout clause so that if your escrow disappears and you can't come to an agreement, both parties just get their deposits back.

The ability to hop to as many websites as you want does not make it decentralized.

You don't need any websites. If your point is "things can't be decentralized if they have nostr as a dependency," then I agree. And I suppose that means I was wrong to say celebrity escrow lets you do this without a centralized backend, since it requires nostr, which is the same thing as saying "it requires a centralized backend." But in theory it doesn't require nostr -- that's just how I implemented it, because it's easy. The only requirement (theoretically) is a way to communicate with whatever escrow both parties agree on, and that does not require anything centralized.