как добавить субадрес? как добавить субадрес Слева нажмите "Получить", справа появится основной адрес, а снизу "Создать новый адрес", вот туда нажмите, дайте произвольное название-метку и всё. |
|
|
|
Даже если так, то это надо уже быть совсем кем-то отмеченным, чтобы именно с твоего леджера первая утечка произошла. А как только такая где-то произойдет это станет всеобщим достоянием. Согласен, только нужно следить за новостями. А то вон, на фишинг с Электрумом до сих пор попадаются, хотя уже скоро год будет, как шум поднялся. Большие суммы я бы все равно запер в мультисиг-кошельке. Ledger(Trezor)+Electrum в мультиподпись - и всё, можно ничего не бояться. |
|
|
|
Отслеживаемый? В любом случае, можно создать кроме primary дополнительные адреса. У меня леджер, но в трезоре, думаю, так же - интерфейс-то одинаковый. Описание как это делается есть где-то ? или может вы подскажете как там и на что жать ?Попробую подсказать, но я не понял, что именно вам не понятно? Как использовать монеро на трезоре или как добавить субадрес? Что касается passphrase, то в данном случае расчеты, применимые к паролям здесь не совсем подходят. Все-таки чтобы испытать одну passphrase дополнительно необходимо просчитать 2048 хешей. |
|
|
|
Мы, похоже, о разных вещах говорим. Не надо никуда ничего отправлять - просто наследнику передается подписанная P2PKH (P2WPKH) транзакция в виде текста и всё.
Для того, чтобы было что передавать, нужны входы с блокировкой по времени. Иначе вам передавать будет попросту нечего. А чтобы эти входы создать, нужно сначала написать скрипт с локтаймом, посчитать его хэш и отправить на этот хэш монеты. Реальной транзакций в сети, а не текстом. Я в курсе. Только не умею подписывать тратящую этот P2SH-выход транзакцию, из консоли Bitcoin Core это сделать нельзя. Как не умеет и 99% остальных биткоин-пользователей. Какой смысл в этом тогда? Да и особых преимуществ не вижу. Это в том случае, если вы хотите, чтобы никто не мог аннулировать переданную внуку транзакцию, завладев вашими ключами тем или иным образом. Если это пофиг, то да, можно просто создать транзакцию с локтаймом и все. Так всем понятно, что ключи надо беречь от посторонних. А то, что можно аннулировать переданную транзакцию, то это считаю плюсом, а не минусом. В скрипте, кстати, по-хорошему тоже надо возможность траты без локтайма (с ключом деда) предусмотреть, то есть опять надо прятать ключи. |
|
|
|
Что значит нельзя? До наступления определенного момента такую транзакцию сеть будет отвергать, но от этого она не перестает быть правильной неP2SH-транзакцией. Вполне ее можно использовать для завещания. Именно это и значит. Оправку монет нельзя провести напрямую на скрипт с локтаймом, только на его хэш т.е. P2SH адрес. Если, конечно, у вас нет в кармане своего пула, чтобы подтвердить нестандартную транзакцию. Мы, похоже, о разных вещах говорим. Не надо никуда ничего отправлять - просто наследнику передается подписанная P2PKH (P2WPKH) транзакция в виде текста и всё. Думаю, этот процесс от начала до завершения займет пару лет как минимум. Там же еще попутно будут обнуляться миллионы Накамото и прочих.
Зависит от размеров дыры. Если для взлома будет требоваться кластер, то может быть. В случае же падения криптостойкости до уровня MD5 обновление будет внедряться форсированными темпами. Ну и для того, чтобы отреагировать, надо в эти пару лет быть живым. Вполне возможно. Но это катастрофа для битка и для крипты в целом, это можно назвать форс-мажором. А если просто ECDSA станет "сомнительным" алгоритмом, то, надеюсь, умные головы придумают, как ввести новый алгоритм без хардфорка, чтобы он работал параллельно старому (как сейчас сегвит, например). |
|
|
|
Я считаю, что для простого программного завещания использование P2SH-транзакции является необоснованным усложнением. Небольшая ошибка в скрипте, и деньги отправляются в "космос". В случае с изменением nLocktime ошибиться сложно, а деньги отправить в никуда практически невозможно.
Возможно, прозвучит как высказывание Капитана Очевидность, но в стандартных транзакциях битка nLockTime нельзя использовать без P2SH. Так что пост выглядит примерно как "у меня аллергия на мед, поэтому я буду покупать облепиховый мед". Что значит нельзя? До наступления определенного момента такую транзакцию сеть будет отвергать, но от этого она не перестает быть правильной неP2SH-транзакцией. Вполне ее можно использовать для завещания. Теперь по теме... Подумал немного, и похоже что криптозавещание вряд ли стоит делать, если только на совсем короткие сроки.
Почему? Да потому что лет через 30-40, к примеру, схему ECDSA pubkey + RIPEMD могут взломать. И тогда сеть придется обновлять, очевидно что обновление будет проводиться путем последовательного выпуска сначала новой версии, которая сможет тратить выводы старого формата, но создавать их не сможет. А затем, скорее всего, будет выпущено обновление, которое удалит поддержку и траты старых инпутов. И если блокировка по времени к тому моменту не снимется, то заблокированные монеты будут потеряны навсегда. Да, такое когда-то может быть. Думаю, этот процесс от начала до завершения займет пару лет как минимум. Там же еще попутно будут обнуляться миллионы Накамото и прочих. |
|
|
|
Просто в теме постоянно кто-то пытается упростить или свернуть не туда. Как бы обсуждаются программные возможности и лучшие варианты. Я считаю, что для простого программного завещания использование P2SH-транзакции является необоснованным усложнением. Небольшая ошибка в скрипте, и деньги отправляются в "космос". В случае с изменением nLocktime ошибиться сложно, а деньги отправить в никуда практически невозможно. Вариант со скриптом, по-моему, оправдан только для каких-то сложных схем с ветвлениями и мультисигами, что в подавляющем большинстве случаев не нужно. Если у человека есть деньги на нотариуса и доверенного юриста, то думаю найдутся деньги и на специалиста который правильно сформирует транзакцию.
Действия нотариуса просты и всем понятны, а что там специалист напрограммирует, никто проконтролировать не сможет. |
|
|
|
|
If I had to burn bitcoin coins I would have sent them to the same outgoing address with a maximum fees equal to the total amount. It's probably applicable in this case too.
|
|
|
|
To ALL
Кто в курсе эта связка "GUI+аппаратник" (трезор т к примеру) имеет один уникальный (и отслеживаемый) адрес ?
Отслеживаемый? В любом случае, можно создать кроме primary дополнительные адреса. У меня леджер, но в трезоре, думаю, так же - интерфейс-то одинаковый. |
|
|
|
В RAW транзакцию это число надо перевернуть в LE.
Но блин, реально, руками это переворачивание делать муторно и легко ошибиться.
Можно здесь переворачивать https://learnmeabitcoin.com/tools/swapendian/ Интересно, спасибо, надеюсь, что народ поддержит. |
|
|
|
и для безопасности лучше когда 25 слово подлиннее.
Мы тут с коллегой в соседней ветке спорили недавно по этому поводу, и он меня переубедил, что в данном случае длина пароля в 20-30 и больше символов избыточна, достаточно и 12-ти, но случайных. |
|
|
|
Получаем правильную RAW транзакцию
0200000001b53833f2b974c9639bf8debac6861c21d59591571f75ee624f7dcbd996c1cc2800000000502102cb460ab0b6c7b551fa7faea9e38c1a327f3d2596362db453e514dc7eae1f90e20 387D6120387D61288762102cb460ab0b6c7b551fa7faea9e38c1a327f3d2596362db453e514dc7e ae1f90e288ADFEFFFFFF01083801000000000017a914e4b3d47cc59f2c895a4c09107c98f8acc47 6c9688700000000
А здесь зеленое (txid) не надо разве переворачивать (переводить в little endian)? 7. Эта транзакция не может быть отправлена в сеть, потому что ее еще надо подписать приватным ключем от адреса 2N6pgTPjjHbpTaT6YgHyZDnQewVjrzqRfsb
К сожалению стандартный клиент биткоина не умеет подписывать нестандартные отпирающие скрипты и я не могу пока найти простого способа - как добавить цифровую подпись к полученной транзакции.
Может можно как-то openssl прикрутить для подписи, там вроде есть такая опция? |
|
|
|
Да, только такую P2SH-транзакцию подавляющее большинство не сможет создать, обсуждали уже.
ну мы здесь не обсуждаем тему "как завещать биткоины для тупых". Чуть раньше kzv думал сделать вариант со скриптами лайтнинга, где были скрипты nlocktime и CheckSequenceVerify. Типа если наследник пытается потратить раньше времени свои деньги, то для него включается nlocktime, а скрипт CheckSequenceVerify дает возможность в таком случае деду потратить деньги без локтайма. Так что на сложности лучше внимания не обращать, саму возможность обсуждаем. Я, например, не умею тратить нестандартные P2SH-выходы, то есть я тупой. Думаете, мне стоит тут создать отдельную тему "как завещать биткоины для тупых"? По-моему, это общий раздел "для всех", для специфических вариантов "для умных кодеров" уже есть тема на форуме. |
|
|
|
Задача 2
Написать и отправить транзакцию такую, чтобы потратить биткоины смог только тот, кто знает пароль: 1234567 и одновременно имеет приватный ключ от адреса 2NDHNjQRV1vH6QaG3sCh3w8mMJ1JNJzxVVd
Самого интересного для себя я не увидел. Допустим, у меня есть пароль и приватный ключ от этого адреса, что мне с этим всем делать? Нанимать программиста? |
|
|
|
Т.е. получается когда вы впервые устанавливаете приложение, например для EOS, ключ вычисляется на устройстве, далее вы его удалили не потратив монеты, установили приложение для Grin и т.д. приватники для всех этих монет будут вычислены. Потом вы вводите свой сид на новом Леджере и при установке приложения для ЕОС, оно вычисляет опять определенное "место на дереве" и берет оттуда приватник? Ну да, примерно так. Только не помню, чтобы Grin поддерживался Леджером. |
|
|
|
Получается что потом когда вы вводите в новый кошелек сид, и при установке приложения для определенной монеты, которые у вас были раньше - приложение обращается к сиду и находит там приватник для кошелька этой монеты? Да. А как оно знает что там такой приватник уже был ранее, а не нужно вычислить новый?
Не понял вопроса, разверните. Как я сказал, на определенном месте дерева (на определенном пути деривации) для данного сида всегда будет один и тот же ключ, он не случайно сгенерирован, он вычислен. |
|
|
|
Я выше прочитал, что при потере своего Леджера, по сид фразе устройства можно восстановить все монеты на новом Леджере. Получается что на серверах производителей леджера где-то хранится информация о ваших монетах?
Из вашей Сид фразы генерируются все приватные ключи ко всем монетам. Восстановить все свои монеты можно и без леджера по одной сид фразе. Сид к Леджеру создается на стартовом этапе его использования. Получается что она сразу в себе содержит приватники ко всем возможным кошелькам, которые вы будете создавать в будущем для своих новых монет? Для меня это непонятно. Это все описано в BIP39 и BIP32. Мнемоническая фраза + пароль посредством хеш-функций преобразуются в огромное число, которое тоже по определенному алгоритму преобразуется в корневой приватный мастер-ключ, из которого получаются ключи следующего уровня, из тех следующего и так далее. Получается большое ветвистое дерево ключей, где каждый ключ занимает строго определенное место (derivation path) в иерархии (поэтому такой кошелек называется Hierarchical Deterministic wallet, сокращенно HD-кошелек). Кошельки, поддерживающие BIP44, сортируют главные ветви дерева по монетам, следующие ответвления по аккаунтам, ну и дальше внешние/внутренние (приемные/сдачи) и наконец ключи, которыми мы пользуемся для генерации адресов и подписывания транзакций. Это дерево при генерации леджером не просчитывается заранее (да и невозможно это), просто по мере надобности нужные ключи вычисляются из сида (даже слабомощный леджер/трезор это делает достаточно быстро). То есть ключи в леджере не хранятся, хранится только сид. |
|
|
|
~
Как вариант можно сделать две транзакции с разным локтаймом. Первый локтайм например на 5 лет для "основного наследника", вторая транзакция с тех же выходов с локтаймом на 5,5 лет на "запасного наследника". Если основной наследник закинет свою транзу в сеть - выходы потратятся и Биткоины переведутся на его адрес, для "запасного наследника" ничего не останется. В противном случае все достается через полгода "запаснику".
Думаю, что не все случаи может закрыть этот способ. Конечно не хочется крайностей в примерах, но бывает такое в жизни, что у наследника не будет выхода в интернет, в определенный период времени. И тогда этот механизм не будет работать. Надеюсь не надо приводить примеры, где человек может находиться 5 и более лет. Можно придумать страховку и на случай попадания за решетку наследодателя или первого наследника: 1. Дед делает транзакцию с локтаймом, допустим, "+1 год" для внука, состоящую из двух исходящих адресов - адреса с наследуемой суммой и "подрывного" адреса, на котором лежит, скажем, 5 баксов (или 50, лишь бы на комиссию хватило при любых раскладах). Приватник этого второго адреса нужно запомнить, поэтому в идеале адрес лучше создать из придуманного приватника (alevlaslo у нас тут специалист по этому). 2. Также делается транзакция для внука с локтаймом "+5 лет", но без "подрывного" входа. 3. Повторяются пункты 1 и 2, но уже это будут транзакции для внучатого племянника с локтаймами, соответственно, "+2 года" и "+6 лет". Всё, раздаются по две транзакции наследникам, внуку дается тот легкозапоминающийся приватник (он должен его выучить не позже смерти деда). Теперь, если дед попадает за решетку, он может оттуда послать письмо на волю с приватником другу/приятелю, чтобы тот либо сам потратил эти деньги, либо отправил на криптофорум сообщение, типа: "вот, мне тут дали какой-то номер <вставить приватник>, чё с этим делать?")). Как только деньги потратятся, транзакции "+1 год" и "+2 года" станут инвалидными. Если внук попадет за решетку после смерти деда, но раньше времени локтайма, он сможет так же перенести локтайм на 4 года. Конечно, схема усложняется, но сделать такое можно. |
|
|
|
|
Show Posts
