Вообще-то незачем, и биткоину начиная с 0.8 не нужно его хранить, достаточно только лишь непотраченных инпутов. В пользовательских инсталляциях блоки на данный момент используются лишь для раздачи и сервисных целей (для работы функций типа gettransaction).
Не нашел как это реализовано. Скачивать все Blockchain нет желания. 
Topic: Идея хранения Blockchain (Read 2482 times)
Ну и я не понимаю зачем хранить весь лог операций вечно. Хватит только сумм на конечных адресах.
Вообще-то незачем, и биткоину начиная с 0.8 не нужно его хранить, достаточно только лишь непотраченных инпутов. В пользовательских инсталляциях блоки на данный момент используются лишь для раздачи и сервисных целей (для работы функций типа gettransaction).
Electrum еще сырой. Например у меня не работает через сокс. Обещают в следующем релизе.
Установить сервер не вышло, правда пробовал очень давно. Там все далеко не юзерфрендли. А если народ будет юзать в основном публичные серверные части, электрум будет легко вывести из игры.
Ну и возможно полностью веб клиент не имеющий доступа к закрытому ключу был бы также интересен.
Постараюсь точнее описать идею. Допустим нужно совершить транзакцию. Серверная часть генерирует уникальный запрос на совершение операции, клиент генерирует ответ при помощи закрытого ключа. Серевер получает только сгенерированный ответ. Таким образом ключ можно хранить даже на машине без доступа к инету.
Ну и я не понимаю зачем хранить весь лог операций вечно. Хватит только сумм на конечных адресах.
Установить сервер не вышло, правда пробовал очень давно. Там все далеко не юзерфрендли. А если народ будет юзать в основном публичные серверные части, электрум будет легко вывести из игры.
Ну и возможно полностью веб клиент не имеющий доступа к закрытому ключу был бы также интересен.
Постараюсь точнее описать идею. Допустим нужно совершить транзакцию. Серверная часть генерирует уникальный запрос на совершение операции, клиент генерирует ответ при помощи закрытого ключа. Серевер получает только сгенерированный ответ. Таким образом ключ можно хранить даже на машине без доступа к инету.
Ну и я не понимаю зачем хранить весь лог операций вечно. Хватит только сумм на конечных адресах.
Блоки должны быть на машине с широким каналом, находящейся онлайн 24/7. Т.Е. на сервере. Локальное хранение блоков, это издевательство.
Ключ должен быть на локальной машине.
Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему
ИМХО, по истечению определенного времени стоит удалять историю операций.
Можно например так:
Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька.
Вы только что описали схему работы Electrum.Ключ должен быть на локальной машине.
Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему
ИМХО, по истечению определенного времени стоит удалять историю операций.
Можно например так:
Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька.
Сервер Electrum: Модифицированный сервер bitcoin + abe, занимается помимо основных дел bitcoind, принимает от клиентов их созданные транзакции и отвечает на вопрос - сколько монет на этом адресе и нет ли новых транзакций с ним.
Клиент Electrum: хранит приватные ключи у себя (в дополнение к этому интересный способ их генерации на базе единого числа seed, который может быьт представлен словами, т.е. запомнил 12 слов и все, получил доступ ко всем будущим транзакциям и адресам на своем кошельке), занимается тем что фрмирует транзакции и отсылает на сервер.
Плюс сюда пытаются накрутить модульность, какие то плагины, например для работы с публичными метками адресов (хранятся децентрализовано) и т.п.
Блоки должны быть на машине с широким каналом, находящейся онлайн 24/7. Т.Е. на сервере. Локальное хранение блоков, это издевательство.
Ключ должен быть на локальной машине.
Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему
ИМХО, по истечению определенного времени стоит удалять историю операций.
Можно например так:
Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька.
Ключ должен быть на локальной машине.
Нужно исключить возможность коннекта множества клиентских частей к одной серверной, понятно почему
ИМХО, по истечению определенного времени стоит удалять историю операций.
Можно например так:
Публичный ключ на сервере, закрытый на локальной машине. И генерировать код для каждой операции. + вебморда для кошелька.
Обычному пользователю даже скачивать 2-3гб блоков будет лениво. Он скорее поставит легковесный клиент.
Сама идея интересная (принцип Freenet), но для безопасности лучше хранить 100%.
Сама идея интересная (принцип Freenet), но для безопасности лучше хранить 100%.
Умный математик с самого начало просчитал все так чтоб работало.
Если б можно было "избыточность" сделать меньшей то сделал бы.
Если б можно было "избыточность" сделать меньшей то сделал бы.
а я думаю основная проблема тут в том что сломать систему можно будет взломав лишь часть одинаковых блоков хранящихся лишь у одной четверти пользователей...
короче на взлом системы понадобиться больше 50% от 25% мощностей пользователей, для того чтобы записать в нужную часть блоков фиктивные транзакции.
короче на взлом системы понадобиться больше 50% от 25% мощностей пользователей, для того чтобы записать в нужную часть блоков фиктивные транзакции.
Непомерная избыточность, хранить полную цепь блоков на каждом компьютере. А что, если на каждом ПК хранить не всю цепь, а лишь её треть по принципу дисков в RAID5? Я не силён в жёстких дисках и системах хранения, но на пальцах это будет выглядеть так: Каждый компьютер получает рандомный номер от 0 до 3 и скачивает лишь часть цепочки блоков. Чтоб его данные можно было проверить, данные хранятся с избыточностью по принципу RAID5, где вместо хардов выступают отдельные компьютеры. На каждый компьютер будет скачиваться лишь часть цепочки блоков с избыточностью, а все компьютеры будут синхронизироваться между собой с соседями. Или бред?
1. такой метод подходит ТОЛЬКО для обычных клиентов, но не майнеров (пулов и соло), у которых любая миллисекундная задержка (они будут копиться на каждую транзакцию не загруженную локально) - повышение шанса орфана.2. хранить можно случайные блоки, количеством - доля, обратно пропорциональная количеству клиентов (ну там от логарифма или еще как), готовых технологий миллион, тот же DHT
3. овчинка выделки не стоит
p.s. лучше развивать альтернативные клиенты (отдельно для майнинга отдельно для кошелька), и параллельно решать проблему концентрации мощностей у пулов майнинга...
имел SHA5Sum
Чтобы хакеры вместо SHA1 могли подбирать SHA5Sum, да?
Можно конечено заявить, что фиксирование количества типов узлов K = 4
позволяет проще решить проблему доверия сторонним узлам. Такое заявление следует обосновать.
Я бы даже наоборот расчитывал - чем больше сеть, тем на большее количество кусков можно поделить (при фиксированном заданном времени доступа).
Допустим, нам нужна некоторая вероятность успешного считывания (нахождения заданного количества узлов нужного типа в онлайне), тогда надо:
1) определить это количество узлов (допустим N1)
2) разделить всю цепочку на N1 типов узлов и получить K = Total/N1 кусков (а не 4), здесь Total - общее число блоков
Идея в том, что K может быть гораздо больше 4 и масштабироваться вместе с сетью.
Так же можно учитывать узлы разных видов (используя N1, N2, N3 и т.д. по количеству видов - сервер 7x24, десктоп, мобила)
Можно конечено заявить, что фиксирование количества типов узлов K = 4
позволяет проще решить проблему доверия сторонним узлам. Такое заявление следует обосновать.
Допустим, нам нужна некоторая вероятность успешного считывания (нахождения заданного количества узлов нужного типа в онлайне), тогда надо:
1) определить это количество узлов (допустим N1)
2) разделить всю цепочку на N1 типов узлов и получить K = Total/N1 кусков (а не 4), здесь Total - общее число блоков
Идея в том, что K может быть гораздо больше 4 и масштабироваться вместе с сетью.
Так же можно учитывать узлы разных видов (используя N1, N2, N3 и т.д. по количеству видов - сервер 7x24, десктоп, мобила)
Можно конечено заявить, что фиксирование количества типов узлов K = 4
позволяет проще решить проблему доверия сторонним узлам. Такое заявление следует обосновать.
Непомерная избыточность, хранить полную цепь блоков на каждом компьютере. А что, если на каждом ПК хранить не всю цепь, а лишь её треть по принципу дисков в RAID5? Я не силён в жёстких дисках и системах хранения, но на пальцах это будет выглядеть так: Каждый компьютер получает рандомный номер от 0 до 3 и скачивает лишь часть цепочки блоков. Чтоб его данные можно было проверить, данные хранятся с избыточностью по принципу RAID5, где вместо хардов выступают отдельные компьютеры. На каждый компьютер будет скачиваться лишь часть цепочки блоков с избыточностью, а все компьютеры будут синхронизироваться между собой с соседями. Или бред?
Jump to: