Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
1 мая 2013, 10:16:54 PM   # 1
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Почему Bitcoin сложность не выражается в битах?

С HashCash я всегда использовали биты, например, 20bits. Я думаю, что Bitcoin в настоящее время в 55.26, а добыча Bitcoin расширяется, чтобы дробные биты (вместо того, чтобы найти K 0 битов, чтобы найти номер < 2 ^ к, где может быть дробным - это то же самое, когда к целое число).

Вы можете преобразовать трудности в биты с log2 (сложность) +32. (Журнал (сложность) / журнал (2) +32).

(+32, потому что 2 ^ 32 является оригинальной или минимальной трудностью в Bitcoin и исключается из числа сложности).

Я считаю, эта страница является излишне сложной для очень простой актуальной проблемы: https://en.bitcoin.it/wiki/Difficulty
(Текущая сложность 10076293 от http://bitcoindifficulty.com/).

По сравнению с битами очень легко читать, даже вручную. Если один смотрит на выходе хэша в шестнадцатеричном просто умножить ведущие 0s на 4 (а следующий клеве цифра, если это >7 = +0 бит, > 3 = + 1 бит, > 1 = +2 бит и 1 = +3, биты (и, очевидно, 0 было бы другим ведущими 0). QED тривиальным, человек понятнее трудности, которые могут быть вручную проверены. Это было частью проектной цели для HashCash упростить вычисления, программирование и человеческие проверки.

И когда вы видите Bitcoin в шестнадцатеричном вы можете визуально видеть эти 55 бит. Это последняя хэш от блока проводника:

http://blockexplorer.com/block/00000000000000e3d3268e05a9901759c1452590d0838a80aeb8abaea59f1e9f

и лото я могу рассчитывать 0s (14 из них) умножить на 4 (бит в шестнадцатеричных кусочках), и я знаю, что это 56bit хэш столкновение. (Вы удачливы и дополнительный 1 бит половину времени, 2 бита 1/4 времени и т.д.).

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us


Как заработать Биткоины?
Без вложений. Не майнинг.


1 мая 2013, 11:07:40 PM   # 2
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Получил 1806 Биткоинов
Реальная история.





Это означало бы, что шаги в сложности должны быть факторами 2.

Если текущий период занимает 20 дней, вы должны настроить до 10 дней (или оставить его на 20).
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

1 мая 2013, 11:29:44 PM   # 3
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Это означало бы, что шаги в сложности должны быть факторами 2.

Если текущий период занимает 20 дней, вы должны настроить до 10 дней (или оставить его на 20).

Нет, я имею в виду дробные биты. Hashcash работал на весь бит только, и там можно было только удвоить или наполовину сократить биты, как вы сказали. Bitcoin требуется более точный контроль, и поэтому расширенный HashCash с дробными битами и есть задача технически не найти хэш с 55 ведущих битами, но найти хэш, который меньше, чем 1/2 ^ 55,26 бит, где биты дробной и хэш рассматриваются как точка десятичных 256-битная точность фиксированной. (Это то же самое, если биты целы).

Так 55,26 бит это число < 1/2 ^ 55.26 рассматривается в шестнадцатеричном, что любая хэш < .00000000000001FFE

(Я использую Ьс -l: бит = L (10076293) / л (2): +32; obase = 16 1 /; 2 ^ 55.26).

В любом случае моя точка для человеческого понимания вы можете в основном игнорировать или оценить дробные биты и быть в пределах 10% прав. И его легко и содержательные (в терминах шифра & хэш безопасности, которые измеряются в битах) и визуально проверяемый, чтобы увидеть, что его около 55 бит = 13 или 14 ведущих 0s. Вы даже можете аппроксимировать дробные биты, как я говорил.

Для сравнения: ЕФФС 1998 $ 250,000 DES трещины машины сломал 56-битный DES в 112 часов ожидается. Bitcoin сеть делает что-то примерно аналогичное каждые 20 минут

Теперь, если мы могли бы убедить EFF сделать еще один шахтер, но для Bitcoin, они могли бы финансировать свои собственные пожертвования. Я сделал это предложить людям на трещины команды DES ...

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us

1 мая 2013, 11:48:38 PM   # 4
 
 
Сообщения: 1974
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Почему Bitcoin сложность не выражается в битах?

У меня нет никаких проблем с любой нотации, но есть плюсы и минусы. Преимущество выражения трудности в качестве показателя является то, что число меньше, и более усваиваемой. К недостаткам можно отнести, что она не может быть представлены точно, и люди, как правило, будут иметь трудное время, относящееся к значениям.
odolvlobo сейчас офлайн Пожаловаться на odolvlobo   Ответить с цитированием Мультицитирование сообщения от odolvlobo Быстрый ответ на сообщение odolvlobo

2 мая 2013, 12:08:12 AM   # 5
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Почему Bitcoin сложность не выражается в битах?

У меня нет никаких проблем с любой нотации, но есть плюсы и минусы. Преимущество выражения трудности в качестве показателя является то, что число меньше, и более усваиваемой. К недостаткам можно отнести, что она не может быть представлены точно, и люди, как правило, будут иметь трудное время, относящееся к значениям.

OK вот еще один вариант для вас. Что трудность даже означать конкретно? 

Прочитайте это и скажите мне, если вы можете понять это: https://en.bitcoin.it/wiki/Difficulty

Я попробовал, и это было довольно запутанной. Отрывки кода C, определение в терминах других неопределенных вещей. Перемешивание в 600 секунд в местах, не в других. Включается ли сложность 2 ^ 32 или нет? С поправкой на 600 секунд или нет? Вся эта страница является дополнительной путаницей.

В то время как я знаю, что 55 бит означает, как с хэш и шифрами: это означает, что вы должны были попробовать 2 ^ 55 раз, чтобы получить это (в среднем). И я могу преобразовать биты = log2 (Diff) +32 не так трудно на любом научном калькуляторе.

И поэтому, если я могу найти 1GH / сек, то я знаю, что это 30bits / сек, так что я собираюсь нужно попробовать 2 ^ 25 раз.

Я думаю, что часть проблемы заключается трудность фактически делится на 2 ^ 32. Таким образом, ее на самом деле не число ожидаемых попыток. И 2 ^ 32 разве 1G его 4G.

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us

2 мая 2013, 12:37:56 AM   # 6
 
 
Сообщения: 154
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Это в основном сводится к тому, Satoshi над зависимостью от OpenSSL. Все это хак вокруг функции BN_bn2mpi () (Который преобразует bignum в последовательность байтов), так что только 3 старших байта числа хранятся и остальные отбрасывают.

EDIT: После повторного чтения, я, кажется, отвечая на другой вопрос к одному спросил. Я думал, что вопрос спрашивает, почему поле Информационного центра «бит» было кодирование цели, а не просто кодирование числа дробных бит.
Zeilap сейчас офлайн Пожаловаться на Zeilap   Ответить с цитированием Мультицитирование сообщения от Zeilap Быстрый ответ на сообщение Zeilap

2 мая 2013, 1:39:04 AM   # 7
 
 
Сообщения: 1512
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Сложность является на самом деле в битах, поле в блоке, который содержит его называют бит, который декодирует в мишень.

Вот текущая цель, хэш должен быть меньше, чем это число:
00000000000001AA3D0000000000000000000000000000000000000000000000

или в двоичном виде:
0000000000000000000000000000000000000000000000000000000110101010001111010000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000

Трудность в том, легко понять, и это то, что представлено пользователям. То, что вы предлагаете сложнее:

>>> Math.log (2 ** 256 /ИНТ('00000000000001AA3D0000000000000000000000000000000000000000000000',16), 2)
+55,26448364017038

Какие  "немного" Трудность будет 10% больше?

>>> Math.log (2 ** 256 / ((ИНТ('00000000000001AA3D0000000000000000000000000000000000000000000000',16)) /1,10), 2)
+55,40198716392032

Satoshi получили это право. Не каждый использует Python в качестве калькулятора. Используйте основную трудность, где 1 = 1 блок найти в ~ 4295032833.0 хэшей в среднем и выше трудности являются множителями этого.
deepceleron сейчас офлайн Пожаловаться на deepceleron   Ответить с цитированием Мультицитирование сообщения от deepceleron Быстрый ответ на сообщение deepceleron

2 мая 2013, 9:07:10 AM   # 8
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Нет, я имею в виду дробные биты. Hashcash работал на весь бит только, и там можно было только удвоить или наполовину сократить биты, как вы сказали. Bitcoin требуется более точный контроль, и поэтому расширенный HashCash с дробными битами и есть задача технически не найти хэш с 55 ведущих битами, но найти хэш, который меньше, чем 1/2 ^ 55,26 бит, где биты дробной и хэш рассматриваются как точка десятичных 256-битная точность фиксированной. (Это то же самое, если биты целы).

Это на самом деле использует систему с плавающей точкой. Тем не менее, я понимаю, что вы имеете в виду.

16-битное число будет охватывать весь диапазон 256 бит с 256 Фракцию битовых уровней.

Кстати, при выполнении обновления сложности, они используют с плавающей точкой, или полная трудность? Является ли значение в блоке фактические трудности или просто резюме?
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

2 мая 2013, 12:46:13 PM   # 9
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Сложность является на самом деле в битах, поле в блоке, который содержит его называют бит, который декодирует в мишень.

Вот текущая цель, хэш должен быть меньше, чем это число:
00000000000001AA3D0000000000000000000000000000000000000000000000

Разве не интересно, что hextarget разве то же, что я вычислил, может быть не так просто, как deepceleron объявляет Начиная с трудностью 10,076,293 http://bitcoindifficulty.com/ Я получаю .00000000000001AA3EA9EBE ... так что есть 0,0015% расхождение. Очевидно, что цель является правильным значением в качестве используемого значения. Глядя вокруг него, кажется, что трудности на самом деле кратная твердость по отношению к минимальной сложности, которые на самом деле не 32 0s (ожидаются 2 ^ 32 попыток), а 0.FFFFh / 2 ^ 32 (т.е. х < .00000000FFFF0000h) ожидается, пытается 2 ^ 32 / 0.FFFFh = 4295032833 (100010001h вместо 1000000h).

Таким образом, преобразование из мишени в сложности и трудности битам даже грязнее:


Шкала = 80
Определим Pow (х, р) {обратный е (р * л (х)); }
определить журнал (Ь, х) {возвращение л (х) / л (б); }
Определим log2 (х) {журнал возврата (2, х); } 

# http://blockexplorer.com/q/hextarget
IBase = 16
целевых = 1AA3D0000000000000000000000000000000000000000000000 / 2 ^ 100
mindiff = FFFF / 2 ^ 10 # источник 0,0015% несоответствия
IBase = А

пытается = 2 ^ 32 / mindiff

Diff = 1 / цель / пытается
бит = log2 (Diff * пытается)   
сибиты = -log2 (мишень)   

gdiff = Diff * 4 * mindiff # трудность в gigahashes
nhash = 70,48 * 1024
время = gdiff / nhash


Я думаю, что мой ненужный вопрос сложности с этой страницей https://en.bitcoin.it/wiki/Difficulty (И мера выбрана для сложности) не так много, что log2 масштаб или нет. Я могу справиться с этим. Но это даже не ожидается, количество хэшей (или Gigahashes и т.д.). При приближении число хешей / 2 ^ 32. Теперь 2 ^ 32 не хороший номер в обеих базах (log2 шкале и log10 шкале); 2 ^ 30 является хорошим числом. Это было бы лучше способ сообщить трудности ИМО, как то будет GH, и вы увидите все шахтеры сообщают власти в GH или MH; и скорость хеширования сети в TH. (Не сложности глыбы, которые бывший деленное на 2 ^ 32). Но на вершине, что для надлежащей точности это даже не хэш / 2 ^ 32, но сложность = хэш /2^32*0.FFFFh. И это труднее проверить на дискретные трудности (целое число). Именно поэтому бассейн акция не кратна трудность, а конечные FFF трудности, чтобы противостоять действовать этот вопрос.

Вы знаете, что я когда-то знал крипт математика / хакер парень, который имел обыкновение думать, кодирование Хаффмана людей было весело. Satoshi? Хммм

котировка
>>> Math.log (2 ** 256 /ИНТ('00000000000001AA3D0000000000000000000000000000000000000000000000',16), 2)
+55,26448364017038

Какие  "немного" Трудность будет 10% больше?

Ну, что не были в точности моей точки (моя точка в том, что вы можете получить мяч парковать приблизительный порядок с вашими глазами и умственной арифметикой с битами). Но о вашем вопросе log2 (1,1) = .1375 (называют его .14, помните, что) так 55.26 + 10% = 55,40?

котировка
Используйте основную трудность, где 1 = 1 блок найти в ~ 4295032833.0 хэшей в среднем и выше трудности являются множителями этого.

Я не найти 2 ^ 32 / .FFFFh особенно значимое число. Я знаю, что расхождение невелико, но почему даже потрудились .. только упростить и использовать конечные FFF трудности.

Извините, но простота делает дело.

Во всяком случае, распутывая и не обращая внимания на 0,0015% несоответствие, можно преобразовать трудности в приблизительно gigahash путем умножения на 4: сложности * 4 = 40305172 GH. А сеть скорость хеширования = 70.48TH, поэтому ожидаемое время = 40305172 / (70,48 * 1024) = 558s. Достаточно близко - скорость хеширования сети выросла с, что трудность была рассчитана. (Или в log2 шкале Трудность состоит в 55,26 и скорость сети хэш 46,14 так > 2 ^ 9 попыток > 500 секунд. )

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us

2 мая 2013, 1:01:25 PM   # 10
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

Это на самом деле использует систему с плавающей точкой.

Это зависит от того, как вы относитесь к его - можно считать это 256-битный большой Int также. Однако я думал об этом, как неподвижной точке, потому что я нашел дробное сравнение легче думать. (С фиксированной точкой означает, используются только мантиссы, показатель фиксируется на 0, или, по меньшей мере, фиксированное значение. Люди привыкли к злоупотреблению инструкции целого числа процессоров выполнять арифметические операции с фиксированной точкой в ​​дни перед процессорами с плавающей точкой были включено в ЦП или по крайней мере целочисленная арифметики была гораздо быстрее, чем FP сопроцессора).

котировка
Кстати, при выполнении обновления сложности, они используют с плавающей точкой, или полная трудность? Является ли значение в блоке фактические трудности или просто резюме?

Я не знаю, но позвольте мне угадать, основанный на алгоритме сложности: мое предположение он использует только целочисленную арифметику.

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us

2 мая 2013, 1:18:41 PM   # 11
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

котировка
Это зависит от того, как вы относитесь к его

Я думал о том, как блок обрабатывает его.

В резюме

Это, как номер повторно calcalated. Биты / число с плавающей точкой является фактической целью кодированием. Трудность вычисляется из этого.

Код:
если (prev.height + 1 моды 2160! = 0), а затем вернуть последний prev.bits

первый = предыдущий
первый = first.prev (2159 раз)

// первый это первый блок в последний период сложности
// пред последний блок, в последний период сложности

actual_time = prev.blockTime - first.blockTime

actual_time = предел (actual_time, 3,5 дней, 56 дней)

big_number = некомпактный (prev.bits) * actual_time / 14 дней

если (big_number > MAX_ALLOWED)
 big_number = MAX_ALLOWED

вернуть компактный (big_number)

Компактная / разуплотняют функция преобразования с плавающей точкой.

Компактная форма: ab_uvwxyz (каждая буква представляет собой шестнадцатеричное число)

Int = hex2Int (UVWXYZ) << (8 * (hex2Int (аb) - 3))

Уплотнитель дается Вот
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

2 мая 2013, 3:26:35 PM   # 12
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?


Я думал о том, блок обрабатывает его.

В резюме

ОК да вот что я имел в виду с "Хаффман кодер человек" комментарий. Поэтому я понимаю, что вы имеете в виду о том же, я просто имел в виду, что было бы (я думаю) не с плавающей точкой в ​​смысле вызова команд процессора с плавающей запятой, и что, кажется, дело

Его просто, как такие вещи идут (я видел хуже) и просто способ кодирования между 23 и 16 бит точности плюс 8 бит мантиссы. (Вид странно, что точность зависит от того, насколько близко трудности к границе 8bit, но там вы идете.) Он мог бы сделать лучше использовать 8bit показателя, например, путем обработки его в виде бит вместо байт, как число в любом случае definitionally 256-битное число.

Если оптимизированы это может быть, вероятно, кодирующий 16-бит (8-битный показатель + 8-битовый мантиссы), если биты в показателе были использованы в качестве битов, а не байт. Или, конечно, 24-бит. Но, может быть, вот моя очередь по-оптимизируют - точность трудности не столь критична в любом случае.
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us

2 мая 2013, 5:37:19 PM   # 13
 
 
Сообщения: 400
Цитировать по имени
цитировать ответ
по умолчанию Re: почему бы не измерить трудности в битах?

точность трудности не столь критична в любом случае.

Кстати, что я думал, там точность трудности в идеале должно быть несколько битов больше, чем log2 (интервал = 2016). Таким образом, 8-бит может быть немного низким. 16 бит (+ 8-битовый мантиссы) будет достаточно.

Если бы это было не так (например, 8-бита точность) считает пул держит 50%, то теперь он может видеть, что трудность заключается в получении близко к опрокидыванию другой LSB цифры трудности, он может отступить (добычу стоп), чтобы продлить время к блоку была найдено, предотвращая опрокидывание. Это делает затрудненную часть е легче 1/128 < е < 1/256 в течение следующих двух недель, или, в частности F = 1 / м для сложности мантиссы м, 128 < м < 256. Путем проведения с нее теряет 1-блок, и это стоит сделать г = 2016 / м * 50% вознаграждение г, для этого действия. (Или г = 1008 / (м * б) < для проведения выключения для би-блоков, что имеет смысл, так долго, как г > б. С 50%, что остается в случае между 1 и 3 < б < 7 в зависимости от мантиссы. Теперь, конечно, как 50% пула мин быстрее, чем сложность и предсказывалось, 2-недельный период проходит мимо в возрасте до 2-х недель slighty, но все-таки это 2016 монет, по определению, а на самом деле бассейн на самом деле получает чуть более 50% монет кроме того, потому что теперь он работает на полную мощность, в то время как потравленными кратко раньше.

Таким образом, минимально 8 + log2 (7) бит = 11 бит убивает слабую атаку. И Bitcoin минимум 16 бит. Совпадение? Возможно нет.

Возможно, что-то для медленного altcoin думать о (все, кажется, идут для более быстрых бассейнов для какой-то причине). Хотя недобросовестный получить преимущество тонкий даже тогда.

Адам
adam3us сейчас офлайн Пожаловаться на adam3us   Ответить с цитированием Мультицитирование сообщения от adam3us Быстрый ответ на сообщение adam3us



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW