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
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
I talked to pallas had problems with xcn， but he did not believe it
How do you deal with these problems now?
