Topic: О "тонких" клиентах (Read 4406 times)

Я предлагаю сделать клиента на этот сервер. Через пару лет будут разные скины, модули и т.д... Только не C++

А если команды "домашнему" кошельку слать через xmpp? Защита по jid получается. На крайний случай к некоторым командам можно пароль прикрутить.

В публичной альфе есть еще http://safeb.it/ - без всякого сервера, просто приложение для хрома, незнаю, работает ли он вообще.
А вообще, как многие уже тут высказались, было бы интереснее сделать на джаваскрипте генерацию ключей и подписку транзакций, а на сервер возложить лишь работу по распространению этих транзакций, вот это было бы круто.

Хоть с локального диска. В идеале - с микровебсервера, встроенного в узловое ПО, тогда не надо будет заморачиваться с обновлениями клиентской части.

Я что-то не понимаю проблему.
Откуда тонкий клиент будет брать все необходимые для работы js-ки?

Видел.

Обязательно посмотри это http://bitcoinjs.org/

А вот и не подеретесь! Больше клиентов хороших и разных!

Вот ещё - примочки на ведроид ставить... Обычной браузерной технологии, как я вижу, так и нету...

Для ЭТОГО случая я уже сказал.. Electrum готовое решение, работает на python, запускается и на Android (а это железо от 100$ с экраном), хотя да его нужно причесать, инсталятор под Android, и по мелочи...

Кажется, я понял, в чём мы друг друга не понимаем.
Вы рассматриваете ситуацию, когда "участников проекта" будет более одного-двух.
Я же говорю об обычном, "домашнем" кошельке, которым можно безопасно управлять с мобильного устройства или через интернет из любого места планеты без необходимости ставить на используемую технику какие-либо приложения. В этом случае мне спокойнее, когда ключи лежат у меня дома, а не таскаются со мной по всем буеракам.

Это настолько фигня мелкая, что недостойна даже упоминания. Питон сейчас можно запустить почти на всем что питается электричеством... если не понятно, даже на 8-битных avr-ках запускают (понятно что именно это извращение но как пример). Не нравится python, возьмите реализацию из клиента на C++, будет быстро и компактно.

С фига ли повесится? Всего то подписать транзакцию своим ключом, к тому же на это можно и время потратить, секунды - не проблема (конечно если у вас проект, который в секунду десятки исходящих транзакций требует - вы можете подумать о чем то более производительном)

Значит не понял!

С какой целью есть необходимость разделить сервис на две части? В обычной ситуации, если клиент bitcoin с кошельком сервиса размещен там же где и основной сервер, то доступ нему открыт всем участникам это проекта (разработчикам, администраторам, хостеру, ... хакерам, взламывающим сервис). После очень ярких примеров только очень глупый будет складывать такие яйца в одну корзину.

Лучше разделить весь сервис на две составляющие:
1. Обычная серверная - обрабатывает всю логику, интерфейс пользователя (веб) и т.п. - тяжелый, требует ресурсы и много кода, тут запущен и обычный bitcoind исключительно для анализа входящих транзакций.
2. Небольшая, секретная, управляющая исходящими транзакциями.

Между этими частями нужна связь, ведь 'секретный' модуль как то должен узнавать, какие транзакции нужно создать. Если сделать тупую отсылку, пусть даже и по защищенному протоколу, команд, то получивший доступ к серверу легко сможет их подделать (проанализировав код и вызвав нужные функции со своими данными).
Идеальной защиты не существует, но можно очень усложнить вору задачу, если вместе с отсылкой сырых команд на создание транзакций, отсылать еще и часть базы главного сервера (а лучше всю, ее вообще неплохо бы реплицировать куда-нибудь), а эта 'секретная' программа должна проанализировать базу и транзакцию с таким условием, чтобы обнаружить аномальные отклонения от обычного и при обнаружении опасности придержать транзакацию 'до выяснения'.

Главный се6рвер может даже не иметь возможности переслать любые деньги на адрес, пусть он оперирует терминами своего сервиса - 'вывести с депозита пользователя XXX сумму YYY' и уже злоумышленник не сможет украсть все средства сервиса одной транзакцией.

Внезапные увеличения перемещений денежной массы, несовпадения 'дебита с кредитом', все это нужно анализировать, контролировать и дважды проверять.. ведь это не банковские транзакции, которые можно 'откатить в течении месяца', если отослал монеты - то это на всегда.

А сам интерпретатор питона сколько весит?

... и написать на JavaScript... Бедный браузер на слабеньком мобильном процессоре, он же повесится!

Обычный кошелёк на сервере. Под логином и паролем, которые передаются по защищённому каналу (HTTPS). Чем плохо?

При правильно настроенном кешировании скриптов это не-очень-то и важно...

O_o
electrum\lib\wallet.py ~ 40кб (и там мне кажется много лишнего)
И не нужно хранить и проверять базу blockchain

В крайнем случае формирование транзакции можно взять из любых других альтернативных клиентов, может быть отдельно кто уже писал в виде утилиты. да хотя бы выцепить из C++ кода bitcoin.

Львиная доля кодинга в таком клиенте - это алгоритм выяснения, нужно ли действительно генерировать транзакцию (вы ведь должны какой то механизм предусмотреть, иначе если напрямую слать команды от веб-сервера на ваш секретный сервер, то ничем это не будет отличаться от 'обычный кошелек на сервере', просто взломщику придется чуть подольше покопаться с вашим кодом), - это всякие проверки на взломы, контроль итогового баланса, аномальные транзакции и т.п.

Тогда этот клиент получается не очень-то и "тонким"...

В идеалогии https://en.bitcoin.it/wiki/Thin_Client_Security это не так.

Клиент Electrum сообщает серверу только об адресах кошелька (только публичные ключи) а приватные остаются на клиенте. Сервер, благодаря адресам знает когда клиенту нужно будет ответить что приехала транзакция (там обычные push запросы от клиента). Зато Когда нужно создать транзакцию, клиент ее создает и подписывает своим приватным ключом, и уже эта подписанная транзакция отсылается серверу (для этого на стороне сервера стоит пропатченный bitcoin клиент с добавленной командой importtransaction).
p.s. мне правда непонятно зачем там реализован механизм генерации адресов на основе seed, защищенности это не добавляет, удобство сомнительно, но его можно отключить а адреса импортировать из офф клиента.

Благодаря этому патчу bitcoin от electrum при большом количестве можно спокойно держать на сервере клиент bitcoin с пустым кошельком (благо уже можно довольствоваться одним клиентом чтобы быстро анализировать любые адреса на приход транзакций, правда пока только после их помещения в блоки и самостоятельно эти транзакции анализировать), а на гораздо более защищенной машине (пусть даже на своем сотовом или специально выделенном для этого планшетнике/роутере/rasberry pi/сервер в ethernet коннекторе) держать простенький модуль подписывания исходящих транзакций.

GLBSE сделали JavaScript клиент, чтобы подписывание было на клиенте, а не на сервере.

Чтобы сервер подписал транзакцию, ему один чёрт нужны ключи, и их тогда придётся передавать по сети...

Мне было был интереснее клиент у которого резделение бы шло по принципу electrium, данные на стороне сервера, секретная часть на стороне клиента, и две главные функции обмена сообщениями get_balans и send_tx.
Душа спокойнее когда ключи у меня.

Ну и ваше решение я так понимаю тоже опирается на серверную часть, логично если оно будет основано на оригинальном клиенте (Electrum патчит bitcoin чтобы он принимал 'не свои' транзакции и использует ABE... но последний только потому что нужного функционала по анализу не своих транзакций попросту не было).

Пишите, не останавливайтесь, не бойтесь публиковать свои наработки. Любое развитие проекту bitcoin в целом - польза. Не нужно бояться эксперементировать, самое полезное останется, будет поглощено, использовано и улучшено.

Электрум всё равно опирается на сервер. И у него свой вариант RPC зачем-то. И опять питон...

Скажем так: я всё это замутил с некоторым прицелом на будущее. На какое - пока не скажу.
Интересно мне было одно: такие решения кому-нибудь интересны или можно спокойно отправлять его в долгий ящик?

О монструозности.

Лучше развивать идеологию https://en.bitcoin.it/wiki/Thin_Client_Security например ее использует клиент https://en.bitcoin.it/wiki/Electrum питон, можно запустить под android
И если уж переделывать протокол под web-oriented то именно его.

Монструозностью. В идеале всю эту конструкцию должен обслуживать маленький встроенный веб-сервер узлового ПО биткойна. Без всяких похапе, питонов и рерайтов.
Обычному человеку нужна небольшая софтинка, которая будет стоять у него дома и тихо шуршать в углу, а в магазин он пойдёт со смартфоном или планшетом. Ему не нужен апач и пляски с бубном вокруг него.
И специальную примочку для ведроида или айоса тоже ставить не надо в таком случае - сгодится стандартный браузер.

а чем напрягают? В случае апача - обычный прокси. Питон не смотрел, но по смыслу тоже.

Я в курсе, что такое BDB, пользовался (причём как программист).
А вот в курсе ли вы, как организован этот самый steam, как реализована масштабируемость и балансировка нагрузки между серверами БД в этом проекте? На "голом" BDB этого явно не сделать, он только на обычных файлах работает. Следовательно, разработчики написали некий программный продукт поверх BDB, он-то и даёт все эти преимущества.
Фактически всё это похоже, например, на mongodb. Лёгкий nosql-движок "в фундаменте", а над ним - система распределения нагрузки и обработки транзакций. Я готов поверить, что разработчикам steam чем-то не угодил mongo, вот они и применили BDB с нахлобучкой для масштабирования. Верю, что нахлобучку эту они написали хорошо и красиво.
Но хочу обратить ваше внимание на то, что в биткойне BDB намертво впилен в код, и никакую нахлобучку для облегчения масштабирования над ним уже не напишешь. Без полной переборки кода биткойна, ессно...
Примерно с тем же успехом можно было использовать и sqlite, хотя я согласен, что BDB в этой "весовой категории" всё же быстрее.

Вот вебсервер на питоне и апач меня и напрягают...

p.s. Ничего не имею против утверждения о плохой работе текущего клиента...

Смотреть клиенты bitcoin тут https://en.bitcoin.it/wiki/Software

Радоваться этому https://en.bitcoin.it/wiki/Bitcoin-js-remote - A user interface for Bitcoin written in JavaScript.
Вместе с ним идет мини RPC-веб-сервер на питоне с поддержкой SSL
Так же предлагается документация по настройке RPC-прокси штатными средствами вебсервера Apache

Как пример вашей неправоты - Steam использует BerkeleyDB и обрабатывает миллионы ACID-транзакций в день. Это ОЧЕНЬ быстрый движок, на самом деле, и не надо смотреть на то как он используется в bitcoin-клиенте. Это, скажем так, далеко не эталон.

Советую почитать
http://itc.ua/articles/nevidimka_berkeley_db_25938/

Я говорю о "персональных" мордах, а не общесетевых.

Что касается движков - я ничего не имею против берклеевского, когда речь идёт об одном небольшом сервере. Но этот движок весьма слабо масштабируется. Потому для крупных узлов хочется чего-нибудь sql-ного вроде mysql или даже nosql-ного вроде mongodb. Но без костылей (или полного рефакторинга кода) нынче этого не добиться.
Опять же - прямо таки напрашивается фича работы с сетью I2P. И написал бы, да встроить некуда - весь движок стандартного биткойна строго заточен под ipv4. Опять костыли, опять ручками туннели настраивать...
Почему я и говорю - проще с нуля сделать, с учётом всех найденных на данный момент граблей.

У BlockChain есть клиент Bitcoin на JavaScript.

Насчет остального... Может оно и так, но сейчас реализован принцип разумной достаточности. Комьюнити разработчиков не очень большое, и так проще вылавливать баги. Хотя, конечно, то как TOR и прочее прикручивают костылями, это нехорошо. Ну а движки БД... Как ни странно, лучше BDB для подобных целей ничего не придумано.

Хорошо, назовём это RPC-мордой. В любом случае я пока не видел подобных морд.

Что касается узлового ПО биткойна - его вообще следовало бы полностью переработать. Отделить и абстрагировать всю криптографию, реализовать модульность для работы с различными движками хранения данных (не только BDB, но и sqlite, mysql, mongodb и т.п.), различными сетевыми движками (не только ipv4, но и i2p, ipv6 и т.д.), полностью отделить UI от криптографического ядра (и сделать его модульным) и т.п.
Тут, как в том старом анекдоте: всю систему менять надо.

RPC-морда и клиент - это не одно и то же. 

P.S. патчить RPC-сервер биткоина не некошерно, а наоборот, очень даже кошерно. Он давно застрял на уровне курсовой работы, ибо один блокируемый тред.

Взрустнулось мне, решил потрясти стариной, покодить чуток.
Посмотрел на спецификацию RPC и подумал: почему бы не сделать клиент вообще на голом яваскрипте? Браузерный то есть.
В процессе исследования и набрасывания скелета примочки понял, что совсем уж голый сделать нельзя: мешает same origin policy в браузерах. Патчить bitcoin ради поддержки CORS мне показалось некошерным.
Выход нашёлся самый простой: прокси-скрипт, транслирующий HTTP в достаточном объёме на порт биткойновского RPC. Этот скриптик у меня написан на PHP, но вместо него можно использовать и другие средства (для встроенных веб-серверов и т.п. использование PHP опять же некошерно).
В результате нескольких часов исследования и кодинга у меня получилась заготовка для "тонкого" клиента на базе jquery. Пока что она может только принять логин и пароль да отобразить getinfo. Всё общение с биткойном осуществляет через стандартный RPC.
Таким образом, работоспособность концепта проверена.
Собственно, вопрос, кому-нибудь интересно превращение этой заготовки в полноценный "тонкий" клиент?