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

[zasad@]

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

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

[1714185836]

1714185836

[1714185836]

1714185836

[igor72]

Комьюнити должно требовать от разрабов топовых монет ввести эту возможность в оф кошельках.

В интерфейсе аппаратного кошелька Trezor присутствует функция Locktime, поэтому пользователям этого кошелька ничего колдовать не надо. Есть у cryptonist-а ролик на эту тему.
Пользователям Electrum поменять локтайм немного сложнее, но тоже относительно просто (нужно просто изменить 3-4 байта в неподписанной транзакции, транзакция должна быть с RBF).

[Kepasa]

Позавчера представили новую разработку по этой теме: Casa Covenant.
Технология передачи биткоинов по наследству основана на мультисигнатурном кошельке, для совершения транзакции нужно 3 ключа из 6, из них домашний, рабочий, мобильный ключ клиента и есть дополнительные ключи юриста, ключ Casa и ключ депозитарной коробки.
Подробнее можно почитать здесь: https://blog.keys.casa/announcing-casa-covenant-bitcoin-inheritance-service-and-protocol/

[kzv]

Позавчера представили новую разработку по этой теме:

Вы ошиблись.
Эстонская локаль в другом месте.

[madnessteat]

Позавчера представили новую разработку по этой теме: Casa Covenant.
Технология передачи биткоинов по наследству основана на мультисигнатурном кошельке, для совершения транзакции нужно 3 ключа из 6, из них домашний, рабочий, мобильный ключ клиента и есть дополнительные ключи юриста, ключ Casa и ключ депозитарной коробки.
Подробнее можно почитать здесь: https://blog.keys.casa/announcing-casa-covenant-bitcoin-inheritance-service-and-protocol/

Об этой новости уже писали выше. https://bitcointalk.org/index.php?topic=5189658.msg52840167#msg52840167
Хороший сервис, но услуги Casa многим людям просто не по корману.

[johhnyUA]

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

Или я что-то путаю, или вы. nLockTime просто добавляет транзакцию (ну или пушит, как кому угодно) в нужный блок, через n блоков или же UTC время. И туда можно добавить все что угодно: можно чтобы отправлялось на конкретный адрес наследника, или порциями на несколько адресов как угодно короче. Какая транзакция больше понравится.

Как можно "скомпроментировать" передачу? Просто клепаешь транзакцию с адреса1 на адрес2 плюс дополнительное условие (через 100 блоков) и все. Или я где то ошибаюсь?

[igor72]

Вы что-то путаете, я думаю. Изменение поля локтайм на блок/время в будущем просто не позволит эту транзакцию транслировать в сеть, пока этот блок/время не наступит, она даже в мемпул не попадет. Или я вас не понял.

[taikuri13]

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

Вот этот момент я очень хорошо понимаю.

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

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

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

ps: В этом вопросе я специально не стал говорить про шифрование и другие методы защиты. Так как по смыслу - будет передача сид-фразы.

[johhnyUA]

Вы что-то путаете, я думаю. Изменение поля локтайм на блок/время в будущем просто не позволит эту транзакцию транслировать в сеть, пока этот блок/время не наступит, она даже в мемпул не попадет. Или я вас не понял.

Ты не понял, смотри:

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

Так вот, вопрос: как можно скомпроментировать обычную транзакцию, точнее метод ее передачи о чем и писал kzv. Адрес получателя не меняется же. Ну кто-то отправит ее вместо наследника наследнику по сути, и что?

[igor72]

Так вот, вопрос: как можно скомпроментировать обычную транзакцию, точнее метод ее передачи о чем и писал kzv. Адрес получателя не меняется же. Ну кто-то отправит ее вместо наследника наследнику по сути, и что?

Теперь, кажется, понял )). Вы правы, смысла кражи транзакции нет, разве что из вредности (типа "так не доставайся же ты никому"). Я думаю, kzv имел в виду, что при передаче текста транзакции она может каким-то образом потеряться или исказиться.

[samuel-sd]

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

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

[igor72]

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

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

[samuel-sd]

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

Мне такой способ не нравится по нескольким причинам:
0. Лично я не хочу обсуждать вопросы наследства с наследниками, тут нужно будет это делать регулярно. (лично моя заморочка).
1. Способ требует крипто квалификации обеих сторон (наследодателя и наследника)
2. Способ требует регулярной передачи новой транзакции, как время будет подходить. Причем я так понимаю, нужно будет пересоздавать кошелек, чтобы наследник не мог запустить транзакцию раньше смерти наследодателя.
3. Транзакция подразумевает конкретную сумму, но сумма в кошельке потенциального наследодателя может расти или уменьшаться, получается после каждого изменения баланса, нужно пересоздавать транзакцию и давать ее наследнику?

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

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

[kzv]

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

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

[igor72]

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

Мне такой способ не нравится по нескольким причинам:
0. Лично я не хочу обсуждать вопросы наследства с наследниками, тут нужно будет это делать регулярно. (лично моя заморочка).

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

1. Способ требует крипто квалификации обеих сторон (наследодателя и наследника)

Минимальное понимание от наследника требуется, конечно. Как и в любом другом варианте, вы же крипту передаете. От наследодателя требуется немного больше умений, да.

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

Да, нужно пересоздавать транзакции. Адрес наследника менять не нужно.

3. Транзакция подразумевает конкретную сумму, но сумма в кошельке потенциального наследодателя может расти или уменьшаться, получается после каждого изменения баланса, нужно пересоздавать транзакцию и давать ее наследнику?

Да.

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

Неудобства действительно есть, но это плата за отсутствие посредников/сторонних сервисов

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

Да, идеального решения я тоже пока не вижу. Когда-то, наверное, будет, но живем сейчас.

[samuel-sd]

Не обязательно регулярно. Можно оставить конверт и менять его содержимое.

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

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

А потом (через 20 лет) окажется, что наследник забыл пароль или его аккаунт стерли за-за неиспользования и все.

[igor72]

Не обязательно регулярно. Можно оставить конверт и менять его содержимое.

А где будет храниться конверт? Если у наследника, то это надо к нему ездить (а если это другой город/страна?). Если у наследодателя, то нужно держать наследника в курсе о месте хранения, напоминать как-то.

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

Плюс сам наследник должен не потерять/скомпрометировать ключи от своего кошелька в течении долгого времени.

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

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

А потом (через 20 лет) окажется, что наследник забыл пароль или его аккаунт стерли за-за неиспользования и все.

Не через 20, а через 2. Надо сделать, скажем, 5 или 10 дубликатов таких папок на разных серверах, за год-два все не исчезнут. Пароля там не нужно.
Вообще масса вариантов есть, как эту транзакцию передать, да можно даже в подпись на форумах или в аватарку запихать (тут, конечно, слегка зашифровать не помешает, но пароль может быть совсем простым, типа фамилия_имя, такой не забудешь). Можно и в блокчейн запихать, там уже точно не пропадет .

[johhnyUA]

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

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

Сложно будет придумать, твое предложение упирается вот в этот момент "раньше смерти наследователя". А это очень скользкий момент, так как нельзя точно заверить смерть наследователя. Бумаги можно подделать, сайт похоронного бюро взломать, а оракула (читай эскроу) - купить

По поводу твоего варианта это надо работать через секреты и условные блокировки CheckSequenceVerify. Суть в том, что если наследник пытается потратить средства ранее указанного блока, то ему нужно будет ждать какое то количество блоков, а хозяин сможет потратить же их сразу (так как обладает необходимым секретом). Вот как я это вижу.

По поводу наследства в биткоин вики кстати вариант через оракула - https://en.bitcoin.it/wiki/Contract#Example_4:_Using_external_state

[kzv]

Сложно будет придумать, твое предложение упирается вот в этот момент "раньше смерти наследователя". А это очень скользкий момент, так как нельзя точно заверить смерть наследователя. Бумаги можно подделать, сайт похоронного бюро взломать, а оракула (читай эскроу) - купить

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

По поводу твоего варианта это надо работать через секреты и условные блокировки CheckSequenceVerify. Суть в том, что если наследник пытается потратить средства ранее указанного блока, то ему нужно будет ждать какое то количество блоков, а хозяин сможет потратить же их сразу (так как обладает необходимым секретом). Вот как я это вижу.

Да, как-то с CheckSequenceVerify поиграться наверное надо. Пока не могу понять как.

[igor72]

Оракулом смерти можно сделать скрипт на хостинге, который раз в год будет посылать наследнику письмо: "я еще живой".

А насколько надежен хостинг? Потому что если полагаться на сторонние сервисы, то проще использовать гугл-сервис https://myaccount.google.com/inactive и передавать зашифрованный сид через него. С сидом же лучше - не надо транзакции переделывать при изменении набора UTXO.

Если наследователь помрет, то он не оплатит хостинг и скрипт помрет тоже.

Надо также озаботиться, чтобы кто-то оплачивал хостинг в случае попадания наследодателя за решетку. Тут почему-то вспоминается один из "сатоши накомото" Ле Ру ).