Как завещать свои биткоины?

[kzv]

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

[1715085002]

1715085002

[igor72]

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

Это понятно, а если позже?

Если наследователь попадет за решетку, то он может ведь попросить адвоката оплатить хостинг за сколько-то лет вперед )

Да можно оттуда и письма посылать, и даже интернет там иногда есть. Просто это нужно продумать заранее и подготовить.

Ну или настроить автооплату с привязанной карты на которой заведомо дофига денег на несколько лет вперед.

Смысл всей затеи тогда теряется.

[kzv]

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

[igor72]

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

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

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

Если UTXO в наследстве будут меняться, все равно придется пересоздавать транзакции.

[kzv]

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

Софт наследователя периодически посылает сигнал. Наследник может получать сигнал на почту, наследнику специальный софт не нужен...
Ну это же как звонок по телефону от дедушки к внуку раз в год: "Привет внучек. Я жив, здоров. Попробуешь воспользоваться наследством - я его тебя лишу. Примерно через год позвоню еще раз. Если не позвоню - считай, что я помер и наследство твое". Через год звонка нет - значит дедушка помер и можно пользоваться наследством.

[igor72]

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

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

Ну это же как звонок по телефону от дедушки к внуку раз в год: "Привет внучек. Я жив, здоров. Попробуешь воспользоваться наследством - я его тебя лишу.

"Попробуешь - лишу" означает, что внучек может попробовать, у него ничего не получится, и эта попытка будет обнаружена дедушкой, так? Ок, допустим, что это возможно сделать. Но если завтра дедушка помрет, то как у внука это получится завтра или через год, если больше никакой информации он никогда не получит?

[johhnyUA]

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

Очень ненадежно.

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

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

[kzv]

Короче я вроде понял как можно сделать
Допустим Дед имеет 100 битков и хочет чтобы после его смерти Внук мог распоряжаться этими битками. До смерти Деда, Внуку распоряжаться битками запрещено...

1. Дед пишет скрипт

Битки может потратить тот
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год

2. Дед хэширует скрипт и подписывает транзакцию перевода 100 битков на адрес скрипта. Транзакция в сеть не посылается!
3. Дед передает рав транзакцию из п.2 Внуку со словами: "Если эта транзакция окажется в сети до моей смерти, то я заберу все битки на свой адрес".
4. Дед пишет скрипт, который раз в год посылает письмо Внуку: "твой Дед живой, транзакцию в сеть посылать нельзя!". Этот скрипт Дед размещает на хостинге, хостинг оплачивает на год вперед.

5. Если Дед помрет, то хостинг продлен не будет, скрипт помрет, Внук не получит очередного письма и пошлет транзакцию Деда в сеть.
6. Через год после первой транзакции, Внук сможет отправить вторую транзакцию которой переведет битки из п.5 на свой адрес.

[igor72]

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

[johhnyUA]

Битки может потратить тот
у кого есть приватник Деда в любое время
ИЛИ
у кого есть приватник Внука И прошел один год

 

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

А приватник то ясное дело. Здесь дед просто может приватник отдать. Да и хитрого скрипта я не вижу, все тоже что Игорь72 предлагал.

[kzv]

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

Вариант с локтаймом сложнее. Деду нужно будет каждый раз
1. делать инвалидной предыдущую транзакцию
2. создавать новую транзакцию
3. передавать новую транзакцию Внуку.

В пункте 3 точно также есть зависимость от сервисов. Передача транзакции раз в год ничем не лучше ежегодного емайла с напоминанием о себе.

В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )

[igor72]

Вариант с локтаймом сложнее. Деду нужно будет каждый раз
1. делать инвалидной предыдущую транзакцию

Простейшее действие, минуту занимает.

2. создавать новую транзакцию

Тоже просто, занимает, скажем, 5 минут.

3. передавать новую транзакцию Внуку.

Во многих случаях совсем не проблема.

В пункте 3 точно также есть зависимость от сервисов. Передача транзакции раз в год ничем не лучше ежегодного емайла с напоминанием о себе.

Какая? Мылом, например, или в мессенджере передал, получил подтверждение, что принято. Разве это зависимость?

В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...

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

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

Ок.

В общем, при условии, что монеты наследства не будут двигаться и не будут добавляться новые, ваша схема действительно имеет плюсы. Но если сумма будет меняться (что часто и происходит), то преимущества пропадают.
Но главный недостаток, что вы можете такую схему воплотить в жизнь, а 99% - нет. И, думаю, половину из них и не научишь особо, потому что не так просто. А схеме с локтаймом научиться легко - в виндовом калькуляторе перевести число в 16-ричную систему и результатом заменить в хвосте транзакции 6 циферок. Мануал для электрума получится из пары абзацев текста и пары картинок. 

[FontSeli]

В варианте со скриптом
1. транзакция передается один раз и больше никаких действий от Деда не нужно. Ну кроме ленивого отслеживания блокчейна раз в полгода...
2. вместо хостинга со скриптом, можно делать банальный телефонный звонок, что между родственниками обычно практикуется чаще чем раз в год )

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

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

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

[igor72]

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

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

Так есть же у гугла такое: https://support.google.com/accounts/answer/3036546?hl=ru , и ничего мудрить не надо. Но это уже зависимость от стороннего сервиса ).

[FontSeli]

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

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

Так есть же у гугла такое: https://support.google.com/accounts/answer/3036546?hl=ru , и ничего мудрить не надо. Но это уже зависимость от стороннего сервиса ).

В принципе тоже рабочий вариант. Нужно будет изучить его получше.
На данный момент вот что меня в нем смущает:
1. Номер телефона, по которому будет проходить подтверждение личности доверенного лица. За много лет номер может поменяться, его можно лишиться по вине оператора.
2. Можно ли в случае необходимости менять настройки времени не активности аккаунта после чего данные будут отправляться доверенному лицу?
3. Вопрос доверия сервисам гугла.

[madnessteat]

Вопрос знатокам:

Допустим завещатель решил передать биткоины наследнику через локтайм, выставил условное количество времени, например, 5 лет, ну или какое-то количество блоков, не столь важно. Через 2 года завещатель скончался. Еще через какой-то промежуток времени в сети биткоина была обнаружена какая-то уязвимость, решить ее можно только с помощью хардфорка. В такой ситуации не пропадут ли средства?

[igor72]

В принципе тоже рабочий вариант. Нужно будет изучить его получше.
На данный момент вот что меня в нем смущает:
1. Номер телефона, по которому будет проходить подтверждение личности доверенного лица. За много лет номер может поменяться, его можно лишиться по вине оператора.

Я тоже не пользовался, но почти уверен, что это касается функции передачи информации с аккаунта. А сначала выбранному адресату (или нескольким) отправляется уведомление, часть текста в котором можно написать самому. Этого достаточно, чтобы передать зашифрованный сид. Для простого уведомления телефон не нужен.

2. Можно ли в случае необходимости менять настройки времени не активности аккаунта после чего данные будут отправляться доверенному лицу?

Проверил - можно менять настройки, а также отключить функцию.

3. Вопрос доверия сервисам гугла.

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

Допустим завещатель решил передать биткоины наследнику через локтайм, выставил условное количество времени, например, 5 лет, ну или какое-то количество блоков, не столь важно. Через 2 года завещатель скончался. Еще через какой-то промежуток времени в сети биткоина была обнаружена какая-то уязвимость, решить ее можно только с помощью хардфорка. В такой ситуации не пропадут ли средства?

Если хардфорк как-то радикально заденет функцию локтайма, то теоретически могут пропасть. Но я думаю, это очень маловероятно.

[kzv]

В общем, при условии, что монеты наследства не будут двигаться и не будут добавляться новые, ваша схема действительно имеет плюсы. Но если сумма будет меняться (что часто и происходит), то преимущества пропадают.

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

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

Да ладно, можно сделать оффлайновый сервис (приложение), который по указанным параметрам будет писать такой скрипт. Деду останется только заполнить пару полей с информацией о транзакции, потом подписать готовый скрипт в коре и передать его Внуку.

Можно сделать онлайновый сервис, тогда Деду надо будет вбить только адреса с которых он планирует передать наследство, на выходе будет неподписанная транзакция. Дед ее подпишет в коре и все! Если под это дело подвести грамотный маркетинг, то может еще и денег заработать удастся )

[FontSeli]

В принципе тоже рабочий вариант. Нужно будет изучить его получше.
На данный момент вот что меня в нем смущает:
1. Номер телефона, по которому будет проходить подтверждение личности доверенного лица. За много лет номер может поменяться, его можно лишиться по вине оператора.

Я тоже не пользовался, но почти уверен, что это касается функции передачи информации с аккаунта. А сначала выбранному адресату (или нескольким) отправляется уведомление, часть текста в котором можно написать самому. Этого достаточно, чтобы передать зашифрованный сид. Для простого уведомления телефон не нужен.

2. Можно ли в случае необходимости менять настройки времени не активности аккаунта после чего данные будут отправляться доверенному лицу?

Проверил - можно менять настройки, а также отключить функцию.

3. Вопрос доверия сервисам гугла.

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

В таком случае Сервис "На всякий случай" может быть вполне рабочим способом. И его кстати можно сделать дублирующим вариантом к Локтайму на случай каких-либо сбоев, например, как случай с хардфорком, который выше привел madnessteat.

[igor72]

В общем, при условии, что монеты наследства не будут двигаться и не будут добавляться новые, ваша схема действительно имеет плюсы. Но если сумма будет меняться (что часто и происходит), то преимущества пропадают.

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

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

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

Да ладно, можно сделать оффлайновый сервис (приложение), который по указанным параметрам будет писать такой скрипт. Деду останется только заполнить пару полей с информацией о транзакции, потом подписать готовый скрипт в коре и передать его Внуку.

Можно сделать онлайновый сервис, тогда Деду надо будет вбить только адреса с которых он планирует передать наследство, на выходе будет неподписанная транзакция. Дед ее подпишет в коре и все! Если под это дело подвести грамотный маркетинг, то может еще и денег заработать удастся )

Сделать можно, только некому ). Когда появится такой софт, тогда появится и смысл говорить об этом.

В таком случае Сервис "На всякий случай" может быть вполне рабочим способом. И его кстати можно сделать дублирующим вариантом к Локтайму на случай каких-либо сбоев, например, как случай с хардфорком, который выше привел madnessteat.

Да, только хотел написать об этом ). Например, делается так. Шифруется сид, настраивается этот гугл-сервис по его передаче наследнику, допустим, через год. Скажем, 90% суммы переносится на отдельный путь деривации на этом сиде и готовится тратящая ее транзакция с локтаймом 5 лет, передается наследнику. Оставшиеся 10% могут быть в обороте без переделки транзакции. Если все сработает, наследник получит сид со 100% средств через год, если гугл подведет, то через 5 лет 90%.