Thanks for your reply! That makes sense.

Regarding your first paragraph: is this the scenario you describe in "A potential problem, solved" on the Github page? Am I correct in saying that if Alice initiates a closure in state X-1, she will not be punished (the (counterparty && sender) spending condition mentioned on Github is used, as the revocation secret is not yet shared), whereas if she closes the channel in an earlier state, she will be punished (as the revocation secret for that earlier state is known now)?

If Alice and Bob are in state X, where Alice sent Bob some money, Alice can do a unilateral exit by initiating a channel closure in state X-1, i.e. the state before she made that payment. This triggers the 2016 block countdown, during which Bob must broadcast the latest state, unless he is okay with losing his most recent payment from Alice. So neither party is ever "stuck" -- they can exit whenever they want.

If you're specifically asking about the very first state, where there is no prior state for Alice to broadcast, she simply doesn't put her money in the multisig until Bob cosigns her exit transactions. I didn't show this is the video but it's part of my work-in-progress wallet implementation (the code is not released yet).

supertestnet

bitcoin

Hedgehog: A protocol for asynchronous layer two bitcoin payments

Cool idea! Maybe I am missing something, but when setting up the Hedgehog channel, what stops Bob from just holding Alice's funds in the 2-of-2 multisig hostage, by not cosigning the transactions proposed by Alice? And potentially blackmailing Alice to cosign only if she sends over more of her funds in the channel?