Я предполагаю, что это не так много о безопасности, так как это больше о конфиденциальности. Мне очень нравится концепция здесь, что вы отправляете себя много, так что единственный способ провести это, чтобы получить вторую подпись от третьей стороны, которая будет делать проверку подлинности двухфакторной, прежде чем предлагать свои подписи.

(A а также B) или С

A: Ваш нормальный, электронный кошелек.
B: Сторонние веб-сайт проверки
C: Резервный ключ хранится в сейфе

Casascius описал это лучше всего: она может быть реализована таким образом, что, когда вы говорите ваш компьютер потратить некоторые средства от одной из этих операций, он будет подписывать с закрытым ключом А, и отправить частичную сделку с третьей стороны, которая будет потом, скажем, отправить вам текстовое сообщение с запросом "Вы санкционировать 23,7 BTC будет отправлен в адрес 1Ptk21Fjk38?", Когда они получают подтверждение, они подписывают его и транслировать его, что делает его окончательным. Если третья сторона выходит из бизнеса, вы всегда можете пойти в сейф, чтобы получить ключ C, что является достаточным в одиночку тратить средства.

Вот моя проблема с этим, хотя. Есть множество причин, это хорошо, чтобы использовать другой адрес для каждой транзакции. Однако, в этом случае, что разный адрес составляет изменяющие каждый раз. Проблема заключается в том, что о B и C? Независимо от того, как вы это делаете, адрес В и С должны быть видны blockchain в какой-то момент (или в первоначальной сделки, или после получения проводится в случае изменения предложения OP_CHECKSIG Casascius'). Если B или C тот же самое на каждом из этих сделок, то вы теперь создали проверяемую связь между каждым адресом А вы когда-либо использовали. Итак, как вы справляетесь с созданием транзакций, которые отправляют деньги на это (AandB) ORC-обремененный счет и имеют различные B и C адрес?

Давайте посмотрим на адр / Публичных B:
Это легко. Есть три варианта здесь:
(1) Сторонние дает один ключ для использования на каждой сделке.
(2) Вы периодически загружать новую партию 1000 publickeys / адрес из B, которые будут использоваться, пока не закончится и получить больше.
(3) Приложение запрашивает третью сторону и запрашивает новый адр / ключ, который будет использоваться, прежде чем каждая транзакция выполнена.

Вариант-явно худший, но это самое простое. (Если служба использует тот же единственный адр / Публичную для каждого пользователя, у нас нет этой проблемы, но это ставит все пользователи в опасности, если это закрытый ключ просочилась ... Я не хотел бы использовать эту услугу)
Вариант 2 является, вероятно, лучше всего, так как она позволяет синхронизировать через Интернет или пакет обновления каждый сейчас и потом, но в основном остается в автономном режиме и подписывать сделки удаленно. (Это наиболее актуально для систем, которые полностью отсутствует, которые хотят подписать эти типы транзакций.
Вариант 3 является лучшим для всегда-онлайн-услуг, но ставит нагрузку на вас, чтобы иметь доступ в Интернет и для третьей стороны, которая будет доступна, только чтобы отправить деньги с помощью такого рода сделки.

Проблема здесь заключается в том, что если вы выбрали вариант 2 или 3, вы должны разработать дополнительную инфраструктуру для обработки связи ключей / адра между сторонами. Не страшно, но это не тривиально, либо.

Для Addr / Публичных C:
Это ваш ключ в вашей безопасности для хранения ценностей. Это та часть, которая немного сложнее. Варианты (1) и (2) выше, потому что вы не можете запросить новый адрес каждый раз, даже если вы хотели. Моя главная задача в том, что если вы используете пакет 10000 ключей, вы, вероятно, не будете печатая QR-коду закрытых ключей на бумагу в свой сейф (это было бы много страниц). Но кто знает, что произойдет, если вы только сохранить его на ключ USB: вы можете получить ключ USB из памяти, чтобы выяснить, память повреждена. Конечно, хранить ключи на нескольких палок USB и некоторых ZIP дисков.

Это не может быть на самом деле проблема. Возможно Вариант 2 для обоих можно просто хранить 1,000,000 ключи / адреса, и вы никогда не будете бежать. Но это беспокойство / решение, которое будет решать, когда это становится стандартным типом транзакции. По крайней мере, разработчики программного обеспечения могли бы рассмотреть возможность включения функции, позволяющей хранить пулы ключей / адр, которые будут использоваться только для этой цели. Вы бы сторонний бассейн и резервный пул. Вы "заполнить" оба из них, когда вы начинаете этот вид счета, и клиент будет автоматически получать адреса из каждого в В и С полей каждый раз, когда вы хотите, чтобы построить этот вид сделки.