и помещается в выход типа OP_RETURN транзакции coinbase. Спасибо, этого не знал. Видел эти op_return в первой транзакции, теперь понятно, что там. Хотя их там часто по три штуки вместо одного.
|
|
|
Подпись включена в хэш транзакции. Не будет подписи - никак не проверить правильность хэша транзакции. Не проверите хэш транзакции - не сможете проверить хэш блока В сегвит подпись не входит в хэш транзакции, а таких транзакций уже процентов 80, если не ошибаюсь.
|
|
|
Заметил, что транзакции с этих разных "аккаунтов" отличаются версией, как будто разным софтом создавались. Дальше выяснилось, что и ключи в транзакциях были разного типа (сжатый и несжатый), возможно поэтому и версии разные. Похоже, что два адреса, с которых угнали монетки, созданы в разных программах, но автор об этом ничего не сказал.
|
|
|
Не убеждает. Имея физический доступ к потрохам можно взломать практически любое устройство. Не знаю. Но помню, как они писали, что их устройство неуязвимо в том числе и при физическом доступе, благодаря секьюрному чипу. Мол, поэтому у них даже нет пломб на девайсах/коробках, как у трезора.
|
|
|
Как можно судить об уровне програмистов не имея доступа к разрабатываемым кодам? Разве нельзя судить о мастерстве повара по блюдам на столе? За 5 лет несколько раз сам сталкивался с глюками прошивки и Ledger Live и видел много жалоб на реддите. Еще вспоминается, как уязвимость (именно уязвимость), найденную в конце 17-го года, они исправляли 4 месяца. По-моему, это очень долго. Справедливости ради нужно сказать, что последние две-три прошивки Nano S у меня работают хорошо (да и у народа вроде бы). Но Ledger Live пока еще не безупречен. И с серверами у них периодически проблемы - недавно не мог отправить XLM, пришлось подключаться к стороннему сервису (благо, он есть в данном случае).
|
|
|
Это безопасно настолько, насколько они захотели или смогли, не больше.
Это значит уязвимости они добавляют намеренно? Мне в это не верится, хотя исключать бэкдор в прошивке у меня тоже оснований нет. Все люди ошибаются и никто не сможет написать идеальный код. Может быть. Но за пять лет наблюдения за леджеровцами у меня сложилось впечатление, что там программисты, скажем так, не самого высокого уровня, могли бы быть и лучше при таком бюджете. Не совсем понял вашу мысль. Я говорю, что новые версии леджеров принципиально мало отличаются от старой, поэтому вероятность новой уязвимости ненамного выше, чем в старой нано с.
Аналогия с айфонами здесь тоже уместна? Не слежу за айфонами, но думаю, что нет, все-таки слишком разные устройства по сложности - в леджере прошивка-операционка весит около 150 килобайт, в смартфонах на порядки больше.
|
|
|
А что есть доказанный факт с точки зрения нахождения дыр в безопасности? Открытые и проверенные сообществом исходники для меня являются основанием считать кошелек безопасным (в плане дыр). Уязвимости найти пытаются постоянно, тратят на это тысячи и миллионы долларов и пока безуспешно. Что они там делают и на что тратят деньги на самом деле, нам достоверно неизвестно. Ищут уязвимости у конкурентов и выкладывают их на своем сайте, это мы видим. В то же время мы сталкиваемся с периодическими багами в леджер лайв и нестабильной работой нод некоторых монет. Может, и с прошивкой там не все так безопасно, как утверждают, кто знает? Это безопасно насколько возможно и это факт. Это безопасно настолько, насколько они захотели или смогли, не больше. Для чего на аппаратные постоянно выпускают прошивку в таком случае? Если баги не фиксяться, то в один прекрасный момент могут появится через неосторожное обновление прошивки. А если баги найдут, то старыми версиями кошельков пользоваться будет невозможно.
Не совсем понял вашу мысль. Я говорю, что новые версии леджеров принципиально мало отличаются от старой, поэтому вероятность новой уязвимости ненамного выше, чем в старой нано с.
|
|
|
Кошелек безопасен, это факт Доказанный факт? Или факт потому, что не доказано обратное? Я бы любой кошелек с закрытым кодом относил к небезопасным. Вместо прддеожки старой продукции, они выпускают новую чуть ли не каждый год и уязвимости в одной из новых моделей это лишь вопрос времени. Каждые три года точнее (nano s - 2016, nano x - 2019, nano s+ - 2022). Да и последние два, я думаю, по софту мало чем отличаются от первого, вряд ли там появятся новые уязвимости. По этому поводу я бы не переживал.
|
|
|
Как нода понимает, что последний блок, который она добавила, добавили так же все остальные? Никак, она этого не знает. в самом блоке есть подписи нод? Нет. или сложность pow хэша такая, что подразумевается, что другого блока быть и не может и нода принимает его не опрашиваю другие ноды?
Другой блок случается периодически (раз в несколько месяцев в среднем, кажется). Суть здесь в том, что верной считается самая длинная цепочка блоков. Если нода приняла блок, и оказалось, что он прицеплен не к тому, который она приняла перед этим, а высота (номер) этого блока больше, то нода считает эту версию блокчейна правильной и переписывает в своей базе предыдущий блок (или несколько) согласно этой версии. p.s. Я говорю о биткоине и подобных. Как устроены всякие экзотические сети, я не знаю, меня это не интересует.
|
|
|
Сегодня такое же письмо и мне пришло. Не знаю, как у ТС, а у меня был отправитель "Stellar Development Foundation< noreply@justbetja.com>". Всегда обращайте внимание на адрес электронной почты отправителя, по нему обычно сразу понятно, что это спам или фишинг.
|
|
|
Во всех кошельках, которые мне попадались, эфир использует стандарт bip44, адресов здачи нет, так что подобрать путь деривации не проблема и нет смысла в подобной таблице. Наверное, вы правы, действительно можно подобрать - либо убрать нолик, либо добавить ). Вот у меня леджер около пяти лет, поэтому мои эфиры лежат на пути m/44'/60'/0'/0, а кто не застал времена до Ledger Live, тот уже получал адрес по пути m/44'/60'/0'/0/0. Оба вроде по BIP44, и первый как будто тоже логичный, так как сдачи нет, а значит один параметр лишний. А ETC у меня на леджере лежали вообще по пути m/44'/60'/160720'/0'/0, не знаю, чем они там руководствовались, когда такое придумывали. В Ledger Live уже выдаются по стандартному m/44'/61'/0'/0/0. А, например, в Atomic wallet эфирный адрес вообще получен из корневого мастер-ключа m. При том, что другие account-based монеты там нормально расположены (ну как нормально, одну ветку все-таки убрали, как в старом леджере, то есть с большинством несовместимо). В таблице про которую я написал по аналогии с биткоином можно примерно определить какой путь деривации будет у других UTXO монет, в любом случае других подобных таблиц я не встречал.
В UTXO-монетах все вроде в порядке, такого разброда я не видел. По большому счету, и там эта таблица не нужна, имхо ). Разве что подсмотреть пути деривации мультисигов, но и они там у всех совместимые вроде бы.
|
|
|
Различные пути деривации кошельки используют скорее всего в маркетинговых целях, чтобы привязать клиента к себе. Не думаю, иначе у всех были бы свои пути деривации. Наоборот, по-моему, все стремятся к унификации, просто в некоторых случаях либо пока не выработан стандарт, либо он неоднозначно трактуется. Вот сайт, на котором собраны различные пути деривации популярных кошельков, если возникнет необходимость восстановления монет на не родном кошельке. Там указаны пути деривации только для биткоина, а по биткоину расхождений практически не наблюдается, полезнее была бы такая табличка для эфира и прочих account-based монет. Еще там для некоторых кошельков одинаковые пути деривации записаны по-разному, можно запутаться. Например, для Mycеlium, Electrum и Trust wallet пути деривации на сайте указаны соответственно m/84'/0'/n' , m/84'/0'/0' и m/84'/0'/0'/0/0, а при импорте сида в эти кошельки мы получим одинаковые адреса.
|
|
|
Вопрос только в удобстве такого подхода: человеку проще воспринимать слова, чем рандомный набор символов. Оперировать строками из кракозябр - это шаг назад в подходе к кошелькам. Со словами удобнее, конечно. Хотя для некоторых и английские слова - это набор кракозябр ). Для разовой операции это большого значения не имеет. Важнее другое. Мы здесь говорим про варианты действий при невозможности использования родного интерфейса аппаратного кошелька. Самые популярные кошельки (леджер и трезор) можно использовать со стронними интерфейсами, это решает проблему для многих монет. Для тех же монет, которые нельзя отправить аппаратником без использования родного софта, как раз использование приватников предпочтительнее использования сид-фразы в горячем кошельке, так как подвергаются риску компрометации не все монеты, а только одна. Если вручную копировать, то нет. Главное, чтобы офлайн-комп после не подключался к сети. В статье про это не написано, но подразумевается, что отключение компьютера временное. Цитирую: "Использовать ПК который больше никогда не будет подключен к сети или сразу же после восстановления приватного ключа, на нем будет переустановлена ОС". Импортировать один ключ, чтобы никогда больше не серфить Интернет с этого девайса? Никто на такое не пойдет, а значит есть риск потери денег. Для этого проще всего использовать Live-cd флешку с системой. Сам иногда пользуюсь в подобных случаях Tails, вполне удобно. Каким стандартам, BIP44? С utxo-монетами там все понятно и однозначно, а как трактовать этот бип для всяких эфироподобных монет? Какой путь деривации эфирного адреса считать стандартным: m/44'/60'/0'/0/0, m/44'/60'/0'/0 или m/44'/60'/0? И почему? Здесь среди разработчиков кошельков согласия нет.
Потому что они даже консенсус меняют по нескольку раз в год, чего уж говорить про генерацию адресов. Не поэтому. Переформулирую вопрос. Если бы вы были разрабом eth-кошелька, какой путь деривации из перечисленных вы бы выбрали, и почему?
|
|
|
Оперировать сырыми приватными ключами даже на оффлайн-компьютере это не очень хорошая идея: во-первых вам еще надо как-то перенести приватный ключ Да просто перепечатать руками, это займет минуту времени (флешку дольше искать-подключать-копировать туда сюда), а главное безопаснее всего. а во-вторых если компьютер был до этого подключен к сети, то это верный способ потерять вообще все средства. Если вручную копировать, то нет. Главное, чтобы офлайн-комп после не подключался к сети. Если два мультивалютных кошелька поддерживают разный набор монет, но при этом следует одному стандарту (BIP39 и SLIP39), то импортировать лучше сид-фразу целиком. При этом все монеты и адреса должны быть на своих местах, так как специфичные монеты всегда булут иметь один и тот же путь деривации на разных кошельках. Кошельки, которые не следуют стандартам, вообще следует избегать, так как ваши монеты могут быть залочены на нестандартных путях деривации. Каким стандартам, BIP44? С utxo-монетами там все понятно и однозначно, а как трактовать этот бип для всяких эфироподобных монет? Какой путь деривации эфирного адреса считать стандартным: m/44'/60'/0'/0/0, m/44'/60'/0'/0 или m/44'/60'/0? И почему? Здесь среди разработчиков кошельков согласия нет.
|
|
|
Все выглядело натурально Да, часто в таких случаях делают одну страницу, и ссылки с нее никуда не ведут. А в данном случае действительно всё, как в оригинале, даже аппаратники вроде бы подключаются. Спасибо за сообщение, будьте бдительнее в следующий раз.
|
|
|
В связи с ограничениями, которые постоянно вводят. Решил написать краткую инструкцию как запускать Ledger Live и Trezor Suite под Ubuntu.
Полезная инструкция, кому-то, наверное, пригодится. Но это описывает, как сделать загрузочную флешку для работы с аппаратником. Как это связано с ограничениями? Для обхода ограничений, по-моему, первым делом VPN нужен, и, возможно, этого будет достаточно.
|
|
|
Можно конечно и так, но как мы помним больше сидов - это больше бэкапов и больше вероятность потерять один из них. При хранении в одном месте (на одном листе бумаги, например) вероятность потери увеличиваться не будет. Ну а у родственника с BIP85 все равно есть лазейка - достаточно поставить надежную парольную фразу и никто не сможет увести средства. Тогда зачем ему вообще у нас что-то хранить? Разговор же начинался с того, что родственник неопытный, легкомысленный. Он так и парольную фразу потеряет/забудет, особенно если она надежная (т.е. сложная). Вот кстати на заметку семейным - мультиподпись 2 из 2 хорошо подходит для хранения семейного бюджета. Тратить средства можно только после согласия обеих сторон. Никаких вам "мои деньги - это мои деньги, а твои деньги - это наши деньги." Не знаю, может быть кому-то это и подойдет (сомневаюсь). У меня за 30 лет семейной жизни таких разговоров никогда не было ). Также поможет при разделе имущества. Возможен вариант "так не доставайся же ты никому".
|
|
|
Ничто не помешает потерять бэкап: если очень захотеть, то можно практически все. Сам по себе BIP85 ничем не отличается в плане бэкапов: вы делаете копию своей сид-фразы и храните ее в безопасном месте. Но вот ваши неопытные родственники могут забыть сделать копию или они могут потерять свой бэкап. Но вы как опытный криптовалютный пользователей всегда можете помочь родственникам восстановить доступ к кошельку, сгенерируя все их бэкапы со своего собственного бэкапа. Можно конечно и так (для этого мне никакой BIP85 и не нужен), а можно просто все сиды родственника у себя хранить. Разумеется, здесь присутствует вопрос доверия, так как вы всегда можете потратить средства с их кошельков. В этом плане это решение хуже, но в плане удобства оно выигрывает перед мультиподписью: для отправки транзакции не надо никуда ходить и не надо много заботиться о правильном хранении бэкапов. По-моему, идеально для обучения пользованию криптовалют. В том-то и дело, что "присутствует вопрос доверия". Я, например, не хочу оказаться в ситуации, когда у родственника уведут монеты с кошелька, а вы? Вопрос риторический. Помню, разбирали случай на форуме, когда у человека с леджера ушли все деньги, и мы, перебрав вроде бы все варианты, так и не придумали возможную причину, - всё как будто у него было правильно. Только его жена знала, где хранится бумажка с сидом, и тут хочешь-не хочешь, а начнут нехорошие мысли появляться... Я тогда как-то хорошо прочувствовал ужас ситуации, поэтому и на хранение чужого сида никогда не подпишусь, ну и свой, конечно, никому не доверю.
|
|
|
|