Хорошо, это звучит здорово! Вне работы интерес / команда действительно может помочь мотивировать меня, чтобы это сделать. Так вот сделка, приставать мне об этом, и я буду пытаться доставить. Я делаю лучше всего под давлением, поэтому позволяет установить целевой срок для начальной способности говорить 1 месяц.

Позвольте мне привести некоторые из моих дизайнерских идей, чтобы получить обратную связь. Я мог бы начать с TOR или I2P, но если все узлы не работают для получения прибыли вы будете иметь некоторые основные проблемы с производительностью. Кроме того, я думаю, TOR и I2P оба имеют некоторые положительные аспекты дизайна. В конце концов, я думаю, что это будет быстрее создать TOR, как систему, а не интеграции с ТЗ.

1) Это будет UDP на основе, чтобы обеспечить легкий обход брандмауэров и включить «потоковый» данные, которые не требуют порядка.
2) Он будет использовать протокол UDT, чтобы включить потоковую передачу данных TCP более UDP
3) Каждый узел будет иметь 2048 открытый ключ, который будет идентифицировать узел.
4) Открытый ключ используется для предотвращения человек-в-середине и вести переговоры BlowFish ключ.
      - Иглобрюхий ключ используется, потому что это «быстрое» и достаточно безопасно, и мы хотим
        минимизировать время задержки в сети.
5) версия 1 будет реализовать простой HTTP прокси-интерфейс на стороне клиента, что позволит
    любой браузер для подключения. Более поздние версии будут использовать SOCKS.
6) на «стороне выхода» каждый узел может либо создать свой собственный HTTP прокси-сервер, что все соединения TCP «выхода» будут подключаться.

Как вы платите за обслуживание:
1) Сначала я создал Bitcoin банка, который будет выдавать анонимные ослепленные маркера кэша (открытые транзакции), клиент позволит внести Bitcoin и снимать денежные жетоны. Эти жетоны будет небольшой номинал, может быть 1uBTC. Вы также можете внести денежные жетоны и вывести на Btc адрес.
2) Этот Bitcoin банк также проведет публичную базу данных всех известных узлов в системе вместе с их IP / открытым ключом. Эта база данных будет использоваться клиентом для планирования маршрутов.
3) Узлы и клиенты будут чередоваться быть «кредитором» таким образом, что первоначально клиент будет депонировать 1uBTC и имеет право на 1 единицу передачи данных. Клиент будет разрешен до 2-х единиц передач данных перед тем, как отрезать с балансом -1 uBTC. Чтобы продолжить клиент затем осаждаться 2uBTC. Это назад / вперед обмен должен привести к «среднему балансу на тесной связи», чтобы быть 0 и должен поощрять «долгоживущие» соединение (10 минут или около того), которые должны иметь лишь небольшой процент под / над оплатой.   
       
При открытии соединения вы планируете маршрут через N узлов и постепенно строить из канала. Как вы это сделаете вы вносите 54uBTC на каждом узле и кредитуются с фиксированным количеством данных. После того, как клиент будет автоматически депонировать больше как ваш баланс иссякает.   

Теперь, если вы оставите свой узел в сети все время, вы будете зарабатывать больше, чем BTC вы используете, и вы можете иметь «быстрый» и «свободный» опыт. Если вам нужно загрузить много данных, то вы можете внести BTC. Теоретически, цена, которую вы платите за услуги должна подходить к стоимости пропускной способности, используемой. Высокоскоростные узлы могут взимать больше, чем DSL узлов.   

Первоначально там будет только один «банк», но это может быть легко децентрализовано.

Альтернативная система «микроплатежи» будет иметь узлы вычислить «доказательство работы» в стороне горного бассейна. К сожалению, эта система создает задержку и, вероятно, потребует конечных пользователей, чтобы иметь ASIC генерировать достаточное значение, чтобы заплатить за их использование полосы пропускания в реальном масштабе времени.