Магазины могут заводить внутренний виртуальный счёт для покупателя (в биткоинах), и покупатель заранее в домашней обстановке забросит туда средства, а уже в магазине будет оплачивать с этого счёта - вообще без следов в блокчейне и без ожидания. Если же покупатели магазинам доверять особо не будут, магазины могут реализовать такую схему
https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit:
1. Покупатель и магазин формируют совместный адрес (2-of-2 multisignature address, трата с такого адреса возможна только с подписью (и, соответственно, согласия) обоих участников).
2. Покупатель формирует транзакцию, переводящую свои средства на совместный адрес, но не публикует её, а только сообщает её id магазину (а также переводимую сумму и номер выхода транзакции).
3. Магазин на базе полученной формирует другую транзакцию, переводящую средства обратно на кошелёк покупателя, но только в определённый момент времени в будущем (скажем, через год - см.
https://en.bitcoin.it/wiki/NLockTime). Подписывает эту вторую транзакцию своим ключом и передаёт её покупателю.
4. Покупатель проверяет корректность 2-й транзакции (в т.ч. связанность её с 1-й), доподписывает 2-ю транзакцию и публикует 1-ю.
На данном этапе ситуация такова: с совместного адреса трата битков без согласия обоих участников невозможна, но если магазин закроется, то через год покупатель сможет опубликовать 2-ю транзакцию и вернуть битки себе на личный адрес.
Всё это было описано в
https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit. Теперь дополнение.
5. Покупатель приходит в магазин и совершает покупку.
6. Магазин формирует транзакцию T1, переводящую битки с совместного адреса, у которой будет два выхода - стоимость покупки на адрес магазина, сдача обратно на совместный адрес. Подписывает своим ключом и передаёт её покупателю.
7. Покупатель проверяет корректность транзакции, доподписывает её и (пока не публикуя T1) передаёт её id магазину.
8. См. п.3 (на базе id T1 формируется T2, возвращающая сдачу на личный адрес покупателя через год).
9. См. п.4. После проверки покупатель публикует T1.
В этот момент 2-я транзакция из п.4 становится недействительной, теперь её роль играет T2. При новой покупке пп. 5-9 повторяются.
Если опустить пп. 8-9 (т.е. покупатель будет сразу публиковать T1), то магазин, конечно, не сможет присвоить битки с общего адреса, но заморозить их навсегда будет вполне в состоянии (скажет, что в результате "технического сбоя" потерял свой ключ).
Плюсы схемы: можно не ждать подтверждений, ибо double spend невозможен (покупатель просто не сможет подписать double-spend транзакцию - у него нет ключа магазина); магазин не сможет захватить средства покупателя (по симметричной причине); потеря средств по ошибке тоже исключена (если покупатель будет бережно хранить транзакции возврата). Причём это всё доступно уже сейчас, все необходимые фичи протокол поддерживает.
Минусом схемы является её сложность, но её вполне можно автоматизировать и скрыть подробности от рядовых участников.
