Topic: NovaCoin (scrypt PoW + PoS hybrid) [self-mod] - page 221. (Read 744451 times)

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

мы же говорим об истинном случайном числе, для которого равномерность распределения очевидно должна выполняться

ну нету у меня альфа-трубки и источника, пока только СБМ-20 и фон 0.05-0.15 мкЗв/ч
так что сначала попробуем снять максимум с того что есть и провести тесты на энтропию

и еще:


осторожно надо детекторы дыма разбирать

А зачем завязываться на время между импульсами? Само же это и является источником этой проблемы.

Не лучше ли сделать вот так:

http://www.youtube.com/watch?v=JCI4IuTP0RU#t=163

И опрашивать само значение на регистраторе (есть частица/нет частицы) с частотой 1 кГц (для примера с 60000 CPM)? Частоту опроса подстроить под частоту импульсов в минуту, достигающуюся с используемым источником. Которое, в свою очередь, можно отрегулировать изменением расстояния между окном счетчика и источником.

В случае с 60000 CPM на счетчике и соответственно настроенной частотой опроса состояния мы будем иметь случайную последовательность нулей и единиц, выдающуюся с рейтом 1000 бит в секунду.

Всё равно что там пишут. Равномерное распределение не имеет ничего общего со случайностью.

Последовательность случайных чисел - последовательность чисел, элементы которой независимы друг от друга и подчиняются заданному распределению(обычно равномерному).

Броски шестигранного кубика у которого грани 1,1,2,3,4,5 дадут случайную последовательность, хотя вероятность 1 больше чем у остальных чисел.

ну вообще-то неправда. и по ссылке Бальта авторы пишут что

Нет. Можно и разные вероятности. Просто будет другое распределение. Число по прежнему будет случайным.

хорошо, с пропусками понятно, с диапазоном что делать?
истинно случайное число должно лежать в заранее известном диапазоне и равновероятно принимать все возможные значения из этого диапазона, верно?
как определить максимальное значение диапазона, если, допустим, источник непостоянен? (фон)
фон увеличился - диапазон генерируемых чисел очевидно пропорционально уменьшился.

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

needbmw
Если следовать логике, то последовательный пролет двух частиц через счетчик в пределах интервала его перезарядки равносилен ситуации, в которой эта частица вообще бы через счетчик не пролетала. А это происходит постоянно, ведь угол вылета частицы из источника тоже непредсказуем.

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

проблема на самом деле шире, и дело не в нулевом значении. ноль как раз действительно можно скорректировать программно.
проблема вот в чем: мы имеем случайный процесс попадания гамма-кванта в детектор на некотором отрезке времени.
допустим для упрощения что у нас идеальный детектор, который выдает очень короткий (бесконечно короткий) импульс и мы его 100% определяем. но мы не знаем заранее на каком отрезке времени ждать этот импульс, т.к. физически средняя вероятность его появления в детекторе пропорциональна фоновому (или не фоновому, в зависимости от реализации) облучению.
т.е. мы фактически знаем, что в идеале у нас случайное число будет от единицы до какого-то значения счетчика, а вот какого конкретно - не знаем. можно сделать все строго, калиброванный изотоп (не знаю существуют ли такие в природе), свинцовый ящик для экранирования детектора от внешнего фона, но это как-то сложно получается  
соответственно перед нами стоит задача определения разрядности получившегося случайного числа. если решим - число будет если не идеальным, то сильно приближенным к идеалу  

жду мнений гуру от математики. я, к сожалению, больше по припаять чего-нибудь  


ну я тоже с теорией ГПСЧ знаком только понаслышке, но в целом их проблема должна быть понятна.
они выдают хорошие случайные числа, но только на определенном отрезке времени. потом последовательность ПОВТОРЯЕТСЯ.
рано или поздно - зависит от разрядности, но она все равно повторится. что губит всю идею на корню.
хотя в крайнем случае все же придется взять ГПСП и инициализировать его от "истинного" RNG. все это можно запихнуть в матрицу, она очень хорошо для этого подходит...

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

А без сообщества кто будет делать? Сантаклаус или роботы?
Всё вокруг делают люди, их труд человекочасы оплачивается человекочасами других людей.
Чтобы валюта жила надо найти этих самых людей одни из которых будут другим оплачивать и все вместе что-то делать.

В том то вся и хрень что если кто-то попользовался женой и отдал соседу, то ценность жены вроде как падает, хотя кто-то считает наоборот.
Ценность предметов быта которые были до этого в чужом пользовании тоже от этого не вырастает, если конечно на этот ноут сам дикаприо не кончал.
А вот ценность валюты от этого прикинь только растёт!
нужно использоать эту фишку!

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

Когда увеличиеается ыгода в коллективно ипользовании того или иноо предмета если он не ломается и т.д. при этом? Когда больше народу могут им пользоваься.
Писать программу для самого себя или для троих тупо. Как и остальное так же.
Сделали кошелек на андроид и сами его и заюзали 10 человек и сидят кайфуют, при эоом ниего не переводя и т.д. а просто запустив, круто? нет.
Круто когда было 1000 человек , собрали деньги ну или несколько человек или вся тысяча, сделали опять же ну или несколько еловек или опят же много. И вся тысяча пользется, вот это круто. После этого из 1000 становится уже 1100 человек или 2000.
Вот так ценность валюты и растёт.

Ладно, тут я должен признаться, что в вопросе плаваю.
Не совсем хорошо улавливаю что именно не так.
Если ваш генератор не выдает нули - то что мешает от каждого числа отнять 1?
Это простейший вариант исправления "неправильного генератора".
Более сложный вариант - это как я выше привел - с использованием хеш-функции мы его "исправляем".
Доказать строго, что в этом случае мы получаем криптографически строгий генератор я, пожалуй, не смогу.
Знаний явно недостаточно.
На этом раскланиваюсь.

ЗЫ. С задачей про гнутую монету ответ прозрачным цветом:
Кидаем монету два раза. Если выпал орел, потом решка - записываем 1.
Если выпала решка, потом орел - записываем 0.
Если два орла или две решки - ничего не записываем. В результате получаем из плохого рандома хороший

Обновил свой пост выше. Пойду поем и обдумаю всё это, за едой часто в голову умные мысли приходят.

это все равно будет уже ПСЕВДО случайная последовательность.
SHA2 основан на сдвиговых регистрах с обратной связью, то бишь на ГПСП 
а мы трём сейчас об истинно случайном числе. о том, которое 4 

Ну я же вам намекнул про гнутую монету!

Возьмите y_n = sha256 ( y_n-1 | rng ) // палочка - это операция конкатенации

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

Ну СБМ-20 сто лет в обед, есть намного более быстрые счетчики. Просто его используют широко из-за доступности и дешевизны. Фундаментально это ситуацию не меняет, но снижает количество пропусков.

Свинцовый ящик не поможет, потому что у самого свинца есть радиоактивные изотопы.

Бороться же с этим можно методом от противного - использовать альфа-активный источник типа Am-241 и счетчик со слюдяным окном. Любые вариации естественного фона в сравнении с этак 90000 распадов в минуту от Am-241 будут пренебрежимо малы. Источник этот можно выковырять из детектора дыма, особого экранирования он не требует т.к. альфа-частицы задерживаются даже листом бумаги, а гамма-фон от него довольно низок.

вот именно, как только в цепочке появляется слово "псевдо" - результат будет тоже псевдо

на FPGA будем пробовать вообще? там я могу сделать счетчик практически любой разрядности и прикинуть доступные частоты
кардинально ситуацию это не улучшит, но все же.

кстати по ссылке выше хорошее замечание про значение RNG равное 0.
для квантового RNG это означает по сути попадание в детектор двух частиц одновременно (для СБМ-20 длина имульса у меня порядка 120мкс, т.е. одновременно для него - это в пределах двух длин этого импульса). счетчик Гейгера-Мюллера не сможет сказать сколько частиц попало одновременно, значит значение RNG равное нулю выпадает из списка возможных состояний генератора, что не совсем хорошо с математической точки зрения и наверняка вылезет на тестах.

и еще одна проблема вырисовывается - синхронизация ширины счетчика и вероятности попадания кванта в детектор.
т.е. получается мы не знаем доверительной разрядности получившегося случайного числа, т.к. она зависит от интенсивности облучения в данный момент. использовать калиброванный источник и экранировать все в свинцовый ящик? омг 

кстати если делать все в лоб (генератор-счетчик) и частота генератора достаточно высока (десятки мегагерц), при этом еще будет "выпадать" часть значений RNG, находящихся "в тени" импульса детектора.
избежать этого вроде бы можно осложнением схемотехники счетчика, его нужно перезапускать заново строго по заднему фронту импульса с детектора. опять же в случае использования FPGA это элементарно реализуется, ну а на рассыпухе придется раздувать схему и не всякий счетчик подойдет...

Я твоё сообщение ужал до одного слова. Комьюнити нужно основание (некий каламбур получился кто Айзека Азимова читал - поймут, он похожий момент в одной книге описывал).

Ну вольётся возможный персонаж в нову предположим завтра и спросит:

• А можно на смарт TV кошель поставить ?
• Ну а хотяб на Андроид?
• А законспирироваться в тор и2п и тд и тп?
• А замиксерить монеты?
• А онлайн валлет есть?
• А порнуху на saff.cc анонимно оплатить можно?
• А хотяб в Рованиеми посещение Санты?
• Ах, только на сотовый перевести - да и то не факт, мож Icreator завтра опять вывод обрежет
• Список можно продолжать до бесконечности я думаю

У комьюнити под ногами даже не почва, а гранит нужен. Впаривать сырой полуфабрикат? Я думаю тут другой путь выбран.

Можно пойти на компромисс и использовать в самом драйвере выданное счетчиками значение в качестве seed для алгоритма Ярроу, переинициализируя его с каждым новым значением. Как вариант, на распике же полноценный процессор, всё-таки.

Но это похоже на стратегическое отступление, надо подумать.

Кстати, тесты генератора, "стимулируемого" цезием-137:

https://www.fourmilab.ch/hotbits/statistical_testing/stattest.html

Я бы сказал, что результаты почти точно совпадают с предсказанными для идеального генератора.  Впечатляют 7.999975 бит энтропии на байт. Более чем неплохо, особенно для собранного на коленке девайса.

я похоже методически ошибся на порядки когда сначала прикидывал. получается что про отечественный КМОП вообще можно забыть к сожалению, слишком медленные они.
если взять ТТЛШ счетчики (до 20МГц если повезет) получится снять с них всего лишь 24-25 бит в секунду
если взять современный счетчик на 200МГц -> 250 бит в секунду

причем этот параметр не зависит от частоты попадания гамма-квантов в детектор, от этого зависит только разрядность счетчика (делаем "шире" счетчик -> можем работать и на фоновых значениях).

похоже без промежуточного ГПСП, инициализируемого реальным квантовым ГСЧ, не обойтись...

идеальной платформой для такой штуки конечно была бы CPLD/FPGA, и частоты там можно выжать поболее, но учитывая требования к открытости схемотехники это вроде как неприемлемо.

https://qrng.anu.edu.au/RainHex.php - квантовый RNG онлайн, красота 

needbmw
Я как-то тестировал СБМ-20 на образце с 0.12г оксида тория, получалось порядка 2000 частиц в минуту. Если таким потоком промодулировать генератор на К176ИЕ10, то должно быть интересно.

Чем больше, тем лучше, масло кашей не испортишь.

100 байт/с хватит на генерацию 2-3 ключей или 2-3 подписей в секунду. Кому-то достаточно, а кому-то будет мало, для какого-нибудь онлайн-сервиса вроде сатошидайс явно не хватит. Впрочем, байты можно генерировать заранее и записывать впрок.

P.S. Регистрирующий тракт дозиметров обычно способен переварить этак до 50-80 тысяч частиц в минуту, что хватает с избытком...