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.


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

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.

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!

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:


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.

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.

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.

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.

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.

This is an awesome project.
I can get the thUSD feed loaded into the application, but it refuses to load the mtgoxUSD ticker from bitcoincharts.
It just gets stuck on "Acquiring data for MTGOXUSD".

Does anyone have any suggestions?

Really? Why are you involved in bitcoin again?
It's not that complicated.


Let me expand on that:

1) No images
2) Figure out a way of solving the problem and save server costs
3) Locally cache images
4) Do nothing and accept that you may be attacked

I'm aware of that. Read the second part of my post again.

Why not write a server side script that would allow users to input ad-hoc an external image link, it would then be tested for various properties (i.e. the size of the file, whether it is a valid image file, whether it is a dynamically generated image, whether it obeys the dimension restrictions) and if the image passed the criteria, permission would be given to the post parser to display the embedded image. If not, then the image would not be embedded.


Validated images could potentially be replaced with something else later, necessitating continuous checking - granted, but you just need a database table that keeps track of validated images that the parser can re-query at runtime. If the image has been modified, the image 'hash' would be different and the image would have to be reverified manually by the poster else it would not be displayed, and no further checking would be done until the OP revalidated the image.

You wouldn't have to do this image hash checking each time the thread is loaded, you could just set up a daily cron that would reverify a certain % of the embedded external images table. Maybe have it so that each image is checked once every 2 days or so, or spread it out slowly over a period of time.

You could make it a quite efficient process that would not require that much by way of server resources. We have gotten pretty good at driving down the cost of hashing power, have we not? And it would seem that it would be better in terms of resource usage than actually storing the images, using up potentially huge amounts of disk space and a heckuva lot of bandwidth - simply to ensure their integrity.

This way requires no additional disk space and much lower bandwidth costs as the server only has to download the image once every two days, instead of uploading it hundreds of times per day to individual users.


Then why were you using it as justification for getting rid of embedded images? It is trivial in comparison to the cumulative bandwidth that delivering locally stored images would clock up. And why should the operators of the forum care about how much bandwidth a few images take up on the end-users side? If you watch a single youtube video, I'd imagine it would still account for more bandwidth use than a week's worth of surfing this forum.


Yes, they are of course justified. It is just the conclusions you are drawing that I have questions about. We don't need to crack this walnut with a sledgehammer. There are workarounds that can be put in place.

Your lack of respect for what the users of the forum think is quite cynical and arrogant. At the end of the day, you have to keep your members on side, as they are the ones that produce all of the content and make this forum what it is. Telling them directly that what they think is not important is a highly presumptuous move for you. People remember statements like that.

Yes it's easy for the majority to be wrong, but it's even easier for a single individual to be wrong.

Not over the space of a few months, but time answers all questions. I want the admins here to get the answer right.

e eoe a ooa (lets remove all consonants)

I know I'm being facetious, but it's fun.

This is the first time I have heard anything about banning embedded images. I thought it was just about banning signature images. That in and of itself isn't too big of a deal, so I never felt the need to say much about it. Most find them annoying, and there are legitimate reasons for wanting to get rid of them, but it doesn't bother me nearly as much as total banning of all embedded external images. That is an insane policy unless the admins are willing to go the extra expense and provide local image storage.


I don't want to be part of ANY forum that does not listen to the wishes of its members, privately owned or not. The ideology of bitcoin is one of the rejection of centralized power structures that are inflexible to the wishes of those they rule over. If this forum is not willing to do so, then most of us will just join one that listens to them and bye-bye forum. Democracy still functions correctly on the nets at least. I personally like this forum, so I want to ensure that the admins make the correct decisions and have a thriving community that continues into the future.

I think that was his point.

Trolls will be trolls, whether they can post images or not.

Heatmaps are awesome!
Great project Ferroh. Keep up the good work.
Hopefully you can give us dynamic realtime heat maps at some stage.
That would be very cool.

I don't know where to start with this.

Just because you don't like embedded images Theymos, does not mean that you get to speak for everyone on this forum. There are plenty of means by which all of the technical issues with externally hosted images you have mentioned can be addressed. There are ways of banning dynamic images, preventing cookie stuffing and preventing large unsightly images.

The argument about images taking up online 'real estate' is the weakest I have heard - as if it were limited in some way or in short supply.


YOU have determined. With no consultation with the rest of the users on this forum. So the best way to ensure ideas can be expressed effectively is to unilaterally ban any form of imagery and limit people's means of communication to text only? This is broken logic.


You say that they are never useful, but then go on to shoot your own argument in the foot. Sig images can help you get a better idea of who the person behind the text actually is, thus modifying your preconceptions of the poster and his post. The argument about them being off topic is moot. They were never supposed to be on-topic as they are not part of the thread itself. They are signatures.


You are making huge assumptions. How can they take up more space than they are worth?
There is no end to the amount of space that a thread can take up.
How can you judge their worth anyway?

And like you said, text can also be off topic. Why not ban all the text aswell?
Oh, because it's smaller and less distracting! I see.
We are not all that easily distracted.


Yes, hosting the images is not worth the trouble. Definitely don't do that.
But there are many ways you can prevent the linking of dynamic images, and thus prevent cookie stuffing.

They do NOT use up any of this server's bandwidth. Are you kidding me? The request is not sent from this server, it is sent from the users viewing the images - using up the bandwidth the image is hosted on, not bitcointalk's bandwidth.

I never get HTTPs errors. Never. Using safari, firefox or chrome.
Turn down the fidelity of your browser's error reporting if it's a problem for you.


Why not hold a vote on the issue to find out how correct your assumptions are?

I really don't mean any offense to you Theymos, or to any of the Admin or Mod team. I think you do a great job and I know from past experience of being a forum administrator that it is a thankless job. But this is silly, and I think most would agree that this seems like an over-reaction to something that is only a MILD annoyance at best. I think this is a terrible idea for the vitality of this community.

If we want to ensure a platform for free expression, then people should be allowed to express themselves freely and not be restricted by totalitarian bans on imagery. If you are unwilling or incapable of addressing the technical issues, then you should hire someone to do it for you or step down in favor of someone who is capable.

A text-only forum in 2011? I can't believe we are even having this discussion.

Nice workaround but it won't fly if they catch you. They will ban your account anyway, just for the lulz.

I've seen some private trackers actively incentivize new referrals to rat out their referrer if they made them pay. They get a ratio bonus and the referrer gets banned. Pretty effective strategy, don't know if they do this on demonoid though.

Are you sure you have downloaded the complete blockchain? You have to do this after first installing bitcoin before any transactions will show up. It can take an excessively long time. You need to leave your bitcoin client running until it finishes. There are currently 152324 blocks. How many are showing up in your client, in the status bar at the bottom of the window?