BitCoinTorrentz.com - Torrent Download Service

[mjcmurfy]

I'd like to be able to just send you a couple of bitcoins, and then wait for it to be used up and then top it up as and when- though you may end up with people using you as a wallet service, or just somewhere to store their bitcoins, which may impact on your security concerns - if you are storing lots of bitcoins in user accounts then perhaps you would become attractive for hackers to attack. As it is now there is nothing to attract any sort of attack.
But it's certainly an addition I'd be interested in if you could show you were secure.

I don't know if I would be happy storing funds for people to be honest, not in a wallet on the server anyway. What I was thinking of doing is creating a "virtual" account on the server that users could load funds to. Payment would sent the same way as currently, to an offline wallet. If you want to withdraw, it wouldn't be an automatic process as I would need to verify and send the payment from my local machine where the coins are being stored. It's not the best way, but I really don't want a bitcoin wallet stored on this server. If it gets hacked, seized, or fails in some way I have no recourse and would be liable for the loss.

In fact, the more I think about it, the more I am reconsidering. I don't know if I am happy storing coins at all, on or offline. It just opens me up to unnecessary risk and makes the accounting a hassle. I like TTBit's suggestion about buying download credit bundles though. That way you can pay for some bandwidth with your couple of bitcoin and use it as you need it, topping up when necessary. And the good part is that I don't have to hold coins for users, bringing extra liability, as they are being paid in exchange for future use of the service so can be considered assets rather than an expense that may have to be paid back at some point. What do you think?

[1714203833]

1714203833

[1714203833]

1714203833

[1714203833]

1714203833

[dancupid]

I'd like to be able to just send you a couple of bitcoins, and then wait for it to be used up and then top it up as and when- though you may end up with people using you as a wallet service, or just somewhere to store their bitcoins, which may impact on your security concerns - if you are storing lots of bitcoins in user accounts then perhaps you would become attractive for hackers to attack. As it is now there is nothing to attract any sort of attack.
But it's certainly an addition I'd be interested in if you could show you were secure.

I don't know if I would be happy storing funds for people to be honest, not in a wallet on the server anyway. What I was thinking of doing is creating a "virtual" account on the server that users could load funds to. Payment would sent the same way as currently, to an offline wallet. If you want to withdraw, it wouldn't be an automatic process as I would need to verify and send the payment from my local machine where the coins are being stored. It's not the best way, but I really don't want a bitcoin wallet stored on this server. If it gets hacked, seized, or fails in some way I have no recourse and would be liable for the loss.

In fact, the more I think about it, the more I am reconsidering. I don't know if I am happy storing coins at all, on or offline. It just opens me up to unnecessary risk and makes the accounting a hassle. I like TTBit's suggestion about buying download credit bundles though. That way you can pay for some bandwidth with your couple of bitcoin and use it as you need it, topping up when necessary. And the good part is that I don't have to hold coins for users, bringing extra liability, as they are being paid in exchange for future use of the service so can be considered assets rather than an expense that may have to be paid back at some point. What do you think?

 
Actually the current model works pretty well and fits the way bitcoin works anyway - the extra bitcoin transaction fee is fairly trivial - perhaps you could just highlight the fact at the point of sale - though anyone using bitcoin now already expects these fees anyway. I doubt there are people using your service who don't expect the normal 0.005btc fee (or whatever it is).
It seems a lot of extra work for you just to save people 0.5p (I remember half pennies from the 80s - I could get a black jack in my 10p mix mag in those days for a ha'penny)
My personal problem with using bitcoin is that I run it within an Ubuntu virtual machine within windows, so sometime I have to wait a minute for it to open before I can pay - but if that's the most secure solution then I have no problem waiting.

[mjcmurfy]

Just thought I'd post a quick update to let people know the status of the next update. I am about 80% done, and the two major changes are the correction of the multiple status pages error, and the implementation of a "download bandwidth" balance, that users can top up with a single payment. Users will still be able to use the existing pay-per-use facility.

Should be ready in the next 24 hours or thereabouts.

[mjcmurfy]

Ok, I have fixed the multiple status error. The site now reliably shows the status of simultaneously downloading torrents.

Members can also purchase bandwidth - just visit the members area, and take a look at the column on the right. Once you have topped up your account with a few GB of bandwidth, subsequent downloads will be deducted from this until you have no prepaid balance left. Once you run out, you will go back to having to pay on each use - until you top up your account again.

You are of course free to continue paying per use if you wish, but pre-paying is much faster than sending individual payments and having to wait for the bitcoin network to confirm the transactions each time. As long as you have enough bandwidth credit, the torrent will start immediately after you click download.

Another advantage of prepaying is that sometimes payments can take longer than 5 minutes, so the more individual transactions that you do, the more likely one of them is going to be delayed - which may result in you losing a few bit cents. Prepay means no waiting, no delays and no dropped payments.

Prepaying for the service also minimizes the cost of transaction fees compared with sending multiple transactions.

If anyone has any feedback on this, don't hesitate to post.

[dancupid]

Ok, I have fixed the multiple status error. The site now reliably shows the status of simultaneously downloading torrents.

Members can also purchase bandwidth - just visit the members area, and take a look at the column on the right. Once you have topped up your account with a few GB of bandwidth, subsequent downloads will be subtracted from this until you have no prepaid balance left. Once you run out, you will go back to having to pay on each use - until you top up your account again.

You are of course free to continue paying per use if you wish, but pre-paying is much faster than sending individual payments and having to wait for the bitcoin network to confirm the transactions each time. As long as you have enough bandwidth credit, the download will start immediately after you click download.

Another advantage of prepaying is that sometimes payments can take longer than 5 minutes, so the more individual transactions that you do, the more likely one of them is going to be delayed - which may result in you losing a few bit cents. Prepay means no waiting, no delays and no dropped payments.

Prepaying for the service also minimizes the cost of transaction fees compared with sending multiple transactions.

If anyone has any feedback on this, don't hesitate to post.

Just tried it for the 10gb bundle - very slick.

One question - how are the discounts calculated for each 20gb - will the bandwidth available adjust itself after each 20gb?
If I were to buy the 50gb bundle now, the price is calculated at my current discount level.

[mjcmurfy]

Glad you like it dan.

With regards to the calculation of discount, it's still the same as before. Discounts do not apply until you actually use the bandwidth though. If you buy 20GB for example, your rate will still be the same as before until you use some of the the bandwidth and push your account over the next discount threshold.

Just purchasing bandwidth does not count as "download" until you use it and your "total usage" figure gets incremented. It is only when you use the bandwidth will your rate will come down for subsequent pay-per-use or bandwidth purchases.

Do you think it would be better to include purchased bandwidth immediately in the the discount calculation?
The maths become a little complicated.

[TTBit]

Ok, I have fixed the multiple status error. The site now reliably shows the status of simultaneously downloading torrents.

Members can also purchase bandwidth - just visit the members area, and take a look at the column on the right. Once you have topped up your account with a few GB of bandwidth, subsequent downloads will be deducted from this until you have no prepaid balance left. Once you run out, you will go back to having to pay on each use - until you top up your account again.

You are of course free to continue paying per use if you wish, but pre-paying is much faster than sending individual payments and having to wait for the bitcoin network to confirm the transactions each time. As long as you have enough bandwidth credit, the torrent will start immediately after you click download.

Another advantage of prepaying is that sometimes payments can take longer than 5 minutes, so the more individual transactions that you do, the more likely one of them is going to be delayed - which may result in you losing a few bit cents. Prepay means no waiting, no delays and no dropped payments.

Prepaying for the service also minimizes the cost of transaction fees compared with sending multiple transactions.

If anyone has any feedback on this, don't hesitate to post.

I have tested both pre-pay and multiple downloads, both work for me. Excellent work.

[molecular]

I'm currently experiencing a problem with a payment not getting accepted. It's to address 13s85qvuAX14Z9ME6mMFF37QVNLr3FXA2f, txid: f419e80bc7dcc85e023f6bd3487d3367b981f9c95cf448bd7651a43a148bd039.

The payment popup is still open and the swirly thingy swirls.

tx now has 2 confirmations

Noteworthy fact: the block the tx finally got in (block 152758, block date: 2011-11-10 22:58:57) took about 30 minutes to be found after I broadcast the tx (2011-11-10 22:28:29). That block was found 42 minutes after the previous one, so I picked a really bad time for a transaction

Now, the fact that the tx wasn't seen directly probably means that the bitcointorrentz bitcoind didn't see the broadcast, right? So it waits for the first block it appears in?

Maybe you have some bitcoind troubles (I myself had some yesterday and the glbse bitcoind also crashed a while ago, for example)

[mjcmurfy]

Hi molecular. I have a payment notification received in the database to that address for 0.1545 btc. Is this your payment Everything seems to be fine with the payment system. I'm not quite sure what happened. Perhaps your connection dropped out temporarily? I will refund the bitcoin if you PM me with your payment address.

[molecular]

Hi molecular. I have a payment notification received in the database to that address for 0.1545 btc. Is this your payment Everything seems to be fine with the payment system. I'm not quite sure what happened. Perhaps your connection dropped out temporarily? I will refund the bitcoin if you PM me with your payment address.

Nope, that's not it, amount doesn't match.

Here's the transaction I initiated:

{
        "account" : "",
        "address" : "13s85qvuAX14Z9ME6mMFF37QVNLr3FXA2f",
        "category" : "send",
        "amount" : -0.01420000,
        "fee" : -0.00050000,
        "confirmations" : 10,
        "txid" : "f419e80bc7dcc85e023f6bd3487d3367b981f9c95cf448bd7651a43a148bd039",
        "time" : 1320964109
    }

The page is still open, here's a screenshot



Are you storing the torrent urls? Dont want to paste the complete link here, but it ends in "1bb4dc5545311d123e84e5800924831/download.torrent".
The md5 of the torrent file is d403a0fb6289969a8ee51dfe9a29258f
Maybe this helps to locate stuff?

[mjcmurfy]

I am using bitcoinnotify, which monitors the blockchain and sends POST notifications to my server. I received an email about 15 minutes ago from them that they are shutting down their service. I guess they have been having some server trouble. This is the email I received:

Any payment service requires a very careful maintenance and we were doing so responsibly over the recent months.

The service has never suffered any hack or a major technical problem, earning the trust of hundreds of users.

However, we can no longer invest resources necessary to ensure perfectly safe and robust payment processing. And we are not the ones to keep a half-ass service online.

We are sorry for a short notice, this was an urgent decision.

They gave no timeframe for when they would case operation, so I sent an email to their CEO. He said that they can not guarantee any specific time period, and to work on the basis that they are shutting down immediately.

I am going to have to run a bitcoin daemon on the server now instead. Can I use the bitcoin API to monitor the blockchain in general with a php cron or would I have to accept payments directly to that client? Need to do some documentation digging. Since I am doing this, I might as well transition to a randomly generated address based approach for payments.

I will probably have to suspend payments for the time being until this is sorted out.
Luckily, anyone who has already payed for bandwidth should not be affected.

[molecular]

I am using bitcoinnotify, which monitors the blockchain and sends POST notifications to my server. I received an email about 15 minutes ago from them that they are shutting down their service. I guess they have been having some server trouble. This is the email I received:

Any payment service requires a very careful maintenance and we were doing so responsibly over the recent months.

The service has never suffered any hack or a major technical problem, earning the trust of hundreds of users.

However, we can no longer invest resources necessary to ensure perfectly safe and robust payment processing. And we are not the ones to keep a half-ass service online.

We are sorry for a short notice, this was an urgent decision.

They gave no timeframe for when they would case operation, so I sent an email to their CEO. He said that they can not guarantee any specific time period, and to work on the basis that they are shutting down immediately.

I am going to have to run a bitcoin daemon on the server now instead. Can I use the bitcoin API to monitor the blockchain in general with a php cron or would I have to accept payments directly to that client? Need to do some documentation digging. Since I am doing this, I might as well transition to a randomly generated address based approach for payments.

I will probably have to suspend payments for the time being until this is sorted out.
Luckily, anyone who has already payed for bandwidth should not be affected.

This explains my payment troubles, of course.

I can envision several options to monitor the blockchain/network for transactions.

• I haven't looked at it, but libbitcoin by genjix of Bitcoin Consultancy sounds cool (a reimplementation of bitcoin functionality as a well-written and -structured library).
  
• Another option might be to poll blockexplorer.com/q/getreceivedbyaddress/<address>, which will of course only work for transactions that are in blocks, so we'd have to wait for a block (very bad in my mind).
• Normal bitcoind can be polled via rpc call "getreceivedbyaddress", of course, but unfortunately, that only works for addresses that are in the local wallet, which you might not want (attackable).
• There are also several python implementations of (parts of) bitcoin, like bitcoin-alt (https://github.com/phantomcircuit/bitcoin-alt)
• I myself use bitcoin-abe, which reflects the blockchain into a sql database. That also doesn't work for 0 confirmation payments, of course.
• ...

So basically, if we want to detect 0 confirmation payments and have the private keys off-server, we'd have to either go with one of the alternative bitcoin implementations or use some service (maybe bit-pay.com?)

Just my 0.02 BTC, I'm not an expert.

[mjcmurfy]

Thanks for all the suggestions molecular! You are a great shareholder, and a very resourceful and intelligent guy. I have considered all of the options you put forward, and decided to go ahead with running a local bitcoind on the server.

The site has now been fully transitioned to the new payment system. There have been no changes to the fronted of the site, but the whole payment code has been rehauled and is much simpler than it was before.

The server will now generate a unique wallet payment address for each transaction. It will be generated as soon as the payment popup appears (this might delay the popup a few seconds). Once you send payment to the provided address, the server will poll bitcoind every 5 seconds to check if it has been received.

It all works in the exact same way as before, but is much more stable and secure with a lower chance of payment-dropping, as we are not not relying on third party payment processors for payment notifications.

The one problem is the fact that the wallet has to be stored on the server, but I have put some thought into the best way to secure the earnings from attack. I have encrypted the wallet using a very strong password, and I will not enter the password into the server at any time (to combat keyloggers). I will keep a local copy of the wallet on my home computer that I will use to regularly remove any earnings into another, offline wallet. I don't envision any problems with this setup, as even if the wallet does get stolen, there will be no way for any attackers to decrypt - and therefore steal - any of the coin.

I'm delighted with the current setup of the site now.
I have been meaning to do this since day one, but have not gotten around to it until now.

If anyone has any problems with the new payment system, please do not hesitate to post!

[TTBit]

Bought a package yesterday, can't download. I click on 'Download Now', nothing happens. I have plenty of credit.

EDIT: I don't think I waited the 5 seconds! Works.

[mjcmurfy]

Whoops, caught a tiny error in the bandwidth related payment code.
Thanks for the error report TTBit! Everything should be fine now.

EDIT: if you were still waiting on the payment screen while I was fixing the bug, it would have went through once I corrected the bug.

[molecular]

The site has now been fully transitioned to the new payment system. There have been no changes to the fronted of the site, but the whole payment code has been rehauled and is much simpler than it was before.

You are one of the most dedicated and productive persons I know of!

The server will now generate a unique wallet payment address for each transaction. It will be generated as soon as the payment popup appears (this might delay the popup a few seconds). Once you send payment to the provided address, the server will poll bitcoind every 5 seconds to check if it has been received.

It all works in the exact same way as before, but is much more stable and secure with a lower chance of payment-dropping, as we are not not relying on third party payment processors for payment notifications.

Just went through the process (normal dl, no top-up stuff). Worked like a charm.

One thing: I think the javascript alert confirming the payment appeared twice. I'm not sure what the first one said, cause I clicked OK too quickly.

The one problem is the fact that the wallet has to be stored on the server, but I have put some thought into the best way to secure the earnings from attack. I have encrypted the wallet using a very strong password, and I will not enter the password into the server at any time (to combat keyloggers). I will keep a local copy of the wallet on my home computer that I will use to regularly remove any earnings into another, offline wallet. I don't envision any problems with this setup, as even if the wallet does get stolen, there will be no way for any attackers to decrypt - and therefore steal - any of the coin.

How many keys did you pre-generate before making the wallet copy? The default of 100 should be used up pretty quickly and bitcoind will generate new batches, right?

I'm delighted with the current setup of the site now.
I have been meaning to do this since day one, but have not gotten around to it until now.

Very nice!

[molecular]

I'm not sure what's going on. Might be nothing or a major bug Here's what happened (idkey=6xvv4lma7t):

I downloaded a torrent with quite a few .mp3 files (legal ones, of course) in it. It downloaded to the server in a very short time (like 3-5 seconds after I got to the status page it was finished).

I then downloaded all the files using "wget -r".

The first mp3 plays, but the other are screwed. mplayer reports errors like crazy and even shows part of some movie (!!) when playing one of them.

Either that torrent is screwed in the first place or (wild suspicion here), your download was assumed finished before it really was and the files are filled with leftovers from other downloads or whatever is was on the harddrive before. Is that possible???

EDIT: It get's better:

a friend downloaded all the files a little later. He sent me one (number 26 on disc 2) and I compared the md5 sums:

his: 32ec3b0d1055d665f32d956fcc632806
mine: 9f484155d5b68740a7c2bcbcd52eb95c

my suspicion: when I downloaded the files, they were not really completely dled by the torrent client. When he downloaded them, they were "more complete".

EDIT2: I'm re-downloading the files to confirm/reject my suspicion...

md5sum of same file "26...": a4577bcbfd8a00cb3e9508a3aa33462e (yet another one)

=> suspicion more likely

[molecular]

[mjcmurfy]

One thing: I think the javascript alert confirming the payment appeared twice. I'm not sure what the first one said, cause I clicked OK too quickly.

I'm not sure what's going on. Might be nothing or a major bug Here's what happened (idkey=6xvv4lma7t):

my suspicion: when I downloaded the files, they were not really completely dled by the torrent client. When he downloaded them, they were "more complete".

Just had a look, and it seems that you submitted the torrent twice somehow. The idkey of the first one is ieruqyd32m, the second one is the key you mentioned which was submitted 1 second later - you said that you saw the javascript popup twice? The website saw the previous torrent of the same name in the database, assumed it was finished and served up the files even though the torrent was not complete.

I checked out the process a few times again with a couple of torrents and I can't seem to replicate the behavior. Very odd. I'll keep looking into it, but I think this was some sort of exception.

How many keys did you pre-generate before making the wallet copy? The default of 100 should be used up pretty quickly and bitcoind will generate new batches, right?

I didn't pregenerate any addresses other than the default amount created by the client. I plan to regularly download the wallet file from the server over an encrypted sftp connection, to ensure that the wallet is kept updated with any new addresses created.

Hahaha! 0.00003 btc - less than 1mb. Didn't plan for torrent's that small! rofl

[molecular]

One thing: I think the javascript alert confirming the payment appeared twice. I'm not sure what the first one said, cause I clicked OK too quickly.

I'm not sure what's going on. Might be nothing or a major bug Here's what happened (idkey=6xvv4lma7t):

my suspicion: when I downloaded the files, they were not really completely dled by the torrent client. When he downloaded them, they were "more complete".

Just had a look, and it seems that you submitted the torrent twice somehow. The idkey of the first one is ieruqyd32m, the second one is the key you mentioned which was submitted 1 second later - you said that you saw the javascript popup twice? The website saw the previous torrent of the same name in the database, assumed it was finished and served up the files even though the torrent was not complete.

I checked out the process a few times again with a couple of torrents and I can't seem to replicate the behavior. Very odd. I'll keep looking into it, but I think this was some sort of exception.

It's entirely possible I submittet the torrent link twice. I think I even slightly remember doing that (/me scratches head)

On the next small download I do I will try to replicate the bug. Until then, we can probably file it under "some extremely unlikely unknown crap happened when the user behaved unpredictibly".

Of course, should users report broken files, alarms should go off in our heads.

How many keys did you pre-generate before making the wallet copy? The default of 100 should be used up pretty quickly and bitcoind will generate new batches, right?

I didn't pregenerate any addresses other than the default amount created by the client. I plan to regularly download the wallet file from the server over an encrypted sftp connection, to ensure that the wallet is kept updated with any new addresses created.

Actually I think you did implicitly pre-generate 100 addresses. Bitcoind fills the wallet with a certain amount of addresses initially. Default 100.

there's a switch for bitcoind:

-keypool=<n>       Set key pool size to <n> (default: 100)

I never used it, but it seems maybe that way you could decrease the frequency of the wallet backup. Just an idea... it might be dangerous to fiddle with that, I'm not sure. Better do some tests and read docs before putting it in production blindly.

Actually: backup frequency is not expensive in this case and the danger of loosing money is negligible. So I'd myself probably go with changing nothing here.

IMG removed
Hahaha! 0.00003 btc - less than 1mb. Didn't plan for torrent's that small! rofl

Probably no need to fix this