Я полагаю, что дальнейшее введение (и возможность для заработка) производятся на шахтерах. Таким же образом, что транзакция может транслироваться и распространяется на все шахтер, я предлагаю, что замок-запрос также может быть способен к такому распространению. Замок-запрос должен содержать следующие значения:

{
LR: [A Bitcoin адрес для блокировки, давайте назовем его 1AddrToLock]
LRSig: [подпись в результате первого элемента, когда подписал контракт с 1AddrToLock]
ULSig: [подпись в результате первых двух пунктов, когда подписал контракт с адресом мы называем 1UnlockingAddr]
}

После того, как блок в основной цепи содержит такую ​​блокировку запроса, шахтеры должны исключить все операции, которые не проводят каких-либо результатов от 1AddrToLock до разблокировки-запрос появится в блоке. Разблокировка-запрос будет похож на запрос блокировки:

{
ULR: [1AddrToLock от блокировки запроса]
ULRSig: [подпись в результате первых двух пунктов (и толстой кишки), когда подписал контракт с 1UnlockingAddr]
}

Таким образом, частный ключ может быть временно отменено.

Проблемы: Операции в блоке не всегда достаточно просто попасть в парадигму вымышленной этой идеей. Они действительно скрипты, которые принимают входные и должны возвращать 1 для того, чтобы быть действительным. Один из входов, как правило, подпись генерируется с помощью закрытого ключа (если я правильно помню). Таким образом, более точное описание функции блокировки запроса будет недействительным секретный ключ (один соответствующий 1AddrToLock) до альтернативного закрытого ключа (один соответствующий 1UnlockingAddr) подписывает запрос разблокировки.

Эта идея пришла ко мне, когда я услышал, что хакер получил доступ к корневой веб-сервер LocalBitcoins' в течение примерно 40 минут. Я не думаю, что они бы использовали его, но бывают случаи, когда один, возможно, захотите использовать его.

И, возможно, шахтеры могли опубликовать "ставки запирающие" который должен быть обеспечен через 1UnlockingAddr в Орер включить блокировку запроса в блоке они работают. Если блок также содержит сделку с 1UnlockingAddr, который имеет достаточно высокую плату, шахтер будет включать запрос блокировки. Так что, если шахтер не хочет уважать (новые) стопорные-запросы, они могут просто опубликовать очень высокую плату запирающей и игнорировать (исключить из своего блока) блокировка-запросы, которые не сопровождается достаточно дорогими сделками с 1UlockingAddr. Но как только любой шахтер принимает запрос, все шахтеры обязаны соблюдать его.

Хотя можно просто переместить все монеты из 1AddrToLock на новый адрес, это оставляет уязвимо все транзакции в 1AddrToLock. Это может занять некоторое время для жертвы, чтобы проинструктировать все плательщик использовать новый адрес, и было бы неплохо иметь механизм, чтобы сорвать вор в это время.

Я что-то упускаю?