Привет, криптач!Brainwallet.org по неясным причинам закрыли Closed Permanently, и я решил запилить копию:https://brainwallet.cryptogator.net/Что скажите по этому поводу?
Скажу, что говно. Убрали его не по неясным причинам, а потому, что любой мозгопароль и раньше взъебать можно было, а теперь за пять минут и с музыкой. Независимо от того, какую бы анон фразу для генерации не выбрал.Хотя, в принципе, оно хорошо. Я все больше думаю, что вместо майнинга копеечек надо переходить на майнинг мозгокошельков и богатеть. Вот, кстати, пруфы по поводу стойкости брейнволлитов с текущего дефкона: https://rya.nc/cracking_cryptocurrency_brainwallets.pdf
>>107026А исходники брейнволлита в открытом доступе на гитхабе лежат и вроде никуда не собираются особо.
>>107026>любой мозгопароль и раньше взъебать можно было, а теперь за пять минут и с музыкойПруфы?
>>107026Если у тебя пароль вида "qwerty123", то да. Но если фраза более-менее стойкая и длинная, хуй ты что взломаешь, клоун.
>>107026>OpenSSL>10,000 guesses/secondЭто просто блядь белорусский вирус, VOVAN666 из 10 какой-то. Мам, гляди я радужные таблицы зделол!
>>107026Он хакал кошельки на блокчане?
>>107026>с текущего дефконаКак-то неторт такие баяны докладывать. Ещё и открытия уровня /cc/ об адресах для сдачи, лол.>About half a dozen active thievesХм, всего-то.>>107031Что сказать-то хотел? Без оптимизации там столько и будет, это же умножение на EC.
>>107035Вылажи не боян про уязвимости серверов с монетками.
>>107035>столько и будетА то. Хвастаться этим на дефконе как-то тупо, не? Не говоря уже про слоупочество, слабые брейнволеты года с 2012 пиздят в риалтайме наперегонки. И кукареки про пароли без сида.
>>107037А разве хвастался? Из презенташки-то не понять.
>>107025 (OP)Как хаккать ключи с блокчейна?
>>107060По словам автора >>107026 доклада, во всём мире меньше 10 человек, которые это делают. Ты действительно думаешь, что у тебя есть шанс?
>>107061Ну если подумать, это даже к лучшему. Может, если где-то поближе к Китаю или Австралии лохов ловить, можно первым успеть за счёт меньшей latency.
>>107064Мне кажется, у них там пока гонка ПО, а не скоростей. Так, чисто интуитивно.
>>107093>а не скоростей сети
>>107093Ну софт-то гнать особо некуда, у него вся логика - ключ по leveldb поискать, если нашлось - тут же генерить spend и транслировать. А вот на latency можно 50-100ms выиграть.
>>107103>ключ по leveldb поискатьЛол. Ну попробуй эти миллиарды ключей в свой wallet.dat загнать, посмотришь, как он тебе искать будет. Вот это и гнать, у чувака в презенташке вон кастомный фильтр Блума упомянут, и я не уверен, что это самый быстрый способ.
>>107104>попробуй эти миллиарды ключей в свой wallet.dat загнать, посмотришь, как он тебе искать будетБлядь, хуйню сказал.>попробуй эти миллиарды адресов по блокчейну в leveldb поискать, посмотришь, как он работать будет
>>107105Используй шардинг, Люк. И ramdisk.
>>107104Кастомный блумфильтр - это он так повыёбывался, хэши же индексируем с почти идеальным распределением битов. Взять вместо leveldb tokyocabinet - вот и будет блумфильтр, но и так неплохо.
Упоминаемый софт на гитхабе https://github.com/ryancdotorg/brainflayer
>>107118Там только сам блумфильтр, топорный через mmap, да ещё и всего 20 бит - будет много коллизий на миллиардах-то. Но главное, время лукапа по собственно радужной таблице он никак не сокращает, только количество этих лукапов: фильтрует адреса, которые точно неизвестны. Хуйня короче.
>>107120Я не вчитывался в код, но в bloom.h 32 бита вроде, как и презенташке.>/ 2^32 bits />#define BLOOM_SIZE (51210241024)
>>107123Тестирует он 20: https://github.com/ryancdotorg/brainflayer/blob/master/bloom.h#L40-L59
>>107108Сам же и подтверждаешь, что нужно улучшать ПО.>>107123Это же размер самого фильтра (и не 32, а 232), а проверяет он действительно всего 20.Странный выбор какой-то, в самом адресе 20 значащих бит, а он проверяет всего восьмую часть.
>>107129>в самом адресе 20 значащих байт, а он проверяет всего восьмую часть.
>>107130Это bloom filter, в этом его суть - проверять только некоторые биты, чтобы быстро отфильтровать то, чего в индексе точно нет. Только такой фильтр для значений, в которых биты уже равномерно распределены, нинужен: можно просто использовать многоуровневый индекс как в leveldb, tokyo / kyoto cabinet с тем же эффектом.
>>107132Действительно странно. Распарсил чейн, 20 минут и 88кк уникальных адресов, в структуре std::set (красно-черное дерево) отъело 5.5гб оперативки. На диске, ест-но 88к*20байт = 1.6гб, а у него маска фильтра 512мб.
>>107132А зачем БД, если все адреса помещаются в оперативу? Искать в оперативе по сбалансированному дереву по-любому быстрее, потому что нельзя искать быстрее, чем за log(n).
>>107137Так искать надо по радужной таблице, а не по блокчейну, если заниматься пиздингом в риалтайме транзакций на слабые адреса. Там RAM не хватит.
>>107132>bloom filter, в этом его суть - проверять только некоторые битыА, точно, что-то я хуйню спорол.>>107136Чем парсил?
>>107138Ну на здоровье, блокчейн рамки поиска задает, чтобы по заведомо пустым адресам не искать. А дальше взять пасслист пожирнее и прогнать его по всем входам.
>>107156И обнаружить, что всё давно упизжено. Соревнование в основном сейчас даже не у кого "пасслист" толще, а кто быстрее может ловить транзакции, искать pubkey->privkey и транслировать свой spend.
>>107141> Чем парсил? Там львиная доля script: OP_DUP OP_HASH160 <ключ> OP_EQUALVERIFY OP_CHECKSIG, то есть 19 76 a9 14 <20байт> 88 ac, достаточно просмотреть все blkXXXXX.dat подряд и найти все такие строки. Грязно, но вероятность того, что будет найдено не то, порядка 2^-48, полагаю. А блокчейн весит 50гб = 2^36 примерно. Набыдлокодил на сях.
Пикрелейтед. Спам-лист.
>>107161Хе-хе, так и думал, но надеялся, что ты меня удивишь.>>107162>эллиптический приватный ключ хешируется два разаПубличный.>искать все txout, все txin, и вычитать из первого второеtxin не имеет value, которую можно было бы вычесть из value txout. Также они содержат в себе публичный ключ, а не его хеш.Тебе нужны все txout, а потом txin, которые на них ссылются. Те txout, на которые не сослались, доступны для траты, их и суммируй.
