333.i2p

https://github.com/GOSTSec/gostcoin

Для хэша используется двойной ГОСТ Р 34.11-2012: сначала 80 байт хэшируется 512-битным хэшем, затем полученные 64 байта вновь хэшируются 256-битным хэшем.

Для подписи транзакций используется ГОСТ Р 34.10, в отличие от EcDSA P256 в других койнах.

В настоящий момент работает только через I2P по протоколу SAM с адресами с подписью EdDSA.

Имеются CPU и GPU майнеры:

https://github.com/GOSTSec/ccminer
https://github.com/GOSTSec/cpuminer-x11-gost

Прописал в конфиг строки:

[socksproxy]
enabled = true
address = 127.0.0.1
port = 4447
outproxy = адрес_прокси.i2p
outproxyport = 80

но трафик через прокси не пошёл, а в логе появились строчки:

warn - SOCKS: upstream proxyадрес_прокси.i2p not resolved: Этот хост неизвестен
warn - SOCKS: v5 request failed: 3

Проверил непосредственно сам прокси - он доступен (позже выяснилось, что указанный прокси был http, а не socks, однако резолвится его адрес то всё равно должен был бы, а в логе писало, что хост неизвестен).

Вышел из положения путём прописывания в tunnels.conf отдельного клиентского туннеля до прокси. Чтобы не дергать постоянно настройки браузера, создал файл proxy.pac (прописав в нём правила применения прокси) и подсунул его Файрфоксу.

----------

Прописал в конфиг подписки (каждая подписка с новой строки):

[addressbook]
subscriptions =
адрес_подписки1.i2p,
адрес_подписки2.i2p,
адрес_подписки3.i2p,
...
адрес_подпискиN.i2p

Роутер даже не запустился. Получается, их в одну строчку писать нужно? Но это же очень не удобно.

----------

Отсутствует возможность прописать в конфиге прокси для reseed.urls
Роутер будет подключаться напрямую к reseed-узлам, что в некоторых случаях крайне нежелательно (и явно раскрывает факт использования i2p).

Last edited: Sat, 25 Mar 2017, 06:36pm от anon

Конкретные примеры?

Ну это все сообщения, которые появляются регулярно и НЕ сигнализируют о критических ошибках, не позволяющих продолжать работать роутеру. Например:
warn - Profiling: no profile yet for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
warn - SSU: Missing fragments from 0 to 0 of message 1111111111
warn - SSU: session with 111.111.111.111:11111 was not established after 5 seconds
warn - TunnelMessage: I2NP message size 1078 is not enough
error - Tunnels: Can't select next hop for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
error - Tunnels: Can't create inbound tunnel, no peers available
warn - Tunnels: test of tunnel 1111111111 failed
warn - TunnelMessage: Unexpected fragment 2 instead 1 of message 1111111111, saved
warn - Streaming: Missing messages on sSID=1111111111: from 8 to 12
warn - Streaming: Duplicate message 7 on sSID=1111111111
warn - TunnelMessage: First fragment of message 1111111111 not found, saved
error - ElGamal decrypt hash doesn't match
error - Garlic: Failed to decrypt message
warn - Streaming: Another remote lease has been selected for stream with rSID=1111111111, sSID=2222222222
warn - Streaming: Another outbound tunnel has been selected for stream with sSID=1111111111
warn - SSU: no activity with 111.111.111.111:11111 for 330 seconds
warn - NetDb: destination xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= is requested already
warn - Streaming: packet was not ACKed after 6 attempts, terminate, rSID=1111111111, sSID=2222222222
warn - NetDb: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= was not found on 7 floodfills
warn - SSU: MAC verification failed 52 bytes from 111.111.111.111:11111
warn - Transports: Session to peer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= has not been created in 10 seconds
и т.д.
Их можно из категорий warn и error перенести в info, чтобы не забивали лог, а то он разрастается очень быстро, и в нём много повторяющихся сообщений.

Вопрос, насколько актуально все так детально прорабатывать. Сам этот механизм подписок убогий костыль by design. Может лучше продумать и заимплементить современный addressbook, например, на блокчейне?

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

Last edited: Thu, 23 Mar 2017, 03:41pm от anon

anon wrote:

7. Хотелось бы команду веб-интерфейса перечитать конфиги, без перезагрузки роутера.

+1

anon wrote:

1. В русском readme на гитхабе (github.com/PurpleI2P/i2pd_docs_ru/blob/master/README.md) неверно указана ссылка на образец конфы (github.com/PurpleI2P/i2pd/blob/openssl/docs/i2pd.conf).

Русские доки необходимо дорабатывать со временем. Помощь очень кстати будет.

anon wrote:

4. Хотелось бы иметь различные режимы лога, например: append, rewrite, ограничение по объёму лога. В режиме warn очень много разного текста в логе, может имеет смысл попереносить некоторые некритичные сообщения в категорию info?"

Конкретные примеры?

anon wrote:

5. В логе пишет warn - Addressbook: subscriptions.txt usage is deprecated, use config file instead. Что же тогда использовать, всё в конфиг вносить через запятую? А если подписок очень много?

Да, теперь используем конфиг. Ничего страшного, если подписок много, роутер справится.

anon wrote:

6. Хотелось бы иметь возможность задавать интервал опроса каждой подписки по отдельности. Хотелось бы команду веб-интерфейса обновить подписки принудительно. Желательно отображение в веб-интерфейсе таблицы со списком подписок, статус скачивания успешно-неуспешно, количество скаченных записей, дата-время в UTC последней попытки скачивания для каждой подписки.

Настройка интервала, хорошая идея. Принудительное обновление тоже норм идея.

Вопрос, насколько актуально все так детально прорабатывать. Сам этот механизм подписок убогий костыль by design.

Может лучше продумать и заимплементить современный addressbook, например, на блокчейне?

7 надо сделать - все никак не доберусь до этого

Да, так будет более логично.

А что скажете по пунктам 5,6,7 ?
Если переносить подписки в конфиг, было бы желательно иметь возможность напротив каждой подписки проставить интервал опроса в часах/сутках. Результаты опроса отображать в веб-консоли. Там же кнопка принудительно опросить выбранную подписку или все сразу. В текущей реализации не очень понятно, когда этот опрос производился и насколько успешно, сколько получено новых записей от каждой подписки?

Кнопка "перечитать конфиг" в меню в трее и в веб-консоли также была бы очень кстати.

Last edited: Tue, 21 Mar 2017, 02:32pm от anon

Graceful это ровно 10 минут сейчас. Сделаю чтобы завершался как только исчезнет последний транзитный тоннель.

Да, действительно, сейчас проверил, Graceful shutdown работает. Видимо меня смутило то, что когда выбираешь этот пункт, появляется надпись "SUCCESS: command accepted", через 5 секунд страница обновляется, возвращаясь в меню "Router commands", и ничего не происходит, процесс какое-то время продолжает висеть в оперативке, вебконсоль также работает, хотя транзитных тоннелей нет. Ну я вручную его и прибил. А нужно ждать порядка 5 минут, чтобы он завершился. Возможно стоит написать об этом прямо в вебконсоли.
Система: Windows 7 SP1 x86-64, браузер Firefox.

8. На какой платформе? Только что проверил - все работает.

Небольшой список того, что заметил из особенностей:

1. В русском readme на гитхабе (github.com/PurpleI2P/i2pd_docs_ru/blob/master/README.md) неверно указана ссылка на образец конфы (github.com/PurpleI2P/i2pd/blob/openssl/docs/i2pd.conf).

2. В zip-архив с i2pd.exe желательно сразу положить и все конфиги, чтобы не скачивать их отдельно. При запуске проверять, если конфиги присутствуют в одной папке с exe, то запускаться с этими конфигами в портабельном режиме без дополнительных ключей командной строки.

3. В лог некоторые фразы i2pd пишет на русском. Лучше бы писало всё на английском.

4. Хотелось бы иметь различные режимы лога, например: append, rewrite, ограничение по объёму лога. В режиме warn очень много разного текста в логе, может имеет смысл попереносить некоторые некритичные сообщения в категорию info?

5. В логе пишет warn - Addressbook: subscriptions.txt usage is deprecated, use config file instead. Что же тогда использовать, всё в конфиг вносить через запятую? А если подписок очень много?

6. Хотелось бы иметь возможность задавать интервал опроса каждой подписки по отдельности. Хотелось бы команду веб-интерфейса обновить подписки принудительно. Желательно отображение в веб-интерфейсе таблицы со списком подписок, статус скачивания успешно-неуспешно, количество скаченных записей, дата-время в UTC последней попытки скачивания для каждой подписки.

7. Хотелось бы команду веб-интерфейса перечитать конфиги, без перезагрузки роутера.

8. Не работает режим "Graceful shutdown". А также не работает ни один пункт меню "Router commands".

9. Можно ли задавать outproxy для http-прокси? Предусмотрен ли отдельный https-прокси? Или его функционал уже присутствует в http-прокси? Почему outproxy есть только у socks-прокси?

10. Хотелось бы возможность более точно выставлять ограничения полосы пропускания входящего/исходящего трафика (в т.ч. отдельно по TCP и UDP), а не только классы "P", "O", "X". Например: Inbound TCP = 2048 kbps, Outbound TCP = 4096 kbps, Inbound UDP = 16000 kbps, Outbound UDP = 20000 kbps. Возможность ограничения полосы пропускания для транзитного трафика в процентах или килобитах от общей полосы по каждому виду трафика раздельно.

11. Возможность раздельно задавать порт для TCP и UDP. Если порт выбирается автоматически, сделать опцию конфига, чтобы порты были разные. При автоматическом выборе выбирать из всего диапазона доступных портов или из указанного ограниченного диапазона. Возможность выбирать привязку к конкретному сетевому интерфейсу или определённому ip-адресу раздельно для TCP и UDP.

слово i2pd и слово windows в принципе не могут находиться в одном предложении одновременно.

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

Кстати, насколько чувствительна эта реализация роутера к неточности времени на компьютере? Официальный роутер переставал нормально работать, если расхождение часов компьютера с точным временем было порядка нескольких секунд, если более, то прохождение трафика по тунелям и вовсе практически останавливалось. Что произойдёт, если синхронизировать время при работающем роутере (официальный клиент становился очень быстро неработоспособным в моём случае)? Для чего вообще нужно точное время i2p-роутеру?

.

Last edited: Thu, 25 Jul 2019, 08:24pm от anon

http://git.psi.i2p/r4sas/i2pd