Size: a a a

2019 March 13

R

Rom in Dash-Ru
нет денег нет проблем😀
источник

✔R

✔ Alex Ru in Dash-Ru
Rom
нет денег нет проблем😀
Может поставить это слоганом на главную офиц Даш сайта? 🤪
источник

R

Rom in Dash-Ru
✔ Alex Ru
Может поставить это слоганом на главную офиц Даш сайта? 🤪
не поймут😬
источник

YF

Your Friend in Dash-Ru
Дальше ростём
источник

YF

Your Friend in Dash-Ru
Я про курс на бинансе
источник

CI

Co. In in Dash-Ru
Co. In
Это упрошенный вариант и есть неточности. Как доберусь до компа и будет свободное время напишу более детальный пример с подробным объяснением. С мобилки неудобно строчить. Вопрос постоянно возникает у пользователей так что думаю еще понадобится)
Немного теории, чтоб материал был доступен для любого уровня криптопанков))

Как получаются адреса в ваших кошельках?
Генерируется случайная последовательность (32 байта), которая называется приватным ключем. Дальше из этой последовательности генерируется другая связанная с ней последовательность (64 байта) которая называется публичным ключем, после чего он хешируется SHA-256 а после и RIPEMD160 (в целях безопасности и уменьшения размера) и на выходе мы имеем (20 байт), которые кодируются с помощью base58 и на выходе мы получаем привычный для нас адрес
Я упустил добавление всяких префиксов и контрольных сумм, так как они добавлены для дополнительной валидации адреса и большей наглядности, а в блокчейне не хранятся.

Какая особенность расходования транзакций существует?
Одним из условий для облегчения хранения и поиска транзакций в блокчейне, а также дополнительного запутывания транзакций является полное расходование входов. То есть сумма монет на входах всегда равна сумме монет на выходах, с учётом комиссии.
Для наглядности возьмём любую реальную транзакцию
https://chainz.cryptoid.info/dash/tx.dws?14213238.htm
На адресе XmDku4mxao2MjdSy8ttFeeNcYr5PNdv3oq находилось 26.42153331 DASH. Дальше его владелец перевёл, либо 0.0872093 DASH на Xho65RQTT2SPFUyFBbj2wfmEpy5Yu5tm3w, либо 26.33432175 DASH на XtKodAYqf4WEmc5XtoB5sdqW7w4nLVLh3U, где адрес получателя мы не знаем и какова из этих двух сумма перевода а какая сдача от входа. Если бы сдача вернулась на тот же адрес с которого была отправлена, это можно было бы понять методом исключения. Давайте представим что владелец перевёл 0.0872093 DASH на адресс Xho65RQTT2SPFUyFBbj2wfmEpy5Yu5tm3w, и заплатил комиссию 0.00000226 DASH (разницу между суммой монет на входах и суммой монет на выходах)

Так это такое и что же нам даёт HD Wallet?
В далёкие времена когда не было Seed фраз и бекапы кошельков не создавались автоматически. Существовало два способа резервного копирования. И у каждого из них были свои недостатки. Первый это сохранением кошелька (wallet.dat) на каком-то внешнем носители, и молится чтоб этот носитель не испортился и не потерялся. Второй способ это экспортировать приватный ключ от адреса на котором хранятся средства. И вот тут начинается самое интересное. Вернемся к примеру транзакции выше и представим что мы и есть владелец адреса XmDku4mxao2MjdSy8ttFeeNcYr5PNdv3oq. Нам подарили на день рождения приватный ключ от 26.42153331 DASH мы его распечатали в виде QR кода (чтоб проще было вводить) и сохранили в самом надежном месте. Но тут вдруг мы захотели купить дилдо за 0.0872093 DASH, ну и чтоб мамка не узнала что мы купили дилдо, удалили кошелек с диска и сожгли компьютер. Каково же будет разочарование когда мы попытаемся восстановить адрес из нашего QR кода и увидим пустой баланс. А всё потому что сдача 26.33432175 DASH вернулась на наш второй адресс в кошельке (XtKodAYqf4WEmc5XtoB5sdqW7w4nLVLh3U), и восстановили мы только один адрес а не весь кошелек. А экспортировать все задействованные адреса такая себе забава. Поэтому поклонники сохранения wallet.dat начали делать его автоматические резервные копии. А сторонники бумажных бекапов придумали HD wallet. Но перед тем как рассказать про устройство HD wallet, расскажу про один недостаток резервных копий про который не все знают. Дело в том что при первом запуске DASH создается кошелек, с предварительно сгенерированными адресами. За количество которых отвечает параметр keypool=1000, также эти адреса помимо использования для сдачи используются в PrivateSend. Так что не забываем что после анонимизации монет, ваш баланс размазан по множеству адресов, так что не забывайте про это. Так вот, в резервной копии кошелька хранятся ключи (по крайней мере раньше так было) в количестве равном keypool. То есть если вы использовали 1001 адрес, то первый адрес из списка не попадёт в резервную копию. И будет обидно если на нём лежала мастернода. Но этого можно избежать если использовать HD wallet. Так как же он устроен? Изначально в нём генерируется Seed, семечка из которой в дальнейшем будет строится всё дерево ключей.
источник

CI

Co. In in Dash-Ru
Co. In
Это упрошенный вариант и есть неточности. Как доберусь до компа и будет свободное время напишу более детальный пример с подробным объяснением. С мобилки неудобно строчить. Вопрос постоянно возникает у пользователей так что думаю еще понадобится)
И последовательность создания ключей всегда одинакова для каждого Seed, в отличии от обычного кошелька, где ключи генерируются случайным образом (и вероятность того вам попадётся ваш потерянный ключ снова, не больше чем встретить две одинаковые песчинки во вселенной). Для более человекоподобного  вида который легче ввести чем последовательность байт. Придумали Mnemonic фразу, состоящую из набора простых узнаваемых слов. Это просто разновидность представления в виде слов Seed последовательности, поэтому это обратимый процесс. Mnemonic в Seed и Seed в Mnemonic. Есть некоторое ограничение по тому в какой последовательности должны быть эти слова, и что эти слова не произвольные а описаны в словаре, но это больше тонкости математической реализации. Дальше Seed хешируется с помощью HMAC-SHA512 и на выходе мы получаем 64 байта, первые 32 из которых представляют первый приватный ключ, а последние 32 так называемый ChainCode (который пригодится нам при генерации следующего приватного ключа). Следующая цепочка формируется как снова таки хеш HMAC-SHA512, но не от Seed, а от предыдущий публичный ключ + предыдущий ChainCode + индекс цепочки, в результате получаются всё те же 64 байта и всё повторяется по кругу столько раз, сколько ключей нам нужно. Таким образом сдача всегда приходит на какую-то из цепочек HD Wallet и всё что нам нужно это сохранить Seed или Mnemonic где-то в безопасном месте. Также в некоторых кошельках например DashCore есть возможность указать MnemonicPassphrase, своего рода соль, которая накладывается на Seed и меняет начальный вектор формирования ключей, то есть имея один общий Seed и разные пароли, можно проще, хоть и менее безопасно создать две разные ветки ключей, допустим одну для вас, а вторую для вашего родственника. Для создание HD Wallet в DashCore, необходимо удалить старый wallet.dat и запустить c аргументом --usehd, также можно указать аргументы --hdseed, --mnemonic, --mnemonicpassphrase

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

CI

Co. In in Dash-Ru
Писатель с меня так себе, но коль обещал
источник

AV

Aliaksei Volnov in Dash-Ru
/tip @co_in 2.0 mDash
источник

AV

Aliaksei Volnov in Dash-Ru
@co_in, информация о наличие  MnemonicPassphrase для меня открытие.
источник

J

JanMia in Dash-Ru
Co. In
Писатель с меня так себе, но коль обещал
Меня мучает такой вопрос. В вашей рукописи написано что из seed можно нагенерить любое кол-во адресов. К примеру, я нагенерил их 5000, а на 5001 адрес перевел 1 dash. Потом удалил кошелек и восстановил его заново при помощи seed. Как клиент-кошелек догадается  проверить все 5001 адрес чтобы собрать полный баланс?
источник

CI

Co. In in Dash-Ru
Никак) нужно либо нагенерить 5001 заново, либо указать в dash.conf keypool=5001
источник

J

JanMia in Dash-Ru
Эм, а если я в наследство получил seed фразу, от дедушки, которые ее юзал 50 лет. Как мне понять реальную вложенность адресов?
источник

CI

Co. In in Dash-Ru
JanMia
Эм, а если я в наследство получил seed фразу, от дедушки, которые ее юзал 50 лет. Как мне понять реальную вложенность адресов?
То вам. Нужен скрипт
источник

J

JanMia in Dash-Ru
В этом отношении тогда бекап wallet.dat как то понадежнее будет
источник

CI

Co. In in Dash-Ru
JanMia
В этом отношении тогда бекап wallet.dat как то понадежнее будет
Или перед бекапом перевести на первый адрес все выходы или вообще на другой seed
источник

J

JanMia in Dash-Ru
А как это в хардварных кошельках тогда происходит? Там тоже нужно keypool указывать? Я подозреваю что об этом просто банально никто не знает.
источник

CI

Co. In in Dash-Ru
JanMia
А как это в хардварных кошельках тогда происходит? Там тоже нужно keypool указывать? Я подозреваю что об этом просто банально никто не знает.
Думаю зависит от реализации каждого кошелька. Может там сдача приходит на тот же адрес с которого и ушло
источник

J

JanMia in Dash-Ru
Во всех видосах просто сказано, что сохраните 25 слов и будут ваши данные в сохранности. А выходит, что восстановили вы кошелек на леджере, а там баланс 0, потому что деньги ваши на 5001 адресе находятся, а вы про это как ламмер и нп полозреваете?
источник

J

JanMia in Dash-Ru
Co. In
Думаю зависит от реализации каждого кошелька. Может там сдача приходит на тот же адрес с которого и ушло
Ну дело то не в сдаче, а в том что в аппаратнлм кошельке же можно создать сотню адресов для хранения к примеру даша?
источник