Bitcoin api not dependant on a running bitcoin daemon? - php

I'm trying to get a bitcoin-centric website going, and I need to be able to perform the following actions without having a bitcoin daemon running on any server due to limitations in place by my host:
Create a new bitcoin address (getnewaddress($account))
Receive coins at that address; determine how much was received (getreceivedbyaccount($account, $minconf=1))
Send coins to an address (sendfrom($fromaccount, $tobitcoinaddress, $amount, $minconf=1, $comment="", $comment-to=""))
These are all functions that exist within the existing json-rpc php client, but all of which depend on a running bitcoin daemon on a server.
I did read through the "lazy api" stuff as well, but I would rather not depend on another service to get the block data or send the bitcoins.
tl;dr: I need a version of the bitcoin php api which does not need the daemon running, with at a bare minimum the functions described above.

At present, no such function exists. I've heard talk of bitcoind being ported to native PHP or a Java applet that can run in the browser, but there is no bitcoin without a daemon somewhere - although you could probably manage those basic functions with the MtGox Merchant API.
Alternately, if you have a reliable enough setup at home you could dedicate a rig to bitcoind and forward the appropriate port in your router settings. The only reason you can't usually host sites on your residential internet is that ISPs block port 80; they don't block 8337 (and if they do it's configurable anyway). The PHP API should be capable of connecting to bitcoind just the same across the 'net as if it's on the same box.

Blockchain.info provides a Bitcoind JSON rpc compatible api.
http://blockchain.info/api/json_rpc_api

TL;DR;: not running some sort of Bitcoin client and not trusting a third party will not be possible.
While it is possible to trust a third party to tell you the balance of an account you would have to trust the third party to handle the private keys needed to sign transactions as soon as you use either getnewaddress or sendfrom, which is probably not what you want to do.
As far as I see it a possible minimal solution would be to use a third party, such as http://blockchain.info, to keep track of the balances (read the spendable outputs you can claim when sending a transaction), and use a notification service to tell you about incoming transactions (some are listed as alternatives here https://en.bitcoin.it/wiki/BitcoinNotify).
Now to be able to receive transactions all you need is to create a new address to show the users on your website. It should not be difficult to create such an address in PHP, just take a look at the wiki.
Now for the sending part, that's going to be quite a lot more difficult, as it involves:
gathering outputs;
claiming them by providing matching signatures;
creating new outputs to the desired addresses;
combining everything in a transaction and serializing it to the P2P protocol specifications;
connecting to the P2P network and sending the transaction to the peers.
So as you can see it gets complicated quickly as you try to send out transactions. If sending transactions is not absolutely required I'd suggest to just provide the server with a list of addresses to which it can receive transactions BitAddress allows you to create private key / address pairs just for this purpose.

If you want to only generate bitcoin address and private key, give a try to:
https://github.com/zamgo/PHPCoinAddress
And maybe we can build a script only to find 20 bitcoin peer nodes to broadcast our transaction.
from bitseed.xf2.org or hard coded peer list in chainparams.cpp source code:
https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

At best you will need an API from a service provider that allows wallet creation and transaction queries.
As you're looking for: create, send, receive - this means that you will need a service that is hosting this already:
Coinkite may be a good option as the majority of bitcoin operations can be done with the API:
Send and request bitcoin by email, sms or bitcoin address
Generate public keys (HD)
Check balances and receive notifications
Safely store bitcoin in the HSM or Multi-signature accounts
Create vouchers and paper wallets (with private key published)
Create P2SH payment addresses, withdraw via M-of-N multisig.
Import and sweep private keys
https://coinkite.com/faq/developers

You can use Open Source GoUrl.io Bitcoin-PHP Payment library -
https://github.com/cryptoapi/Payment-Gateway
<?
require_once( "cryptobox.class.php" );
$options = array(
"private_key" => "", // private key from gourl.io
"orderID" => "your_product1_or_signuppage1_etc",
"amountUSD" => 2 // 2 USD
);
// Initialise Payment Class
$box1 = new Cryptobox ($options);
// Display Payment Box or successful payment result
$paymentbox = $box1->display_cryptobox();
// A. Process Received Payment
if ($box1->is_paid())
{
// Your code here to handle a successful cryptocoin payment
// ...
}
else $message .= "The payment has not been made yet";
?>
<!DOCTYPE html>
<html><head></head>
<body>
<?= $paymentbox ?>
<?= $message ?>
</body>
</html>

Related

Poloniex push api

I am interested in writing some basic php to interface with the Poloniex push api.
Their website provides the following info:
https://poloniex.com/support/api/
A php wrapper can be found here:
http://pastebin.com/iuezwGRZ
From what i can determine there are three APIs being push, public and trading. The public and trading APIs provide functions that can be passed parameters etc. The push api stumps me totally as i cannot determine how it works.
The first link above states the API pushes live data and different feeds can be subscribed to.
My questions are:
A) How can php receive a live stream of data?
B) How do i subscribe to a feed?
I may have misunderstood the oush api and my apologies in advance if this is the case.
Edit1:
I believe i need a WAMP client to connect to a WAMP router such as Minion.
https://github.com/Vinelab/minion
Edit2:
Node.js example
http://pastebin.com/dMX7mZE0
The push API is based on Websocket protocol.
Initially you need first to make a connection to the websocket server,
after that you need to register to a data stream (price update stream for example), after that as soon as the server make an update to something (a price ), all connected clients who where previously registred to it will synchronously received the updated price
Finally you got the last price without the need of doublecheck at regular interval if the price has changed

Sending money from address to address on bitcoind with PHP

I'm programming the back-end for an ecommerce solution, Bitcoind API gives me one way of sending money to a bitcoin address: sendfrom <fromaccount> <tobitcoinaddress> <amount>
If I understood well, this will transfer money from one account to an address, but I don't see any way of sending from address to address. I didn't implemented accounts on my backend system, and don't want to do it as it's an aditional layer of complexity that I don't want to deal with right now.
So, I supose this will grab money from whatever address/addresses asociated to the account and send them to the bitcoin address provided. Any way of doing what I want to do?
Check getaccount <bitcoinaddress>: "Returns the account associated with the given address." You give it a bitcoin address, receive the corresponding account, and can then use that account to sendfrom.
However, for security reasons, I advise against sending payments directly from PHP running on a web server. You may want to introduce at least one additional layer of validation before actual payment, and that layer is probably running on a separate machine. For example, have PHP write the payment orders to the database for another application elsewhere to poll and process. Both applications will have access to the database, but no direct link between them; and the PHP side will not (have to) be authorized to access the BTC wallet at all. Also consider using hot and cold wallets.

How can we use Google Play Service for back-end server validation?

I was following these articles: Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implement an In-App Purchase verification system for our Android apps.
I am a bit confused about how this works end-to-end and what we can assume about the generated token from calling GoogleAuthUtil.getToken() with the first email address found--when AccountManager returns more than one account. My questions are as follows:
Should we assume that any e-mail address used by the user to buy our
app will generate the same token (i.e., same user + app ==> same
token)?
If the answer to question 1 is no, is there a way to launch in-app
purchase for a particular account/email?
It looks like Google is picking the first e-mail address returned by
AccountManager for its in-app purchase dialog. Can we assume that
this won't be changed by the user after in-app purchase dialog is
launched? How do we find out if this changed after the in-app
purchase returns?
What should we store in our database to identify this user? Is email
address and/or token allowed? When does the token expire?
The java-client library looks very promising and powerful at first
read. But, a number of things remains confusing. Is there an article
that describes the end-to-end scenario--from an app initiating a
call to a back-end server through launching the in-app purchase
dialog, getting the result and closing with commits on the server?
What articles are the most useful for accomplishing this on Android?
The main issue we are trying to solve is to to get the full picture.
We've gotten the idea that we can avoid requiring userid/password by using the java client features and using tokens. We have registers our project (both the web app and android app on the same project) per the instructions for Google API Console. We have the php java-client for Google Play Service on our back-end server. We got our Android app to generate a token using the first email address and then call the in-app purchase dialog and handle the user response at the end of the dialog. We've got the parts. Now, we need to glue everything together. We are at the point of integrating with the back-end server. E.g., What is Redirect URi supposed to point to in our server? We've got a php url that we do http post messages to for our server app. We've included the code example for Google API client example--with client-id, secret, simple api key, etc. filled in--as an include to our php. But, what should we put in the redirect uri (we are missing a usage instruction for the example code)?
Also, we want to avoid having the e-mail used for the in-app purchase be different from what we log on our server database as the address the user used to buy our app; if the address is the correct thing to track, we want it to be the same as what was used for the purchase. This could be frustrating for our user if we make this mistake and prevent them from the features they paid for. We don't want to make this mistake and need some clarification on how Google Play Service works. If we initiated the server part of the workflow to get app Nonce / Payload / Credentials for the first e-mail address on the Android device, we would want that address to be used throughout the workflow. If the user changed this along the line, we want to be aware of this and gracefully recover. So far the articles have been helpful but incomplete. Any insight/suggestion is appreciated.

Web form autorespond with SMS

I have been asked to design a website for a client but one of the requirements is that there is a form which includes such things as name, email, dob and mobile number once the user submits the form a SMS is automatically sent to the users mobile almost like a autoresponder.
How to achieve this?
This can be done using an external SMS gateway which will not be free, but also not awfully expensive.
However, you say you are not a programmer. For this to be built well and most important of all, safely, it might be a good idea to use the services of one.
If you want to do it yourself, consider using a pre-paid plan with the SMS provider of your choice so you can't be ruined by a bot flooding your form with thousands of requests.
Web sms functionality can be added to any web application or website. As #Pekka said you need to use an external SMS gateway and to connect your application to this SMS Gateway. Most SMS gateways provide external API which can be used to do that. They usually have documentation which you can use to find out how to integrate SMS notification in your PHP code. Unfortunately there are no reliable free sms service provides so you have to pay for this sms service. You can check http://www.phpjabbers.com/web-sms/ which seems to work a lot easy. Their integration code is pretty simple:
<?php
$SMSLIB["phone"] = '44111222333'; // your phone number
$SMSLIB["key"] = 'abcdefghijklmnopqrs'; // your personal API code
include("smslib.php"); // we will provide you with smslib.php file
sendSMS("test message", $SMSLIB["phone"]); // function which sends the message
?>
The easiest way to do this is to send it to their mobile numbers assigned email address (which is different by each carrier) then have it sent like a normal email.
The only issue is you will probably have to have a Dropbox with each carrier then add something to the PHP that changes the email address (ex. $tmobile would be tmomail.net).
More info:
How To Send Email To Any Cell Phone (for Free)
Most of mobile carriers offer free Email To SMS gateways which can be used to forward simple text emails to a mobile phones. And the good news, majority of those gateways are free and available to the general public.

Integrating Fedex into your web application

I realize they have an API but some of
the questions I have wouldn't be
answered by it, and it would be great
to receive feedback from others who
have integrated it before.
I basically am working with a web site where visitors may choose to sell a used item to the site owner.
If the user decides to sell, he can enter in the specifications of the item and be given a quote. Then he'll proceed to enter in his address, which I assume I'll have to verify using the Fedex API before or during the part where it creates a shipping label.
So assuming the address is verified, it looks like the script in the API I have to interact with is /Ship/Ground/Domestic/ShipGroundDomestic.php5 ( since we will not integrate any other type of shipment type yet ).
Is this is the script that actually creates the shipment and charges the account setup, assuming all goes well it returns a xml response with the status?
Since it's SOAP based - I realize there are options for a pdf and png shipping label type, it looks like it generates the label but where is it actually stored, is it just temporary?
In the script it specifies options for a API Key, password, account #, and Meter # - so I would have to actually know the site owners credentials, since it charges for creating shipments/labels I can't use a normal account that doesn't have a CC setup, can I?
I can't actually test anything without contacting them and telling them to make my account go into test mode? Or is there an extra parameter for test mode?
I should store all shipments in a local database to pull them up, right? Or should I solely rely on Fedex for storing all the information? If I use a local database I can map shipments to users and use a Fedex provided script to look up the delivery status so I would think I have to do that.
If I were to have a feature that automatically emailed customers with status updates of a delivery, I would have to use some type of cron job to look and see if there were any updates made, I can't do this any other way?
If you are using the the Fedex Web Services API you get a test key by going to https://www.fedex.com/wpor/wpor/editConsult.do
(You may need to be already signed in).
The label it generates it just dumps into the current directory. That is obviously not acceptable for production code, since it does not even generate a unique file name, but the php file is example code. Modify the code they give to do whatever you want with the returned label.
You would want a local database.
Why would you want to send users updates? Is there any reason they cannot just use the tracking number and look it up themselves? I mean it would be possible to call the tracking API periodically and generate emails, but do users really want these emails?

Categories