Tried to post this on r/CryptoCurrency but apparently you need 500 karma and I only have a couple of hundred. Then I tried r/Bitcoin and it just deleted my post without giving me any reason. Hopefully it doesn't disappear into the ether this time. I felt compelled to write this after I read some recent news articles like the one from CoinDesk titled "Bitcoin's Price May Crash After Ethereum's 'Merge,' Researcher Says".

Let me begin by saying I own roughly an equal amount of Bitcoin and Ethereum, I'm not biased towards either one. I have a lot of respect for people like Vitalik who have helped advance cryptocurrency technology. However I can't totally agree with the way Vitalik and some others are portraying PoW and PoS as if they are two opposing solutions and that PoS is clearly the better solution because it's much more energy efficient.

First of all, without any sort of PoW mechanism, a new cryptocurrency must be sold off to buyers in an initial public offering (IPO). I don't think IPO's are a very good way to distribute the initial coins, because it results in a small number of early adopters owning a large fraction of the coins, and it just doesn't feel like it's in line with a decentralized philosophy of money. PoW allows coins to be distributed in a more slow and fair manner.

Once the PoW system starts to reach the end of its viable life-cycle (when block rewards become too small to be economically sustainable) then the consensus system can be switched over to PoS. Multiple coins have done this in the past, and there's no good reason that Bitcoin couldn't do the same thing many decades from now. In fact I'm pretty sure that's what will eventually happen, but not until PoW has done its job distributing coins to miners.

In the case of Bitcoin, it can't be the type of change which could result in a hard-fork, it must require a vast majority. Any big changes should be implemented long before they are planned to go into effect so that people have plenty of time to update their client. The change will automatically go into effect if enough people have updated to the new protocol. I believe this is usually done in the code by checking protocol version numbers in blocks.

Bitcoin has always followed that philosophy and I believe it's the best philosophy for Bitcoin, although I understand other coins like Ethereum have a more rapid development approach and so they have a different philosophy about changing the fundamental consensus mechanisms. Bitcoin is the original coin and it was supposed to be resistant to any type of centralized oversight or manipulation, even from Satoshi himself, and I think it's an important principle.

We should be able to rely on the rigid nature of blockchains to resist change from centralized forces, we need to know the consensus system is reliable and robust, otherwise what is the point of cryptocurrency? Ethereum sort of challenges this notion, and for the most part it has worked, but I think this is mainly because it has some very smart people working on it and those people seem to be generally trustworthy and have the right motives.

Also, less people would use Ethereum and less people would update their client if they felt it was headed in a bad direction, so it's not like Ethereum developers can do anything they want. The risk of a hard-fork is greatly increased when people disagree on a particular change, and it seems the upcoming change from PoW to PoS will probably cause Ethereum to hard-fork. That could also cause NFT's to be duplicated on each version of the chain.

NFT's are supposed to represent unique items, usually art, so a hard-fork does present a slight problem, although I expect the PoW NFT's will quickly lose most of their value once the PoS chain becomes the "official" Ethereum. Vitalik did point out that people can still mine Ethereum classic using PoW if they really want to, instead of creating a new fork of Ethereum. But I'm not sure that will be enough, we'll probably end up with 3 Ethereums.

Classic Ethereum, Ethereum PoS, and Ethereum PoW. This also highlights another issue related to rapid development and constant hard-forks, how many times can we do it before we have too many Ethereums? Another crucial reason Bitcoin should stick to PoW for as long as possible is because there might very well be some security hole in PoS we haven't fully realized yet, I feel PoW is less experimental and has more obvious security guarantees.

PoS rewards the richest people the most just for holding coins without doing any work, my gut tells me it could have unforeseen weaknesses. PoW requires energy, but that's precisely what makes it so secure, and also what separates Bitcoin from a currency which is easy to create out of thin air using little effort. A PoS coin requires an IPO to distribute coins but the initial price of the coin can be decided by the people who created the coin and premined it.

Whereas a PoW coin has its initial price set by the market (e.g. a miner tries to sell coins for more than the cost of energy used to mine the coins). Obviously speculators play a large role in the process, but it's not like the price of Bitcoin is "whatever we agree it is" as we often hear. It seems to me money should be hard to create and the fact bitcoins require energy to create them gives them some underlying value which isn't based purely on speculation.

Vitalik is correct to say the weakness of PoW is at the end of its life-cycle when the block rewards dry up. The weakness of PoS is at the beginning of its life-cycle because you need a fair distribution to decide which stakeholders to reward. This is why PoW and PoS complement each other, PoW can be used to distribute the coins in a fair and market-driven way over a long period (at least several years) then it can shift to PoS when block rewards dry up.

Obviously you could just have unlimited block rewards in a PoW system, but I'm not going to ignore the clear environmental advantages of PoS. There are many other productive things we could be using our energy for, so if we don't really need to burn energy in order to validate and secure the blockchain, then we should try to avoid it. However I believe PoW still plays an important role and we shouldn't throw it aside or buy into this PoW vs PoS narrative.

Support is provided over on the official forum now: www.bitfreak.info/forum/

As I have previously stated I am working on a new coin coded from the ground up using a highly object orientated approach with cross-platform C++11 code and no large libraries like boost, but that will be at least a few months before I even have the foundations complete, and even after it's finished it will still be considered highly experimental. A coin like Cryptonite which at least has several years of history is going to be more trustworthy than a completely new coin, now that this bug has been patched I'd say Cryptonite is quite secure. I'm sure many people are going to be trying the exploit to see if they can get around our fixes, which will help us find any other holes in the protocol. Also I don't really think the attacker managed to shift the market a whole lot so it's not the end of the world, and we don't know how much of the funds were locked by exchanges, I'm sure the attacker would have triggered some alarm bells before being able to sell off all their coins.

As pallas said the bug is only obvious when you know what to look for, there is a lot of code and without knowing what to look for it's very hard to pick out bugs, especially when neither of us were the original dev for Cryptonite. I developed the idea for the mini-blockchain several years ago but my C++ skills were lacking at the time so I hired a dev to create Cryptonite. The work was very rushed and he was working alone so there was bound to be some problems in the code, although I'm still quite suspicious of the original dev because it seems like he should have noticed this bug. Obviously it's embarrassing because a bug like this should not have been there in the first place. However we are lucky the attacker didn't do more damage then they did because they easily could have.

I am always in communication with pallas and we were not aware there was any serious issue until just recently when btc38 made us aware. There were bugs with the wallet but those issues were not linked to this attack.

I cannot really remember what was happening at that time but I don't think there was any active development on Cryptonite in that period and the block explorer was down, which is probably why it went unnoticed. I doubt the exploit had anything to do with wallet problems, the wallet has always been fairly buggy until recently, but many of those stability issues have been solved over the last few months.

Most updates are made on this thread, Twitter, Slack, etc. I never really update the website except for the download page. I might just remove that page and a few others actually. I'm just very busy with several other projects which is why I'm not around much and why Pallas handles most Cryptonite stuff these days.

Ok guys now the main pool and many exchanges have updated to the new version I feel it's safe to release more information about exactly what happened.

Unfortunately it looks like btc38 is going to remove XCN based on that announcement. Btc38 were the ones who first realized something was wrong because they had a suspiciously high number of XCN in their exchange wallet. They notified us there was something wrong a few days ago and I coded up a blockchain analyzer to look for anything suspicious. I discovered that an attacker found a way to create transactions with outputs larger than the inputs, allowing the attacker to essentially create free coins. The first example of the attack can be seen in this block: http://xcn-explorer.selektion21.de/?b=1007085

They were able to generate a negative fee value because of an integer overflow bug, making it possible to have outputs larger than the input value. Obviously there were checks for integer overflows in place but some integers which should have been unsigned were left signed in the worst place possible, either intentionally or by simple mistake, by the original dev. It looks like the attacker spent most of the smaller outputs and left the massive outputs alone, the latest version should block those massive balances but I calculated they were able to get away with around 260 million XCN from the smaller outputs.

We gave btc38 and other exchanges a list of the addresses used by the attacker so they may have been able to freeze some of the attackers funds, based on my analysis it doesn't seem like there's a whole lot of transactions stemming off from the bad transactions. I also want to make it clear this bug has nothing to do with the mini-blockchain technology, the bug in the code was pretty obvious and quite easy to fix just by making some signed integers unsigned. Look at the latest changes on pallas's github to see exactly what we did to prevent this happening again.

In a few days I will release the source code for an XCN blockchain analyzer that I made to find the issue, it should also be useful for building an explorer that works efficiently. I will also release the javascript code I wrote some time ago for creating raw transactions and signing them, which I used to make sure our fix worked and should also be useful for creating a web wallet. Hopefully we can move past this even without too much issue, I was hoping our quick fix would be enough for btc38 not to drop XCN but I cannot blame them for being spooked by this, especially with the new laws in China.

The following is a list of blocks where the exploit was detected:

1007085, 1009490, 1035837, 1044220, 1052967, 1073572, 1103770, 1119219, 1139944, 1171685, 1188258, 1232798, 1246249, 1255968, 1271558, 1274983, 1278864, 1279894, 1281781, 1284716, 1286093, 1288597, 1290084, 1291824, 1294633, 1297819, 1298379, 1300671, 1302547, 1320111, 1320830, 1322596, 1323220, 1350726, 1360510, 1363161, 1364581, 1366301, 1366351, 1367675, 1369704, 1371786, 1373205, 1375144, 1377644

Original thread has been updated.

I'm still around, was just visiting some relatives, back at home now.

If you sync using an old snapshot it may take a while depending on how old your snapshot is because I believe it will try to download all the blocks it has missed. However doing a fresh sync should take about an hour or less if you have good network connectivity, which is very fast when you consider how long any other coin which is several years old will take to synchronize. I haven't synced Bitcoin in a very long time but I've read it now takes several days even with a fast connection.

Hey guys, please give the new Windows wallet a try if you're on Windows, it should be a whole lot more stable now and syncing should work first try, but we want a bit of feedback so we know it will work for the exchanges (apparently some exchanges actually use Windows binaries). Even if you're using an old linux binary you should update your wallet because the sync fix by pallas will make syncing (from scratch) work better for all versions of the wallet.

The wiki contains a brief explanation: http://cryptonite.info/wiki/index.php?title=Coinbase_account#64_bits_of_Granularity

The coin amounts are so large because we use the full 64 bits of precision so have a much larger coin supply than most coins.

I will send you some XCN that I have, I don't have a whole lot so I might just send you all of it. I appreciate you guys trying to keep this coin alive in my absence. Some time ago I did try to figure out the sync issue by looking at the source code but it's so hard to understand such complex code especially when you didn't write that code yourself. I've been thinking seriously about writing a new coin from scratch using the MBC scheme along with some other stuff such as a quantum resistant signature scheme and the homomorphic encryption proposal by B.F. Franca (see this and this). I feel like if XCN did anything it has proven that the MBC scheme can work and isn't easy to exploit since it hasn't been done. I also think that when a coin is created from scratch it feels less like a simple clone of Bitcoin and people can appreciate it more, and it allows us to avoid all the issues inherent with the Bitcoin code. So much of the Bitcoin core code is also made redundant within the MBC scheme, like everything to do with scripts. The goal would be to create simple and elegant code that makes it easier to understand and modify. I would also prefer to avoid using Qt altogether, since the creation of GUI's should be a job for wallet software developers. That would also mean using a robust networking library instead of the one that comes with Qt. This is all just an idea right now, I'd like to hear what you guys think before going ahead with anything.

I have previously tried looking for a specific commit which fixed the issue but couldn't seem to find one. I think the fix may have been included with some larger patch, I'm not really sure. I found several bug reports about random wallet corruption, such as this one, which were made around the start of 2014 and have the same error codes, however it seems they were closed without referencing a commit which solved the issue. I recall our core dev being stumped about the wallet corruption because he didn't change anything that could have caused it, so I'm fairly certain it is a bug inherited from Bitcoin.

Yes it wont be as simple as copying the Bitcoin implementation because we have the whole account tree thing. I have a rough idea as to what would be required, the hard part will be adapting all the changes Bitcoin has undergone in the last few years, much of the code has been overhauled to work in a very different way to how it worked when Cryptonite was forked from it, but many of those changes are necessary to make things like the parallel block downloading work properly.

I didn't code Cryptonite, I helped develop the concepts behind it and funded the development of it. If you read the first pages of this thread you will see we had a core dev but he's no longer around. As I've said before, not having a premine makes it hard to attract developers. I made a mistake assuming that open source developers would continue improving Cryptonite. My C++ skills are still fairly limited so it's unlikely I will be able to solve all these issues myself, but I am looking in the sync issues.

Based on some research I did a few days ago many of the bugs in Cryptonite have been carried over from Bitcoin. For example, there are Bitcoin bug reports about wallet corruption submitted around the time Cryptonite was forked from Bitcoin. The bugs are clearly related because even the error numbers and error messages are the same as the ones reported by people using Cryptonite. I think many of the bugs in Cryptonite could be solved simply by applying many of the fixes which have since been applied to Bitcoin.

The version of Bitcoin used to create Cryptonite also lacked several important features it has now. As I said earlier, the networking code was fairly poor and only allowed the blockchain to be downloaded from one peer at a time. Back then, Bitcoin also didn't download the block headers before downloading blocks, so it had to download blocks in order and couldn't do it in parallel.

Cryptonite was actually the first coin to implement the headers first approach, Bitcoin gained that feature shortly after the release of Cryptonite. However our headers first implementation was rushed and is not as robust as the Bitcoin implementation, and without good networking code we cannot download blocks in a parallel fashion from multiple peers at the same time, which is much faster and less error prone.

Once again I think many problems with Cryptonite could be solved by adapting the new networking code and new syncing code from Bitcoin so that the headers first synchronization works more smoothly. I am looking into how I can make some of these upgrades myself but like I said my skills are limited. Also I wont be back home for another day or two and I'm stuck with a slow laptop which doesn't have much of my software on it.

My point is, Cryptonite needs all the developers it can get right now. I know it's not easy to locate these bugs and fix them because it probably would have been done by someone by now. If we had the original dev it would probably be a lot easier to fix these issues but I doubt he will be coming back any time soon so we need other developers to keep Cryptonite alive.

I have been considering the idea of remaking Cryptonite and implementing a pre-mine, then allowing the old coins to be converted to the new coins, but I'm not exactly sure how that would be done in a fair manner. I'm not sure if that would really be a good idea but at least then we could provide a reason for devs to work on the new version of Cryptonite.

For those people who asked to know more about the syncing process, here's a post I made a little while back:

@pallas: yeah the problems with syncing from scratch have existed for a long time. In my experience the best way to sync is to add a node which is already fully synced and working properly, and configured to share blocks. What exactly does syncing "from scratch" mean though? If you haven't started your XCN wallet in several months it will try to catch up by downloading all the blocks it missed but there's no guarantee any node will have blocks several months old. If you download Cryptonite for the first time or you delete your block files it wont attempt to download every block ever made, it will only download blocks from the last week, but it will download all the block headers (aka the "proof chain"). That process is also known to be fairly buggy from what I remember but I've gotten it to work many times.

@Blockchain Mechanic: well I pretty much just explained the syncing process to pallas. One of the other reasons I believe syncing is so problematic is because Cryptonite was forked from Bitcoin at a time when Bitcoin had rather crappy networking code. When syncing I believe it only downloads the blockchain from a single peer. Since then Bitcoin has obviously improved the networking code and it now downloads blocks in parallel from many different peers but Cryptonite is still stuck with that crappy code, I truly don't know why anyone would create it to work that way in the first place.

@dextronomous: yeah don't worry I'll probably put the block explorer back up, but first I need to recode it to work a bit differently. Like I said I cannot really do much until I get home but that's near the top of my to-do list.

Cryptonite is not a Cryptonote coin, they have no relation.