What issues are they having exactly? I'm guessing the cause of the issue is one of these old bugs Cryptonite has always had, so solving those problems should solve a lot of other problems.

@enerbyte: thanks man, good to see you still around.

@pallas: I've been trying to catch up on all the posts I missed in this thread but I haven't seen that patch, can you link me to it please. I appreciate what you've done to keep XCN alive and of course I'll take any coding help I can get. I do have a roadmap for Cryptonite development, but the most important thing right now is getting people who can work on the core code and iron out some of these annoying bugs. I'm currently visiting relatives for xmas so I cannot do much right now but I'll be back at home after new years.

@dextronomous: well it just happens that one of the projects I've been working on is a ray tracing engine which uses OpenCL. So I could probably write some code for mining XCN with an AMD GPU, especially since I imagine most of the code I will need is already out there in open source miners. The most difficult part will probably be making it run fast enough to be remotely competitive with the CUDA miners, and also the networking code, but I imagine most of that code has already been written for me as well.

Well I guess there's no better time than Christmas to let you guys know I'm still alive. I am truly sorry for being absent for so long, I've just had so many other projects that have consumed my time and honestly there's not much I can do in terms of core development. Like I said before, since there was no premine it's very hard to create an incentive for people to work on Cryptonite. However I am really amazed how well XCN has managed to chug along without absolutely any development and without me being around. It's still ranked #143 on coinmarketcap.com despite all the bugs and lack of development. That tells me people think the technology behind Cryptonite has value and I think developers should see that instead of focusing all their effort of complex scripting applications. Some times people just want to send some coins to each other and they want fast micro-transactions to be possible without needing to hear about how it bloats the blockchain.

Anyways, after new years I will make myself more active in this community again. I've finished most of the stuff I wanted to work on now and I have done quite a lot of C++ development in the process. So I'm probably at the point where I would feel confident modifying the Cryptonite code base but it's still a very complex task especially since it works very differently to most coins. As for the block explorer, the chain is now so large that I will need to recode the existing explorer so that it reads block files directly from disk instead of using the RPC API. However I could also design it to only show transactions from the last week so that anyone could create their own explorer without needing a complete copy of the blockchain. I feel like that's ultimately a better approach because it wouldn't have the sort of scaling problems that a normal block explorer would have.

Of course it would still show the correct balance because that information is stored in the account tree. I don't think people would really care if they couldn't see transactions made more than a week ago. However I've come to the decision that I cannot run the explorer myself unless I think the explorer can be kept alive by donations. The type of server required to run a coin daemon is not very cheap and I already paid to keep the explorer alive for over a year. I don't make anything from Cryptonite and I'm not going to keep spending money to keep it alive. I also decided not to run a XCN web wallet myself for the same reason, and also because I don't want to be responsible for all that money if something were to go wrong with the web wallet. I can share all the javascript code I wrote for creating valid XCN transactions, but I don't want to run a web wallet myself.

I also don't think it's a good idea to have XCN services so centralized, it shouldn't be up to me to build and run all these services. I will see what I can do in terms of core development, but I cannot do everything myself. One of the reasons I haven't been around here for a while is because I felt overwhelmed having so much to do myself. Obviously I care a lot about Cryptonite since I played a large role in developing the concepts behind it, so I don't want to see it fail. But I cannot do everything myself and I cannot keep spending my own money to get things done. I am thankful to you guys who have been helping others solve problems while I was absent, once again I'm glad to see so many people still showing interest in this coin. Hopefully in 2017 we will be able to make a bit of progress and get things happening again.

The XSS vulnerabilities you showed me are false positives. The only XSS exploit found in BitShop recently was one on the category page but it has been fixed in the latest version of BitShop which was just released.

Sorry about that, was a bug with the latest version of BitShop caused by the addition of the PHPMailer library. Apparently PHP doesn't like when you use more than one autoloader. Has been fixed now and should work properly. If you already downloaded v1.1.1 just download it again and use it to replace the /lib/common.lib.php file. Btw, now that bug is corrected, I would consider this release of BitShop to be quite stable and if you're running an older version I would highly recommend updating to 1.1.1.

Version 1.1.1 of BitShop has been released. It adds a stand alone PHPMailer email library which replaces the outdated PEAR email package. It also fixes the bug where SMTP was enabled by default and a few other small bugs. The latest version can be downloaded from the client file area using a valid license key.

Hey sorry for the delay again, just had to finish up on that other project and also had to visit a relative. Should have the next few weeks to work on Cryptonite stuff though. I've already did quite a bit of work on the web wallet before I started my other project, and I should be able to finish it fairly soon. I also noticed that the explorer node went offline, it's resyncing now and it should be back up shortly.

All block chains grow forever, what's important is how much of that blockchain is required in order to synchronize with the network. If you had a Cryptonite node running since the first day without turning it off then it will have a complete copy of the blockchain, and when a new node joins the network is will share blocks with them. However the new node wont require the full blockchain to sync, they will only require the most recent blocks from the last week, along with the header chain and account tree, with which they can be a full node. I cannot really make it any clearer than that.

No but it's near the top of my list of gateways I plan to add to BitShop.

Apparently the SMTP Pear package hasn't been updated in a while and doesn't obey the new standards of PHP. But those strict standard errors shouldn't really stop it from working, you should be able to hide them like warnings just by disabling error reporting. But I have a feeling the SMTP emails wont work even after disabling error reporting, I didn't actually confirm it was working because I assumed they wouldn't let such an important Pear package get so out of date it would no longer work, but it seems that may be the case. In the next release of BitShop I will replace the crappy Pear package with a modern SMTP library which can be included with BitShop so it wont have to rely on the SMTP Pear package being installed.

Open /inc/config.inc.php and set $smtp_enable to false.

You need to disable SMTP emails, I accidentally enabled it by default.

Sorry bud, at least you got out while it was at a high. Can always buy back in at a lower price. 

Yeah well even when I had lots of funding for development it still took a very long time to find a developer willing and capable to work on this project.

Infinite storage devices still wouldn't alleviate the time required to download the blockchain, and that's just as much an issue as the space required.

Hello guys, sorry I haven't been around for a while, been spending most of my waking hours working on another project, but that is pretty much finished now, and at least I gained quite a bit of C++ experience from it. I will now try to focus the majority of my time on improving Cryptonite and try to get the web wallet released some time soon.

I saw that the market cap for XCN climbed back into the top 100 a couple of weeks ago so that has given me some motivation to keep this coin alive if I can. But like I said my abilities are still quite limited and if there is any team willing to take over this project so that it's not left alone when I'm not around, that would probably be for the best.

I also cannot keep funding the explorer and other services forever unless we can figure out some sort of funding scheme. At this point it seems to me, if mining pools want XCN to stay alive, one or more of the pools should participate in an agreement to fund development of Cryptonite by diverting a fraction of their XCN profits to that cause.

Now let me attempt to answer some of your technical questions, although it's been a while since I brushed up on my cryptocoin knowledge. Bitcoin did adopt a sort of limited pruning system not too long after Cryptonite was released but there are some critical differences which make Cryptonite more scalable, that's why it syncs so fast if you manage to make it sync correctly.

The main difference really comes down to the fact the Bitcoin uses transaction scripting but Cryptonite doesn't. When you sync with Bitcoin you need to download the full blockchain in order to validate it and calculate your wallet balance because the inputs and outputs link the transactions together, which makes it difficult to prune old transactions.

For that same reason it can be slow to import a new private key into a bitcoind-based wallet because it needs to rescan the blockchain to recalculate the wallet balance. And that is why you simply cannot get the balance of any address which isn't in your wallet using bitcoind. However I think they've also recently remedied this problem a little bit with watch only addresses.

But I believe bitcoind still needs to perform a rescan after importing a watch only address in order to calculate the address balance, and I believe a Bitcoin wallet with pruning enabled wouldn't be able to perform those rescans because it wouldn't have the entire transaction history required to calculate the balances, because it has pruned that data.

The release notes for Bitcoin Core 0.11.0 stated that "Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.)", and I'm uncertain if the situation has improved since then but they had plans for it.

I think I read some where not too long ago that they wanted to use a hash tree structure to store the unspent outputs and maybe even balances, some what similar to the "account tree" in Cryptonite, however I believe that would still require the full blockchain to be downloaded and scanned so the tree could be built, so syncing would still be very slow.

The main advantage with Cryptonite is that transactions don't link together, so all of them can safely be forgotten after a certain period of time. Instead of having to download the full blockchain, nodes only have to download a recent portion of the blockchain along with the account tree / balance sheet, with which they can become a full node.

The real trick is that the nodes share the account tree between themselves and they're able to use data embedded into the blockchain in order to verify the validity of their copy of the account tree. When a new block is accepted, transactions in the block will cause balances in the tree to be updated among all nodes so they all have the same copy of the balance sheet.

So when a transaction is being made, there is no need to reference what may be a very old transaction like with Bitcoin, instead the inputs and outputs of a transaction will simply reference address nodes in the account tree. It's a more purely mathematical approach without all the scripting on top, closer to how a normal banking system would work.

The consequences of this approach is that the balance of any address can be cheaply computed simply by looking up the balance of that address in the account tree, which all synced nodes will have an up-to-date copy of. It also means block pruning is completely compatible with using a wallet because blockchain rescans are not necessary.

Most importantly, it means that the time required for a new node to sync is vastly reduced, because instead of needing to download every transaction which has ever occurred, they only need to download transactions from the last week or so, along with the account tree which nodes are programmed to share, and they've got all they need to be a full node.

They will never have to worry about not having some old transaction which has been pruned from their disk because those transactions will never have to be referenced again. The account tree is a self contained balance sheet which tells a node essentially everything it needs to know in order to check balances and validate transactions.

Of course there are a lot of little finicky details like the inversion database which is required for undoing changes made to the account tree in the case of forking, and I would suggest reading the Cryptonite wiki if you want a deeper understanding of how it works. I tried to keep this explanation relatively simple so that it wasn't too hard to understand.

That fix was just so the gateway debugging would work. Do you now see any error messages? And the default gateway already uses the blockchain.info API, among several others, to confirm payments.

Free bootstrap 2 themes can be downloaded from WrapBootstrap and Bootswatch.

I recently had an order by someone going by the name of "Pwner". If you're reading this, please send me a PM because I was unable to send you an email. Your email server seems to be rejecting all incoming emails and that's probably why you have not received any BitShop emails.

The design is just the default Bootstrap theme. Also C++ is oldschool, that doesn't mean it's bad to use. And no it's not laravel PHP, BitShop doesn't use any PHP framework, it's just pure PHP coded from scratch.

Ok it looks like you found a bug. Open /sci/gateways/default/config.html and replace lines 11 and 12 with the following lines:


I will include that fix in the next release.