Matt Corallo

Right, agreed, this only does half of what #970 was doing, we still need to clarify the "when can you send closing_signed" part.

> Good point! In this case, we can use the same idea to simplify the code, with the following way: Lets do this in a separate PR, probably #970, I...

> no other updates can happen to a channel I assume this does *not* include HTLC removal updates? Just checking to make sure. This would imply if a peer removes...

> lnd doesn't do shutdown until the channel state is totally clean. Ah that's...an interesting interpretation of the spec. But in practice I'd imagine that means this isn't a big...

> I think this is precisely why we need multiple implementations. When the protocol evolves in the future, having multiple implementations will help illuminate bugs faster. I'm not sure what...

@sfultong ahh! that was the confusion. No, my comment about consensus bugs was not between-versions-of-Bitcoin-Core but consensus-bugs-in-other-implementations.

> similar complex financial protocol implementations do get by codifying a spec and using formal proofs/tests to verify different implementations. It might be hard but not impossible. I'm curious which...

@5chdn I'd be interested in knowing why. Is there something that you'd like from the libbitcoinconsensus library API that would make it easier to use? I'd be happy to work...

Discussion in the FluffyChat matrix room: ``` : fluffychat definitely does reactions wrong, but I'm not sure how wrong it is exactly : It encrypts them : Which is not...

> However, doing so would eliminate the ability to batch-CPFP several unconfirmed commitment transactions at once (although this isn't reliable anyway today, since the carveout protections don't apply to this...