Вопрос знатокам:
Допустим завещатель решил передать биткоины наследнику через локтайм, выставил условное количество времени, например, 5 лет, ну или какое-то количество блоков, не столь важно. Через 2 года завещатель скончался. Еще через какой-то промежуток времени в сети биткоина была обнаружена какая-то уязвимость, решить ее можно только с помощью хардфорка. В такой ситуации не пропадут ли средства?
Topic: Как завещать свои биткоины? - page 18. (Read 4994 times)
пишется программа и размещается на виртуальном хостинге, суть программы - она должна один раз в установленный промежуток времени получать код, который передает информацию о том, что Наследодатель жив, а также может устанавливать промежуток времени необходимый для получения следующего кода (например если Наследодатель сядет в тюрьму или еще какие причины, то он заранее на стадии расследования может установить временной период с запасом). Если в течении временного периода код не приходит - зашифрованная сид фраза отправляется на почту (или несколько почт) Наследника.
Чтобы не беспокоиться об оплате услуг хостинга, программу можно установить на телефон/ноутбук Наследодателя и предусмотреть возможность портирования на другое устройство. Главное чтобы об этом не знали наследники если есть подозрения в их ненадежности.
Так есть же у гугла такое: https://support.google.com/accounts/answer/3036546?hl=ru , и ничего мудрить не надо. Но это уже зависимость от стороннего сервиса ).Чтобы не беспокоиться об оплате услуг хостинга, программу можно установить на телефон/ноутбук Наследодателя и предусмотреть возможность портирования на другое устройство. Главное чтобы об этом не знали наследники если есть подозрения в их ненадежности.
В принципе тоже рабочий вариант. Нужно будет изучить его получше.
На данный момент вот что меня в нем смущает:
1. Номер телефона, по которому будет проходить подтверждение личности доверенного лица. За много лет номер может поменяться, его можно лишиться по вине оператора.
2. Можно ли в случае необходимости менять настройки времени не активности аккаунта после чего данные будут отправляться доверенному лицу?
3. Вопрос доверия сервисам гугла.
пишется программа и размещается на виртуальном хостинге, суть программы - она должна один раз в установленный промежуток времени получать код, который передает информацию о том, что Наследодатель жив, а также может устанавливать промежуток времени необходимый для получения следующего кода (например если Наследодатель сядет в тюрьму или еще какие причины, то он заранее на стадии расследования может установить временной период с запасом). Если в течении временного периода код не приходит - зашифрованная сид фраза отправляется на почту (или несколько почт) Наследника.
Чтобы не беспокоиться об оплате услуг хостинга, программу можно установить на телефон/ноутбук Наследодателя и предусмотреть возможность портирования на другое устройство. Главное чтобы об этом не знали наследники если есть подозрения в их ненадежности.
Так есть же у гугла такое: https://support.google.com/accounts/answer/3036546?hl=ru , и ничего мудрить не надо. Но это уже зависимость от стороннего сервиса ). Чтобы не беспокоиться об оплате услуг хостинга, программу можно установить на телефон/ноутбук Наследодателя и предусмотреть возможность портирования на другое устройство. Главное чтобы об этом не знали наследники если есть подозрения в их ненадежности.
В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )
Возможно есть смысл с такого скрипта, который с блокчейном напрямую не связан. Шифруется сид фраза Наследодателя, инструкция по расшифровке фразы и дальнейшем её использовании заранее передается Наследнику. Далее пишется программа и размещается на виртуальном хостинге, суть программы - она должна один раз в установленный промежуток времени получать код, который передает информацию о том, что Наследодатель жив, а также может устанавливать промежуток времени необходимый для получения следующего кода (например если Наследодатель сядет в тюрьму или еще какие причины, то он заранее на стадии расследования может установить временной период с запасом). Если в течении временного периода код не приходит - зашифрованная сид фраза отправляется на почту (или несколько почт) Наследника.
Чтобы не беспокоиться об оплате услуг хостинга, программу можно установить на телефон/ноутбук Наследодателя и предусмотреть возможность портирования на другое устройство. Главное чтобы об этом не знали наследники если есть подозрения в их ненадежности.
П.с. возможно не стоит ничего мудрить, если наследникам напрямую нельзя доверить своих денег?
Вариант с локтаймом сложнее. Деду нужно будет каждый раз
1. делать инвалидной предыдущую транзакцию
Quote
2. создавать новую транзакцию
Тоже просто, занимает, скажем, 5 минут.Quote
3. передавать новую транзакцию Внуку.
Во многих случаях совсем не проблема.Quote
В пункте 3 точно также есть зависимость от сервисов. Передача транзакции раз в год ничем не лучше ежегодного емайла с напоминанием о себе.
Quote
В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
Такую транзакцию сложнее подготовить. Затем еще вторую транзакцию нужно подготовить, тратящую первую в пользу наследника, она еще сложнее (99% дедов и внуков ее сами не сделают). Вероятность ошибиться здесь гораздо выше, чем с элементарным локтаймом.1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
Quote
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )
Ок.В общем, при условии, что монеты наследства не будут двигаться и не будут добавляться новые, ваша схема действительно имеет плюсы. Но если сумма будет меняться (что часто и происходит), то преимущества пропадают.
Но главный недостаток, что вы можете такую схему воплотить в жизнь, а 99% - нет. И, думаю, половину из них и не научишь особо, потому что не так просто. А схеме с локтаймом научиться легко - в виндовом калькуляторе перевести число в 16-ричную систему и результатом заменить в хвосте транзакции 6 циферок. Мануал для электрума получится из пары абзацев текста и пары картинок.
Это, конечно, интересно с точки зрения скриптописательства и так далее, но для практического применения я вижу только один плюс перед банальным локтаймом - проверка внука "на вшивость" (в этом случае я бы реплику в 3 пункте поменял на более лаконичную: "До моей смерти не отправлять"). Но эта проверка вряд ли многим нужна. Больше плюсов не вижу, одни минусы - сложность, зависимость от сервисов (еще и платить за хостинг нужно).
Вариант с локтаймом сложнее. Деду нужно будет каждый раз
1. делать инвалидной предыдущую транзакцию
2. создавать новую транзакцию
3. передавать новую транзакцию Внуку.
В пункте 3 точно также есть зависимость от сервисов. Передача транзакции раз в год ничем не лучше ежегодного емайла с напоминанием о себе.
В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )
Битки может потратить тот
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год
Ну это как бы очевидно. Но в лайтнинге там приватниками никто не светит, там секреты это по сути хэши некоторой информации известной только одной стороне. Надо освежить память что конкретно там использовали, но секреты генерировались конкретно под каждый канал свои.
А приватник то ясное дело. Здесь дед просто может приватник отдать. Да и хитрого скрипта я не вижу, все тоже что Игорь72 предлагал.
Это, конечно, интересно с точки зрения скриптописательства и так далее, но для практического применения я вижу только один плюс перед банальным локтаймом - проверка внука "на вшивость" (в этом случае я бы реплику в 3 пункте поменял на более лаконичную: "До моей смерти не отправлять"). Но эта проверка вряд ли многим нужна. Больше плюсов не вижу, одни минусы - сложность, зависимость от сервисов (еще и платить за хостинг нужно).
Короче я вроде понял как можно сделать
Допустим Дед имеет 100 битков и хочет чтобы после его смерти Внук мог распоряжаться этими битками. До смерти Деда, Внуку распоряжаться битками запрещено...
1. Дед пишет скрипт
Битки может потратить тот
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год
2. Дед хэширует скрипт и подписывает транзакцию перевода 100 битков на адрес скрипта. Транзакция в сеть не посылается!
3. Дед передает рав транзакцию из п.2 Внуку со словами: "Если эта транзакция окажется в сети до моей смерти, то я заберу все битки на свой адрес".
4. Дед пишет скрипт, который раз в год посылает письмо Внуку: "твой Дед живой, транзакцию в сеть посылать нельзя!". Этот скрипт Дед размещает на хостинге, хостинг оплачивает на год вперед.
5. Если Дед помрет, то хостинг продлен не будет, скрипт помрет, Внук не получит очередного письма и пошлет транзакцию Деда в сеть.
6. Через год после первой транзакции, Внук сможет отправить вторую транзакцию которой переведет битки из п.5 на свой адрес.
Допустим Дед имеет 100 битков и хочет чтобы после его смерти Внук мог распоряжаться этими битками. До смерти Деда, Внуку распоряжаться битками запрещено...
1. Дед пишет скрипт
Битки может потратить тот
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год
2. Дед хэширует скрипт и подписывает транзакцию перевода 100 битков на адрес скрипта. Транзакция в сеть не посылается!
3. Дед передает рав транзакцию из п.2 Внуку со словами: "Если эта транзакция окажется в сети до моей смерти, то я заберу все битки на свой адрес".
4. Дед пишет скрипт, который раз в год посылает письмо Внуку: "твой Дед живой, транзакцию в сеть посылать нельзя!". Этот скрипт Дед размещает на хостинге, хостинг оплачивает на год вперед.
5. Если Дед помрет, то хостинг продлен не будет, скрипт помрет, Внук не получит очередного письма и пошлет транзакцию Деда в сеть.
6. Через год после первой транзакции, Внук сможет отправить вторую транзакцию которой переведет битки из п.5 на свой адрес.
Если скрипт должен посылать письмо наследнику раз в год, а хостинг умрет раньше наследователя, но наследователь купит другой хостинг и запустит скрипт там.
Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед ) Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед. Хотя если срок действия карты протухнет раньше чем владелец отсидит срок, то придется кому-то доверить пароль от панели хостинга, что не очень хорошо...
Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед ) Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед. Хотя если срок действия карты протухнет раньше чем владелец отсидит срок, то придется кому-то доверить пароль от панели хостинга, что не очень хорошо...
Очень ненадежно.
Есть вариант такой, если мы уже хотим скрипты: Есть некий скрипт на Эфире, который хранит транзакцию в биткоинах (с локтаймом) в себе. Условие хранения - постоянные депозиты небольших сумм эфирок с указанного адреса на адрес смарт контракта (скрипта). Депозиты прекращаются - смарт контракт "открывает" доступ к этой транзакции.
Здесь тоже не идеальный вариант, зато решается проблема сгоревшего домена. Ну тоесть менее вероятно что сеть эфира исчезнет в отличии от некоего сайта. А если за решетку попадет, то тот же адвокат (доверенное лицо) будет депозитить средства на счет. Та же проблема, но хотя бы убирается проблема с сайтом.
Софт наследователя периодически посылает сигнал. Наследник может получать сигнал на почту, наследнику специальный софт не нужен...
Зачем наследнику получать этот запрещающий сигнал, если он может его не получать и присвоить наследство раньше времени? Я понимаю ждать разрешающий сигнал (например, ключ для мультисиг-транзакции), но тут что-то не догоняю.Quote
Ну это же как звонок по телефону от дедушки к внуку раз в год: "Привет внучек. Я жив, здоров. Попробуешь воспользоваться наследством - я его тебя лишу.
"Попробуешь - лишу" означает, что внучек может попробовать, у него ничего не получится, и эта попытка будет обнаружена дедушкой, так? Ок, допустим, что это возможно сделать. Но если завтра дедушка помрет, то как у внука это получится завтра или через год, если больше никакой информации он никогда не получит? не могу себе представить, как можно сделать зависимость получения наследства от НЕполучения сигнала. А софт, проверяющий этот сигнал, где будет работать, у наследника?
Софт наследователя периодически посылает сигнал. Наследник может получать сигнал на почту, наследнику специальный софт не нужен...
Ну это же как звонок по телефону от дедушки к внуку раз в год: "Привет внучек. Я жив, здоров. Попробуешь воспользоваться наследством - я его тебя лишу. Примерно через год позвоню еще раз. Если не позвоню - считай, что я помер и наследство твое". Через год звонка нет - значит дедушка помер и можно пользоваться наследством.
Если хостинг оплачивать раз в год на го вперед то через год
или умрет наследователь и письмо наследнику не придет - сигнал о смерти наследователя получен
или умрет хостинг и наследователь купит другой и наследник получит письмо - сигнал, что наследователь жив.
не могу себе представить, как можно сделать зависимость получения наследства от НЕполучения сигнала. А софт, проверяющий этот сигнал, где будет работать, у наследника?или умрет наследователь и письмо наследнику не придет - сигнал о смерти наследователя получен
или умрет хостинг и наследователь купит другой и наследник получит письмо - сигнал, что наследователь жив.
Quote
Это значительно проще и меньше шансов ошибиться, чем в способе с переподписыванием транзакций.
Если UTXO в наследстве будут меняться, все равно придется пересоздавать транзакции.
Если хостинг оплачивать раз в год на го вперед то через год
или умрет наследователь и письмо наследнику не придет - сигнал о смерти наследователя получен
или умрет хостинг и наследователь купит другой и наследник получит письмо - сигнал, что наследователь жив.
Это значительно проще и меньше шансов ошибиться, чем в способе с переподписыванием транзакций.
или умрет наследователь и письмо наследнику не придет - сигнал о смерти наследователя получен
или умрет хостинг и наследователь купит другой и наследник получит письмо - сигнал, что наследователь жив.
Это значительно проще и меньше шансов ошибиться, чем в способе с переподписыванием транзакций.
Если скрипт должен посылать письмо наследнику раз в год, а хостинг умрет раньше наследователя, но наследователь купит другой хостинг и запустит скрипт там.
Это понятно, а если позже?Quote
Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед )
Да можно оттуда и письма посылать, и даже интернет там иногда есть. Просто это нужно продумать заранее и подготовить.Quote
Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед.
Смысл всей затеи тогда теряется.
Если скрипт должен посылать письмо наследнику раз в год, а хостинг умрет раньше наследователя, но наследователь купит другой хостинг и запустит скрипт там.
Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед ) Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед. Хотя если срок действия карты протухнет раньше чем владелец отсидит срок, то придется кому-то доверить пароль от панели хостинга, что не очень хорошо...
Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед ) Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед. Хотя если срок действия карты протухнет раньше чем владелец отсидит срок, то придется кому-то доверить пароль от панели хостинга, что не очень хорошо...
Оракулом смерти можно сделать скрипт на хостинге, который раз в год будет посылать наследнику письмо: "я еще живой".
Quote
Если наследователь помрет, то он не оплатит хостинг и скрипт помрет тоже.
Надо также озаботиться, чтобы кто-то оплачивал хостинг в случае попадания наследодателя за решетку. Тут почему-то вспоминается один из "сатоши накомото" Ле Ру ).Сложно будет придумать, твое предложение упирается вот в этот момент "раньше смерти наследователя". А это очень скользкий момент, так как нельзя точно заверить смерть наследователя. Бумаги можно подделать, сайт похоронного бюро взломать, а оракула (читай эскроу) - купить
Оракулом смерти можно сделать скрипт на хостинге, который раз в год будет посылать наследнику письмо: "я еще живой".
Если наследователь помрет, то он не оплатит хостинг и скрипт помрет тоже.
По поводу твоего варианта это надо работать через секреты и условные блокировки CheckSequenceVerify. Суть в том, что если наследник пытается потратить средства ранее указанного блока, то ему нужно будет ждать какое то количество блоков, а хозяин сможет потратить же их сразу (так как обладает необходимым секретом). Вот как я это вижу.
Да, как-то с CheckSequenceVerify поиграться наверное надо. Пока не могу понять как.Думаю можно объединить оффчейн транзакцию и хитрый скрипт. Наподобие того, как это работает в лайтинг нетворке.
1. Наследователь создает транзакцию с хитрым скриптом и отдает текст транзакции наследнику.
2. Скрипт написан так, что если наследник отправит транзакцию в сеть раньше смерти наследователя, то наследователь сможет забрать все битки себе если увидит в сети свою транзакцию.
Пока не могу придумать эти скрипты, надо посмотреть еще раз как это в лайтинге работает...
1. Наследователь создает транзакцию с хитрым скриптом и отдает текст транзакции наследнику.
2. Скрипт написан так, что если наследник отправит транзакцию в сеть раньше смерти наследователя, то наследователь сможет забрать все битки себе если увидит в сети свою транзакцию.
Пока не могу придумать эти скрипты, надо посмотреть еще раз как это в лайтинге работает...
Сложно будет придумать, твое предложение упирается вот в этот момент "раньше смерти наследователя". А это очень скользкий момент, так как нельзя точно заверить смерть наследователя. Бумаги можно подделать, сайт похоронного бюро взломать, а оракула (читай эскроу) - купить
По поводу твоего варианта это надо работать через секреты и условные блокировки CheckSequenceVerify. Суть в том, что если наследник пытается потратить средства ранее указанного блока, то ему нужно будет ждать какое то количество блоков, а хозяин сможет потратить же их сразу (так как обладает необходимым секретом). Вот как я это вижу.
По поводу наследства в биткоин вики кстати вариант через оракула - https://en.bitcoin.it/wiki/Contract#Example_4:_Using_external_state
Не обязательно регулярно. Можно оставить конверт и менять его содержимое.
А где будет храниться конверт? Если у наследника, то это надо к нему ездить (а если это другой город/страна?). Если у наследодателя, то нужно держать наследника в курсе о месте хранения, напоминать как-то.Quote
Плюс сам наследник должен не потерять/скомпрометировать ключи от своего кошелька в течении долгого времени.
Надо дать ему понять, что потеряет ключи - останется ни с чем. Если не совсем ребенок, то поймет и не потеряет.Quote
Quote
Можно создать папки в облачных хранилищах, ссылки на них будут постоянными, а файлы в них можно менять.
А потом (через 20 лет) окажется, что наследник забыл пароль или его аккаунт стерли за-за неиспользования и все.Вообще масса вариантов есть, как эту транзакцию передать, да можно даже в подпись на форумах или в аватарку запихать (тут, конечно, слегка зашифровать не помешает, но пароль может быть совсем простым, типа фамилия_имя, такой не забудешь). Можно и в блокчейн запихать, там уже точно не пропадет
. Jump to: