О "тонких" клиентах

[m0Ray]

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

[1713571434]

1713571434

[1713571434]

1713571434

[Balthazar]

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

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

[m0Ray]

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

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

[Balthazar]

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

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

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

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

[m0Ray]

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

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

[Balthazar]

Что касается движков - я ничего не имею против берклеевского, когда речь идёт об одном небольшом сервере. Но этот движок весьма слабо масштабируется.

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

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

[rPman]

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

[m0Ray]

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

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

[m0Ray]

Что касается движков - я ничего не имею против берклеевского, когда речь идёт об одном небольшом сервере. Но этот движок весьма слабо масштабируется.

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

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

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

[tenzor]

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

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

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

[m0Ray]

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

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

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

[rPman]

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

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

[m0Ray]

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

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

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

[rPman]

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

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

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

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

[Azrace]

Какие люди

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

[Lis]

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

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

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

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

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

[m0Ray]

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

[ArsenShnurkov]

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

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

[rPman]

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

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

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

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

[m0Ray]

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