.@MoreBloodWine: I didn't write the coinbase code so I can't really say what the issue is until I look into, and I don't really have much time right now. Did you try the .htaccess file from 1.0.0? Maybe try doing a fresh install using the install.php script? Try using a different web browser or different computer and see if that makes a difference. And no, you don't have to upgrade anything in the database. As for your question about the pages breaking, just remove the PHP code and replace it with what ever HTML you want. Eg:

<h1>My Title</h1>
<p>My page text.</p>

All you should need to do is delete the inc/rss.inc file.

Probably the only reason that can happen now is that you failed to properly copy the public key. Some other people who had that problem said that some web browsers don't select the full key properly when you double click in the text box because the key contains ':' characters. Log into the admin area and then go to Settings and then select RSA KEYGEN. Then generate a new RSA key pair and make sure to copy the full public key properly. Click inside the text box and use ctrl+a to select all the text.

Well that's because there's a lot of code changes between 0.9.9 and 1.0.0. The page with all the stuff is still listing which files need to be updated, it just contains more information. The column you want to focus on is the "Comparison result" column. If it says "Text files are different" or "Binary files are different" then you need to update the corresponding file. If it says "Left only" that means the corresponding file is new to 1.0.0 and "Right only" means the file only exists in 0.9.9 and has been removed from 1.0.0.

Well we're back to work but it might be another few days before we have anything new and worth testing.

Sorry we've been so quiet the last few days, we're taking a short break from development but we should get back to it in a few days. Still a bit of work to be done but we're much closer to our goal now.

Well I'll keep that in mind but we already have a lot on our plate and I don't feel like pools pose a significant threat. People tend to leave pools when they become too large anyway.

There were several people involved in the development of the scheme and I have two developers working on the implementation. Some of them would prefer to remain anonymous so I refrain from mentioning names when possible.

No, that is a test thread where the client must run in testnet mode. Any coins mined in those tests will be lost, we've already had to reset the blockchain one or two times due to changes we made in the protocol.

Good to hear! If you have any questions I'm always around.

Thank you! Might be a while before I release another update but I'm always looking for helpful suggestions about what sorts of features I should include in future releases. Some of the ideas I already have planned for the near and distant future are the following:

- support for discount/coupon codes
- send email to subscribers when item in stock
- user account system (undecided)
- support for other alt coins
- support for other databases
- wider range of translations

Ok well it looks like RC3 was pretty much bug free so I've released v1.0.0 Final. The only difference between it and RC3 is a few cosmetic changes in the admin area. If you're running anything lower than RC3 I'd highly suggest updating to v1.0.0 Final.

There is no such thing as "spent" and "unspent" transactions in the mini-blockchain scheme, and you're right, it's not the same as a "rolling root" design. The transactions simply perform operations on the account tree (the balance sheet). So you see, the inputs and outputs in our transactions do not point to other transactions, they simply point to addresses in the account tree, so the transactions aren't linked together the same way they are in bitcoin, and we can discard all transactions after a safe amount of time has elapsed (enough to make the Secret Chain Attack infeasible). In our implementation nodes will be able to delete all transactions older than a week, but they can choose to store as much history as they want. I'm sure many people will even choose to store the full blockchain for historic reasons. But for new nodes who don't have any of the blockchain, they wont need to download the full blockchain to synchronize with the network and become a full node, they only need the last weeks worth of transactions and the account tree. Of course the account tree will grow over time as new non-empty addresses come into existence but the level of compression and scalability this system offers is virtually unbeatable.

I asked catia about the "Ready for committal" thing and he said it only shows that on the first time. As for that error in the log, it looks like it might just be someone sending you a transaction your already have or something, but we'll have to wait for catia to take a look at it to be sure though. I assume getinfo and other commands are still working for you?

As mentioned, it's not really possible to do that with Bitcoin due to the way inputs and outputs work. But I do have a project underway right now where we are designing an alt coin which works in essentially this way, it stores the balance of all non-empty addresses in a structure we call the "account tree", enabling us to delete ALL transactions after a certain period of time passes (1 week in our implementation). We have removed the entire idea of interlocking transactions and replaced it with a much simpler concept where transactions perform basic operations on the account tree such as "subtract coins from balance of address A and add to balance of address B". Obviously without any type of script system our coin is less flexible, but we've already got support for multi-signature transactions, and many other cool features that aren't really possible without a balance sheet scheme. When you get down to it, people really just want simple types of transactions to perform simple banking functions. If we want this extreme level of scalability we're going to have to give up some flexibility, and that's not such a bad trade off considering that Bitcoin already has pretty strict rules about what transactions are considered standard format.

The other trade off, which seems to be more concerning for most people, is that deleting all the old transactions could lead to a situation where no one has them, since no one is required to have them, and that opens the door for someone with 51% or more of the hashing power to pull off an attack we call "The Secret Chain Attack". In our implementation it would require the attacker to maintain the majority of the hashing power for more than a week (in secret), since all transactions can be discarded after a week. But we believe even if this attack does happen it wont be catastrophic because 1) the attack will only affect nodes who haven't synced with the network in more than a week, all other nodes can detect the attack and reject the fake chain and 2) a possible Secret Chain Attack underway can be detected by new nodes, although they cannot know which chain is the real one. Based on settings specified by the user the new node will either refuse to participate in the network until one chain wins, or stick with the first chain it received, or wait for the release of a "community checkpoint" which would point them to the correct chain in the off chance this attack did happen.

Test thread:
[TEST RELEASE] Cryptonite binary for linux (mini-blockchain implementation)

Project Wiki:
Mini-Blockchain Project Wiki

More on Secret Chain Attack:
Weaknesses and attack vectors

Well you must keep in mind that the block reward will keep halving over time until it's extremely small, at some point it'll probably be smaller than the actual transaction fees. So before the block reward reaches 0 we will already have a mining system subsidized by fees more than block rewards. The question is, how will that affect the profitability of mining over time. It is my belief that the last time the block reward halved it contributed a lot to the price spike throughout 2013 because all of a sudden mining became half as profitable as it was the day before, but the level of fees was not increasing to account for that. There is no realistic situation where people are going to pay fees higher than what is charged by commercial banks, but when the block reward does get lower than the fees something will have to give, otherwise miners will just give up on mining for a profit and the network will lose the majority of it's hashing power.

Well I have no idea what is causing the issue because no one else seems to be having the same problem. We have to recode a lot of the syncing code anyway when we implement blockchain trimming, if the problem is still persisting after we do that then we'll pay more attention to it, but for now we have to focus on other things.

The idea for the mini-blockchain sort of started off as a plan for compressing the bitcoin blockchain but it became clear to me that we'd have to make a new coin if we really wanted to get the maximum level of compression, because we have to forget about using scripts and instead use a "balance sheet" type of format for maintaining address balances. So when a transaction is made all it needs as an input is a non-empty address, there is no such thing as spent or unspent outputs, and that's why we're able to discard old transactions.

Just delete the .cryptonite folder. If your wallet contains the -1 conf bug like mrvegad that might be why it's giving you problems. Just delete it and start again.

Lol guys you might want to cut back on the spamming a bit... try to limit your scripts to 1 tx per second or longer.

Pooled mining has its advantages. It helps people to get a smoother income from mining and can make forks easier to resolve, among other things which I can't remember off the top of my head because I'm tired. I think it would be worse if we couldn't support pooled mining.

It's just less problematic for people to compile it themselves, but like catia said if there's enough demand we probably will offer Linux binaries. There doesn't seem to be any great reason for not offering Linux binaries.

Yes, but in the beginning it wont be a simple job to create pools for this coin. Like catia mentioned, we are in many ways back in the stone age because a lot of the current technology built around bitcoin-based coins will need to be altered quite a bit in order to work with Cryptonite.