Just a quick post to say that I been AFK for the past week or so, and that development of the service will resume as normal today. I should have the next live update ready to go at some stage this weekend. Thank you to everyone who continues to use this service.

Hmm. Interesting proposal. I'll give this some thought. Thanks for the suggestion!


I think it would be better to just display a usage history in the members area as we discussed earlier. After further thought, I don't think this would be too much of a problem, as anonymous usernames are not a viable means of identification. I will get to work on this.

Also, just want to add that I have made a slight modification to the status page.
It now also shows the total number of available and connected seeds.
More updates to come soon.

I was thinking about doing something like this. It's a good idea, but the reason it is difficult is because torrents are not stored with any identifying information within the database. There is nothing in the code that links the download to your member account. To achieve this, I would have to make extensive changes and label torrents entered into the database with the corresponding username. From the perspective of anonymity, I don't know how happy other users of the site would be about this. I personally don't think it is a big issue, since you always have the option of downloading the file as an unregistered user. Thoughts?

I'll try and think of some way of achieving this or something similar for the next live update of the site. I am also working on several other modifications to the service, so I hope to do another live update this weekend at some stage.

@dancupid: yeah, that is the glitch I was referring to in post #169. It was a small code error that would immediately bring the user to the torrent complete status page under certain circumstances before the file had completely finished downloading. I had this problem originally when I first implemented the javascript refresh script too. I have patched it up now, so it should all be fine.

@terrytibbs: thats a good point you raised about non-starting torrents. It hasn't yet occurred, but it is an exception that I will have to think about handling soon. What I may do is give the user the option to cancel the download on the status page, and then provide a refund account address. Again though, this could lead to people taking the piss. Let a massive torrent get to 99% and then cancel it. It probably wouldn't happen, but you never know.

@molecular: yeah, I'm finding it hard to drag myself away from dreamweaver! Right now, it would take a lot of effort to handle these exceptions automatically with code. I'll work on it, but I think the best stop-gap measure would be to just warn users beforehand to use healthy torrents, and then to advise them to use the contact us page with a link if the download goes so slowly that it will not complete in a reasonable amount of time.

I am actually already using BEncode to obtain the torrent's infohash.

Originally, I tried to obtain seed and peer information about the torrent using the hash and scraping all the info from the list of announce trackers in the file directly, but the requests took too long. Some trackers time out, some are not responsive, and some torrents are actually trackerless, meaning the user would have to wait up to a minute or more on a blank screen while the queries completed, making it unfeasible for smooth, fast usage. So I just pulled all that code, and parsed just the data in the file.

I think the best solution would be to just remind users that poorly seeded torrents may be speed limited due to poor availability, and to ensure that they only use healthy torrents. Then I can easily update the seeds/peers totals on the status page by querying my client without having to go to all that extra hassle. They will then be able to see WHY their torrent is going slow. Not because of the server, but because of the torrent itself. I could create a "health" indicator, and explain on the status page why a certain torrent may download slowly.

The only reason I want to include something like this is because some users may attribute the slowness to the speed of the server, rather than the speed of the torrent, and might not return. If they realize that it is going slowly because of few seeders, they are more likely to return with a better seeded torrent in the future.

I don't think it should be the duty of bitcointorrentz service to check seeds and warn users that a torrent will be slow. I think that duty should probably fall on the user themselves. It's pretty easy to check, it's plain to see on most torrent trackers. Also, it would probably lead to fewer conversions.

Just found a small bug with the ajax refresh script where it would fail to display any of the status information. It's all fixed now, so if anyone noticed anything odd, just want to reiterate that it's all good now.

@BitcoinPorn: You're not an idiot by any means. You are exactly like most of us on this forum. We tend to trivialize and often completely forget laws which we deem archaic and insufficient. But we must remember that the law is the law, and can come down on you pretty hard if you are not extremely cautious.

@terrytibs: hmmmm.... the btjunkie API! I will definitely take a look into it. It would mean than btjunkie MUST remain operational at all times though, as my service would then depend on constant connectivity to btjunkies servers. I have noticed their site go down at times too. Do you know if they count seeders from all trackers, or just seeders on the btjunkie tracker? Also, do they include DHT seeds and peers in their results? Very interesting indeed.

The problem with this is that before payment has been completed, the torrent is not loaded into the torrent client. Therefore, I cannot query the client for the number of seeds. All I can do is parse the torrent file, and display information like size and name, etc. The torrent file itself does not contain the number of seeds or peers.

So I would have to actually load the torrent into the client, start downloading it, and then query the seeds and peers counts. It would need to download for a while to get true seeds and peer figures aswell, because most torrents use multiple trackers which need to be connected to separately, and also the DHT and other p2p protocols that torrent clients use to obtain seeds and peers take a while to reel in the true figures. So the actual query could take several seconds, if not much longer, to actually complete.

If the user decides then not to pay for it, this could lead to problems. There are many who upload torrent files just to see how much it would cost, and then decide not to go ahead. If the server were to load every queried torrent, it would leave the site vulnerable to users loading torrents for the sake of it, wasting a lot of server resources and bandwidth.


Very interesting proposal, but that could lead to the implication of the site in the illegal distribution of copyrighted materials however. Bitcointorrentz does not (officially) permit the use of the service for copyrighted or illegal materials, only legal torrents that are open source or not copyrighted. I'd love to do this, but I think it could be damaging to the site.

I have finished implementing an ajax refresh of the torrent download status page. Now the page will not javascript refresh every 5 seconds until the torrent is complete. I have tested the code locally and have completed some live tests, and everything appears to be working smoothly. I do not anticipate any problems, but if anyone runs into any issues with it please do not hesitate to let me know, either in this thread or through the contact form on the website. If there are any, I will address them immediately.

I may include more information in the torrent status page, like number of seeders, leechers and the availability of the torrent. Some people have uploaded torrents with 1-2 seeders, and do not avail of the full download speed of the server due to the torrent being very unhealthy. I may include advice to use well seeded, healthy torrents to utilize the full capability of the server.

I have also removed the Facebook and Google Plus widgets from the site. They are ugly, take longer to load than the rest of the page, and make the page appear to be wider than it actually is, causing a horizontal scrollbar to appear unnecessarily. Does anyone know how to prevent this?

I have also implemented a site wide global variable that determines the base fee of the service. If prices need to be increased in the future, it can be done easily and quickly by changing a single variable without having to trawl through every bit of code. I am also looking into linking the price to the usd:btc exchange rate. The code required to do this is still in beta, but I hope to have it finished soon.

With regards to advertising on torrent search engines, I will certainly look into it. The only problem is that the service can only be paid for with bitcoin, meaning a large majority of users of those search engines will not be able to avail of the service.

I might include a brief introduction to what bitcoin is, and provide information on where it can be bought etc. This will be especially important if we want to attract users to the service who are not already familiar with bitcoin.

I wasn't in in for the money mate!
Glad you got it all sorted out.

Maybe you are right. I think I might take a day or two off. It's been pretty full-on over the past 2 weeks!
Any suggestions on marketing then? My current strategies:

1. Dailybitcoins.org
2. Operation fabulous
3. Social media: Google+ and Facebook Like
4. Affiliate system
5. Forum whoring

Perhaps a google adwords campaign... but they are pretty expensive.
AND you have to pay in worthless fiat!

Just join btc guild. No consideration required.

It's just another underground forum, the purpose of which is the distribution of illegal goods. There are many others like it. It's only special because it uses bitcoin as the means of payment. So it is much more advanced in that regard.

They also have a hedging feature, so if you want to sell something, and don't want the hassle of shifts in the value of btc:usd exchange, you can hedge your account in USD so if btc price rises, you have less btc but same USD, and likewise, if price reduces, you have more btc but same USD value.

The only reason it is important in providing an economic backdrop for bitcoin is that the majority of legal trade websites are not using bitcoin yet. Once it does, SR's "value" to the bitcoin economy will be much less significant.

BTW, just scanned your avatar with my smartphone and realized your QR code is encoded with the link to your website.
Thats pretty awesome.

To be honest, that code you derived from the example looks really messy and unlikely to work. I think there is something none of us is understanding about soap! LOL. It's probably something to do with formatting the header correctly, which I have no idea how to do. I'm not a coder by trade, just have a lot of experience with PHP.

nhodges code on stackoverflow might work, you could give that a shot.

But if you are still having trouble, take a look at using their REST API instead of their SOAP API. It uses simpler HTTP GET and POST methods, rather than the complicated SOAP protocol. I believe it also encodes responses in JSON format, so that should be familiar to most devs here. I believe it is still sort of in beta though. Their SOAP API is the bigger brother.

Links for more info:
http://www.dwolla.org/d/showthread.php?2-REST-API
http://www.dwolla.org/d/showthread.php?690-Dwolla-GRID-Start-Here-to-Access-the-GRID

Does anyone have any feature requests or feedback on the site so far?
Any and all suggestions will be considered.

Based on current earnings so far of 5.87784 btc in 16 days, and assuming a highly conservative estimate of NO further growth, i.e. earnings continue at the current rate only and do not increase, and assuming prices do not change, this gives us average earnings of 0.367365 btc/day. That is 134 btc in 365 days, and that is approximately 0.134 btc profit / share.

The last share price was 0.85 btc / share on GLBSE. Taking this as the current share price, yearly return on investment at this level is 15.8%.

For those of you who bought up shares during my IPO at 0.2 btc / share, and haven't since sold, your yearly return on investment would be 67%.

Both of these assume ZERO growth in the next 12 months. And they are just estimates, as share price and profits will be quite variable. Share prices because of the nature of publicly traded stock, and profits because of the possibility of future earnings increases / decreases. I have already halfed my prices to grow the business and reach more users. There will be a upwards review within the next 6 months.

I consider my investors to have made a good choice...

It's quite possible. An associative array might do the trick alright.

If you have passed your amount to that script as a string, you can get the float value by using: floatval($amount);
You can have it round to 2 decimal places if you use floatval(round($amount,2));

@nhodges: it doesn't matter what you initialize the variable with. If you initialize it with an integer, the variable will be an integer. If you initialize it with a float, it will be a float variable. So it's not necessarily an integer he has defined. For testing purposes yes, but if he wrote $amount=1.23, it would be initialized as a float.

Here is a chart of my own. The stock price of BitCoinTorrentz on GLBSE: