Допустим, Вася у Пети заказывает какую-нибудь серьёзную работу, и Петя хочет убедиться, что бюджет под этот заказ не будет пущен на другие цели - путём заморозки средств (доказать-то владение битками не проблема, но гарантий, что ты их завтра не переведёшь на другой адрес, обычно нет). Переводим битки на совместный адрес и генерируем отложенную транзакцию возврата всех средств на адрес заказчика Васи (которая, скажем, сработает не раньше чем через год). Это будет гарантией от невыполнения работы исполнителем и от его саботирования возврата. По мере выполнения этапов работы перевыпускаем транзакцию возврата (с более ранним временем срабатывания, чем предыдущая), которая будет иметь теперь 2 выхода - часть денег Пете за суммарный объём выполненной работы, остальное обратно Васе.
Если работа будет завершена - просто переводим всю сумму Пете без блокировки вообще.
Если она будет выполнена лишь частично - каждый из участников сможет активировать последний вариант транзакции возврата и получить свою часть. При этом Пете нужно не прозевать момент разблокировки - если время разблокировки предпоследней транзакции возврата наступит до того, как он опубликует последнюю, то Вася сможет опубликовать предпоследнюю и вернуть себе больше средств, чем было достигнуто последним соглашением. Для этого и нужно постоянное "омоложение" времени разблокировки. Но такое слежение - это уже проблема Пети.
Если время разблокировки неотвратимо приближается к текущему моменту, а договор расторгать желания нет - переводим средства хоть на тот же адрес и снова выпускаем транзакцию возврата (по последнему соглашению) с произвольным временем разблокировки. Строго говоря, так можно делать после каждого этапа, просто схема с уменьшающимся nlocktime выбрана для уменьшения количества мусора в блокчейне.
Если всё упирается лишь в согласие обеих сторон, то гарант не нужен.