|
![]() |
# 1 |
Сообщения: 1750
цитировать ответ |
![]()
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru С постоянно растущей blockchain, хранение и проверка blockheader может стать проблемой для очень легких SPV клиентов. Это было бы полезно включить merkleroot из blockheaders в coinbase (как мягкая вилка)? Таким образом, клиенты SPV должны хранить только заголовки соответствующих блоков.
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 2 |
Сообщения: 1750
цитировать ответ |
![]()
Получил 1806 Биткоинов
Реальная история. Ну, как только я после этого я понимаю, что это не может быть хорошей идеей, поскольку клиенты SPV должны проверить POW, поэтому они должны все blockheaders в любом случае. Тем не менее, эта идея полезна каким-то другим способом?
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 3 |
Сообщения: 2366
цитировать ответ |
![]() Ну, как только я после этого я понимаю, что это не может быть хорошей идеей, поскольку клиенты SPV должны проверить POW, поэтому они должны все blockheaders в любом случае. Тем не менее, эта идея полезна каким-то другим способом? Вот: http://blockstream.com/sidechains.pdf прочитайте Приложение B "Эффективный SPV доказательство", В нем мы представляем проект, который позволяет точно количество проделанной работы (в ожидании) на цепи и вычислить точно такое же значение, как пользователь линейно читают заголовки, используя только журнал связи. (Компромисс в том, что, потому что есть несколько образцов измерение имеет высокую дисперсию, поэтому злоумышленник авторинг ложного доказательства может повезти, подобно тому, как вы могли бы найти блок на вашем CPU ... так что даже если ожидаемая работа подделывать доказательство точно так же, вероятность успеха в атаке на выше, чем для эквивалентной длины REORG, хотя существуют различные пути дальнейшего затвердевают его, наиболее дальнейшее снижение эффективности коммуникации). |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 4 |
Сообщения: 412
цитировать ответ |
![]() Я не думаю, что это возможно по той же причине подпись не может подписать сам .. coinbase транзакции используются для вычисления хэша Merkle, поэтому, следовательно, не может содержать Merkle хэша без изменения хэша вы хотели бы включить.
|
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 5 |
Сообщения: 1750
цитировать ответ |
![]() Я не думаю, что это возможно по той же причине подпись не может подписать сам .. coinbase транзакции используются для вычисления хэша Merkle, поэтому, следовательно, не может содержать Merkle хэша без изменения хэша вы хотели бы включить. Чтобы быть точным, я говорю о Merkle хэш хэш всех предыдущий блоки |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 6 |
Сообщения: 1750
цитировать ответ |
![]() Ну, как только я после этого я понимаю, что это не может быть хорошей идеей, поскольку клиенты SPV должны проверить POW, поэтому они должны все blockheaders в любом случае. Тем не менее, эта идея полезна каким-то другим способом? Вот: http://blockstream.com/sidechains.pdf прочитайте Приложение B "Эффективный SPV доказательство", В нем мы представляем проект, который позволяет точно количество проделанной работы (в ожидании) на цепи и вычислить точно такое же значение, как пользователь линейно читают заголовки, используя только журнал связи. (Компромисс в том, что, потому что есть несколько образцов измерение имеет высокую дисперсию, поэтому злоумышленник авторинг ложного доказательства может повезти, подобно тому, как вы могли бы найти блок на вашем CPU ... так что даже если ожидаемая работа подделывать доказательство точно так же, вероятность успеха в атаке на выше, чем для эквивалентной длины REORG, хотя существуют различные пути дальнейшего затвердевают его, наиболее дальнейшее снижение эффективности коммуникации). Вы имеете в виду, можно использовать хэш очень низкое значение, чтобы заменить весь blockchain? EDIT: Я сделал ошибку Таким образом, с текущем chainwork = 69fdb53bd3217bc08921f в блоке 354922, я могу переписать всю blockchain, если я достаточно удачлив, чтобы получить хэш ниже 0000000000000000000026a50fe1b18437 .......? (Я получаю это число, взяв 1 / 69fdb53bd3217bc08921f https://www.wolframalpha.com/input/?i=1%2F0x69fdb53bd3217bc08921f) это 39136 раз сложнее, чем то текущая цель 00000000000000001713dd000000000000000000000000000000000000000000 и, как ожидается, один в |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 7 |
Сообщения: 1148
цитировать ответ |
![]() это 39136 раз сложнее, чем то текущая цель 00000000000000001713dd000000000000000000000000000000000000000000 и ожидается, что один в 19,4 недель с текущей hashrate 39136 блоков почти 1 год блоков. Если у вас было так много хэширования мощности, то можно сразу заменить цепь. Основная проблема заключается в том, что если власть хеширования экспоненциально возрастает, то все предыдущие POW сделаны равно 1 время удвоения стоимости текущей мощности хеширования. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 8 |
Сообщения: 1750
цитировать ответ |
![]() это 39136 раз сложнее, чем то текущая цель 00000000000000001713dd000000000000000000000000000000000000000000 и ожидается, что один в 19,4 недель с текущей hashrate 39136 блоков почти 1 год блоков. Если у вас было так много хэширования мощности, то можно сразу заменить цепь. Основная проблема заключается в том, что если власть хеширования экспоненциально возрастает, то все предыдущие POW сделаны равно 1 время удвоения стоимости текущей мощности хеширования. Это выше, поскольку сложность является довольно стабильной в течение последних нескольких месяцев. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 9 |
Сообщения: 2366
цитировать ответ |
![]() Вы имеете в виду, можно использовать хэш очень низкое значение, чтобы заменить весь blockchain? Не совсем; Вы передадите работу, которую вы таргетирования ... так что вы не можете просто найти что-то и заменить столько, сколько вы можете; Вы должны установить заранее, какое количество работы Вы утверждаете; а ссылка не делает ничего, если вы не ударил его. Если вы пытаетесь, но не увенчались успехом, вы просто впустую свои усилия. Другими словами, с таким же количеством хэширования мощности в среднем вы могли бы сделать ошибочный компактное доказательство того, что заменяет цепь, или вы могли бы нормально заменить всю цепочку; они принимают тот же ожидаемый объем работы точно. Но если у вас не было, что много хеширования власти ... достаточно только, чтобы, скажем, заменить 6 месяцев; то, возможно, вы могли бы получить повезло и успешно создать компактное доказательство для всей цепи, но, скажем, 0,01% вероятность успеха в то время как вероятность успеха просто повезло получить непосредственно добычи блоков будет 0,0000001% вероятность успеха; только из-за уменьшенное количество образцов. (Хотя примечание, вы можете увеличить ваши шансы успеха Reorg даже без компактных доказательств по добыче, так что сложность растет с максимально возможной скоростью (например, 4x каждый Retarget) ... и _if_ вы предполагаете, что hashrate каждого экспоненциально растет навсегда; то любая фиксированная доля hashrate (например, 0,1%) будет в конечном, но потенциально очень большая, время, в конце концов заменить всю цепочку только благодаря тому, что 4x наращивает дисперсию атака: в конце концов, у вас есть цепь с аналогичной работой, но гораздо меньшим количеством образцов и так что вы можете получить повезло) Что касается исторической работы: http://bitcoin.sipa.be/powdays-50k.png это сколько времени в текущем hashrate, что было бы предпринять, чтобы заменить работу в цепочке. |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 10 |
Сообщения: 1750
цитировать ответ |
![]() Вы должны установить заранее, какое количество работы Вы утверждаете; Вы имеете в виду морфинг "биты" поле в заголовке? Является ли это законно использовать более низкие, чем требуется "биты" в Bitcoin заголовке? а ссылка не делает ничего, если вы не ударил его. Если вы пытаетесь, но не увенчались успехом, вы просто впустую свои усилия. Другими словами, с таким же количеством хэширования мощности в среднем вы могли бы сделать ошибочный компактное доказательство того, что заменяет цепь, или вы могли бы нормально заменить всю цепочку; они принимают тот же ожидаемый объем работы точно. Но если у вас не было, что много хеширования власти ... достаточно только, чтобы, скажем, заменить 6 месяцев; то, возможно, вы могли бы получить повезло и успешно создать компактное доказательство для всей цепи, но, скажем, 0,01% вероятность успеха в то время как вероятность успеха просто повезло получить непосредственно добычи блоков будет 0,0000001% вероятность успеха; только из-за уменьшенное количество образцов. Шансы на успех выше из-за более высокой дисперсией, верно? Обычный способ следует гамма-распределение (Erlang) в то время как компактное доказательство следует экспоненциальное распределение? Это звучит связано с моими ранее (плохими) идеями "уменьшение дисперсии интервала блока без уменьшения среднего интервала" |
![]() ![]() |
![]() ![]() ![]() |
![]() |
# 11 |
Сообщения: 2366
цитировать ответ |
![]() Вы имеете в виду морфинг "биты" поле в заголовке? Является ли это законно использовать более низкие, чем требуется "биты" в Bitcoin заголовке? Нет; обязательства, включенные в блок является hashtree с листьями, которые выглядят как:{Индекс для того, как много назад, previous_block_hash, компактная кодированный разница между работой в настоящее время, а затем} ... Для нескольких обратных указателей. Задний указатель действителен только (считается приемлемым для обхода в качестве доказательства), если блок привязки к нему соответствует порогу работы разностей. Аналогично объединить добычу, можно выполнять N-hashcashes параллельно все с различными порогами. Так же, как если бы трудности namecoin были выше, чем Bitcoin вы могли mergemine namecoin и имеют Bitcoin блок с namecoin обязательства в нем, которая до сих пор непригодны для namecoin, хотя его действительный блок Bitcoin. Таким образом, чтобы перейти по ссылке, которая выходит один блок обратно, вам нужны биты work-- это обычный случай. Чтобы перейти по ссылке, которая выскакивает два назад ваш блок должен быть действителен на 2 * бит уровня ... и так далее, чтобы успешно шахта 10000 назад хмель вам нужно иметь блок, который является действительным, если рассматривать с порогом работы все, что было натянуто на этих блоков (например, 10000x больше, если трудность была постоянной). Поэтому доказательство можно скрыть данные, но вы не можете поддельные один с меньшим количеством работы (в среднем), чем просто добыча нормально. Индивидуально любой блок вряд ли прыгать далеко назад, но на совокупные длинные скачки случаются и в результате доказательство лог размера по длине цепи. (На самом деле меньше, когда hashrate постоянно увеличивается). Для данного набора обязательств существует несколько возможных путей, и поэтому несколько доказательств для одной и той же цепи possible--, если вы могли бы пойти 100 назад вы могли бы также пойти 50 назад. Иногда происходит меньше обратно делает для меньшего доказательства, возможно, на 51 сзади есть один хмель, который проходит весь путь. Наималейшее доказательство можно построить линейное время с помощью динамического программирования: Начните с блоком, который вы пытаетесь достичь с помощью доказательства (например, генезис), и сканирования вперед, для каждого блока следить за размером лучшего доказательства от него назначения и первый хмель назад, когда рассмотрит блок проверку каждый из его действительных обратных ссылок, добавить стоимость принятия этой обратной ссылки на стоимость его назначения лучшего. Возьмите минимум, как лучше и перейти к следующему блоку. Когда вы дойдете до конца ходить backwords. Этот алгоритм всегда производит наименьшее возможное доказательство, хотя простой жадный алгоритм (всегда прыгать, насколько вы можете, но не мимо пункта назначения), обычно не _that_ гораздо больше. котировка Шансы на успех выше из-за более высокой дисперсией, верно? Обычный способ следует гамма-распределение (Erlang) в то время как компактное доказательство следует экспоненциальное распределение? Право, exactly-- хорошо, чтобы быть более точным, то компактное доказательство и нормальное оба гамма; но компактное доказательство принимает журнал формы, в то время как увеличение лямбда --- то же самое ожидаемое работы, представлено меньшим числом более редких событий, таких, что математическое ожидание такой же, но форма распределения отличается.Технически его можно сделать доказательство "более доказать", Например, идти X-работа назад вы должны показать ожидаемую общую работу а * X; но я думаю, что я пришел к выводу, что вы можете получить только постоянные улучшения коэффициента тех пути, если вы не нарушать асимптотическое логарифмическое масштабирование корректур. Одна хорошая вещь в том, что такие методы между расстойки и проверяющего, обязательства не меняются. |
![]() ![]() |
![]() ![]() ![]() |