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

[igor72]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

[1611356575]

1611356575

[1611356575]

1611356575

[1611356575]

1611356575

[1611356575]

1611356575

[Balthazar]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

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

[johhnyUA]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

https://raymii.org/s/tutorials/Sign_and_verify_text_files_to_public_keys_via_the_OpenSSL_Command_Line.html
И вот еще - https://www.zimuel.it/blog/sign-and-verify-a-file-using-openssl
Но у open ssl свой формат ключей, там надо будет переводить в них.

А вообще жаль что скрипты по P2PKH лучше не использовать (как я понял из сообщений Бальтазара)

[Balthazar]

Забыл вчера сказать. Смысл транзакций на такой адрес отличается от смысла голого lockTime.

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

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

[johhnyUA]

Забыл вчера сказать. Смысл транзакций на такой адрес отличается от смысла голого lockTime.

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

Об этом вроде бы выше уже писали. Обычный локтайм это просто невозможность отправить транзакцию в сеть до определенного блока. А OP_CLTV это блокирование выходов транзакции до определенного блока/времени.

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

[stmar]

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

Прошу прощения. Что означает более старые монеты?

[Balthazar]

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

Прошу прощения. Что означает более старые монеты?

Это означает монеты с бОльшим количеством подтверждений.

[FontSeli]

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

Прошу прощения. Что означает более старые монеты?

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

Прошу прощения. Что означает более старые монеты?

Это означает монеты с бОльшим количеством подтверждений.

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

[TechPriest]

В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.

Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.

[Balthazar]

В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.

Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.

Не получится. Предложение сначала выносится на обсуждение тут, на форуме, или в списках рассылки. Потом надо будет написать подробный BIP, что это шаблон реализует, каким образом и зачем он нужен. Потом по этому бипу сначала голосование девелоперов, а после этого включают реализацию в клиент и добавляют флаги для голосования майнящими нодами. Далее, после набора 95% поддержки в пределах интервала пересчёта сложности, новый шаблон начнёт поддерживаться обновлёнными узлами. Если не будет набрана поддержка, то начнутся многолетние срачи, как с сегвитом, и там уже результат будет зависеть от веса участников противоборствующих сторон. Если задавят авторитетом, то заставят майнеров обновиться под угрозой попадания в форкнутую ветку. В противном случае предложение пойдёт в утиль, как BIP17.

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

Для примера, пулл реквест вашего покорного слуги:

https://github.com/bitcoin/bitcoin/pull/9893

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

[johhnyUA]

Не получится. Предложение сначала выносится на обсуждение тут, на форуме, или в списках рассылки. Потом надо будет написать подробный BIP, что это шаблон реализует, каким образом и зачем он нужен. Потом по этому бипу сначала голосование девелоперов, а после этого включают реализацию в клиент и добавляют флаги для голосования майнящими нодами. Далее, после набора 95% поддержки в пределах интервала пересчёта сложности, новый шаблон начнёт поддерживаться обновлёнными узлами. Если не будет набрана поддержка, то начнутся многолетние срачи, как с сегвитом, и там уже результат будет зависеть от веса участников противоборствующих сторон. Если задавят авторитетом, то заставят майнеров обновиться под угрозой попадания в форкнутую ветку. В противном случае, предложение пойдёт в утиль, как BIP17.

Значит, по твоим же словам, OP_CHECKLOCKTIMEVERIFY и OP_CHECKSEQUENCEVERIFY должны быть в стандартных скриптах, так как на них есть успешные BIP-ы:

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Ыыыыыыы. Значит все должно получиться, и не обязательно юзать именно P2SH. Кому слабо проверить в мейн нете, а? 

[Balthazar]

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Упомянутые бипы описывают только новые опкоды и их реализацию в скрипт машине. Хоть они и не предписывают обязательное использование в контексте P2SH, они неявно подразумевают это. То есть, использование для скриптов либо P2SH, либо его более современного аналога, на сегодня это P2WSH. Посмотрите приложенные в бипах примеры и увидите это.

Ыыыыыыы. Значит все должно получиться, и не обязательно юзать именно P2SH. Кому слабо проверить в мейн нете, а?  

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

Так что использовать в мейн нете без P2SH/P2WSH можно, но только есть свой пул, и немаленький. И настоящий, а не прокси обвязки всякие. Ну или если у кого из друзей есть пул, и он согласится отмайнить транзакцию. Иначе транзакция если и будет подтверждена, то только в случае сильного везения. Без этого она даже в мемори пул к майнерам не попадёт.

В общем, оплата на скрипты напрямую - это решение не для смертных юзеров.

[johhnyUA]

Посмотрите приложенные в бипах примеры и увидите это.

Смотри, цитата из самого бипа:

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

Code:

    <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

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

[Balthazar]

Смотри, цитата из самого бипа:

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

Code:

   <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

Ну тут же по структуре видно что P2PKH. И из контекста такое понимание приходит.

Язык юридический, а равно как и язык описания стандартов, заметно отличаются от языка человеческого. Там написано "can be frozen", так что с точки зрения скриптовой машины никакого противоречия текущей ситуации нет. Ведь ты действительно можешь заморозить выходы таким скриптом и авторов документа не волнует, что они по умолчанию не майнятся. Это описание логики скрипт машины, а не клиента в целом.

Если бы доступность такого формата в качестве стандарта была обязательной, то использовались бы ключевые слова must или should. Так и было бы написано "Clients must treat these outputs as standard ones" или аналогично.

В реализации проверки на стандартность чётко определён шаблон скрипта P2PKH:

https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L60
https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L138

Определённые опкоды должны находиться на заданных смещениях, длина скрипта тоже фиксирована, шаг вправо или влево - расстрел.

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

Люди в транзакции манделу запихивают через data carrying выходы, это отдельный тип выхода транзакции, и через P2SH redeem скрипты. Эти транзакции стандартны с точки зрения текущей реализации протокола, потому и майнятся.

[igor72]

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

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

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

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

[Balthazar]

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

[igor72]

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

Конечно. Но, имхо, использовать вариант со скриптом лишь ради OP_CLTV (как в примере в вашем гайде) не оправдано - "множим сущее без необходимости", по-моему.

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

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

[Balthazar]

"множим сущее без необходимости", по-моему.

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

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

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

[igor72]

"множим сущее без необходимости", по-моему.

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

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

Кстати, если создать скрипт без "аварийного выхода", то как тогда отодвинуть срок вступления в наследство?

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

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

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

[kzv]

Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки?

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