Bitcoin SCI [PHP]: process transactions yourself! (addresses gen, IPN, QR Codes)

[bitfreak!]

This is a little project I've been working on for the last few days. I first came up with this idea here: PHP script to create private key & public address. It was hard to find a decent Elliptic Curve library for PHP but eventually I came across this on a blog: Elliptic Curve PHP-OOP DSA and Diffie-Hellman. The library only came with a set of NIST curves so I had to create a set of SEC curves using the parameters supplied in sec2_final.pdf. Then to convert the keys into bitcoin addresses I basically followed the instructions on this page: Technical background of version 1 Bitcoin addresses. I found that many of these steps had already been coded in PHP: bitcoin-php - Bitcoin utility functions. I did a lot of testing with it and it seems to generate valid bitcoin addresses each time, I even sent coins to one of the addresses generated in PHP and it worked fine. However, I am far from an expert on cryptography so please check the code and let me know if you see any problems. If you have time, take a look at the bitcoin.lib.php file and check the following functions for problems. The mini key functions aren't really used for anything at this point, I just coded them because it seemed like a good idea at the time. getNewPrivKey() getNewKeyPair() getNewKeySet() privKeyToAddress($privKey) privKeyToWIF($privKey) checkMiniKey($miniKey) getNewMiniKey() miniKeyToWIF($miniKey) miniKeyToAddress($miniKey) The other part of this script is the Bitcoin Payment Gateway. Instead of passing the transaction through to a 3rd party for processing, payments are verified simply by using blockexplorer to monitor the status of a payment to a specified address. There's no need to install bitcoind on your server, everything is done in pure PHP. This script essentially enables you to have your own Payment Notification System without the need for a middleman (except blockchain.info/blockexplorer.com), very safe imo, and another amazing feature of bitcoin. This is the description from my website:

The Bitcoin Shopping Cart Interface package is a set of libraries and tools that enable you to process bitcoin transactions with only PHP. You can have your own Instant Payment Notification system without the need for a middleman. If you've been wondering how to handle customer payment since MyBitcoin went down, look no further, because this is the safest solution.

An elliptic curve library written in PHP is used to achieve server side generation of FRESH bitcoin addresses for each customer. The script monitors the status of a payment by making use of the data supplied by blockexplorer.com. As such, there is no need to install a heavy duty service such as bitcoind on your server. The only limitation with this PHP package is that you can't make outgoing payments.

The SCI package comes with a simple example to give you an idea about how to generate new keys and initiate a new payment through the Bitcoin Payment Gateway. This is NOT full shopping cart software, you would typically use this script to offer Bitcoins as one method of payment. Some of the Bitcoin SCI scripts (in the 'sci' folder) need to be modified to work properly on your website.

Info: Bitcoin SCI: process bitcoin transactions with PHP

Download: Bitcoin SCI

Demo: BitShop Integration

[1714031436]

1714031436

[1714031436]

1714031436

[1714031436]

1714031436

[HostFat]

Great!
Do you think that it should be easy to add also the support to blockchain.info API ?

[bitfreak!]

Great!
Do you think that it should be easy to add also the support to blockchain.info API ?

Yah it should be simple. Go ahead and do what you like with it.

[slush]

Don't forget that blockexplorer is technically run by private party and it's closed source. Support for alternative sites would be important for the safety.

I'm looking exactly to this (handling keys in PHP) for writing PHP client for my Stratum project. Maybe you would be interested in writing API for it? It has basically JSON-RPC interface, with some significant benefits over using blockexplorer.

Main benefit is that you can actively subscribe for watching some Bitcoin address and Stratum server will push you notification to given URL when something change, in realtime. With this feature, there's no need for extra buttons like "confirm payment", website can detect incoming transaction by self, providing excellent user experience: Webpage with displayed bitcoin address will have open ajax connection to the website, when website receive notification about new transaction to this particular address, it send that transaction back to webpage over the ajax connection. No polling, no extra buttons, seamless integration...

This is still under development (I'm implementing blockchain handling right now), but will be ready in few days. However one Stratum server is already online, so writing client side is already possible.

[bitfreak!]

Don't forget that blockexplorer is technically run by private party and it's closed source. Support for alternative sites would be important for the safety.

Good point. I'll get around to it when I have more time. Can you recommend some alternative sites?

I'm looking exactly to this (handling keys in PHP) for writing PHP client for my Stratum project. Maybe you would be interested in writing API for it? It has basically JSON-RPC interface, with some significant benefits over using blockexplorer.

That seems like it would be way over my head. Even if I could, I don't really have time to help out. Sorry about that. Seems like a very interesting project though.

With this feature, there's no need for extra buttons like "confirm payment", website can detect incoming transaction by self, providing excellent user experience: Webpage with displayed bitcoin address will have open ajax connection to the website, when website receive notification about new transaction to this particular address, it send that transaction back to webpage over the ajax connection.

Well I was thinking about using AJAX, but I decided not to use any javascript at all so it would be more reliable. With AJAX I could have sent queries to blockexplorer in the background and automated everything. Even if I were to use AJAX, it would be rather pointless to send queries to blockexplorer when the user hasn't even sent the bitcoins; although you could automate it that way. The 'confirm' button simply tells the script that it can start looking for confirmations once the user has sent the payment. It's only one extra button they have to click anyway, and I think it helps to have it there with the cancel button before the confirmation stage.

[slush]

Good point. I'll get around to it when I have more time. Can you recommend some alternative sites?

Yes, I hope that Stratum will be reasonable choice in few days :-).

That seems like it would be way over my head.

Come on, it's not so hard as it looks from reading "formal specification". This is full example of subscribing events (incoming transactions) for any given Bitcoin address (callback will expire in X-Session-Timeout second, whill will be presented in HTTP response, but can be prolonged by another call):

Code:

POST / HTTP/1.1
Host: stratum.bitcoin.cz
Connection: close
Content-Type: application/stratum
Content-Length: 81
X-Callback-Url: http://yourdomain.com/callback.php

{"id": 1, "method": "blockchain.address.subscribe", "params": ["1YourAddress"]}

(Note: there must be newline ("\n") on the end of every JSON command).

Expected response:

Code:

HTTP/1.1 200 OK
Content-Length: 36
X-Session-Timeout: 3600
Server: Stratum/0.1
X-Content-Sha256: fe2a156e058307b4b7782e0b236cbd631c5bce3091f8800f818c91fcb850bfc3
Connection: close
Date: Fri, 06 Jan 2012 12:36:17 GMT
Content-MD5: b0d24c6c203d57e8a998be226a16a3c1
Content-Type: application/stratum
Set-Cookie: STRATUM_SESSION=e6ad15c26f0fe711ba632a7978a3ab30; Path=/

{"error":null,"id":1,"result":true}

After this call, URL http://yourdomain.com/callback.php will be called everytime there will be some event on 1YourAddress.

Doesn't look so difficult, does it? ;-)

EDIT: Added example of response.

[mcorlett]

Good point. I'll get around to it when I have more time. Can you recommend some alternative sites?

Yes, I hope that Stratum will be reasonable choice in few days :-).

That seems like it would be way over my head.

Come on, it's not so hard as it looks from reading "formal specification". This is full example of subscribing events (incoming transactions) for any given Bitcoin address (callback will expire in X-Session-Timeout second, whill will be presented in HTTP response, but can be prolonged by another call):

Code:

POST / HTTP/1.1
Host: stratum.bitcoin.cz
Connection: close
Content-Type: application/stratum
Content-Length: 81
X-Callback-Url: http://yourdomain.com/callback.php

{"id": 1, "method": "blockchain.address.subscribe", "params": ["1YourAddress"]}

(Note: there must be newline ("\n") on the end of every JSON command).

After this call, URL http://yourdomain.com/callback.php will be called everytime there will be some event on 1YourAddress.

Doesn't look so difficult, does it? ;-)

What parameters are sent together with the callback and in what form?

[slush]

What parameters are sent together with the callback and in what form?

Generally: Input addresses, output addresses (where one of output address is subscribed one) and transferred amount. I want to provide information in high level form, so there won't be any advanced parsing necessary. Please note that this particular method isn't implemented yet, I'm working on blockchain indexing right now.

I also added example of expected HTTP response to the subscription call.

[bitfreak!]

Update: I've extended the script so that it will also display addresses as QR Codes (by using the javascript library from ecdsa.org).

It also uses AJAX instead of meta refresh. It may be buggy in some really crap browsers like the PSP browser.

I also updated the OP with a screen and changed the thread title a little bit.

[bitfreak!]

Another important update: I recently noticed that the private key generation wasn't producing valid private keys most of the time. I overlooked this problem because the public keys generated from those private keys seemed to be perfectly valid 100% of the time. It wasn't until I tried to import some of those keys into my StrongCoin eWallet account that I noticed the problem with the private keys (admittedly I should have tried importing the private keys earlier). Since this thread died out relatively quickly I assume not many people actually tested this script or took the time to look over the functions as I asked, otherwise I'm sure someone would have noticed this problem. So I hope it didn't cause anyone to loose any bitcoins, and I'm very sorry if this has caused you any inconveniences. Rest assured the problem appears to be completely fixed now and all private keys generated are valid. I also made a bunch of other small updates to the script if you want to test it out (such as support for blockchain.info). I can only make it better and weed out the bugs if people are willing to try it and provide me with feedback.

[scintill]

Another important update: I recently noticed that the private key generation wasn't producing valid private keys most of the time. I overlooked this problem because the public keys generated from those private keys seemed to be perfectly valid 100% of the time. It wasn't until I tried to import some of those keys into my StrongCoin eWallet account that I noticed the problem with the private keys (admittedly I should have tried importing the private keys earlier). Since this thread died out relatively quickly I assume not many people actually tested this script or took the time to look over the functions as I asked, otherwise I'm sure someone would have noticed this problem. So I hope it didn't cause anyone to loose any bitcoins, and I'm very sorry if this has caused you any inconveniences. Rest assured the problem appears to be completely fixed now and all private keys generated are valid. I also made a bunch of other small updates to the script if you want to test it out (such as support for blockchain.info). I can only make it better and weed out the bugs if people are willing to try it and provide me with feedback.

What was the problem?  How crucial is it to make the private key less than the order of the generator?

[crazy_rabbit]

I just found this, and I'll be sure to look at it in the next week. Sounds great, nice to hear that the problems with Key generation have been solved, but it does raise a question- why not include in the script a function to double check all generated keys to ensure they are valid?

you never know. :-)

[bitfreak!]

What was the problem?  How crucial is it to make the private key less than the order of the generator?

The problem it seems, was rather trivial. The private key hex string needs to be exactly 64 characters long but some of the keys generated were shorter (smaller number). I solved it by left padding the keys with '0' until 64 characters long. It appears my script was generating valid private keys but I wasn't padding the hex string properly when they were too small. The bitcoin address is generated via hashing and so it seems if you don't pad the private key correctly you'll still get a valid looking bitcoin address but the private key you have isn't the right one for that bitcoin address. Adding in that padding causes the hashing algorithm to output a totally different bitcoin address.

[bitfreak!]

Ok folks I just fixed another critical but rather uncommon bug which some times happened when converting private keys to bitcoin addresses. It was somewhat similar to the last bug, some hex values needed to be padded with '0' if less than 64 characters long. I took me a while to even notice this bug so I hope it hasn't affected anyone. I lost a few BTC because of it. 

But I am now fairly certain the address generation and conversion functionality is totally bug free so that's a plus.

[slimofftb]

is there a tutorial for how to set this up???

[bitfreak!]

is there a tutorial for how to set this up???

There isn't at the moment but I plan to make a short video overview/walkthrough soon. It should be released within a few weeks.

[Jouke]

Wow, your bitcoin.lib.php is really usefull and should alomst get a topic for itself!

Thank you very much!

[Jouke]

Wow, your bitcoin.lib.php is really usefull and should alomst get a topic for itself!

Thank you very much!

Again: I really think your bitcoin.lib.php should have a topic on its own as I find it really helpfull. If you ever do, here is a little contribution of my own.

I have added these functions for compressed key handling:

  public static function privKeyToPubCompKey($privKey) {

    $g = SECcurve::generator_secp256k1();

        $privKey = self::decodeHex($privKey);
        $secretG = Point::mul($privKey, $g);

        $xHex = self::encodeHex($secretG->getX());
        $y = $secretG->getY();
        if (bcmod($y,2)){
                $pre = "03";
        } else {
                $pre = "02";
        }

        $xHex = str_pad($xHex, 64, '0', STR_PAD_LEFT);
        return $pre.$xHex;
  }

  public static function privKeyToCompAddress($privKey) {

        $pubKey = self::privKeyToPubCompKey($privKey);
        $pubAdd = self::pubKeyToAddress($pubKey);

        if (self::checkAddress($pubAdd)) {
          return $pubAdd;
        } else {
          return 'invalid pub address';
        }
  }


 public static function privKeyToCompWIF($privKey) {
    return self::hash160ToAddress($privKey, '80',true);
  }

 public static function CompWIFtoPrivKey($WIF) {
        return substr(self::addressToHash160($WIF),0,-2);
  }

And I changed this function:

public static function hash160ToAddress($hash160, $addressversion = BITCOIN_ADDRESS_VERSION,$compressed=false) {
        if($compressed){
                $hash160 = $addressversion . $hash160 . "01";
        }else{
                $hash160 = $addressversion . $hash160;
        }
    $check = @pack("H*", $hash160);
    $check = hash("sha256", hash("sha256", $check, true));
    $check = substr($check, 0, ;
        $hash160 = strtoupper($hash160 . $check);
    return self::encodeBase58($hash160);
  }

[bitfreak!]

Nice work, even though I'm not entirely sure what a compressed key is.

But as I said most of that bitcoin.lib.php file wasn't made by me.

It is a very useful library though with the functions I added to it.

You can create a thread about it if you like, but I don't think it's necessary.

[Jouke]

Compressed keys are used since version 0.6 iirc. They take up less space in the blockchain, but they also require a new wallet input format.

With new clients, when you do a dumpprivkey, you will see that the private WIF won't start with a 5.