Some Encounters on the Productive Use of a Failed Proof Attempt or a Counterexample Ra´ ul Monroy  Tecnol´ ogico de Monterrey, Campus Estado de M´ exico Carr. Lago de Guadalupe Km. 3-5, Atizap´ an, 52926, M´ exico raulm@itesm.mx Abstract. In the formal methods approach to software verification, we use logical formulae to model both the program and its intended specifi- cation, and, then, we apply (automated) reasoning techniques to demon- strate that the formulae satisfy a verification conjecture. One may either apply proving techniques, to provide a formal verification argument, or disproving techniques to falsify the verification conjecture. However, pro- grams often contain bugs or are flawed, and, so, the verification process breaks down. Interpreting the failed proof attempt or the counterex- ample, if any, is very valuable, since it potentially helps identifying the program bug or flaw. Lakatos, in his book Proofs and Refutations, argues that the analysis of a failed proof often holds the key for the development of a theory. Proof analysis enables the strengthening of na¨ ıve conjectures and concepts, without severely weakening its content. In this paper, we survey our encounters on the productive use of failure in the context of a few theories, natural numbers and (higher-order) lists, and in the context of security protocols. 1 Introduction In the formal methods approach to software development, both the program and its intended specification are first modelled using logical formulae. Then, (automated) theorem proving techniques are used in order to demonstrate that the program and its specification are related in a way given by the verification conjecture. Alternatively, disproving techniques could be used in order to falsify the verification conjecture, and, in that case, provide either a counter-model or a counterexample (see, for example, [12, 21, 1]). Of course, proving and disproving techniques can be used simultaneously; a number of techniques combine them (see, for example, [2, 20]). Programs, however, very often contain bugs or are flawed; accordingly, any verification attempt involving a faulty program is bound to break down. Inter- preting a failed proof attempt or a counterexample, if any, is very valuable, since it will potentially lead to identifying the root of the problem.  I am grateful to Dieter Hutter for his valuable comments on an earlier version of this paper.