Jump to content

4_tochka

Пользователи
  • Content Count

    261
  • Joined

  • Last visited

  • Days Won

    1

4_tochka last won the day on December 30 2016

4_tochka had the most liked content!

Community Reputation

79 Очень хороший

4 Followers

About 4_tochka

  • Rank
    Пользователь

Информация

  • Пол
    Не определился

Recent Profile Visitors

1839 profile views
  1. Раздача тестовых лайткоинов. Лимит 0.01 LTC раз в 5 минут. https://tltc.bitaps.com
  2. Ну как минимум предложенная мною версия теоретически реализуема и не является фантастической🙂.
  3. Для всех разработчиков раздаем тестовые биткоины. Лимит 0.01 BTC раз в 5 минут. + бонус функция создания двойной траты на указанный вами адрес. То есть такая транзакция пришлет вам биткоины с 0 подтверждений, а конкурирующая транзакция заберет все обратно. https://tbtc.bitaps.com Использованные и больше не нужные, тестовые биткоины присылайте обратно на адрес 2NBkWjz21BoT4abvAF5wsqnZAS7HA4LKrZe , не забывайте и о своих коллегах 🙂
  4. Ну не закардить а слить с киви, и в теории если есть возможность почему бы и нет.
  5. Как вариант еще может быть уязвимость протокола SS7 в gsm сетях.
  6. Ничего личного, просто разница в ценах бросилась в глаза тогда и сейчас.
  7. О как цены упали 😊. В 2017 разработчики от 1к баксов просили.
  8. Блокчейн Биткоина построен на архитектуре UTXO - не потраченные выходы транзакций (монеты). Это несколько другая концепция в отличии от Account based архитектуры к которой все привыкли. В системе с аккаунтами мы следим за балансом и проверяем достаточно ли его, перед транзакцией списания. В UTXO, балансом является совокупность всех монет, принадлежащих определенному адресу. При создании транзакции в системе UTXO нет понятия отправитель а есть понятие монета (не потраченный выход транзакции) которая тратиться. Для функционирования такой системы каждая нода должна иметь список всех не потраченных монет и проверять корректность транзакций исходя их данного списка. По это причине у биткоин ноды нельзя запросить баланс произвольного адреса в отличии к примеру от эфириума, где используется система аккаунтов. Баланс всех адресов можно узнать если составить отдельный список не потраченных монет сопоставленных с адресами. Что к примеру делают битокин экплореры.
  9. Когда связь восстановиться начнет синхронизироваться цепочка блоков а она явно не сойдется. И тут та часть что была меньшей будет иметь неверную копию реальности и будет отброшена. (ну это вкратце без подробностей, основная идея такая)
  10. Исходя из данной информации, я так полагаю можно сказать что в блокчейне биткоин адреса используются с КПД 37% остальные генерируются как техническая необходимость. Ну и данный вывод можно сделать в контексте того, что цель транзакций это передача биткоинов от одного владельца другому.
  11. Вот сам отчет собственно. https://blog.chainalysis.com/reports/bitcoin-addresses Они имеют ввиду, под экономической релевантностью, что они отсортировали адреса те куда возвращалась сдача и принадлежит отправителю и теми что принадлежать получателю и в транзакции использовались для перемещения биткоинов другому владельцу. И мол только 37% адресов связанны с реальным перемещением средств от одного владельца другому. Но хотелось бы конечно взглянуть на методику как они это высчитали, потому что все равно как то вопросы остаются.
  12. Все равно глупости скорее всего, только 7 процентов адресов имеют не нулевой баланс. Так что дополнительные 30% процентов записанных адресов с нулевыми балансами выглядит сомнительно.
  13. Контракт появляется только на тех нодах которые синхронизированы до того блока где он был задеплоен. То есть если у ноды нет данного блока то вызвать контракт не удастся. Контракт хранится у каждой ноды, заменить его не получится так блокчейн имеет свойство tamper proof. Все сцепленно зешами и меркл рутами. Удалили контракт - это история в новостях когда в контракте был вызов self destruct, то есть само уничтожиться. И данный метод кто то не прикрыл и сделал public. Любой мог дернуть его и уничтожить контракт. И он не удалился из истории он стал не активным. Все таблички и перемещения токенов можно глянуть в истории блоков. И да контракт /вызов к контракту исполняется тоже у всех-всех-всех
  14. Так тут вроде научно популярная дискуссия а не междусобойчик😆. Так что отвечу на ваш вопрос, несмотря на то что адресован он был не мне. Если вы говорите о приватном ключе записанном в HEX формате и исключаете из него буквы a-f. То получается у вас алфавит из 10 элементов вместо 16. Количество возможных комбинаций данного алфавита с учетом длины ключа в HEX формате 64 символа такова: 10 64 = 10000000000000000000000000000000000000000000000000000000000000000 Если же не исключать буквы a-f а использовать как задуманно 16 64 = 115792089237316195423570985008687907853269984665640564039457584007913129639936 Я думаю тут визуально даже понятно что пространство для перебора в данном случае сократилось очень существенно. Но идем дальше и посчитаем количество бит данного ключа: 10 (log(10) * 64) = 212.60339807279118 бит. против 256 бит в нормальном варианте Существует ряд рекомендация по выбору безопасной длинны ключа в зависимости от того сколько времени планируется обеспечить данную безопасность подробнее тут https://www.keylength.com/en/compare/ Если рассмотреть свежие рекомендации : NIST Recommendations (2016), ECRYPT-CSA Recommendations (2018), BSI Recommendations (2018) то вот что мы имеем: Method Date Symmetric Factoring Modulus Discrete Logarithm Key Group Elliptic Curve Hash ECRYPT 2018 - 2028 128 3072 256 3072 256 256 NIST 2016 - 2030 112 2048 224 2048 224 224 BSI 2018 - 2022 128 2000 250 2000 250 256 Получается что ключ 213 бит не считается безопасным по мнению достаточно компетентных специалистов. По этому не надо придумывать свои хитрые способы, вероятность что вы ошибетесь и существенно снизите защиту до не безопасного уровня, очень высока. И у вас по сути ситуация еще хуже чем 213 бит, так номера телефонов это не набор случайных чисел, из которых вы составляете ключ я так понимаю просто записывая телефоны в определенном порядке. к примеру первая цифра у вам в телефоне будет либо 8 либо 7 либо 9 в зависимости от вашего формата записи.
  15. Ты еще белой перчаткой в лицо кинь и на дуэль вызови😆 Весьма уважительно отношусь к людям, если они не требуют другого отношения к себе. Когда человек несет чушь и пытается этой чуши кого те еще учить то формулировки подходящие Предупреждение там о том что Electrum считает что BIP39 не айс потому, что там не заложено версионирование и что они не гарантируют, что это будет работать в дальнейшем в электруме. А чек сума что не сошлась это отдельное предупреждение. И вычислять из такой фразы ключи по BIP 39 это равносильно как ноутбуком гвозди забивать. Да результат будет если постараться, гвоздь забьешь. Опасностей он не боится😆 Чему ты учишь людей? еще и в картинках постарался, не дай бог найдутся те кто твои инструкции начнут использовать. Типа не баг а фича) А брутить ворд листы для бип 39 как будто это brainwallet повторюсь еще раз это бред сивой кобылы. Рекомендую еще вот эти словари добавить к бруту https://konservs.com/tools/bredogenerator/ Эти высказывания создают иллюзию о том, что - во дела кошельки уязвимы. Но дело в том что в тех диапазонах что ты сканишь это только ключи с которыми кто то игрался, создавая осознанно и не с помощью софта кошельков они знали что он создают не безопасные приватники и типа игрались, никто там денег не хранит. Нет желания тебя просвещать и приводить примеры таких игр. Не один нормальный ГСПЧ не попадет в твои диапазоны. Реально созданных адресов кошелькам там нет и тебе их насканить нет шансов в этой и еще и в следующей жизни. Угрозы никакой там тоже нет. А так монетки в фонтан тоже бросают и если там полазить можно норм насобирать мелочи😆 По брайн валету объявили вроде доходчиво и с примерами, что использовать нельзя. Насканишь если чужой валет с балансом, что делать то будешь?) Ограбишь бедолагу? ( вопрос риторический отвечать на него типа "нет я буду искать владельца" не надо, я тебя прекрасно знаю и знаю как ты поступишь)
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...