Keags

**TL;DR:** On [this line](https://github.com/rustyrussell/lightning-rfc/blob/quiescence-protocol/02-peer-protocol.md?plain=1#L515), s/either peer/the remote peer/g, to give implementations more freedom. -------------------- OK I'm no longer concerned with the scenario I outlined above, however, I do think that...

The issue is that we already cannot consider the channel quiescent simply on the grounds that we have sent and received `stfu`. If we receive an `stfu` from the peer...

@t-bast in reviewing your [most recent comment](https://github.com/lightning/bolts/pull/869#issuecomment-1849665848) I realize that there is even more confusion. When I was reading the language of "no local updates pending on either peer" I...

> I like both your proposed alternatives for the requirement, but I agree with @remyers that it's more a matter of properly defining what is meant by pending for either...

> more clearly define "pending for either peer" Yes please 🙏🏼 > I believe we have at least two implementations that support this feature (cln and eclair), let's try to...

Adding some of the comments that were discussed in the spec meeting: We should add a message that allows for un-quiescing (I'm putting in a bid for `go_on` = Global...

Apologies for not detailing this in my original comment. These are great questions. > I think this would add unnecessary complexity, as we'll now need to handle concurrency between the...

> All properly defined downstream protocols that expect quiescence must also precisely define at what point quiescence ends. This is true whether or not an additional common message is used...

I have now come to believe that if we want this to be a standalone protocol gadget, we actually need an explicit resume message if we want to be able...

> From our experience, tests for quiescence ended by disconnect are very valuable. I am not suggesting this as a substitution. I think we need to test both. However, live...