I'm having trouble finding a transaction which was ignored by the explorer. If anyone has an address which is missing transactions on the explorer and you know what the txid is for the missing transaction please provide it to me as it will help me find out why the explorer skipped that tx. Qt should keep a complete record of all your transactions so look for the txid there. I lost my old wallet file a while ago so unfortunately I don't seem to have a record of all my transactions and the records I do have match up perfectly with the explorer.

EDIT: never mind I found some.

Well I think there's probably more to it than that. I did do some work on the explorer recently. By the way I still haven't gotten around to fixing that bug with the sent and received values. It actually looks like some of the transactions have been missed by my script because I looked at an address with a low number of transactions and the inputs and outputs added up correctly. It might not be a very simple problem to fix but I'll spend a few hours on it tonight and see how I go. Also I should mention that catia got back from his trip a few days ago, however he probably wont be able to start working on Cryptonite immediately because he is dealing with some personal family issues.

Unfortunately that's not possible with the way I have designed the database. That's one of the reasons I wanted to switch over to mysql, it makes it easy to sort records by different fields. I could write a separate script to keep track of the top addresses but I don't want to give the explorer server too many tasks to deal with.

Just fixed several bugs with the filtering and pagination, but haven't solved the issue with total sent and received values yet.

It's back up now however one of the new features I added doesn't seem to be working properly. The total sent and received amounts listed on the address pages seems to be wrong. I've got to get some sleep now but I'll fix it when I return.

On a side note it's worth mentioning I wasted about 4 hours of my life converting the block explorer over to mysql but when I did some testing it was more than 50x slower than the custom file based database I originally created. I never thought mysql would be too slow for my needs but for a block explorer it's way too slow. So I scrapped the mysql code and just improved on the file based database, the explorer should now be faster for addresses which have a very large numbers of transactions.

It should be back up within the next 12 hours.

Well finally some good news. Just got a message from Catia, he got the server back online but apparently he's on a real slow connection so he couldn't get the daemon back online. I'll try to get that done myself shortly. This is a good chance to get the new block explorer code up and running anyway. I'm thinking Catia must not be home yet if he's on a slow connection, but at least we know he's still around.

It seems to be a problem with the DNS records for cryptonite.info. I have opened a support ticket with the host so it should be sorted out soon.

Actually I think it may be the server, the DNS records still seem to be in place. This is annoying because catia owns that server.

Unfortunately not but it's still very interesting work worth following. It wont be as scalable as Cryptonite but the scheme he has developed is miles better than any other anon coin I've ever seen.

Well there are no unspent outputs in the MBC scheme which is why I think your scheme is closer to Bitcoin. If I were to send 1000 micro-transactions to the same address using Cryptonite the account tree would only grow larger on the first transaction, but if the address was already in the account tree before I sent the first tx then the tree wouldn't grow at all. In your scheme the tree would grow for each of those 1000 transactions because you're recording unspent outputs rather than a balance sheet like Cryptonite. And that is the main reason why Bitcoin will never achieve the level of scalability that Cryptonite has, despite what some other people might claim.

Yeah I've thought about it but it's obviously not going to be the easiest thing in the world. It's also very hard to decide when and how the maintenance fees should be subtracted from address balances even if you know what the maintenance fee should be. There always seem to be serious difficulties involved regardless of how the problem is approached.

Still no word from Catia but I can't imagine he will be away too much longer. Hopefully he's not stranded on a tropical island. I played a game called Stranded Deep a few weeks ago in which you have to survive on an island in the middle of no where and it was actually pretty fun.

Now for some better news, B.F. Franca has released an updated version of his Homomorphic Mini-blockchain Scheme paper. I'm really impressed with the level of anonymity he has been able to achieve whilst still keeping it relatively scalable.

Very nice work once again. I like the idea of using temporary addresses for every transaction, it seems to be a powerful way of increasing privacy. If I'm understanding your proposal correctly, the temporary addresses created by transactions are essentially what you store in the account tree, or you could also say that the account tree essentially contains all the unspent outputs from transactions (aka the receipts). What you have proposed is more similar to Bitcoin than the MBC scheme because it revolves around unspent outputs and brings back concepts like change and coin minting without inputs.

At some point in the future Bitcoin developers may figure out a way to compress all the unspent outputs into a compact structure which can be shared among peers much like in your scheme. At the end of the day your scheme might not end up being much more scalable than Bitcoin. But since your scheme, like the MBC scheme, doesn't use tx scripting, that allows you to implement all these clever mathematical tricks to produce a high level of anonymity and privacy while still remaining much more scalable than Bitcoin in its current state and all current anon coins.

Obviously it wont be more scalable than the MBC scheme but the original scheme doesn't provide the remarkably high level of anonymity that your scheme does and anonymity always comes at a cost. I also noticed that your new solution to preventing small value outputs (aka dust) is to enforce a minimum value output. Micro-transactions are much more costly in your scheme compared to the MBC scheme so I can see why you would gravitate towards that solution but it still seems like a rather poor solution to me, especially if the minimum value were to remain static over time.

A better solution might be to simply have miners enforce a minimum transaction fee. I've never really been a fan of the Proof-of-Stake mechanism but one reason I think PoS can be truly useful is for allowing stakeholders to vote on the minimum transaction fee and other important values such as the maximum block size. The problem of pruning dust really is one of the hardest things to solve I think. Sacrificing micro-transactions for more scalability is probably the best solution for your scheme but there are definitely better solutions for the MBC scheme.

@MoreBloodWine: it wont be at least until another 2 or 3 releases.

@dragonjcpf: i'll send you a PM.

Nothing yet but I think he should be back soon.

Well the fact that it's highly scalable is kind of important. You've also got other things like withdrawal limits, native multi-sig support, etc.

@enerbyte: very nice graphic but I'm not sure I understand your question.

A couple of people have reported that problem, but it's strange for it to happen on a Linux OS, or are you now using Windows? I think the only way to solve it is to do a fresh resync again. Try syncing with cryptonited instead of Qt and see how that works. I recently started experiencing some syncing problems with Qt on my Windows machine, which is strange because I haven't had any issues until now. I did upgrade my .NET framework a few days ago so I could install VS 2012 and I highly suspect that has something to do with it, which is why the problems only seems to occur on a fraction of Windows machines.

We could definitely use more experienced programmers, but the reason not much has been done lately is because catia is on a sailing trip and I've been side tracked with other projects and haven't had time to work on the encrypted web wallet lately. But I think catia should be back soon and I should have some time to work on the web wallet in the next few days. I've already done some work on the explorer to make it a bit better at dealing with orphaned blocks and stuff like that but it's incompatible with the current explorer database format so it's going to be a pain to install because it'll need to reprocess the entire blockchain from the start.

For anyone wondering it was just a configuration error, nothing was hacked and the latest version of BitShop remains perfectly secure. When people were directed to the payment gateway the script would completely fail due to the config error and they were unable to pay, that's why he had customers reporting problems and that's why all of the orders remained unconfirmed.

None of the keys were ever given out, the reason the product went out of stock is because when an order is placed the stock is reserved for the buyer under the assumption they are about to pay. If they close the page without canceling the order then the stock will remain lower than it should be. In order to get back the stock from abandoned orders you must delete those unconfirmed orders.

This information is mentioned in the order management section of the admin area:

Skyenet: what version of BitShop are you running?

EDIT: Looks to me like you've got lots of other products still in stock. If it was a breach I imagine the attacker would have taken everything. Did you do what SteamGamesBTC suggested and check the balance of the addresses to see if you got paid? I'm guessing it's some how related to the problem with your unconfirmed orders. Since no one else has reported a similar problem I'll need to take a close look at your website to diagnose the problem. I'll need temporary FTP access to start with.