The idea involves using revocation keys that are known only to the receiver to prevent fraudulent receivers from burning coins. The revocable output can be spent after a certain period of time by either the receiver, sender (if they know the key), or anyone who knows the key (after a shorter period of time). If the output is revoked, the receiver must prevent everyone who has the key from accessing the Bitcoin network during a one-day period between the two spending periods.Rusty acknowledges that the issue of transaction revocation has been solved, but points out that ZmnSCPxj's idea may have different tradeoffs than what Lightning currently uses. He suggests that trusted watchers can know the revocation keys, as they have a compact form and require minimal storage. This eliminates the need for a "burn window" but still allows attackers to steal coins, particularly if they are miners.There is also discussion about addressing denial-of-service attacks and the involvement of bounty hunters to prevent fraud. Rusty mentions that Tadge's watchers could be used to prevent DoS attacks, but they are subject to malleation. The Lightning Network paper had suggested adding a TX_NOINPUT sighash flag to allow watchers to operate even in the case of malleation, but this would require a soft fork. Rusty concludes that waiting for SegWit is a better option.Overall, the conversation explores various aspects of transaction revocation in the Lightning Network and discusses the advantages and tradeoffs of different approaches.