About presenting hard proofs in seminar I am in a study seminar with my advisor. By the nature of the seminar, sometimes we have to go into details of hard proofs instead of waving our hands like in an ordinary seminar.
My question is: How should one determine the amount of detail of a proof to be included in this kind of situation? Is there any type of proof that just should not be presented? (e.g proof that is only bookkeeping or dull homological algebra)
 A: Obviously you're not going to come up with the proof on the spot (and if you do, then kudos, you're in a position where you don't really need this advice). So you have a lot of preparation at home for you.
Prepare the proof in full details, and break it into parts where you have longer arguments. Use lemmas and propositions to cut the work into smaller chunks. 
The greatest advantage is that now you can "color code" the notes into "very important, less important, just technical verification". So if time is pressing you can skip some of the minor claims and just write them on the board. And if something becomes unclear to someone, and they request you go into details anyway, you can still go to your notes if necessary.
A: If you can, practice beforehand with part of your audience.  Ideally your advisor will be your best guide, but seek input from other members of the seminar.  Overprepare your notes, but work on communicating just the high points so that anyone else who has to read through the hard parts will be thankful for your guidance.  If you are doing this for several sessions, ask for some feedback.
Gerhard "Needs More Practice Doing This" Paseman, 2015.12.05
A: Of course the answer strongly depends on the audience. I recommend that you get this information from the organizers.  In any case, for the technical part I would suggest to choose just one key point of the proof, and deserve 5-10 minutes to it: do just one idea with one computation, maybe in a simpler case.  For instance, show the  computation that convinced you that the problem was feasible.
