Lexiko (OP)
|
|
February 01, 2012, 11:41:10 AM Last edit: February 01, 2012, 01:58:00 PM by Lexiko |
|
Идея заключается в создании клиент-серверного OpenSource инструментария для быстрого и легкого разворачивания организации приема биткоинов на своем сайте (продажа товаров, услуг ...). Главный принцип - независимость от сторонних сервисов (использование сторонних мерчантов нарушает основную идею биткоина) , простота развертывания (с установкой должен справится даже самый далекий человек) , минимум кода на клиентской стороне (простота обслуживания), универсальность ( т.е. код должен легко встраиваться в любой сервис). Вот тут я описывал пример , как при помощи биткоина организовать прием платежей. Не смотря на то что код достаточно прост , все же переделывать его придется каждый раз под новый проект. В любом случае нам не обойтись без серверной стороны, на которой будет хранится наш wallet.dat и работать демон bitcoind. Дак почему бы нам не вынести весь основной код, который будет по сути универсален для всех случаев, на сервер, а легкую часть на клиента. Т.е. выглядеть это будет так же , как и работают все основные мерчанты - на frontend стороне сервиса, будет обычная html кнопка перехода на мерчант-сервер <form> <form method="POST" action="http://our_merchant_server.com/index.php"> <input name="method" type="hidden" value="pay"> <input name="InvId" type="hidden" value="{$InvId}"> <input name="hash" type="hidden" value="{$hash}"> <input name="account" type="hidden" value="{$account}"> <input name="Sum" type="text" > <input type="submit" value="Отправить"> </form>
скрипт выписки счета на клиентской стороне будет выглядеть тоже несложно ( прошу просить за говнокод, но это чисто для наглядности, на самом деле конечно все будет немного развернутей, со всеми требуемыми проверками валидности сделки). <?php //выписка счета if ($action === 'pay') { $sum = $_REQUEST['sum']; $hash = md5(InvId+Account+OutSum+CLIENT_PASS);; $InvId = GetNewInvoice();//добавление записи в базу и возврат номера $smarty->assign('InvId',$InvId); $smarty->assign('hash',$hash); $smarty->assign('account',$account); $smarty->assign('account',$sum); $smarty->display('do_pay_bitcoin.tpl'); break; } //оплата if ($action === 'result') { $InvId = $_REQUEST['InvId']; //извлекаем $InvData = GetInvoiceData($InvId); // //проверям валидность этого калбека через Crc //Выдаем товар } ?>
для оплаты, а также скрипт, который будет выписывать счет и ждать его оплаты, а после оплаты выдавать клиенту купленный товар или услугу. Отличие будет лишь в том, что мерчант будет наш, собственный, и располагаться он будет на нашем же сервере вместе с bitcoind демоном. Серверная часть будет универсальной для всех, и разворачиваться буквально в несколько шагов. Клиент будет отправляться для оплаты нашему мерчант-сервису, который будет выводить адрес для оплаты и ожидать зачисления платежа. После того, как на выделенный клиенту адрес поступят BTC, скрипт сделает разноску и сравнит с требуемой суммой. Если сумма равна требуемой, он успешно отстучится на сторону магазина callback-ом и сообщит о том, что можно клиенту выдать желаемое. Выглядеть будет как-то так: При такой схеме реально получается минимум кода на клиентской стороне , а встраивание будет практически таким же , как и любого мерчанта WebMoney , даже проще. Реализация будет тут достаточно несложная, а пользу такого решения для Bitcoin торговли просто сложно недооценить. Я попробую начать и сделать рабочий прототип. Если есть желание помочь, пусть даже словом или советом, вэлкам! Что вы думаете по этому поводу?
|
|
|
|
pent
|
|
February 01, 2012, 11:57:18 AM |
|
многабукв в схеме. мелких. малопонятно
|
|
|
|
|
ArsenShnurkov
Legendary
Offline
Activity: 1386
Merit: 1000
|
|
February 01, 2012, 12:31:23 PM |
|
Инициативу приветствуем и морально поддерживаем.
|
|
|
|
suppp
|
|
February 01, 2012, 12:35:10 PM |
|
идея правильная, +1 еще можно сделать формат запросов/ответов похожим (или вообще совместимым) на какой-нибудь существующий крупный мерчант, чтобы людям быстрее разобраться
|
|
|
|
Lexiko (OP)
|
|
February 01, 2012, 02:27:12 PM |
|
идея правильная, +1 еще можно сделать формат запросов/ответов похожим (или вообще совместимым) на какой-нибудь существующий крупный мерчант, чтобы людям быстрее разобраться Думаю тут велосипедов изобретать не буду, встраивание будет по типу http://www.robokassa.ru/ru/DemoShop/Demo1.aspx?CodeLang=Php можно даже в виде виджета, который можно будет встроить куда угодно. Кстати реализацию клиентской стороне можно будет элементарно сделать под любой язык , как в той же робокассе Php,AsP,Perl,.Net ... Вот мне просто интересно, неужели ни кто до такого еще не додумался за столько времени. Может я не там смотрел, есть решения вэб-обвязок, но они все же, на мой взгляд, достаточно трудоемки и требуют хотя бы минимальных (а то и достаточно глубоких) знаний и понимания работы сети. А это существенно тормозит процесс создания реального сектора под биткоином.
|
|
|
|
|
Lexiko (OP)
|
|
February 01, 2012, 04:40:37 PM |
|
правда я там ничего подобного не нашел
Я тоже, темболее русскоязычного. Вот весь небогатый выбор Web interfaces for merchants Bitcoin Evolution - Non wallet-based Buy Now button to insert into websites (handles sales tracking; client must be used for actual transaction)Задумка вроде какая-то неплохая , но исполнение конечно хромает. Регистрация кривая, на сайте ошибки, отсутствующие картинки и вообще выглядит заброшенным. Цветовая гамма сайта наводит на стойкие мысли о том, что админ сервиса курит что-то забористое, а это несколько напрягает. Исходного кода понятно нет. Btceconomy - a JavaScript widget listing items for sale Тоже выглядит как однодневка, толкового описания как оно работает не нашел, даже желания зарегистрироваться не появилось. Javascript Bitcoin Converter - currency conversion
этот вообще показывает дефолтную страницу хостинга (одного из самых дешевых к слову). Земля ему пухом. Я так понимаю реализации под разные движки с исходными кодами: Zen Cart Bitcoin Payment Module - a payment module that interacts with bitcoind for the Zen Cart eCommerce shopping chart.Модуль под Zen Cart , последний коммит в августе Karsha Shopping Cart Interface - is a mobile payment-interface which enables its users to accept payments.Так и не дождался от них письма с активацией, но выглядит все тоже уныло. Опять-таки, насколько я понял из описания, система совсем не автономная и не бесплатная. Bitcoin-Cash - an easy to use payment module for xt:CommerceМодуль под xt-commerce , не слышал , чтобы у нас кто-то пользовался этими магазинами. Из всех вот это офигительная штука http://bitcoinjs.org/ ребята написали сервер полностью на nodejs и обвязки под него. Работает все как с внутренним форматом, так и с MongoDb , можно ставить сделать свою ноду и хуки на любые события в сети. Правда RPC протокол у них там несколько свой, с пхп мне не удалось его согласовать, хотя может есть какой-то проксик, я не нашел, да и написать не проблема в принципе. Но опять-таки, простым все это дело назвать сложно, скорей это отличный инструментарий для написания какого-то фреймворка более высокого уровня.
|
|
|
|
N.Z.
|
|
February 01, 2012, 09:29:38 PM |
|
Вообще все здорово. Lexiko, а тебе в голову не приходила идея не только оплаты, но и вывода бтц в каком-либо виде?
|
|
|
|
Lexiko (OP)
|
|
February 01, 2012, 09:55:15 PM |
|
Вообще все здорово. Lexiko, а тебе в голову не приходила идея не только оплаты, но и вывода бтц в каком-либо виде?
Вывод можно сделать легко, и это прекрасно вписывается в вышепредоставленную идею. Можно сделать задание, при накоплении определенной суммы в BTC, автоматом будет выполнен перевод на кошелек mtgox, и создан ордер на продажу по текущему курсу. Ну или через метабанк в WebMoney или другую валюту. В такой ситуации для магазина минимум риска погореть на курсе.
|
|
|
|
N.Z.
|
|
February 01, 2012, 09:59:50 PM |
|
Вообще все здорово. Lexiko, а тебе в голову не приходила идея не только оплаты, но и вывода бтц в каком-либо виде?
Вывод можно сделать легко, и это прекрасно вписывается в вышепредоставленную идею. Можно сделать задание, при накоплении определенной суммы в BTC, автоматом будет выполнен перевод на кошелек mtgox, и создан ордер на продажу по текущему курсу. Ну или через метабанк в WebMoney или другую валюту. В такой ситуации для магазина минимум риска погореть на курсе. Да, именно это я и подразумевал
|
|
|
|
Lexiko (OP)
|
|
February 09, 2012, 04:43:47 AM Last edit: February 12, 2012, 02:53:12 AM by Lexiko |
|
Сообщение утратило актуальность.
|
|
|
|
Lexiko (OP)
|
|
February 12, 2012, 03:25:21 AM |
|
Первый вариант оказался немного не оптимальным, поэтому решил переделать. Немного отошел от первоначальной цели, на самом деле оказалось бесполезным разносить клиентскую и серверную части, как показали опыты все это прекрасно уживается на одном сервере/хостинге , там же , где и расположен основной скрипт магазина/сервиса. Однако логическое разделение на клиентскую и серверную части осталось, однако оно чисто условное и используется исключительно для универсальности и простоты интеграции. Таким образом получился простой, но функциональный скрипт при помощи которого, можно у себя на ресурсе организовать прием btc. Итак, исходники тут: https://github.com/Lexiks/BitServLive-demo с полностью рабочим функционалом тут http://bitpay.tk/bitserv/example(написал простенький скрипт витрины магазина, для демонстрации работы платежных скриптов). http://bitpay.tk/bitserv/server/admin.php?action=show_orders просмотр всех заказов (миниадминка). Описание работы:После выбора товара из списка и количества,покупателя перекидывает на скрипт bitclient.php , которому Post запросом передается ItemNo товара , а также его количество (Count) , через сессию передается UserNo покупателя (если он авторизировался), используя все эти данные создается запись в таблице Orders и управление передается скрипту, принимающему оплату bitserver.php , тут для клиента генеритсяя уникальный Btc адрес (в качестве аккаунта используется md5 от полей Логин+Номер заказа+Хэш , для каждого заказа свой адрес) и выводится диалог для оплаты. После того как клиент оплатил требуемую сумму, он жмет на кнопку "проверить" , запрашивается баланс по его адресу и в случае успеха, клиент перекидывается на страницу, которая сообщает ему, что оплата успешно принята, а также и вызывается CallBack функция CompleteOrder из скрипта result.php , которая извлекает детали заказа и в реале выдает клиенту оплаченое. Интеграция в реальные условия очень простая, разместить в рабочий каталог магазина /server/bitserver.php /client/bitclient.php /client/result.php /common/* в файле config.php поправить параметры доступа к mysql базе и серверу bitcoind . Шаблоны допилить под свои нужды и под свой шаблонизатор, прикрутить авторизацию . В общем работы не больше чем при использовании обычного мерчанта. каталог examples -это как понятно из название примеры использования, debug_func.php - отладочная функция, которая перекидывает из тестового кошелька нужную сумму, в реальных условиях, понятно, не нужна. Автоматическую разноску поступивших платежей сделал пока примитивно http://bitpay.tk/bitserv/server/admin.php?action=cron - выбирает все неоплаченные заказы и по каждому уточняет баланс. Чуть позже переделаю по-человечески, чтобы на таймауты php не нарываться. Про то как настроить bitcoind можно почитать тут https://bitcointalk.org/index.php?topic=62498.0 , также ничего сложного.
|
|
|
|
LZ
Legendary
Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
|
February 12, 2012, 05:35:03 AM |
|
Выглядит весьма симпатично! Хорошая работа!
|
My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
February 12, 2012, 01:46:53 PM |
|
Чуть чуть неправильно сделано идеологически с товаром и его количеством...
Правильнее завести понятие заказ или корзина, в которой любое количество товаров... Плюс сюда хотелось бы минимальную поддержку скидок.. это проще реализовывать просто формулой как опция заказа. Так же должно быть понятие счет... Бизнеслогика такая:
Поиск и выбор товаров -> карзина -> счет покупателю -> ожидание оплаты -> ожидание прихода товара -> доставка покупателю (отлуп к логистам) -> подтверждение приема покупателем (на каждом пункте нужна еще обработка ошибок и отмены)
|
|
|
|
LZ
Legendary
Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
|
February 12, 2012, 02:39:05 PM |
|
Ну, судя по названию темы, это же инструментарий, а не готовый магазин. Готовый магазин нужно лицензировать, а доход вкладывать в сообщество.
|
My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
|
|
|
Lexiko (OP)
|
|
February 12, 2012, 02:56:17 PM |
|
Ну, судя по названию темы, это же инструментарий, а не готовый магазин. Готовый магазин нужно лицензировать, а доход вкладывать в сообщество.
Совершенно верно. Магазин я и не собирался писать и акцентировать на нем внимание, то что в папке examples сделано на скорую руку и содержит самый минимум , исключительно для демонстрации, чтобы понять как можно адаптировать все это под свои нужды. Максимум что туда еще доделаю, это цену товара в у.е. и пересчет по курсу на момент оформления заказа. Остальное , как правило, уже есть в любом движке А по поводу основного инструментария дополнения и примечания принимаются, как всегда, с удовольствием.
|
|
|
|
promankirov
|
|
March 07, 2012, 04:34:06 AM |
|
Мысль.
Что если полностью разделить сайт принимающий биткоины и сервер с биткоин демоном? Примитивный вариант как я его вижу... Относительно сервера с демоном биткоина 1) Имеем сервер на котором крутится демон биткоина 2) Генерируем на нем предварительно несколько тыс. адресов для предоставления их будующим клиентам. 3) Экспортируем эти адреса в таблицу БД 4) НОВОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ суть которого в мониторинге поступающих на кошелек транзакций и мониторинге писем поступающих на некий почтовый адрес/irc Канал - мониторинг транзакций нужен для выполнения SQL запросов (изменение баланса пользователя при поступлении средств) к БД сервера на котором крутим сайт - мониторинг некого почтового адреса/irc Канала нужен для выполнения SQL запросов (изменение баланса пользователя при поступлении запроса на вывод средств) к БД сервера на котором крутим сайт 5) на этом же сервере ведем дубль БД для анализа транзакций
Относительно сервера с сайтом принимающим/отдающим битконы функция сервера с сайтом это отображение баланса пользователя и выполнение определенных действий при запросе пользователя на вывод средств. Под этими определенными действиями понимаю отправление на почтовый ддрес/irc канал соответствующего сообщения которое будет обработано НОВЫМ ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ работающим на сервере с демоном биткоина - сообщения могут шифроваться исключая таким образом возможность их анализа при взломе почтового ящика или просмотре irc канала
Остается только вопрос подделки сообщений при взломе сервера с сайтом. (думаю его тоже можно решить)
По моему так полностью решается задача исключить несанкционированный доступ к файлу кошелька. Ваше мнение?
|
|
|
|
loga
Member
Offline
Activity: 85
Merit: 10
|
|
March 08, 2012, 04:43:23 AM |
|
Что если полностью разделить сайт принимающий биткоины и сервер с биткоин демоном? Можно пойти дальше - разделить сервер с сайтом и сервер принимающий платежи и осуществляющий выполнение услуги, ограничив их общение каким-нибудь своим протоколом, не позволяющим оказывать услуги не приняв плату за них. Т.е. злоумышленник взломав сайт поймет что это просто надстройка над собственным API и для получения денег ломать стоит совсем не этот сервер. Но этот способ, как и описанный выше, имеет один недостаток - нужно два сервера, или как минимум сервер и shared хостинг.
|
12S3cd5Z6XNroAmDg6Zk7CVv8paYEQi2pA
|
|
|
Lexiko (OP)
|
|
March 08, 2012, 11:41:00 AM |
|
promankirov, а смысл так заморачиваться? Я вот в процессе все равно пришел к схеме: все скрипты на стороне магазина, а демон на отдельном сервере, разделив скрипты на серверные и клиентские чисто логически, для облегчения интеграции. Т.е. серверные скрипты они не столько серверные, сколько перманентные для большинства случаев, а клиентские, это изменяемые в зависимости от специфики сервиса. В магазинах вообще нет смысла сильно шифроваться, достаточно все поступившие на кошелек средства, тут же переводить на другой кошелек, спрятанный в надежном месте. Ведь магазин, это не обменник, которому надо постоянно держать в запасе бтц на вывод. Таким образом на демоне будет минимум живых денег.
Как вариант можно использовать вашу идею, но без заморочек с IRC. Т.е. будем иметь базу заранее сгенерированных адресов, которые будем выдавать клиенту для проведения оплаты, а bitcoind будет только проверять поступили ли деньги, но не содержать самих хэшей от этих адресов. Тогда останется лишь с 3-ей стороны подливать периодически новых адресов в базу.
Вот интересно, как при помощи bitcoind проверить поступили ли средства на определенный адрес, не обладая wallett.dat с этим адресом?
|
|
|
|
|