А сам интерпретатор питона сколько весит?
Это настолько фигня мелкая, что недостойна даже упоминания. Питон сейчас можно запустить почти на всем что питается электричеством... если не понятно, даже на 8-битных avr-ках
запускают (понятно что именно это извращение но как пример). Не нравится python, возьмите реализацию из клиента на C++, будет быстро и компактно.
В крайнем случае формирование транзакции можно взять из любых других альтернативных клиентов, может быть отдельно кто уже писал в виде утилиты. да хотя бы выцепить из C++ кода bitcoin.
... и написать на JavaScript... Бедный браузер на слабеньком мобильном процессоре, он же повесится!
С фига ли повесится? Всего то подписать транзакцию своим ключом, к тому же на это можно и время потратить, секунды - не проблема (конечно если у вас проект, который в секунду десятки исходящих транзакций требует - вы можете подумать о чем то более производительном)
Львиная доля кодинга в таком клиенте - это алгоритм выяснения, нужно ли действительно генерировать транзакцию (вы ведь должны какой то механизм предусмотреть, иначе если напрямую слать команды от веб-сервера на ваш секретный сервер, то ничем это не будет отличаться от 'обычный кошелек на сервере', просто взломщику придется чуть подольше покопаться с вашим кодом), - это всякие проверки на взломы, контроль итогового баланса, аномальные транзакции и т.п.
Обычный кошелёк на сервере. Под логином и паролем, которые передаются по защищённому каналу (HTTPS). Чем плохо?
Значит не понял!
С какой целью есть необходимость разделить сервис на две части? В обычной ситуации, если клиент bitcoin с кошельком сервиса размещен там же где и основной сервер, то
доступ нему открыт всем участникам это проекта (разработчикам, администраторам, хостеру, ... хакерам, взламывающим сервис). После очень ярких примеров только очень глупый будет складывать такие яйца в одну корзину.
Лучше разделить весь сервис на две составляющие:
1. Обычная серверная - обрабатывает всю логику, интерфейс пользователя (веб) и т.п. - тяжелый, требует ресурсы и много кода, тут запущен и обычный bitcoind исключительно для анализа входящих транзакций.
2. Небольшая, секретная, управляющая исходящими транзакциями.
Между этими частями нужна связь, ведь 'секретный' модуль как то должен узнавать, какие транзакции нужно создать. Если сделать тупую отсылку, пусть даже и по защищенному протоколу, команд, то получивший доступ к серверу легко сможет их подделать (проанализировав код и вызвав нужные функции со своими данными).
Идеальной защиты не существует, но можно очень усложнить вору задачу, если вместе с отсылкой сырых команд на создание транзакций, отсылать еще и часть базы главного сервера (а лучше всю, ее вообще неплохо бы реплицировать куда-нибудь), а эта 'секретная' программа должна проанализировать базу и транзакцию с таким условием, чтобы обнаружить аномальные отклонения от обычного и при обнаружении опасности придержать транзакацию 'до выяснения'.
Главный се6рвер может даже не иметь возможности переслать любые деньги на адрес, пусть он оперирует терминами своего сервиса - 'вывести с депозита пользователя XXX сумму YYY' и уже злоумышленник не сможет украсть все средства сервиса одной транзакцией.
Внезапные увеличения перемещений денежной массы, несовпадения 'дебита с кредитом', все это нужно анализировать, контролировать и дважды проверять.. ведь это не банковские транзакции, которые можно 'откатить в течении месяца', если отослал монеты - то это на всегда.