Пароль является 13-тым словом. Как ты зная 13-ое слово планируешь получить остальные 12.
Я так понял, что не этот пароль имелся в виду, а пароль на кошелек. Который требуется при отправке транзакции и показе секретных данных. Но ответ тот же ). |
|
|
|
А никакого практического смысла нет.  На доступном в обозримом будущем уровне технологического развития... Мне, видимо, следовало выразиться яснее. Я имел в виду, какой смысл в знании, что пар ключ-хеш не 2 160, а больше? Вы написали: Потому что нас интересует не просто множество ни с чем не связанных хэшей, что было бы совершенно бесполезно, а множество пар (ключ, хэш). Это очень разные вещи. Поясните, почему это множество нас интересует, и почему полезно? |
|
|
|
Даже если у хэша длина 1 бит, соответствий (ключ, хэш) всё равно будет 2161. А какой в этом практический смысл? У нас есть 2 256 закрытых ключей, из каждого получаем 2 открытых ключа - сжатый (33 байта) и несжатый (65 байт). Все эти ключи (2 257) хешируем HASH160, получается 2 160 уникальных адресов и 2 97 коллизий. Где здесь ошибка? Кстати, количество пар у меня получилось 2 257, а не 2 161. |
|
|
|
2161 значений hash160 Как такое возможно? Это все равно что 4 значения вместить в одном бите, 8 в двух и так далее. |
|
|
|
Скажите пожалуйста если я не знаю пароля от Electrum я могу достать сид фразу - 12 слов? она есть в кошельке у меня.
Нет, конечно. Какой смысл был бы в пароле, если бы он не закрывал сид? |
|
|
|
|
Хорошо, я понял, спасибо за ликбез.
Так сколько адресов в итоге нужно считать в первом посте?
Получается, 2161 P2(W)PKH + 2160 P2WPKH-P2SH = 1.5 * 2161. Так?
P2(W)SH получается самый надежный тип адреса - его никто не будет даже пытаться ломать всякими "коллайдерами" )).
|
|
|
|
[...]
Ок, я понимаю, что 20-байтный хеш в P2PKH и P2WPKH одинаковый, можно ли после преобразования в удобный формат считать их одним адресом хотя бы в контексте расчетов в первом посте? Я думаю, что нет. Ведь при кодировании в base58check еще два SHA256 считать приходится, так что конвертация из bech32 в base58check проходит лишь в два раза быстрее, чем полная генерация P2PKH-адреса из ключа (про скорость кодирования в bech32 не знаю, чек-сумма как-то хитро там считается и, кажется, без хешей). |
|
|
|
Каких причин? Невозможность пополнения адреса?
В частности, а равно как и односторонняя гарантия. Уже одного этого достаточно, чтобы решения не были эквивалентами, а потому к ним нельзя применять бритву Оккама. Яблоки не могут быть лучше или хуже апельсинов, это субъективное сравнение. У меня ощущение, что мы с вами разные задачи решаем. Я решаю задачу залочить транзакцию на какое-то время и всё, никаких фондов и прочего. В этом смысле я не вижу особой разницы в двух методах, поэтому выбираю тот, что проще и надежнее. Ну и что, нетрудно и полностью переделать транзакцию.
Нетрудно, но эффективно ли? Переделанную транзакцию нужно будет заново передавать наследнику и прочим участникам процесса, если они есть. Я не вижу проблем с этим. В конце концов, эту транзакцию можно выложить в десятке облачных хранилищ и дать ссылки наследнику, при изменении только содержания файла (не имени) ссылка меняться не будет. С каждым разом это будет всё больше и больше разубеждать их в серьезности происходящего. Социальные факторы, такие как эйджизм, тоже следует учитывать при оценке эффективности. Не знаю, это, по-моему, уже их проблема. |
|
|
|
Значение HASH160 для всех типов адресов (legacy, P2WPKH-in-p2sh, bc1-P2WPKH) вычисляется одинаково, поэтому формат адреса не имеет никакого значения. Это просто разные способы записи одного и того же хэша в "человекопонятном" виде, и не более того. Но это же разные адреса? А то получается, что как-будто 3 адреса из одного публичного ключа - это один и тот же адрес, но тогда они могли бы конвертироваться друг в друга (как, скажем, в лайткоине адреса на 3 и M). Дело в том, что публичный ключ может быть записан в двух формах - сжатой и несжатой. Точно! Про несжатые P2PKH вылетело из головы. Итого, на 2^160 закрытых ключей получается:
Почему на 2^160? На 2^256, в среднем 2^96 закрытых ключа будут давать одинаковый адрес. P2WSH адреса совсем другая степь, для них никакого соответствия не будет. Равно как и для обычных P2SH адресов, не сегвитных. Да, но я говорил про количество всех возможных биткоин-адресов (не обязательно полученных из ключа). P2WSH-адрес тоже является биткоин-адресом, не так ли? |
|
|
|
Количество адресов биткойнов: 2160
Побольше, по-моему: 2 160 адресов на "1" (P2PKH) 2 160 адресов на "3" (P2SH) 2 160 адресов на "bc1" (42 символа) (P2WPKH) 2 256 адресов на "bc1" (62 символа) (P2WSH) |
|
|
|
Отправить через ViaBTC accelerator например.
Насколько я помню, там TXID нужно вставлять, а не raw-транзакцию. Как они ее смайнят, если она до них просто не дойдет? kzv, 520 вроде. |
|
|
|
"множим сущее без необходимости", по-моему.
Навряд ли, потому что у этой схемы нет аналогов, реализуемых без OP_CLTV. Транзакция с локтаймом не является аналогом в силу причин, озвученных ранее. Каких причин? Невозможность пополнения адреса? Ну и что, нетрудно и полностью переделать транзакцию. Кстати, если создать скрипт без "аварийного выхода", то как тогда отодвинуть срок вступления в наследство? Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).
На самом деле нет. Ибо по итогам нет особой разницы между непополнением счета и его опустошением. Если деду не нравится наблюдаемое, то он просто выставляет внука на мороз, потом перестает делать отчисления и всё. А на сэкономленые деньги нанимает толпу сисястых сиделок, к примеру. Тем временем, нерадивому внуку еще дожить надо до снятия блокировки с того, что уже было начислено. Это если система типа регулярно пополняемого фонда (да и то, уже зачисленнные деньги не вернешь). Но изначально топик был о том, как сделать автоматическую передачу всей суммы единовременно. |
|
|
|
igor72, конкретный сценарий - это уже вопрос фантазии, техническая часть от этого особо не поменяется и можно собирать транзакцию по тому же алгоритму. Конечно. Но, имхо, использовать вариант со скриптом лишь ради OP_CLTV (как в примере в вашем гайде) не оправдано - "множим сущее без необходимости", по-моему. Тем не менее, имхо, добавление черных ходов в скрипт косвенно делает схему более уязвимой. Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки? Как самый простой, но довольно частый пример развития событий. Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ). |
|
|
|
Скрипт же гарантирует, что отправитель утратил контроль над отправленным на него средствами до даты, которая в нем указана. Это полезно только если отправитель поставил именно такую цель. Например, он боится, что спустит деньги раньше времени, или что его ограбят. Кроме того, скрипт позволяет в любое удобное время увеличить сумму наследства, просто отправив на созданный из него адрес ещё одну транзакцию, и так можно делать сколько угодно раз. По сути, это может выступать не только в роли средства передачи наследства, но и в роли личного пенсионного фонда.
На мой взгляд, в таком скрипте нужно обязательно предусматривать ветвление с возможностью траты наследодателем без локтайма. Это дает несколько плюсов: 1. Можно протестировать мелкой суммой вручную созданный скрипт/адрес - если деньги выводятся, то уже не страшно загрузить и крупняк. Иначе, например, я бы не рискнул ). 2. Дает возможность "аварийного выхода" в случае изменения протокола (хардфорка). Маловероятно, что понадобится, но всё-таки... 3. Выше упомянуто про возможность увеличения суммы наследства, в данном варианте ее можно также и уменьшать при необходимости. Такая опция тоже ведь должна быть, для лишения наследства хотя бы ). |
|
|
|
B пpилoжeнии - нeт пoдтвepждeния тpaнзaкций. Bиcит бoльшe cyтoк. Ha блoкчeйнe вce пo нyлям пoкaзывaeт. Ктo-тo cтaлкивaлcя c тaкoй пpoблeмoй ?
Транзакция есть в блок-эксплорере или нет? Не понятно. Я бы на вашем месте импортировал бы сид-фразу в Electrum, посмотрите эту тему. |
|
|
|
|
Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?
|
|
|
|
Ну хорошо, допустим, что условия я смогу исполнить. Меня интересует для начала, на какой адрес монеты ушли? Как это узнать? Ни на какой, адресов никаких не существует и вопрос об адресе не имеет смысла. Адреса - это абстракция, физически никаких адресов в сети биткойна нет. Да, действительно, это я не подумав спросил ). При создании транзакции нужно же просто знать txid предыдущей и номер выхода. Ручками я могу сделать скрипт, закодировать его в P2SH-адрес, даже создать тратящую с этого адреса выход транзакцию. Но как ручками эту тратящую транзакцию подписать, вы знаете? Чтобы без программирования. Конечно знаю, и никакого программирования не надо. Если хотите, покажу пример в реальном битке, чуть попозже сочиню скрипт. И сделаю транзакции для демонстрации. Отлично, буду ждать. |
|
|
|
Логично. Но я вот выше сделал какую-то непонятную транзакцию, и почему-то кор ее не отверг, принял.
Потому что в тестнете нет проверки на соответствие шаблонам. Там принимаются любые возможные фантазии, без проверки. Надо будет в основной сети то же самое сделать. Но странно, казалось бы тестовая сеть на то и тестовая, чтобы реагировать на "фантазии" так же, как и основная. Особенно интересно, куда монеты улетели ))?
Монеты вполне живы. Если у вас есть возможность исполнить условия, соответствие которым ожидает скрипт, то их трата не должна быть проблемой. Ну хорошо, допустим, что условия я смогу исполнить. Меня интересует для начала, на какой адрес монеты ушли? Как это узнать? А как пользоваться? Я этот вопрос всем задаю после подобных пожеланий, и никто не отвечает ).
Ручками. Формат скриптов простейший, даже никаких инструментов не надо. Только прогнать decodescript для проверки, разве что. Если же аллергия на шестнадцатеричную систему счисления, то используйте инструменты вроде bcoin Ручками я могу сделать скрипт, закодировать его в P2SH-адрес, даже создать тратящую с этого адреса выход транзакцию. Но как ручками эту тратящую транзакцию подписать, вы знаете? Чтобы без программирования. Аллергии на шестнадцатеричную систему у меня нет, я не боюсь командной строки, но с программированием знаком только на уровне написания простых батников (то есть практически никак). |
|
|
|
Я вот тоже с удовольствием хотел бы купить купить леджер со скидками, когда они были, но в мою страну не доставляют. Ради интереса попробовал заходить с прокси России, Польши, Австрии - такая же фигня.
Поэтому понятно, чего у человека такая проблема возникла.
Раньше были конторы, которые занимались пересылками в нужную вам страну, уже не помню их названий, но смысл такой, хочешь что-то купить на ebay а в твою страну не поставляют, это контора покупает и получает товар по своему адресу, а далее они уже пересылают туда куда нужно. По поводу они покупают или вы, просто с заказом на их адрес, это надо уточнять. Да это дополнительные расходы, но по крайней мере можно заказать. А ещё как вариант, можно посмотреть у официального представителя в соседней вам стране Он написал, что "хотел бы купить леджер со скидками", а так вся экономия уйдет на посредников. Купить у оф. ретейлера в России с доставкой в Беларусь можно без проблем. |
|
|
|
Также все эти цифры не учитывают время отклика системы на ввод пароля. Если сделать отклик 3-5 секунд, то время поиска драматически возрастет.
Да. Например, в сидах BIP39 используется 2048-кратное хеширование, в AES-шифровании архиватора 7zip 262144-кратное, а где-то, наверное, однократное. Разница на порядки. |
|
|
|
|
Show Posts
