Bitfreak website is now back online.

I'm having some issues with my web host at the moment but my website should be back online within a day or two. Sorry for the inconvenience.

I did click the link and read it but I found it all very confusing with terms like "seed contracts". But I will say it sounds very similar to the solution I proposed in my last post. But for the record I didn't come up with the idea for secure 0-confirmations and it wasn't even a part of the white paper. No one said the 0-conf idea was original but the main mini-blockchain concept certainly is original.

Well since you think both solutions are essentially the same I don't see the point. The solution I described in my last post is described within the context of the mini-blockchain design, making it easy for me to understand and visualize, where as the solution proposed in your link includes jargon which I don't understand, probably because it's written from within the context of the Netcoin design, which is extremely different to the mini-blockchain design.

Now that I think about it, that is actually a very real problem which I don't think anyone has noticed before. But I believe there is a solution for that: a special type of "priority transaction" which takes priority over the other transactions. Obviously the miners could tweak their clients to reject the priority transactions if the fees of the malicious transactions are higher, but one way that could be countered is to impose a double-spend punishment which allows miners to punish someone if they issue a priority transaction and then also issue any other transactions which would infringe upon the withdrawal limit.

I didn't write that part so I'm not exactly sure what it's supposed to mean, but you're right I don't think queue isn't the best term to use there. I think the simplest and best way for the merchant to ensure the transaction gets processed is to rebroadcast the transaction as soon as they receive it so that if the buyer attempts to issue any other transactions which exceed the withdrawal limit the miners can use the priority transaction to impose a double-spending punishment.

Like I said, I am aware of that and I would put more into this if I could, but I'm not a very rich guy and as it stands I've already put quite a bit of my savings into this. It was intended to be an open source project, and it will be an open source project after we get a working client. It's not like the only reward for getting this scheme built properly will be the money, we will get a new crypto-currency with many novel features and that will benefit us all. EDIT: you are right about the GUI though, I will make that optional.

I think point one will really only become an issue much further into the future. Based on the amount of bitcoin addresses that have been seen by the network up until now, if we were to save all those addresses into an account tree it would be quite small, only a few hundred MB maximum. Of course, the account tree is the bulkiest part of the scheme, and there's really no getting around that... but it's a distinct advantage to the historic ledger format offered by the bitcoin blockchain because we only need to know about funded addresses and we don't need to know all of the transactions associated with any given address in order to calculate the balance of that address. So the account tree is a far superior ledger format which offers a much greater level of compression over the long term and is much easier to trim than the bitcoin blockchain... the bitcoin blockchain is going to become untenable many times quicker than the account tree will.

As for point two, I don't really think it would be that hard if the process described on the network synchronization page is followed. The blocks are not solved fast enough to pose a real problem for nodes trying to synchronize imo... did you actually get far enough to test out this aspect of the scheme? And as for point 3 you do have a valid point, but not all blocks would get filled and I was just allowing some wiggle room for future technological enhancements, but that's why I would prefer a dynamic max block size mechanism and I would highly encourage anyone attempting this problem to fulfill that extra bounty, as well as the rest of them. It really wouldn't be complete without those extra components but it would have less chance of even getting started if I made it all part of one bounty.

Well I imagine that creating the raw private key in hex format wouldn't be exceedingly difficult, but deriving the bitcoin address from the private key would be because there is hashing involved.

Discussion has been moved to here:
https://bitcointalk.org/index.php?topic=371601

Check your private messages. And no there isn't a detailed text installation guide, only the video guide (which is now a bit outdated anyway). The hard part is really just setting up the chron job and installing the database. But if you've installed databases before it should be a simple process for you. Look in the install folder to get started.

Yes I will send you back what you paid for the test item if you give me an address.

It appears that you purchased the test item? The test item is just so you can see how it works before actually buying the script.
You can purchase a 1 year license at this link: http://bitfreak.info/bitshop/index.php?page=item&id=4

Version 0.9.3 released. I highly recommend updating to latest version which contains numerous fixes and new features such as subcategories and category icons.

Good to hear, I just appreciate that someone is working on it. If you need a bit of funding to keep you going let me know. Also, how do you intend to do things like implement the proof chain? Will it be just as a chain of block headers or a chain of proof cells? I would suggest going with a normal chain of block headers because it'll be quicker and easier and the other method doesn't offer a huge advantage anyway.

If you have any questions about how something should be done, feel free to ask. Most of the uncertainties are documented in the wiki so I would recommend going through the project wiki if you haven't done so already. I recently disabled account creation for the wiki because there was so many spam accounts being created, but if you want an account so that you can edit things then I will create one for you manually.

I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.

I very much agree with your sentiments concerning the re-mining of lost coins, but the reason why I don't want to put a lot of focus on re-mining is because 1) there are more important things that need to be done first and 2) it's a very controversial issue. I made a thread a while ago about the possibility of implementing re-mining lost coins into bitcoin and I found that many people strongly disagreed with the idea because it impinges on there ability to store coins in the same address for very long periods of time. The reason it needs to be at least 100 years is because then people feel safer about the idea and if they lose their coins they can't exactly say they weren't given enough time to move them.

I figured he meant something like that, but messing with it in any other way will also make it unreadable. The only real thing I can is try to do put some sort of elaborate border around the QR codes but there's not much room to work with and I don't think it'll look good.

Well my picture certainly isn't anywhere as pixelated as the image you posted. I'm a web designer, not a graphics designer, and I didn't draw this note by hand. I simply combined and modified a range of existing pics to produce the final result. I wasn't planning to share it but the final result came out better than I expected. If it doesn't meet your requirements I can't do much about it.

Well the note I printed out looks fine. Unless you want to print a very large note I don't see why it would be a problem.

They are mathematical symbols, which are typically based on Greek Characters.

Some times less is more. I know most currency notes have a full design on both sides but I'm going for more of a playing card look.

Many of those notes are just plain ugly, I have a collection of nice notes that I used for inspiration.

The QR codes do have some slight transparency in order to blend them into the note, but if I messed with them any more they might become unreadable.

Yeah the intention was to make the back a bit like a playing card, I don't think it would really look good with a QR on the back.

And I did have similar thoughts about the pi letter but I was using a font which only gave me a certain set of symbols to work with.

I wasn't aware that QR codes had different levels of error protection, that is pretty cool. The QR codes used in my pics are just as an example though, you can use what ever level of error protection you want when you generate your own QR codes and insert them into the note.

Ok I made both QR images the same size and looks much better imo. I've re-uploaded the PDF files and replaced the old ones, just download them again if you want the new version.