Здравствуйте есть запертые кошельки
Кошельки от какой программы? Bitcoin Core? Electrum? |
|
|
|
Так сколько адресов в итоге нужно считать в первом посте?
Получается, 2161 P2(W)PKH + 2160 P2WPKH-P2SH = 1.5 * 2161. Так?
Все три типа адресов (P2PKH, P2SH и P2WPKH) используют в качестве хеш-функции на последнем этапе одну и ту же функцию - RIPEMD160. Её выходной диапазон значений - от 0 до 2 160. Адрес любого типа - это всего лишь вот этот 160-битный хеш, ничего кроме 160 бит в адресе нет. Поэтому все эти адреса помещаются в одном общем пространстве - 2 160. Исключение - P2WSH-адрес, где в качестве хеш-функции используется только SHA-256 и пространство адресов получается 2 256. |
|
|
|
Ок, я понимаю, что 20-байтный хеш в P2PKH и P2WPKH одинаковый, можно ли после преобразования в удобный формат считать их одним адресом хотя бы в контексте расчетов в первом посте? Я думаю, что нет. Ведь при кодировании в base58check еще два SHA256 считать приходится, так что конвертация из bech32 в base58check проходит лишь в два раза быстрее, чем полная генерация P2PKH-адреса из ключа (про скорость кодирования в bech32 не знаю, чек-сумма как-то хитро там считается и, кажется, без хешей).
Когда я захотел просканировать пространство приватных ключей в диапазоне: от 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 до 00000000 00000000 00000000 00000000 00000000 00000000 00000000 FFFFFFFF на наличие транзакций, содержащих адреса, соответствующие этим приватным ключам, я сделал это так: Вычислил публичные ключи от приватных ключей из указанного диапазона, вычислил хеши этих публичных ключей и записал их в файл в виде 20-байтных последовательностей. Далее просканировал все выходы транзакций блокчейна и выцарапал из них хеши публичных ключей в виде, опять же, 20-байтных последовательностей, записав их в два файла: один - для P2PKH-выходов, второй - для P2WPKH-выходов. Ну, и наконец, проверил наличие хешей из двух последних файлов в первом файле. Заметьте, мне ни разу не понадобились преобразования в base58check и bech32. Для каких задач, по-вашему, нужны эти преобразования? |
|
|
|
Но это же разные адреса? А то получается, что как-будто 3 адреса из одного публичного ключа - это один и тот же адрес, но тогда они могли бы конвертироваться друг в друга (как, скажем, в лайткоине адреса на 3 и M).
По крайней мере, адрес P2PKH (1...) и P2PWKH (bc1...) - это один и тот же хеш публичного ключа RIPEMD160(SHA256(pubKey)), только первый преобразуется в base58check, а второй - в bech32, исключительно для человекочитаемого отображения. Внутри выхода транзакции этот хеш в виде 20-байтной последовательности будет выглядеть одинаково и для P2PKH-выхода, и для P2WPKH-выхода. Совместимые SegWit-адреса (P2PWKH-P2SH) создаются следующим образом: 1. Берётся хеш приватного ключа RIPEMD160(SHA256(pubKey)) 2. К нему спереди добавляются два байта 0014(HEX) 3. Над полученной последовательностью из 22 байт снова выполняется операция хеширования RIPEMD160(SHA256(0014<hashPubKey>)) 4. Результат хеширования представляется в кодировке base58check c версией 05. Таким образом, получается, что из legacy-адреса можно получить bech32-адрес, и наоборот. Из legacy-адреса или bech32-адреса можно получить P2PWKH-P2SH-адрес, а наоборот не получится. |
|
|
|
Да Вы меня и не разочаровали. Ваш уровень познаний в протоколах хэширования, равно как и во всем остальном, что связано с Биткойном, и так виден не вооруженным глазом. А после этого заявления, дак Вы себя просто таки "раскрыли" во всей красе...  Ладно... Думаю, что нужно заканчивать этот разговор, Ваш уровень подготовки слишком слаб, для того, чтобы понять криптографические и сетевые протоколы. До сей поры я отвечал на Ваши вопросы, потому что они были из разряда "FAQ" и ответы на эти вопросы могут быть полезны тем, кто не в теме. Но теперь Вы уже начинаете откровенно ерничать по причине того, что не в состоянии аргументированно критиковать мою разработку, а из-за дурного характера, видимо - очень хочется. В такой ситуации я не вижу больше смысла продолжать Вам отвечать на Ваши вопросы. Извините. Пальцы тут не надо растопыривать. Вы сами если в чём-то и профессионал, то только в сборе бабла под скамные проекты. Бабло собранное под революционный ASIC уже закончилось? Решили окучивать противоположную тему? |
|
|
|
TSMC - тайваньская контора, правительство КНР к ней не имеет никакого отношения. Тайвань всегда был проамериканским, как Южная Корея и Япония, в отличие от КНР. |
|
|
|
Нет, не проблема, если выбрать другую архитектуру решения. Должна быть глобальная распределенная БД, в которой каждому кошельку будет соответствовать отдельный IP. Так же как и Блокчейн, только отдельная БД, которая будет отвечать за эти связки. Вот и все дела. Вполне реализуемо.
И каким образом отдельно взятая нода сможет проверить подлинность записей в этой БД? На самом деле, для проверки соответствия между IP и идентификатором кошелька достаточно, чтобы нода, смайнившая блок, включала свой IP в заголовок блока. Тогда любая нода, получившая блок, сможет напрямую по IP постучаться к ноде, IP которой прописан в блоке, и спросить её идентификатор кошелька. Тогда и никакой БД не надо. Есть только одна проблема: при достаточном количестве нод в сети, майнящая нода, выплюнувшая в сеть блок, ляжет под количеством запросов с каждой ноды, верифицирующей поступивший блок. |
|
|
|
Ну, здесь не совсем понятно, потому что сеть на этот IP будет отсылать запросы и принимать с него данные, так что не совсем понятно, что Вы имеете ввиду под "левым" IP.
Вот есть, например, нода М с IP 1.1.1.1, которая смайнила блок и отправила его ноде A. Нода А имеет непосредственное соединение с нодой M, и поэтому она знает, что нода М имеет IP 1.1.1.1, и, следовательно, нода A может проверить валидность блока, сгенерированного нодой M. Есть нода B, которая имеет непосредственное соединение с нодой A, но не имеет соединения с нодой M. Нода A ретранслирует ноде B блок, сгенерированный нодой M, но нода B не знает что нода M имеет IP 1.1.1.1, и, следовательно, валидировать блок, сгенерированный нодой M она не сможет. Проблема? |
|
|
|
Как-то вяло ноды обновляются. Хардфорк эфира istanbul будет примерно через 6 часов, а больше половины клиентов geth и parity все еще не обновились. https://www.ethernodes.org/istanbulА куда торопиться? 6 января - очередной внеплановый хардфорк. Перед запуском Стамбула внезапно вспомнили, что забыли в очередной раз отодвинуть бомбу сложности. Биржам теперь есть повод до нового года вообще вводы-выводы по Эфиру не открывать. Не, ну а чо? Каждый месяц - хардфорк. Разве можно в такой обстановке работать? |
|
|
|
разработчики монеро совсем не тупые, они в курсе, что били рекорды по ботнету, для того и хардфорк
сейчас оперативы больше нуна, да еще майнеры обновить - любой ботовод запарится
Разработчики алгоритма RandomX специально для ботнетов придумали light mode, который требует 256 МБ памяти. Хешрейт при этом намного ниже, но и электричество для владельцев ботнетов бесплатное. |
|
|
|
Надеюсь команда монеро при хардфорке на алгоритм РандомХ просто не учла влияние ботоводов на сеть
В чём заключается негативное влияние ботоводов на надёжность сети? Я вообще сомневаюсь, что на текущий момент ботнеты играют значительную роль в хешрейте RandomX. По моим собственным наблюдениям, хешрейт CPU при переходе с CryptonightR на RandomX увеличился в 8-9 раз. CryptonightR RandomX
Intel E3-1230 V2 260 h/s 2220 h/s
AMD Ryzen 5 3600 780 h/s 7040 h/s
При этом, хешрейт всей сети увеличился с 300 Mh/s до 800 Mh/s - всего лишь в 2.7 раз. Слабенько для ботнетов. |
|
|
|
I previously asked if someone would be kind enough to do a test on a Ryzen 3xxx
Ryzen 5 3600 @ 4.2GHz (CPU Core Ratio - 42x, PBO is disabled) GCC 9.2.1: blake2s:
znver1 231.46 MH/s
znver2 238.08 MH/s
avx2 236.11 MH/s
avx 236.09 MH/s
sha256t:
znver1 61.44 MH/s
znver2 61.69 MH/s
avx2 46.25 MH/s
avx 46.26 MH/s
|
|
|
|
Под эксплорером вы понимаете ctrl shift i в браузере?
Под эксплорером имеется в виду блокчейн-эксплорер, где можно видеть перемещение токенов с одного адреса на другой. |
|
|
|
Начал синхронизацию в 21:48
Можете начинать вести дневник синхронизации в Твиттере. В этом году это модно: https://twitter.com/ercwl/status/1159940020331040770https://twitter.com/mskvsk/status/1166325983227654151оказывается оно не умеет останавливаться никак кроме
killall -HUP parity
Должен корректно завершаться по Ctrl+C, но у меня он при этом зависал без всяких сообщений в консоль и не хотел завершаться. Возможно, у вас та же ситуация. Хочу узнать прогресс синхронизации - нет такой команды!
Здесь расшифровка белиберды, которую Parity выводит в консоль, в том числе, информация о процессе синхронизации. |
|
|
|
Я объединил два полуторатерабайтных иде диска в RAID10 и получил скорость лучше, чем на премиум тарифе амазоновского SSD dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output conv=fdatasync bytes (84 MB, 80 MiB) copied, 0.0493326 s, 1.7 GB/s Кажись, эти 84MB были где-то закешированы, оттого и получились таки фантастические результаты. Но в любом случае - это всё писькомерство и к реальным задачам имеет слабое отношение. Эфир чувствителен не столько к линейной скорости чтения-записи, сколько к количеству операций ввода-вывода в секунду (iops). По этому параметру HDD сливают SDD, в результате чего эфирная нода на HDD обречена на вечную синхронизацию, при том что Биток легко синхронизируется на HDD. |
|
|
|
A-Bolt, когда миксер создают то заранее имеют немного битков для работы.
Понятно, клиентам отдают чистые битки из своей тумбочки, а себе оставляют грязные битки клиентов. А дальше что? Напомню, что kzv не предлагает идентифицировать владельцев битков на каждом адресе. kzv предлагает отслеживать сами битки и помечать их процентным содержанием грязи. |
|
|
|
Да, с хешрейтом чудеса какие-то прям. Не могут же это быть юзеры с райзенами
Никаких чудес. С лета по всему миру затаривались 3900X, плюс вытерли пыль со всякого старья типа двухпроцессорных серверов на Xeon-ах. Дошло до того, что в заповеднике были обнаружены дайбатники, хотя этот вид майнеров считался вымершим ещё в 2018 году. |
|
|
|
Хорошая новость с переходом на новый алгоритм и судя по показателям, то интеловские процессоры значительно уступают амд. Не удивлюсь, если через пару месяцев цены на райзены взлетят.
А я удивлюсь. Сейчас один 3600 приносит 0.8$/день. Завтра выйдут сисадмины на работу, и как начнут запускать майнеры на офисных компах с бесплатным для сисадминов электричеством - доход вообще упадёт. |
|
|
|
на этот же адрес миксер переводит такое же количество биткоинов что пришло на addr_btc_mix_input
А где миксер их возьмёт? |
|
|
|
|
Show Posts
