Topic: Как завещать свои биткоины? - page 3. (Read 4881 times)
520 это максимальный размер данных который можно поместить в стек за одну операцию. Если уж быть совсем точным, то максимальный размер скрипта 1650
Правда я бы с вами немного не согласился, так как при попадании к майнеру напрямую, есть немаленькая вероятность что транзакция будет смайнена. Как мне известно пулы майнят практически все, за хорошую комиссию.
Это миф, основанный непонятно на чем и взявшийся непонятно откуда. Кто-то, безусловно, майнит такие транзакции, к примеру некоторые ноды p2pool. Абсолютное же большинство майнеров использует политику по умолчанию и не будет майнить нестандартные транзакции, если только они не запушены через локальный RPC с модификациями. А это означает, что код формирования работы эту транзакцию не увидит, даже если её напрямую прислать на P2P порт, и даже не дойдет дело до вопросов о том, а какая вообще у транзакции комиссия. И это сделано не просто так, а в целях защиты от самых простых DoS атак. Если майнер не проверяет транзакции на соответствие шаблонам, то ему в мемори пул можно напихать мусора, приводящего к созданию блока, который при получении будет вообще невозможно провалидировать в разумные сроки. В обсуждениях на гитхабе встречаются примеры, чем набить блок, чтобы он валидировался 10 минут.
В итоге у такого майнера будет орфан, что в лучшем случае просто впустую сделанная работа. В худшем же случае, с помощью такого майнера проведут даблспенд атаку на людей, принимающих транзакции с 1 подтверждением. Никакая разумная комиссия не скомпенсирует риск потери награды за блок, плюс репутационные риски. По крайней мере, в обозримом будущем, пока генерационная часть на порядки превышает комиссии. Тем более что транзакции могут быть RBF, то есть атакующий их легко сможет перезаписать сразу после генерации майнером такого блока, и ничего на комиссиях не потеряет.
Каких причин? Невозможность пополнения адреса?
В частности, а равно как и односторонняя гарантия. Уже одного этого достаточно, чтобы решения не были эквивалентами, а потому к ним нельзя применять бритву Оккама.Яблоки не могут быть лучше или хуже апельсинов, это субъективное сравнение.
Ну и что, нетрудно и полностью переделать транзакцию.
Нетрудно, но эффективно ли? Переделанную транзакцию нужно будет заново передавать наследнику и прочим участникам процесса, если они есть. С каждым разом это будет всё больше и больше разубеждать их в серьезности происходящего. Социальные факторы, такие как эйджизм, тоже следует учитывать при оценке эффективности.520*2 вроде.
Лимит именно 520 байт, потому что в целях совместимости с древними клиентами скрипт перед выполнением помещается в стек, как данные. А размер значения в стеке не может превышать 520 байт. На практике это значение несколько меньше, потому что 520 байт не кратно размеру публичного ключа.В любом случае, этого более чем достаточно для использования в разумных рамках. Ибо этого хватит аж на 15 участников в multisig транзакции, как пример. Вероятнее всего, в будущем лимит уберут или поднимут, потому что segwit сделал возможным внесение изменений в скрипт машину без поломки совместимости с древними клиентами.
Отправить через ViaBTC accelerator например.
Насколько я помню, там TXID нужно вставлять, а не raw-транзакцию. Как они ее смайнят, если она до них просто не дойдет?kzv, 520 вроде.
520*2 вроде.
В килобайт может влезть довольно много кода команды которого в основном однобайтовые, главная проблема в том, что команд-то кот наплакал и именно поэтому особо не развернешься в фантазиях...
В килобайт может влезть довольно много кода команды которого в основном однобайтовые, главная проблема в том, что команд-то кот наплакал и именно поэтому особо не развернешься в фантазиях...
igor72, конкретный сценарий - это уже вопрос фантазии, техническая часть от этого особо не поменяется и можно собирать транзакцию по тому же алгоритму.
Главное чтобы фантазия влезла в 520 байт
Так как больше redeem script в себя не вмещает. Опять таки, если мне не изменяет память. Правда я бы с вами немного не согласился, так как при попадании к майнеру напрямую, есть немаленькая вероятность что транзакция будет смайнена. Как мне известно пулы майнят практически все, за хорошую комиссию. Другое дело, что обычные ноды будут такую транзакцию отвергать и непересылать соседним.
Отправить через ViaBTC accelerator например.
Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки?
Его бабки - имеет право.
Если мы говорим о наследстве как о подарке конечно, а не как о плате за уход и присмотр.
"множим сущее без необходимости", по-моему.
Навряд ли, потому что у этой схемы нет аналогов, реализуемых без OP_CLTV. Транзакция с локтаймом не является аналогом в силу причин, озвученных ранее.Кстати, если создать скрипт без "аварийного выхода", то как тогда отодвинуть срок вступления в наследство?
Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).
На самом деле нет. Ибо по итогам нет особой разницы между непополнением счета и его опустошением. Если деду не нравится наблюдаемое, то он просто выставляет внука на мороз, потом перестает делать отчисления и всё. А на сэкономленые деньги нанимает толпу сисястых сиделок, к примеру. Тем временем, нерадивому внуку еще дожить надо до снятия блокировки с того, что уже было начислено.Но изначально топик был о том, как сделать автоматическую передачу всей суммы единовременно.
"множим сущее без необходимости", по-моему.
Навряд ли, потому что у этой схемы нет аналогов, реализуемых без OP_CLTV. Транзакция с локтаймом не является аналогом в силу причин, озвученных ранее.Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).
На самом деле нет. Ибо по итогам нет особой разницы между непополнением счета и его опустошением. Если деду не нравится наблюдаемое, то он просто выставляет внука на мороз, потом перестает делать отчисления и всё. А на сэкономленые деньги нанимает толпу сисястых сиделок, к примеру. Тем временем, нерадивому внуку еще дожить надо до снятия блокировки с того, что уже было начислено. igor72, конкретный сценарий - это уже вопрос фантазии, техническая часть от этого особо не поменяется и можно собирать транзакцию по тому же алгоритму.
Конечно. Но, имхо, использовать вариант со скриптом лишь ради OP_CLTV (как в примере в вашем гайде) не оправдано - "множим сущее без необходимости", по-моему.Quote
Тем не менее, имхо, добавление черных ходов в скрипт косвенно делает схему более уязвимой. Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки? Как самый простой, но довольно частый пример развития событий.
Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).
igor72, конкретный сценарий - это уже вопрос фантазии, техническая часть от этого особо не поменяется и можно собирать транзакцию по тому же алгоритму.
Тем не менее, имхо, добавление черных ходов в скрипт косвенно делает схему более уязвимой. Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки? Как самый простой, но довольно частый пример развития событий.
Тем не менее, имхо, добавление черных ходов в скрипт косвенно делает схему более уязвимой. Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки? Как самый простой, но довольно частый пример развития событий.
Скрипт же гарантирует, что отправитель утратил контроль над отправленным на него средствами до даты, которая в нем указана.
Это полезно только если отправитель поставил именно такую цель. Например, он боится, что спустит деньги раньше времени, или что его ограбят.Quote
Кроме того, скрипт позволяет в любое удобное время увеличить сумму наследства, просто отправив на созданный из него адрес ещё одну транзакцию, и так можно делать сколько угодно раз. По сути, это может выступать не только в роли средства передачи наследства, но и в роли личного пенсионного фонда.
На мой взгляд, в таком скрипте нужно обязательно предусматривать ветвление с возможностью траты наследодателем без локтайма. Это дает несколько плюсов:1. Можно протестировать мелкой суммой вручную созданный скрипт/адрес - если деньги выводятся, то уже не страшно загрузить и крупняк. Иначе, например, я бы не рискнул ).
2. Дает возможность "аварийного выхода" в случае изменения протокола (хардфорка). Маловероятно, что понадобится, но всё-таки...
3. Выше упомянуто про возможность увеличения суммы наследства, в данном варианте ее можно также и уменьшать при необходимости. Такая опция тоже ведь должна быть, для лишения наследства хотя бы ).
Смотри, цитата из самого бипа:
Ну тут же по структуре видно что P2PKH. И из контекста такое понимание приходит.
Язык юридический, а равно как и язык описания стандартов, заметно отличаются от языка человеческого. Там написано "can be frozen", так что с точки зрения скриптовой машины никакого противоречия текущей ситуации нет. Ведь ты действительно можешь заморозить выходы таким скриптом и авторов документа не волнует, что они по умолчанию не майнятся. Это описание логики скрипт машины, а не клиента в целом. Quote
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:
CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG
Ну тут же по структуре видно что P2PKH. И из контекста такое понимание приходит.
Если бы доступность такого формата в качестве стандарта была обязательной, то использовались бы ключевые слова 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 скрипты. Эти транзакции стандартны с точки зрения текущей реализации протокола, потому и майнятся. 
Посмотрите приложенные в бипах примеры и увидите это.
Смотри, цитата из самого бипа:
Quote
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:
CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG
Ну тут же по структуре видно что P2PKH. И из контекста такое понимание приходит.
Транзакция конечно будет нестандартной, но люди в транзакции нельсона манделлу запихивают, или лого биткоина, и все ведь отлично, майнится это все.
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
Ыыыыыыы. Значит все должно получиться, и не обязательно юзать именно P2SH. Кому слабо проверить в мейн нете, а?
Так что использовать в мейн нете без P2SH/P2WSH можно, но только есть свой пул, и немаленький. И настоящий, а не прокси обвязки всякие. Ну или если у кого из друзей есть пул, и он согласится отмайнить транзакцию. Иначе транзакция если и будет подтверждена, то только в случае сильного везения. Без этого она даже в мемори пул к майнерам не попадёт.
В общем, оплата на скрипты напрямую - это решение не для смертных юзеров.
Не получится. Предложение сначала выносится на обсуждение тут, на форуме, или в списках рассылки. Потом надо будет написать подробный 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. Кому слабо проверить в мейн нете, а?
В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.
Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.
В общем, если за предложением не стоит несколько тысяч человек, которые готовы активно постить его всюду и везде, трясти СМИ, нагнетать ажиотаж и прочее, то добавить его в мейнстримовый клиент просто нереально. Причём, это касается не только чувствительных для протокола вещей, но и вполне себе утилитарного функционала, ни на что особенно не влияющего в плане совместимости.
Для примера, пулл реквест вашего покорного слуги:
https://github.com/bitcoin/bitcoin/pull/9893
Итог - ответ "нет", аргументация "потому что не нужно". Несмотря на то, какой рост производительности это даёт для кластерных решений. Я не особо упирался, правда, поскольку закоммитил это больше от нечего делать, чем от реально желания.
В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.
Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.
Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.
Прошу прощения. Что означает более старые монеты?Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.
Прошу прощения. Что означает более старые монеты?Вот здесь можно дополнительно почитать об этом. Там нужно будет дополнительно сделать несколько переходов по ссылкам.
Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.
Прошу прощения. Что означает более старые монеты?Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.
Прошу прощения. Что означает более старые монеты? Jump to: