Скорее, если учесть недопустимость отрицательного остатка после каждой операции.

Вот например - на определенном адресе-счёте имеется 10 BTC. Есть две транзакции - одна на перевод с этого счёта 6ти BTC, другая - на перевод с этого счёта 7ми BTC. Одна из этих транзакций, очевидно, должна быть отвергнута. Но какая именно?

Видимо, отвергнута должна быть та, которая позже. Но как узнать, которая из них позже? На поле "время", произвольно устанавливаемое отправителем транзакции, полагаться нельзя. Что же делать?

Классическим ответом на этот вопрос будет:

• по защищенному соединению звоним в NIST
• пересылаем в NIST будущую транзакцию, подписанную ключом отправителя
• NIST проставляет в транзакции поле "время" и подписывает её своим сертификатом
• NIST отправляет транзакцию в широковещательную сеть

Заметим, что для исполнения этой роли NISTу, вообще говоря, не обязательно иметь точные часы. Главное, чтобы эти часы не шли назад, чтобы счетчик мог только увеличиваться. А равномерно он увеличивается во времени или нет - это уже неважно.

Чтобы такая схема работала, все должны доверять NISTу. Верить, что NIST не будет мошенничать с метками времени. Но чем опасно мошенничество с метками времени? Что сможет сделать злоумышленник, захватив контроль над сервером времени?

Он не сможет изменять суммы переводов. Он не сможет подменить получателя перевода. Всё что он сможет - это переставить переводы местами (проставив некорректные метки времени) или заблокировать некоторую транзакцию (отказавшись проставлять ей метку времени и транслировать в сеть).

Именно то же самое сможет делать злоумышленник, захвативший контроль над генерацией блоков.