idea backup

src/assets/protocol_bacteria/idea.txt

@@ -0,0 +1,50 @@
+Bacteria protocol.
+Идея. (abstract)
+Крипто-биржа (API) крипто-систем/монет/валют на фиат/товары/криптовалюта — криптовалюта.
+Частично децентрализованная сеть. Каждый клиент хранит информацию о последних публичных ключах серверов, а так же их репутацию, отзывы, какие криптовалюты поддерживаются и так далее.
+Каждое действие сервера подписывается приватным ключом, и проверяется участниками сети публичным. Так же сервер обязует менять свои ключи каждые 12/24 часов и отсылать на сервера Bootstrap(Далее по тексту - Б.), по типу как в Tox (https://nodes.tox.chat/). Новые ключи подписываются новыми и передаются участникам сети и бутстрап серверам, что тоже клиенты, но при этом ничего кроме поддержанием сети не занимаются. 
+
+P2P сеть меж клиентами — клиенты будут подключаться между собой через UDP транзит кто за NAT, а так же и напрямую. Если они не желают публиковать свои настоящие IP адреса, то они будут иметь возможность публиковать себя в P2P сети через onion зеркала и I2P[SAM/I2CP].
+
+Каждый клиент будет обязан хранить последние 10 хешей серверов, и хранить значения сколько дней подряд он проверял эти хэши. Например:
+X = 9
+Z = ...arr...[10]
+Y = 0 
+Last = timestamp
+First = timestamp
+При условии если клиент видел последние 9 хэшей. То есть все 9 дней видел разные адреса, подряд.
+X = 1
+Z = … arr …[10] = {…};(одна значение)
+…
+Y = 10
+При условии если все 10*10 + 1 дней он видел изменения хэша и хранит только один последний.
+
+Сервера будут обязаны хранить о себе данные в Б. серверах. Все отзывы и оценки серверов будут подписываться клиентами и хранится локально на Б. серверах в PSQL/NoSQL/просто файл с записями.
+Сервер хранит только публичный ключ участников, а так же ключ-пароль (AES/ChaCha20) от файла с форматом what=value;what=value;….. …. для структуры User. То есть пользователя. Восстановление пароля не возможно. Остальные значения виртуальны и не будут иметь значение для злоумышленика. После иницилизации пользователя, до его отключения ключ-пароль должен быть стёрт из оперативной памяти. Хранится должен только shared ключ, что будет меняться каждый раз. (x25519) Клиенты так же будут иметь возможность менять часто свои ключи.
+
+Атака по времени — рандомный usleep.
+
+Клиенты<=>Клиент <=> Сервер <=> Б. <=> Клиенты
+
+При желании скомпрометировать сервер участники сети заметят подмену. И будут обязаны предупредить другие в автоматическом режиме. В клиенте должна будет выйти ошибка, которую надо будет обходить в ручную. Теоретически может быть потеря всех ключей или разовое отключение всех участников.
+
+Ключ-пароль => SHA-256(32 байта, 16 для IV, 16 для ключа) + XOR на дополнительную информацию на этот ключ. 
+
+Клиенты*
+Desktop клиенты. Первое приложение будут терминальным с базовым функционалом, как прототип других клиентов. Так же желательно JS+HTML5 (websocket) клиент для браузера.
+Посредники — боты/CGI сайты будут обязаны предоставить возможность сверять и сами не должны хранить ключей, человек сможет использовать один RSA взамен ed25519/AES/ChaCha20/… Что не совсем безопасно. Либо же посредник обязует гарантировать себя как надежная система. Это уже будет режим без шифрования так такового, сервер будет заниматься шифрованием. Клиент же бота/CGI просто будет им пользоваться.
+
+
+
+ Панический режим*
+В будующем сервера должны будут отслеживать попытки проникновения в них, то есть отслеживтаь попытки отладки программы и предзагрузки библиотек, а так же инжекта. По крайней мере пытаться. В особом случае даже отслеживать новое подключение по TTY/SSH/VNC/… до этого не отключив на время режим владельцем сервера, подписав это сообщение. 
+В паническом режиме все деньги, а сервера будут обязаны хранить реальные адреса кошельков, если клиенты такие предоставляют. И отсылать им. Адреса на выплату будут хранится в открытом виде в БД, просто потому-что не возможно будет расшифровать их достать. Мгновенно всем высылаться у кого баланс подходит для комиссии на их адреса обратно. Так же раз в заданный промежуток времени вплоть до NEVER сервера будут обязаны так же высылать эти деньги обратно. Вместо 0 так же клиент сможет выставить другое минимальное значение, что обязательно должно хранится у него на балансе и ниже этого значения не выводить. В паническом режиме это будет игнорироваться. 
+Даже отключение жёсткого диска в реальном времени и пропажа интернета на период больше N минут — сервер будет обязан делать оффлайн транзакции и ожидать последующего подключения в сеть. Пароли от RPC, а так же как и хост должен удаляться разом в паническом режиме, что бы не возможно было скомпрометировать нахождение реального кошелька. Сервера по возможности должны использовать loop файлы в качестве хранилища с шифрованием LUKS по паролю/ключу.
+
+Сам собственно протокол.
+Минимальный, банальный, примитивный. Кроме как шифрования. Каждые первые 4 байта будут задавать ОПКОД операции. Будут опкоды зарезервированные, для тех же доработок сервера через Lua. А так же опкоды обязательные, что нельзя будет изменить или модифицировать не изменяя Си код. 
+(0xN3 0xN2 0xN1 0xN), например опкод 1 → 0x00 0x00 0x00 0x01. Да первые 4 байта будут пытаться читаться .Возможно, лучше будет сделать вместо 0, тк \0 байт строки… игнорирующий байт, например 0x0E — shift in.
+
+Опкоды, которые стоит зарезервировать - 
+Авторизация/handshake, получения списка кошельков, список обменов. Создать обмен, получить свой адрес+баланс на нём, поиск обмена, запрос чата, запрос торга — иницилизация/отмена/диспут. 
+И так далее.