Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
30 ноября 2011, 7:48:03 PM   # 1
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

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


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

Глядя на исходный код C / C ++ для Bitcoin, кажется, есть немного слабость в механизме загружающего блок, и есть также место для совершенствования.

1. Сначала слабость:

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

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

Клиент Bitcoin 0,5 всегда выбирает первое соединение для загрузки блоков из, так что потенциал слабость:

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

Так что, возможно, это может быть использовано.

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

Также есть место для совершенствования:

2. Вместо загрузки только с первого, блоки также могут быть загружены из нескольких соединений, один блок для каждого соединения, раскинувшийся, то он повторяет. Однако это, вероятно, потребуется некоторое регулирование полосы пропускания в противном случае клиент, вероятно, в конечном итоге Døssing себя, например, это загрузить трубу перегружается / полным, который не обязательно должен быть проблема, а также TCP предназначена для компенсации, что и есть некоторые основные дросселирования для предотвращения переполнения всей сети, однако если клиент все еще хочет сделать что-то другое, что может быть все еще иметь под рукой удушения, однако дросселирование не является непосредственным требование поэтому эта идея, вероятно, может быть реализована сразу.

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


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


30 ноября 2011, 7:51:54 PM   # 2
 
 
Сообщения: 406
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

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





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

30 ноября 2011, 8:07:06 PM   # 3
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Хорошо, что это на самом деле смешно.

Давайте посмотрим, как долго он будет брать с собой текущим размером базы данных, скажем, 1 гигабайт:

1024 * 1024 * 1024/1024 * 8 = секунд требуется сто тридцать одна тысяча семьдесят два.

131072/60 * 60 = 36,40888 часов.

Таким образом, около 37 часов, что удивительно по-прежнему довольно выполнимо только с 56k6 модемом!

Может быть, немного оптимистичное расчет, но все же, это будет делать в течение примерно 2 дней загрузки!

По крайней мере, моя оценка! Ваш может измениться! = D

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

30 ноября 2011, 8:12:52 PM   # 4
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Клиент Bitcoin бы хорошо, чтобы просто принести большую часть blockchain как знаковый файл через HTTP из хранилища, и полагаться только на P2P-сети, чтобы довести его до настоящего времени. Пойди разберись, он может даже использовать BitTorrent!
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

30 ноября 2011, 8:37:11 PM   # 5
 
 
Сообщения: 154
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Хороший вызов Майк.
btc_artist сейчас офлайн Пожаловаться на btc_artist   Ответить с цитированием Мультицитирование сообщения от btc_artist Быстрый ответ на сообщение btc_artist

30 ноября 2011, 8:43:24 PM   # 6
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

просто принести большую часть blockchain как подписанный файл
Почему подписан? Блок-цепь уже подписан до неузнаваемости. Blkindex.dat все избыточной информации и может быть безопасно воссоздан на месте по мере необходимости.
2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112

30 ноября 2011, 9:05:46 PM   # 7
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Клиент Bitcoin бы хорошо, чтобы просто принести большую часть blockchain как знаковый файл через HTTP из хранилища, и полагаться только на P2P-сети, чтобы довести его до настоящего времени. Пойди разберись, он может даже использовать BitTorrent!

Нех, это идет вразрез с распределенной / p2p философии Bitcoin

Кроме того, сервер HTTP будет перегрузиться очень быстро и в будущем Bitcoin становится более populair и центральную точку отказа / атаки

Задача Bitcoin является эволюционирует в масштабируемый, надежный, tolerent неисправностей, децентрализованная, эффективная и безопасная система

HTTP не принадлежит в "безопасный" категория.
HTTP не принадлежит в "масштабируемый" категория.
HTTP не принадлежит в "децентрализованная" категория.
И т.д...

Так уже три причины, чтобы уволить HTTP, некоторые из них могут быть решены, если все начинает работать мини-сервер HTTP в Bitcoin, но это было бы немного странно! и до сих пор не решает все потенциально! И еще нужно немного больше работы ... Я уже писал / отправил идею, как распределенная загрузка блоков может быть сделано с Merkle дерева хэш!

^ Эта идея, вероятно, может быть лучше, чем BitTorrent, потому что сразу позволяет блокам, которые были загружены быть проверены на достоверность.

С BitTorrent там еще может быть риск отдельных сегментов данных, чтобы быть неправильным / поврежден. Насколько я помню, битторрент работает со списком хэшей для каждого блока. Таким образом, проблема здесь является "торрент-файл",

Кто будет производить этот торрент файл?.

Торрент-файл не в категориях выше, и, таким образом, должно быть отвергнуто!
Skybuck сейчас офлайн Пожаловаться на Skybuck   Ответить с цитированием Мультицитирование сообщения от Skybuck Быстрый ответ на сообщение Skybuck

10 декабря 2011, 5:42:50 AM   # 8
 
 
Сообщения: 249
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Эта проблема могла бы гораздо легче быть solved- без Bittorrent или repositories- просто загрузив блоки в циклическом режиме через различные каналы.
Пусть Connection 1 мучительно медленно.
Клиент будет использовать соединение 1 для передачи блока 1. Соединение 2, блок 2 и так далее.
(Предположим, что 8 соединений)
Первое соединение, чтобы закончить загрузку блока будет загрузить блок 9, следующий блок 10, и так далее. Для обработки блоков, вам нужны их в порядке, так что вы все равно будете ждать на более раннем этапе (например, блок 1, в данном случае). Если 50 блоки будут загружены и сохранены (блоки 2 до 51 в данном случае), все еще ждет от предыдущего блока для загрузки дополнительных загрузки приостановлены. Если скорость передачи данных этого соединения составляет менее 10% от среднего значения всех соединений, то передача прекращается, и блок повторно запрошен через другое соединение.

Это решение
* Является безопасным
* Децентрализована
* Не требует от нас, чтобы реализовать БитТоррент.
* Предотвращает злонамеренные медленные соединения от наличия какого-либо воздействия
* Терпит случайный огромного блок, даже если это произойдет прийти через медленное соединение

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

10 декабря 2011, 6:31:54 AM   # 9
 
 
Сообщения: 1862
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Задача Bitcoin является эволюционирует в масштабируемый, надежный, tolerent неисправностей, децентрализованная, эффективная и безопасная система

GIT принадлежит в "безопасный" категория.
GIT принадлежит в "масштабируемый" категория.
GIT принадлежит в "децентрализованная" категория.
И т.д...

Таким образом, уже три причины для поддержки GIT, в идеале, если кто-нибудь может запустить сервер GIT и клиент может пройти вокруг последней ГОЛОВЫ хэш. Некоторые люди просто использовать GIT, чтобы вытащить из надежного источника, другие будут получать блок через сеть Bitcoin.

^ Эта идея, вероятно, может быть лучше, чем BitTorrent, потому что сразу позволяет блокам, которые были загружены быть проверены на достоверность.

FTFY

А если серьезно, я хотел бы видеть больше разнообразия в хранении и передаче блока цепи. Я уверен, что мы теперь оказаться весьма примитивными по сравнению с тем, как он будет обработан в течение 5 лет.

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

10 декабря 2011, 3:55:48 PM   # 10
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Эта проблема могла бы гораздо легче быть solved- без Bittorrent или repositories- просто загрузив блоки в циклическом режиме через различные каналы.
Пусть Connection 1 мучительно медленно.
Клиент будет использовать соединение 1 для передачи блока 1. Соединение 2, блок 2 и так далее.
(Предположим, что 8 соединений)
Первое соединение, чтобы закончить загрузку блока будет загрузить блок 9, следующий блок 10, и так далее. Для обработки блоков, вам нужны их в порядке, так что вы все равно будете ждать на более раннем этапе (например, блок 1, в данном случае). Если 50 блоки будут загружены и сохранены (блоки 2 до 51 в данном случае), все еще ждет от предыдущего блока для загрузки дополнительных загрузки приостановлены. Если скорость передачи данных этого соединения составляет менее 10% от среднего значения всех соединений, то передача прекращается, и блок повторно запрошен через другое соединение.

Это решение
* Является безопасным
* Децентрализована
* Не требует от нас, чтобы реализовать БитТоррент.
* Предотвращает злонамеренные медленные соединения от наличия какого-либо воздействия
* Терпит случайный огромного блок, даже если это произойдет прийти через медленное соединение

-Atheros

Этого недостаточно, даже текущая реализация Bitcoin может быть восприимчива к битовым ошибкам. Я не уверен, если Bitcoin добавляет дополнительную проверку целостности поверх протокола TCP. Просто Tcp сам по себе не достаточно для передачи данных без изменений в течение dialups. Я видел dialups вводить битовые ошибки, которые не были обнаружены в UdP протоколов, я предположил бы, что произойдет в ТСРЕ, так как он использует ту же самую проверку ошибок, что является очень слабым: только сложения.

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

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

Так что это хороший вопрос:

Как Bitcoin защиты от битовых ошибок или вредоносных битовых ошибок? Есть ли хэш, который рассчитывается по всему блоку? Значение каждого бита

Я не совсем уверен, но я думаю, что Bitcoin делает это с блок-хэшей, и блок цепи ...

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

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

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

Но на самом деле эта идея будет гораздо сложнее, чем просто круговой ... однако более сложная идея может иметь преимущество в производительности ...

Идея состояла в том, чтобы предотвратить одно соединение из замедляет работу.

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

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



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

10 декабря 2011, 11:07:29 PM   # 11
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Задача Bitcoin является эволюционирует в масштабируемый, надежный, tolerent неисправностей, децентрализованная, эффективная и безопасная система

GIT принадлежит в "безопасный" категория.
GIT принадлежит в "масштабируемый" категория.
GIT принадлежит в "децентрализованная" категория.
И т.д...

Таким образом, уже три причины для поддержки GIT, в идеале, если кто-нибудь может запустить сервер GIT и клиент может пройти вокруг последней ГОЛОВЫ хэш. Некоторые люди просто использовать GIT, чтобы вытащить из надежного источника, другие будут получать блок через сеть Bitcoin.

^ Эта идея, вероятно, может быть лучше, чем BitTorrent, потому что сразу позволяет блокам, которые были загружены быть проверены на достоверность.

FTFY

А если серьезно, я хотел бы видеть больше разнообразия в хранении и передаче блока цепи. Я уверен, что мы теперь оказаться весьма примитивными по сравнению с тем, как он будет обработан в течение 5 лет.

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

Вы не можете загрузить GIT репозиторий с несколькими коллегами параллельно, хотя. Интересная идея, хотя.
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald

10 декабря 2011, 11:20:29 PM   # 12
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Это причина, почему битторрент использует ша хэш для защиты сегментов против битовых ошибок или злонамеренных битовых ошибок.
Так что это хороший вопрос:
Как Bitcoin защиты от битовых ошибок или вредоносных битовых ошибок? Есть ли хэш, который рассчитывается по всему блоку? Значение каждого бита

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

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


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

10 декабря 2011, 11:30:04 PM   # 13
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Это причина, почему битторрент использует ша хэш для защиты сегментов против битовых ошибок или злонамеренных битовых ошибок.
Так что это хороший вопрос:
Как Bitcoin защиты от битовых ошибок или вредоносных битовых ошибок? Есть ли хэш, который рассчитывается по всему блоку? Значение каждого бита

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

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



Ты имеешь в виду "может быть предотвращен с периодическим контрольно-пропускными пунктами" не так ли?
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald

11 декабря 2011, 12:14:18 AM   # 14
 
 
Сообщения: 1862
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Задача Bitcoin является эволюционирует в масштабируемый, надежный, tolerent неисправностей, децентрализованная, эффективная и безопасная система

GIT принадлежит в "безопасный" категория.
GIT принадлежит в "масштабируемый" категория.
GIT принадлежит в "децентрализованная" категория.
И т.д...

Таким образом, уже три причины для поддержки GIT, в идеале, если кто-нибудь может запустить сервер GIT и клиент может пройти вокруг последней ГОЛОВЫ хэш. Некоторые люди просто использовать GIT, чтобы вытащить из надежного источника, другие будут получать блок через сеть Bitcoin.

^ Эта идея, вероятно, может быть лучше, чем BitTorrent, потому что сразу позволяет блокам, которые были загружены быть проверены на достоверность.

FTFY

А если серьезно, я хотел бы видеть больше разнообразия в хранении и передаче блока цепи. Я уверен, что мы теперь оказаться весьма примитивными по сравнению с тем, как он будет обработан в течение 5 лет.

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

Вы не можете загрузить GIT репозиторий с несколькими коллегами параллельно, хотя. Интересная идея, хотя.

Что вы можете. протоколы передачи GIT поддерживаемый разрешать запросы для отдельных объектов. Поэтому, как только у вас есть список объектов, которые вы можете запросить каждый объект из другого хранилища. Это добавит намного больше накладных расходов, чем захват всех объектов сразу же. Это не должно быть слишком большой проблемой, поскольку с большинством протоколов, которые вы можете легко задать для диапазонов объектов или поддерева дерева объектов.
notme сейчас офлайн Пожаловаться на notme   Ответить с цитированием Мультицитирование сообщения от notme Быстрый ответ на сообщение notme

11 декабря 2011, 12:18:59 AM   # 15
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Это причина, почему битторрент использует ша хэш для защиты сегментов против битовых ошибок или злонамеренных битовых ошибок.
Так что это хороший вопрос:
Как Bitcoin защиты от битовых ошибок или вредоносных битовых ошибок? Есть ли хэш, который рассчитывается по всему блоку? Значение каждого бита

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

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




Трудно сказать, как протокол работает точно.

Однако вы, кажется, намекают на этом разделе:

https://en.bitcoin.it/wiki/Protocol_specification

Он содержит структуру сообщения под названием "общие структуры",

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

Это помогло бы, если спецификация протокола будет содержать некоторые диаграммы / линию / стрелку, чтобы наглядно показать, как поля ссылки в другие структуры.

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

11 декабря 2011, 4:10:15 AM   # 16
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Трудно сказать, как протокол работает точно.

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

Умение чтения кода меняется, но я думаю, что «официальный клиент» код в Bitcoin достаточно ясно.

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

11 декабря 2011, 6:59:08 AM   # 17
 
 
Сообщения: 186
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Трудно сказать, как протокол работает точно.

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

Умение чтения кода меняется, но я думаю, что «официальный клиент» код в Bitcoin достаточно ясно.



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

Однако, когда дело доходит до контрольной суммы такого рода вещи тоже пугают меня немного:

От main.cpp:
Код:
        // Контрольная сумма
        если (vRecv.GetVersion () >= 209)
        {
            uint256 хэш = Хеш (vRecv.begin (), vRecv.begin () + nMessageSize);

Что, черт возьми, vRecv.begin () делать?

Один должен быть импульс "эксперт" понять, что

Это своего рода указатель? И почему это нужно знать о начале сообщения?

Это, вероятно, что-то поток родственный

Тем не менее, глядя на код, это не сразу apperent, что это Overal структура сообщения, по крайней мере, структура сообщения между клиентами это кажется.

"ProcessMessages" это рутина.

Это может означать что угодно ... это "Процесс сообщения IRC" ? это "клиентские сообщения", Это что-то особенное, как "блокировать сообщения",

IRC использует свой собственный протокол, а также используют сообщения, даже TCP могут быть рассмотрены сообщения, хотя обычно считаются "потоки" (или сегменты).

Тогда есть HTTP? И, возможно, даже другие вещи, я не знаю, о и может быть там ... все, что я знаю, что база данных может быть общение с "Сообщения"

Даже окна связывается с "Сообщения" = D

Удивительно, но факт.

Ofcourse от просмотра его это, кажется, что-то делать с какой-то протокол связи.

С некоторой помощью Документов, коды, и вы, ребята, на форуме, он начинает иметь некоторый смысл

Кроме того, иногда имя файла помогает, irc.cpp и irc.h довольно очевидно! = D
Skybuck сейчас офлайн Пожаловаться на Skybuck   Ответить с цитированием Мультицитирование сообщения от Skybuck Быстрый ответ на сообщение Skybuck

11 декабря 2011, 7:22:46 PM   # 18
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: потенциальная слабость в блоке загрузки

Задача Bitcoin является эволюционирует в масштабируемый, надежный, tolerent неисправностей, децентрализованная, эффективная и безопасная система

GIT принадлежит в "безопасный" категория.
GIT принадлежит в "масштабируемый" категория.
GIT принадлежит в "децентрализованная" категория.
И т.д...

Таким образом, уже три причины для поддержки GIT, в идеале, если кто-нибудь может запустить сервер GIT и клиент может пройти вокруг последней ГОЛОВЫ хэш. Некоторые люди просто использовать GIT, чтобы вытащить из надежного источника, другие будут получать блок через сеть Bitcoin.

^ Эта идея, вероятно, может быть лучше, чем BitTorrent, потому что сразу позволяет блокам, которые были загружены быть проверены на достоверность.

FTFY

А если серьезно, я хотел бы видеть больше разнообразия в хранении и передаче блока цепи. Я уверен, что мы теперь оказаться весьма примитивными по сравнению с тем, как он будет обработан в течение 5 лет.

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

Вы не можете загрузить GIT репозиторий с несколькими коллегами параллельно, хотя. Интересная идея, хотя.

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

Я исправлюсь.  http://code.google.com/p/gittorrent/wiki/MirrorSync может быть интересным способом распространения цепи. Будет ли каждый блок будет совершать?

(Я думал, что я это вчера, но я не должен иметь)
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW