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

[Balthazar]

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

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

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

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

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

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

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

[1714000748]

1714000748

[1714000748]

1714000748

[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]

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

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

[TechPriest]

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

Главное чтобы фантазия влезла в 520 байт   Так как больше redeem script в себя не вмещает. Опять таки, если мне не изменяет память.

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

Отправить через ViaBTC accelerator например.

[kzv]

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

[igor72]

Отправить через ViaBTC accelerator например.

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

kzv, 520 вроде.

[Balthazar]

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

Это миф, основанный непонятно на чем и взявшийся непонятно откуда.

Кто-то, безусловно, майнит такие транзакции, к примеру некоторые ноды p2pool. Абсолютное же большинство майнеров использует политику по умолчанию и не будет майнить нестандартные транзакции, если только они не запушены через локальный RPC с модификациями. А это означает, что код формирования работы эту транзакцию не увидит, даже если её напрямую прислать на P2P порт, и даже не дойдет дело до вопросов о том, а какая вообще у транзакции комиссия. И это сделано не просто так, а в целях защиты от самых простых DoS атак. Если майнер не проверяет транзакции на соответствие шаблонам, то ему в мемори пул можно напихать мусора, приводящего к созданию блока, который при получении будет вообще невозможно провалидировать в разумные сроки. В обсуждениях на гитхабе встречаются примеры, чем набить блок, чтобы он валидировался 10 минут.

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

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

В частности, а равно как и односторонняя гарантия. Уже одного этого достаточно, чтобы решения не были эквивалентами, а потому к ним нельзя применять бритву Оккама.
Яблоки не могут быть лучше или хуже апельсинов, это субъективное сравнение.

Ну и что, нетрудно и полностью переделать транзакцию.

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

520*2 вроде.

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

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

[kzv]

520 это максимальный размер данных который можно поместить в стек за одну операцию. Если уж быть совсем точным, то максимальный размер скрипта 1650

[Balthazar]

520 это максимальный размер данных который можно поместить в стек за одну операцию.

Да, но redeem скрипт помещается в стек как раз за одну операцию. Потому что нельзя положить в стек часть значения, равно как нельзя немножко забеременеть, на то он и стек. Поэтому, для стандартных P2SH redeem скриптов верхний теоретический предел составляет 520 байт. Фактически он меньше, 513 байт для обычных скриптов, генерируемых Bitcoin Core.

Если уж быть совсем точным, то максимальный размер скрипта 1650

Максимальный размер скрипта неинтересен юзеру, потому что до этого лимита юзеру ещё надо добраться. Актуально разве что для тех, кто использует raw multisig транзакции, т.е. отправку на скрипт вида

<N> <ключ 1> <ключ 2> <ключ 3> ... <ключ N> <M> OP_CHECKMULTISIGVERIFY

Тогда в подписании транзакции максимально сможет участвовать 48 участников.

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

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

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

[kzv]

Максимальный размер скрипта неинтересен юзеру, потому что до этого лимита юзеру ещё надо добраться. Актуально разве что для тех, кто использует raw multisig транзакции, т.е. отправку на скрипт вида

<N> <ключ 1> <ключ 2> <ключ 3> ... <ключ N> <M> OP_CHECKMULTISIGVERIFY

Я использую этот предел для хранения данных в блокчейне.

Code:

<sig><data520bytes><data520bytes> OP_DROP OP_DROP <public_key> OP_CHECKSIG

[Balthazar]

Я использую этот предел для хранения данных в блокчейне.

Code:

<data500bytes><data500bytes> OP_DROP OP_DROP OP_TRUE

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

[kzv]

Я использую этот предел для хранения данных в блокчейне.

Code:

<data500bytes><data500bytes> OP_DROP OP_DROP OP_TRUE

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

Отчего же?
В килобайте данных можно зазиповать много интересного зашифрованного (при желании) текста который может очень даже быть полезным в реальных сделках