pyromaniac (OP)
|
|
July 19, 2013, 09:42:13 PM |
|
Непомерная избыточность, хранить полную цепь блоков на каждом компьютере. А что, если на каждом ПК хранить не всю цепь, а лишь её треть по принципу дисков в RAID5? Я не силён в жёстких дисках и системах хранения, но на пальцах это будет выглядеть так: Каждый компьютер получает рандомный номер от 0 до 3 и скачивает лишь часть цепочки блоков. Чтоб его данные можно было проверить, данные хранятся с избыточностью по принципу RAID5, где вместо хардов выступают отдельные компьютеры. На каждый компьютер будет скачиваться лишь часть цепочки блоков с избыточностью, а все компьютеры будут синхронизироваться между собой с соседями. Или бред?
|
|
|
|
Tenar_Pofiguel
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 20, 2013, 12:23:24 AM |
|
Я бы даже наоборот расчитывал - чем больше сеть, тем на большее количество кусков можно поделить (при фиксированном заданном времени доступа). Допустим, нам нужна некоторая вероятность успешного считывания (нахождения заданного количества узлов нужного типа в онлайне), тогда надо: 1) определить это количество узлов (допустим N1) 2) разделить всю цепочку на N1 типов узлов и получить K = Total/N1 кусков (а не 4), здесь Total - общее число блоков Идея в том, что K может быть гораздо больше 4 и масштабироваться вместе с сетью. Так же можно учитывать узлы разных видов (используя N1, N2, N3 и т.д. по количеству видов - сервер 7x24, десктоп, мобила)
Можно конечено заявить, что фиксирование количества типов узлов K = 4 позволяет проще решить проблему доверия сторонним узлам. Такое заявление следует обосновать.
|
|
|
|
pyromaniac (OP)
|
|
July 20, 2013, 12:56:44 AM |
|
Можно конечено заявить, что фиксирование количества типов узлов K = 4 позволяет проще решить проблему доверия сторонним узлам. Такое заявление следует обосновать.
Число 4 взято скорее для примера или упрощения, не суть важно. Но число кусков должно быть меньше числа узлов, чтоб каждый кусок многократно дублировался (и обязательно имел SHA5Sum).
|
|
|
|
Tenar_Pofiguel
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 20, 2013, 01:01:45 AM |
|
имел SHA5Sum
Чтобы хакеры вместо SHA1 могли подбирать SHA5Sum, да?
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
July 20, 2013, 07:14:40 AM |
|
Непомерная избыточность, хранить полную цепь блоков на каждом компьютере. А что, если на каждом ПК хранить не всю цепь, а лишь её треть по принципу дисков в RAID5? Я не силён в жёстких дисках и системах хранения, но на пальцах это будет выглядеть так: Каждый компьютер получает рандомный номер от 0 до 3 и скачивает лишь часть цепочки блоков. Чтоб его данные можно было проверить, данные хранятся с избыточностью по принципу RAID5, где вместо хардов выступают отдельные компьютеры. На каждый компьютер будет скачиваться лишь часть цепочки блоков с избыточностью, а все компьютеры будут синхронизироваться между собой с соседями. Или бред?
1. такой метод подходит ТОЛЬКО для обычных клиентов, но не майнеров (пулов и соло), у которых любая миллисекундная задержка (они будут копиться на каждую транзакцию не загруженную локально) - повышение шанса орфана. 2. хранить можно случайные блоки, количеством - доля, обратно пропорциональная количеству клиентов (ну там от логарифма или еще как), готовых технологий миллион, тот же DHT 3. овчинка выделки не стоит p.s. лучше развивать альтернативные клиенты (отдельно для майнинга отдельно для кошелька), и параллельно решать проблему концентрации мощностей у пулов майнинга...
|
|
|
|
dropt22
|
|
August 03, 2013, 07:51:50 PM |
|
а я думаю основная проблема тут в том что сломать систему можно будет взломав лишь часть одинаковых блоков хранящихся лишь у одной четверти пользователей... короче на взлом системы понадобиться больше 50% от 25% мощностей пользователей, для того чтобы записать в нужную часть блоков фиктивные транзакции.
|
|
|
|
orion_zx
Newbie
Offline
Activity: 19
Merit: 0
|
|
October 14, 2013, 09:55:34 PM |
|
Умный математик с самого начало просчитал все так чтоб работало. Если б можно было "избыточность" сделать меньшей то сделал бы.
|
|
|
|
manrus
Legendary
Offline
Activity: 1334
Merit: 1004
TTM
|
|
October 15, 2013, 02:51:54 PM |
|
Обычному пользователю даже скачивать 2-3гб блоков будет лениво. Он скорее поставит легковесный клиент. Сама идея интересная (принцип Freenet), но для безопасности лучше хранить 100%.
|
|
|
|
gelius
|
|
October 29, 2013, 05:23:27 PM |
|
Блоки должны быть на машине с широким каналом, находящейся онлайн 24/7. Т.Е. на сервере. Локальное хранение блоков, это издевательство. Ключ должен быть на локальной машине. Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему ИМХО, по истечению определенного времени стоит удалять историю операций. Можно например так: Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
October 29, 2013, 07:44:17 PM |
|
Блоки должны быть на машине с широким каналом, находящейся онлайн 24/7. Т.Е. на сервере. Локальное хранение блоков, это издевательство. Ключ должен быть на локальной машине. Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему ИМХО, по истечению определенного времени стоит удалять историю операций. Можно например так: Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька. Вы только что описали схему работы Electrum. Сервер Electrum: Модифицированный сервер bitcoin + abe, занимается помимо основных дел bitcoind, принимает от клиентов их созданные транзакции и отвечает на вопрос - сколько монет на этом адресе и нет ли новых транзакций с ним. Клиент Electrum: хранит приватные ключи у себя (в дополнение к этому интересный способ их генерации на базе единого числа seed, который может быьт представлен словами, т.е. запомнил 12 слов и все, получил доступ ко всем будущим транзакциям и адресам на своем кошельке), занимается тем что фрмирует транзакции и отсылает на сервер. Плюс сюда пытаются накрутить модульность, какие то плагины, например для работы с публичными метками адресов (хранятся децентрализовано) и т.п.
|
|
|
|
gelius
|
|
October 30, 2013, 05:05:49 AM |
|
Electrum еще сырой. Например у меня не работает через сокс. Обещают в следующем релизе. Установить сервер не вышло, правда пробовал очень давно. Там все далеко не юзерфрендли. А если народ будет юзать в основном публичные серверные части, электрум будет легко вывести из игры. Ну и возможно полностью веб клиент не имеющий доступа к закрытому ключу был бы также интересен. Постараюсь точнее описать идею. Допустим нужно совершить транзакцию. Серверная часть генерирует уникальный запрос на совершение операции, клиент генерирует ответ при помощи закрытого ключа. Серевер получает только сгенерированный ответ. Таким образом ключ можно хранить даже на машине без доступа к инету. Ну и я не понимаю зачем хранить весь лог операций вечно. Хватит только сумм на конечных адресах.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1359
|
|
November 07, 2013, 07:09:09 PM |
|
Ну и я не понимаю зачем хранить весь лог операций вечно. Хватит только сумм на конечных адресах.
Вообще-то незачем, и биткоину начиная с 0.8 не нужно его хранить, достаточно только лишь непотраченных инпутов. В пользовательских инсталляциях блоки на данный момент используются лишь для раздачи и сервисных целей (для работы функций типа gettransaction).
|
|
|
|
gelius
|
|
November 07, 2013, 11:09:15 PM |
|
Вообще-то незачем, и биткоину начиная с 0.8 не нужно его хранить, достаточно только лишь непотраченных инпутов. В пользовательских инсталляциях блоки на данный момент используются лишь для раздачи и сервисных целей (для работы функций типа gettransaction).
Не нашел как это реализовано. Скачивать все Blockchain нет желания.
|
|
|
|
|