Как "заморозить" биткойны?

[Antibit]

Допустим, что у меня есть несколько монет и я хочу уберечь их от:

1) Доступа третьих лиц
2) Траты самим собой на определенный период времени (до определенной даты)

Если по первому пункту все понятно, безопасное храние крипты обсуждалось неоднократно, то вот по второму вопросу на ум ничего толкового не приходит.

Резкие скачки курса или внезапные финансовые нужды могут толкнуть к необдуманной продаже биткойнов, тем самым будет потеряна возможность в будущем продать эти монеты намного дороже.

Или, например, хочется сделать подарок в виде 5 монет самому себе на ДР, который будет 05.05.15, но для этого нужно, чтобы эти 5 BTC мне стали доступны не ранее этой даты.

Небходимо решение, которое ограничивало бы доступ самого себя на определенный срок к:

1) Файлу - в нашем случае это может быть файл кошелька
ИЛИ/И
2) Текстовой информации - в нашем случае это может быть private key биткоин-адреса

При этом, крайне нежелательно задействовать третьих лиц и вот такие варианты решения не подойдут:

- Файл кошелька с монетами (вариант: txt-файл с приватным ключом) положить в архив под пароль, архив передать другу на хранение, пароль не сообщать, копию архива у себя удалить. Дать наказ, ранее определенной даты архив не возвращать.
- Перевод WMX WebMoney с протекцией по времени.
- ...

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

У кого-нибудь есть идеи на этот счет?

[amaclin]

Вкратце ответ "нет".
Должно быть понятно, почему так.

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

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

Второй вариант, когда вы сами себя ограничиваете тоже можете не думать.
Есть такая вещь Парадокс всемогущества
Вы не сможете создать такой замок, который не сможете открыть до наступления определеной даты, если у вас есть возможность подкрутить стрелки часов.

[Limbo]

ТС, напишите программу, которая будет выдавать вам приватный ключ только после наступления строго определенного времени.
Пусть время она определяет, подключившись к тайм-сайтам в интернете, дабы исключить возможность подкрутки часов в системе.
Компилируйте, стирайте исходники, затем на флешку и в укромное место.

[amaclin]

дабы исключить возможность подкрутки часов в системе.

Это затруднит трату до указанного часа (мы не ищем легких путей? стоя, в гамаке и в скафандрах?)
Но не исключит возможности.
Если я могу написать программу, которая определяет время по часам из интернета - я еще быстрее напишу программу, которая первой программе подсовывает подкрученное время.

[Limbo]

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

Это не проблема. ТС может заложить в свою программу адреса сотни тайм-ресурсов. Привязаться к выдаче гугла с упоминанием этой даты. К ленте.ру, твиттеру, жж. Усложнить алгоритм определения текущей даты как можно сильнее.
К тому времени, когда захочется программу обмануть - он просто не вспомнит, как это сделать.
Здесь принцип запоминания пароля - чем он сложнее, тем быстрее вероятность что ты его вспомнишь стремится к нулю.

Но вы правы, возможность конечно имеется. Стопроцентной защиты от дизассемблинга не существует 

[amaclin]

Но вы правы, возможность конечно имеется. Стопроцентной защиты от дизассемблинга не существует  

Ага. Есть какие-то вроде бы сервисы почтовые, которые позволяют послать письмо, чтобы получатель получил его в указаную дату в будущем. Можно послать самому себе приватный ключ. Ну или запаковать приватный ключ в архив, а пароль к этому архиву послать самому себе в будущее.

Особый цимес будет послать себе письмо на "год вперёд", а через полгода узнать, что почтовая служба дала дубу и письмо не придёт.

ЗЫ. Синхронизацию по времени я сделаю не с помощью дизассемблинга и хакинга существующей программы, а просто подменю сетевой трафик на свой собственный. Мэн-ин-зе-миддл, так сказать.

[Limbo]

Спасибо, кстати, за статью про Парадокс. Именно там содержится решение вопроса ТС, на мой взгляд:

Всемогущество А значит, что утверждение «А может Б» истинно тогда и только тогда, когда Б — логически последовательное описание конъюнктуры. Это положение было когда-то защищено Фомой Аквинским. Это определение всемогущества решает некоторые из парадоксов, связанных со всемогуществом, но некоторые современные формулировки парадокса все ещё работают против этого определения. Пусть Б это «сделать кое-что, что его создатель не может поднять». В этом действии нет ничего логически противоречащего, человек может, например, сделать лодку, которую он не может поднять.

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

[amaclin]

Это уже ближе к Закону Шнайера
http://habrahabr.ru/post/239287/

Каждый человек может изобрести систему безопасности, которую он был бы не в силах взломать.
Но если к системе безопасности есть ключ - то как его хранить?
Создавать очередную систему безопасности? Рекурсия.

[Melifaro]

"Допустим, что у меня есть несколько монет и я хочу уберечь их от:

1) Доступа третьих лиц
2) Траты самим собой на определенный период времени (до определенной даты)"

О, майн Готт...
Мне бы ваши проблемы, господа...

ЗЫ. Знаю совершенно 100% способ, обращайтесь...

[amaclin]

ЗЫ. Знаю совершенно 100% способ, обращайтесь...

Ээээ!! Ты третье лицо! А он просил без третьих! Я четвертое! Обращайтесь ко мне!
Я даже могу пообещать вернуть ваши битки с процентами! Мамой клянусь!

[Melifaro]

Вы ошиблись.
Я лицо без номера... 

[Pivo]

Вы ошиблись.
Я лицо без номера... 

https://ru.wikipedia.org/wiki/%CE%F1%F2%E0%EF_%C1%E5%ED%E4%E5%F0

 

[rPman]

Допустим, что у меня есть несколько монет и я хочу уберечь их от:
...
2) Траты самим собой на определенный период времени (до определенной даты)

не красивый, не точный по времени, в каком то смысле дорогой метод защиты от необдуманной траты монет, но без передачи доступа к монетам третьим лицам:

Code:

Простой скрипт-утилита, с помощью простейших rpc-запросов к кошельку меняет его пароль на случайно сгенерированный, не сильно сложный, и не сохраняет его.
Для траты денег необходимо полным перебором определить этот пароль (так же скрипт очень простой)

Сложность пароля (количество используемых символов и количество символов в пароле) определит приблизительное время на его перебор на имеющемся под рукой железе.

Размер скрипта для этих задач - считанные десятки строк.

Не обязательно делать пароль таким сложным что время перебора - весь срок защиты. Достаточно несколько суток - недель, которых будет достаточно, чтобы подумать и не сделать опрометчивого шага.
А если ситуация будет слишком серьезной и доступ к монетам действительно потребуется сию секунду - можно будет взять в аренду мощности (например кластеры amazon) и определить пароль в сотни и тысячи раз быстрее, чем это можно сделать на десктопном железе, но за это придется заплатить.

[Antibit]

Спасибо всем отписавшимся по теме.
Некоторые из предложенных вариантов были в голове, но до идеального решения ни один из них все равно не дотягивает 

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

Тем не менее, рад буду выслушать еще идеи, если таковые имеются.

[fruit]

Спасибо всем отписавшимся по теме.
Некоторые из предложенных вариантов были в голове, но до идеального решения ни один из них все равно не дотягивает  

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

Тем не менее, рад буду выслушать еще идеи, если таковые имеются.

Попробуйте с другой стороны:
Ограничить не самого себя (или не себя) на определенный срок к биткам (как хотите, так и понимайте).
P.S.: Фьючерс?  (вроде есть фьючерсные криптобиржи).

[ligeros]

Ага. Есть какие-то вроде бы сервисы почтовые, которые позволяют послать письмо, чтобы получатель получил его в указаную дату в будущем. Можно послать самому себе приватный ключ. Ну или запаковать приватный ключ в архив, а пароль к этому архиву послать самому себе в будущее.

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

[Antibit]

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

Какие, например, блоги позволяют постить в будущее? Из массово используемых.

[ligeros]

Какие, например, блоги позволяют постить в будущее? Из массово используемых.

livejournal.com точно позволяет

[bee7]

PIC со встроенной флеш-памятью, с битами защиты от чтения флеша извне, перепрошивки кода и защиты от реконфигурации источника CLK со встроенного осциллятора. "Часы" PICа калибруются изначально по внешнему источнику временных меток, после чего и эта функция программно запрещается. Во флеше хранятся приватные ключи генерируемых PICом же адресов, совместно с временными метками их "размораживания", т.е. разрешения их чтения извне средствами API встроенного микрокода.

Главное, не забывать менять батарейку вовремя, что бы часики не останавливались.

[Borrris]

внутри протокола уже есть script. он позволяет это сделать.
готовьте raw-транзакцию от себя себе со срабатыванием на заданную дату.