Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
4 июля 2012, 12:55:49 AM   # 1
 
 
Сообщений: 18
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Я пытаюсь определить, если следующий вариант для сценария, связанный с операцией получения счетов действителен для обработки сети Bitcoin.
Может ли кто-нибудь ответить на этот вопрос?
Я мог бы просто попробовать, но я решил спросить первым, чтобы увидеть, если кто-то знает ответ или имеет другие информативные комментарии.

Вместо:
OP_DUP OP_HASH160 {хэш открытого ключа} OP_EQUALVERIFY OP_CHECKSIG

использовать:
OP_DUP {полный открытый ключ} OP_EQUALVERIFY OP_CHECKSIG

Цель этого существа, чтобы избежать возможности двух открытых ключей, имеющих один и тот же хэш, который позволил бы одной из сторон, чтобы провести биткойны.
Я не знаком с тем, как мала эта возможность на самом деле.
Единственная причина, чтобы использовать его было бы перевести монеты в "экономия" тип учетной записи (например, бумажный кошелек), поэтому они более надежно "хранится" в блок-цепи.
Это будет передача между двумя (или более) счетов, принадлежащих одному и тому же лицу.
Он не подходит для регулярных сделок, так как он не является частью стандартного бумажника, и это гораздо проще использовать базу-58 Bitcoin адрес для таких операций.

Я ценю ваши комментарии.

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


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


4 июля 2012, 1:48:38 AM   # 2
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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





{Полный открытый ключ} OP_CHECKSIG является допустимым, стандартный тип сделки, погашен путем предоставления только {подпись}.

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

4 июля 2012, 3:52:00 AM   # 3
 
 
Сообщений: 18
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

Привет Гэвин.

Я читал на сайте: https://en.bitcoin.it/wiki/Transactions#Types_of_Transaction

Я еще немного запутался и / или недоразумение. Давайте посмотрим на очень простую операции, используя все биткойна из одной предыдущей сделки, отправленной на другой единый счет. Я правильно здесь?
Для передачи Bitcoin адрес сделку, scriptSig содержит сиговую и открытый ключ, где сиг является измененной транзакцией текущей закодирован с использованием секретного ключа. Это первая часть сделки и определяет предыдущий транзакция (ИД транзакции хэш в минусе), который является источником монет.
ScriptPubKey извлекается из этой предыдущей операции и используется для проверки того, что эта новая транзакция разрешается.
Теперь scriptSig всегда должны быть самостоятельными последовательными, как это должно было быть порождены частными / парами открытого ключа.
Для scriptPubKey из: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Открытый ключ от scriptSig дублируется, перемешанный, по сравнению с хэш scriptPubKey (для проверки полномочий), а затем подпись проверяется на достоверность. Если scriptPubKey был сгенерирован частными / парами открытого ключа, он будет проверять, даже если это не правильный открытый ключ, до тех пор, как открытый ключ имеет тот же хэш (Bitcoin адреса). Так что это не останавливает два открытых ключей, которые имеют один и тот же хэш от каждого быть в состоянии получить доступ монет.

Для передачи IP-адрес, который Вы, кажется, ссылок, процесс проще и еще более безопасный, так как она разбивает данные scriptPubKey между двумя операциями.
Открытый ключ указывается в предыдущей транзакции в scriptPubKey. Текущая транзакция обеспечивает только сиговую в scriptSig. Теперь, как авторизация и проверка объединены в одну стадию. Открытый ключ от предыдущей транзакции используются для проверки сигового, закодированные с помощью закрытого ключа в текущей транзакции. Там не может существовать два закрытых ключей таким образом, что один открытый ключ может проверить сиговых генерируется с использованием либо закрытого ключа, не так ли?

Я понимаю ли это правильно?

Мне нравится последний метод лучше, так как это позволяет избежать проблем хэша и результаты в более коротких сделках. Его главный недостаток заключается в том, что требует предварительного отправителя использовать публичный адрес вместо Bitcoin адрес (короткий адрес). Оно также исключает получение остатка от блока цепи, используя адрес Bitcoin. Баланс должен быть получен с использованием как открытый ключ и адрес Bitcoin, чтобы быть полным (оба вида сделок, возможно, в блок цепи).

Почему это называется переход на IP-адрес, если IP-адрес не является частью сделки?

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

4 июля 2012, 3:52:47 AM   # 4
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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

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

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

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

Существует, по сути, oddbal altcoin предложение вызова MAVEPAY который использует заказанные раскрытия хэш прообразов, как его _только_ подписания примитивно. (Это с ума кучу причин, но факт, что вы можете создать правдоподобную систему подписывания из всего заказанного раскрытия отдельных хэш-входов (например, не высоко над головой, как Лампорт) предполагает, что вы не должны сбрасывать со счетов в пользу безопасности, что)
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

4 июля 2012, 9:43:27 AM   # 5
 
 
Сообщения: 728
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

Я не знаком с тем, как мала эта возможность на самом деле.

Это очень небольшая вероятность, потому что 2 ^ 160 является очень большое количество:

1461501637330902918203684832716283019655932542976

Если 10 миллиардов людей генерировать миллион адресов каждый день в течение 100 лет, вы в конечном итоге с:
365000000000000000000

Обратите внимание на то, что есть намного меньше цифр этого числа. В связи с парадоксом дня рождения вероятность того, что НЕКОТОРЫХ адрес будет сталкиваться значительно больше (но еще далеко), но вероятность того, что ваш почтовый адрес будет сталкиваться практически равна нулю.

Как уже упоминалось выше, вы можете использовать сиговых напрямую, если вы хотите, но я бы не рекомендовал его. Вероятность того, что это будет проблемой на аварии исчезающе мала. Реальная проблема является злоумышленник создает коллизию на цели. ECDSA считается гораздо слабее, чем криптографический ripemd160 (SHA256 ()), так что для практических целей, вы, вероятно, лучше использовать ключ MD160 с девственным адресом без какой публики не проводит (что бы выявить Публичный).
Revalin сейчас офлайн Пожаловаться на Revalin   Ответить с цитированием Мультицитирование сообщения от Revalin Быстрый ответ на сообщение Revalin

5 июля 2012, 2:43:37 PM   # 6
 
 
Сообщения: 532
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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

Пример отправка в Публичную сделке:
https://blockexplorer.com/tx/e39c0c43ddc4bc8d3fd3bd1faf93dc22adac8778a32a66fe1d65c64af5a5fd84
(См выход 0)
DeepBit сейчас офлайн Пожаловаться на DeepBit   Ответить с цитированием Мультицитирование сообщения от DeepBit Быстрый ответ на сообщение DeepBit

6 июля 2012, 7:44:03 PM   # 7
 
 
Сообщений: 18
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

Спасибо Гэвин Андресен, gmaxwell, Revalin и DeepBit за ваши ответы. Они очень полезны.

Я начинаю понимать это лучше. Мое беспокойство основано в долгосрочной перспективе безопасного хранения Bitcoins. Непосредственно с помощью одной учетной записи для этого оставит много сделок в blockchain как для приема и расходования монет. Хотя это может быть замаскировано с помощью временных счетов (кошелька) перевести монеты в и из долгосрочной счет до трансфертов или на счета других, он все равно будет в blockchain, так что открытый ключ не будет полностью скрыт (например, если не используется какой-либо сделки), и было бы легко получить от blockchain, если один знает один из временных номеров счетов.

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

Адрес Bitcoin делает скрыть открытый ключ, используя хэш {ripemd160 (SHA256 ())}, которая делает очень хорошую работу по защите открытого ключа. Это делает намного больше смысла, почему это рекомендуется не тратить из тех же номеров счетов более чем один раз. Затем открытый ключ не подвергается в течение очень короткого срока, за исключением, оставляя очень мало времени, чтобы попытаться использовать его. Имеет ли воздействие открытого ключа действительно имеет значение?

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

В соответствии с https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm
"открытый ключ: Число, которое соответствует закрытому ключу, но не нужно держать в секрете."  Таким образом, один придется либо угадать закрытый ключ или определить способ взломать ECDSA используя blockchain информации, относящуюся к адресу и / или открытому ключу. Гадание на действительно случайный секретный ключе невероятно маловероятно. Если закрытый ключ, полученные из ключевой фразы (мозг кошелек), возможность может стать возможной или даже вероятно.

Секретный ключ имеет уровень безопасности 256 бит. MD160 имеет уровень безопасности 160 бит. Казалось бы, что один Bitcoin адрес будет сталкиваться с о (2 ^ 256) / (2 ^ 160) или около 8x10 ^ 28 открытых ключей. Это, вероятно, это не просто, но адрес столкновение, конечно, кажется гораздо более вероятным, чем ключевое столкновение общественности, если это вообще возможно.

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

Основные проблемы, как представляется:
1) Сколько примерно ECDSA открытых ключей могут иметь один и тот же адрес хэш?
2) Насколько безопасен закрытый ключ, когда открытый ключ известен?
      (Этот вопрос рассматривается немного на http://en.wikipedia.org/wiki/Elliptic_Curve_DSA, который, кажется, указывает, что это так сложно, как угадать секретный ключ. Также на http://eprint.iacr.org/2002/129.pdf   а также   )
Также: http://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money

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

6 июля 2012, 7:53:27 PM   # 8
 
 
Сообщения: 1218
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

котировка
1) Сколько примерно ECDSA открытых ключей могут иметь один и тот же адрес хэш?

Вы уже ответить на него выше (2 ^ 256) / (2 ^ 160) Конечно, что большое число имеет лишь академический интерес. 160bit или 256 бит и не может быть неотшлифованные принудительно. Не с одним компьютером, а не с планетарным размером суперкомпьютера (да и в том числе эффекта закона Мура в течение следующего столетия).

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


котировка
2) Насколько безопасен закрытый ключ, когда открытый ключ известен?
Baring криптографической недостаток в ECDSA? Secure. Если не существует ошибка в выборе секретного ключа (криптографически слабый генератор случайных чисел) единственным вариантом будет перебор. Гораздо более полезным слой защиты для ультра Paranoid бы аппаратный ГСЧ, где выход просто не повторяется. 
DeathAndTaxes сейчас офлайн Пожаловаться на DeathAndTaxes   Ответить с цитированием Мультицитирование сообщения от DeathAndTaxes Быстрый ответ на сообщение DeathAndTaxes

6 июля 2012, 8:12:10 PM   # 9
 
 
Сообщения: 532
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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

Адрес Bitcoin делает скрыть открытый ключ, используя хэш {ripemd160 (SHA256 ())}, которая делает очень хорошую работу по защите открытого ключа. Это делает намного больше смысла, почему это рекомендуется не тратить из тех же номеров счетов более чем один раз. Затем открытый ключ не подвергается в течение очень короткого срока, за исключением, оставляя очень мало времени, чтобы попытаться использовать его. Имеет ли воздействие открытого ключа действительно имеет значение?
В этот момент bruteforcing даже только ваш хэш Публичных не представляется возможным (если, если не был создан известными методами из значимых слов / фразу).
Хотя ECDSA не нарушена и квантовые компьютеры не существует его можно считать достаточно безопасным.

Кроме того, если вы думаете, что ECDSA брутфорс является угрозой, вы можете попробовать multisignature сделки, как 2-из-2 или 3-на-3, так что это займет немного больше 🙂
(К сожалению, это не так эффективно, как удвоение длины ключа)
DeepBit сейчас офлайн Пожаловаться на DeepBit   Ответить с цитированием Мультицитирование сообщения от DeepBit Быстрый ответ на сообщение DeepBit

6 июля 2012, 8:48:24 PM   # 10
 
 
Сообщений: 18
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

Благодаря DeathAndTaxes и DeepBit.

Я также нашел:
и что Revalin является экспертом. Как основатель Tangible Cryptography LLC, DeathAndTaxes вероятно, также. Это здорово, чтобы получить комментарии от людей, которые действительно знают, что они говорят.

Основная проблема с использованием открытого ключа вместо Bitcoin адреса, как представляется, что указано Revalin:
"После того, как монеты были отправлены ИЗ адрес Публичный известно и ECDSA, вероятно, является слабым звеном (около 128 бит эквивалента безопасности). Это может быть правдоподобным, чтобы атаковать в отдаленном будущем, но, вероятно, не в моей жизни, если криптографический недостаток не обнаружен."
Использование адреса хэш-видимому, на самом деле более безопасным, чем ECDSA, так что падение в битах защиты от 256 до 160 на самом деле не реально, только воспринимается из-за слабости ECDSA.

Таким образом, оказывается, что пытается использовать долгосрочный счет на самом деле не стоит. Для анонимности, он стремится связать все ваши другие счета / операции вместе в blockchain. Не хорошо как.
Используя новый номер счета для каждого получающего сделки, в том числе на счета изменений, по-видимому, самым безопасным решением.
Это также примерно так же, как можно сделать для анонимности. Это очень трудно купить что-нибудь с помощью Bitcoins, что требует доставки покупки по коммерческим перевозчиком (на адрес или почтовый ящик) без ущерба для себя в какой-то степени. Для онлайн только там TOR.
Ключ для анонимности, как представляется, чтобы свести к минимуму связи между счетами (все перестановки для отправки / приема).

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

Могу ли я на пути здесь?

КСТАТИ DeepBit, как же сделать несколько подписных сделки на Bitcoin?
Вы знаете, хорошую ссылку на сайт?

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

6 июля 2012, 9:07:22 PM   # 11
 
 
Сообщения: 532
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

КСТАТИ DeepBit, как же сделать несколько подписных сделки на Bitcoin?
Вы знаете, хорошую ссылку на сайт?
Я думаю, что новая версия Satoshi ("официальный") Бумажник может выкупить multisigs если у вас есть все ключи. Одна из последних бет также может создать multisigs, если у вас есть все pubkeys, используя "addmultisigaddress" команды, но я не знаю, если он уже был развернут выпуск версии.
Для получения инструкций см это: https://en.bitcoin.it/wiki/BIP_0016_QA

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

7 июля 2012, 3:28:50 AM   # 12
 
 
Сообщения: 728
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

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


Неправильно. Квантовая механика представляет собой набор реальных физических явлений, которые вполне реальны и наблюдаемые.

сегодня существуют квантовые компьютеры. В 2001 году IBM успешно используется Алгоритм Шора фактор 15 в 3x5, который является наименьшим значимым применение возможно.

Угроза не является неизбежным, но это, безусловно, беспокойство в долгосрочной перспективе (50 + лет). Это еще не известно, если квантовый компьютер достаточно мощный, чтобы взломать криптографию когда-либо будет возможно. Вполне возможно, что требования к питанию предотвратит его от выполнимо. NMRQC (как используется IBM), конечно, не будет масштабироваться до криптографического растрескивания размеров. Тем не менее, это все еще значительное доказательство концепции.

Что касается ECDSA, краткосрочной угроза, что он, как и все с открытым ключом криптографии, основанная на принципах, которые являются менее тщательно изучены и поняты, чем симметричный и односторонний крипто. Поэтому обычно считается более вероятным, что значительная криптографической недостаток можно найти в ECDSA, чем в УВХ2 или RIPEMD.


котировка
Могу ли я на пути здесь?

Я предлагаю: создать серию бумажных кошельков и сделать один депозит на каждый адрес, используя стандартное RIPEMD адреса, которые я считаю самой сильной форма. Разбив его в ряд небольших кошельков вы удаляете стимул, чтобы взломать один большой кошелек (в случае частичного разрыва, который требует значительных затрат для завершения). Когда вы в конечном итоге тратить деньги, отправлять изменения другого нового адреса каждый раз.

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

8 июля 2012, 11:25:04 PM   # 13
 
 
Сообщений: 18
Цитировать по имени
цитировать ответ
по умолчанию Re: изменение сценария для повышения безопасности аккаунта

Привет Revalin.

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

Что касается: В 2001 году IBM успешно используется алгоритм Шора фактор 15 в 3x5,
Видеть: https://en.wikipedia.org/wiki/Shor%27s_algorithm  а также  https://en.wikipedia.org/wiki/Nuclear_magnetic_resonance_(NMR)_quantum_computing
"ЯМР квантовые вычислительные эксперименты, вероятно, были только классические моделирования квантового компьютера."
Таким образом, эксперимент IBM не удовлетворяет истинные квантовые требования. Есть и другие эксперименты, которые сделали продемонстрированные entaglement, но только на пару кубитов.
Существует огромная проблема преодоления классической и квантовой механики. Принцип эквивалентности ОТО (сердце ГР) был проверен путем измерения, по меньшей мере, 12 знаков после запятой. Это является более точным, чем многие законы физики.
Одиночные измерения фотонов не достаточно точны, чтобы подтвердить некоторые основные квантовые свойства, как в интерферометре Маха-Цандера.
esimates плотности энергии вакуума не является даже близко между классическими и квантовыми предсказаниями.

Доказательство примеров концепции только демонстрирует очень небольшую / простую факторизацию, который имеет только один ответ. Означает ли это продемонстрировать путем измерения полиномиальное время скорость факторизации?

К сожалению, это не по теме. Я нахожу это захватывающим, хотя.

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



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW