[ANN][SUPERCOIN] Unique Most Advanced Anonymous Trustless Multisig Technology

[ThisNameIsAlreadyInUse]

skipped.

I find alot of things that are currently going on odd...

Like how only the exchanges were forked and yet the seed nodes that supercoin controlled where not showing any forks which then delayed the response from the dev.  Its as if someone found a way to fork the supercoin system and use it to their advantage to then dump imaginary coins on to the exchanges leaving the exchanges as the bagholders once the fork was corrected.  Obviously these coins were sold otherwise why would these exchanges have a problem with accepting the dev's fork?  They can retrieve supercoins but not bitcoins.

I also find it odd that someone with only two posts would some how magically figure out exactly where this fork happened well before the dev would post in this thread.. hmm almost as if you knew where to look...

This whole situation boils down to one fact:  Someone wanted to destroy SuperCoin before it could ever take off.  I am keeping my coins all 136K of them I don't even care if all of you panic and sell it down to a satoshi...  I will just buy them too

I don't want to reveal my identity. Do I have the right to do so? I think yes.

As for knowing where to look - it is simple: just build the wallet form source yourself and try to download the blockchain from scratch, provided you have only connections to nodes running 3.0.1 wallet. Then look into the debug.log when the downloading stops: you will clearly see that the block in question rejected due to the violation I pointed.
The other 'accusation' would mean that I have 51% of all coins as well as I have control over the dev to make necessary changes in his own code.  How otherwise I would succeed to make network mining the fork that is rejected by the proper protocol implementation?

I do not want to destroy the Supercoin as I have some stake that I bought. I want my stake to be fungible with the coins that are in official fork. Presently they are not.

[1714617794]

1714617794

[RCan06]

What also astounds me is that Mintpal is still allowing trading of Supercoin at this time (even after being contacted by Devs and Bittrex, and likely others). What is their motive? They are only making the situation worse by not putting a freeze on trades. They will be out more bitcoin as they continue to allow people to sell on the forked chain (and there is selling on mintpal). They will then expect to be compensated for not being able to freeze trading for the last few days. 

Kudos to Bittrex for atleast checking in this thread and communicating with us.

[brookefinancial]

Aaaaaaandd this is why the amount of money I have invested in crypto is not even the fifth of what I have in the stock market...

The Wild West environment can be a good thing and also a bad thing.

You can still make a quick buck on the stock market, this is a stock I've been holding the last couple of months.



By the way, I don't much about "fork"...What is the issue here and what are the repercussions? I want to inform the investors of SUPER I personally know of the situation.

[fairglu]

The interesting point is that the "official" block explorer hides this from us at least the negative time difference between these transactions:

The explorer shows the block time there, which is the "official" blockchain time, while the time field is client generated (so it's only visible in the explorer under the raw tab), cf.

http://bitcoin.stackexchange.com/questions/5233/which-is-the-reliability-of-a-transaction-timestamp

The explorer wallet are always compiled from GitHub, and the version is visible in the about tab.
However the blockchain db I used was the one provided as download (as can be seen in this thread) as I couldn't synch quickly, and CPU usage was very high.

High CPU usage is btw what prompted me to post about it and suspiciious debug.log entries on the 28

https://bitcointalk.org/index.php?topic=736705.msg8575023#msg8575023

I try to post or notify coin devs ASAP when my explorer monitoring flags "suspicious events", and I'm regularly refining what qualifies as "suspicious events" fwiw

[RCan06]

Aaaaaaandd this is why the amount of money I have invested in crypto is not even the fifth of what I have in the stock market...

The Wild West environment can be a good thing and also a bad thing.

You can still make a quick buck on the stock market, this is a stock I've been holding the last couple of months.



By the way, I don't much about "fork"...What is the issue here and what are the repercussions? I want to inform the investors of SUPER I personally know of the situation.

Agreed, Crypto is an unregulated volatile market anything can happen, but hopefully we don't have to count ourselves short just yet and the situation can be corrected.

Basically a simple version of the problem(I'm sure I'll be corrected on something). The coin runs on a blockchain (agreed upon transaction ledger) of course, and a fork is basically when the blockchain splits in 2, where some users are on one and some users are on the other. In this case most of use are on the updated blockchain, and the exchanges are on the other (refusing to update as of now). I assume the fork happened because many of us were given the updated wallet which was on a new blockchain sync, where as the exchanges and a few others stayed on the outdated wallet (for too long), and were on the old sync. Thus BOTH blockchains were regarded as valid (by those users) for a certain time and continued to update and process transactions as they normally would.

As it is right now, exchanges are still on a separate blockchain and we users are on the updated blockchain. But the two blockchains can't interact, what happens on one blockchain is not valid on the other (they are essentially two separate units). So the repercussions are basically, we can't send/receive supercoins to/from the exchanges until either we revert to their blockchain or they update to ours, but the side that is on the disregarded blockchain will lose all their transactions from the time of the fork, since that blockchain will no longer be accepted as valid.

Basically, If you bought 1BTC of super on mintpal today (on old fork), and mintpal upgrades to new blockchain tomorrow, you will lose your bought supercoin AND still be out your BTC.  (could be wrong though) Exchanges will also lose because anyone who sells will get BTC and the exchange will no longer have the sold Supercoin after the update. (hense the stalemate that needs to be resolved)

[apojii]

OK, let's look into the situation thoroughly.

The point of our interest is the block #412717 that have been minted on Wed Aug 27 10:27:50 UTC 2014:

Code:

{
    "hash" : "0a4b5d908ad166687458b53be3e38026cc0739fe6bdc07f5d1b3fab56d1ab450",
    "confirmations" : 35211,
    "size" : 1483,
    "height" : 412717,
    "version" : 6,
    "merkleroot" : "63df532bbda833e32e5e35351eeece814f676a8913a2b25755cb3970e125d242",
    "mint" : 151.44383561,
    "time" : 1409135270,
    "nonce" : 0,
    "bits" : "1e00f33b",
    "difficulty" : 0.00411126,
    "blocktrust" : "10d709f",
    "chaintrust" : "77fe3838c266eb",
    "previousblockhash" : "e195ffc523b5ae5eb22f276ddf16d371264a50e14efd027734ffcc0d3f648efc",
    "nextblockhash" : "139ce9f8459e2900ac21afac356206aa9caf8e2706719bd211066e20e2a4c0c5",
    "flags" : "proof-of-stake",
    "proofhash" : "005d88032d28e23818f34d32ee6d25646cd6ece09a24857e5bc8220c6c2ed08c",
    "entropybit" : 0,
    "modifier" : "96a50c668d2e6d91",
    "modifierchecksum" : "48e73dfe",
    "tx" : [
        "e56d535befb465438c3462fafc7fad7c8166f1787acd081b8f9a393a02859d87",
        "0fcdfa6eddd4f072ca60c127e964322aeef963104f1f22b2a17564807ea93fc8",
        "16795d47790afc33661739e1f475a190052e4635248299b963974c1bc86f063d"
    ],
    "signature" : "304402204c9d042f5d02aaaf0c9fe2f5ba19b05015e2c81e2362861f8e82943364cf877c022015cadb60241be39a4d287877001e0af5065e16e51e8a9a7080d611a48cc8cee2"
}

First two transactions are usual PoS block preamble, nothing special.

But the third one is very interesting:

Code:

gettransaction 16795d47790afc33661739e1f475a190052e4635248299b963974c1bc86f063d
{
    "txid" : "16795d47790afc33661739e1f475a190052e4635248299b963974c1bc86f063d",
    "version" : 1,
    "time" : 1409130103,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "b6603f95330e3bc35ee55c553d456d262821671369ee5e11bc64343910136214",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "0 3045022100c56a3bc0b0cebee99b0cb34669d487d5625a46ac67faa9fb572b32f52b55c1cf022060db626a364ea7bf7d425543986afe9f8861ffe34a44106a9107b2ca9848a13f01 3044022019c25f281eebb2b7ddedace1c92226428a32f7c4ce0e34c362828bfadfc6ef7a022069cccdffc282d3e500a5ecd55df8b6619647b91e44f1ea0c03384f230c78a9de01 522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae",
                "hex" : "00483045022100c56a3bc0b0cebee99b0cb34669d487d5625a46ac67faa9fb572b32f52b55c1cf022060db626a364ea7bf7d425543986afe9f8861ffe34a44106a9107b2ca9848a13f01473044022019c25f281eebb2b7ddedace1c92226428a32f7c4ce0e34c362828bfadfc6ef7a022069cccdffc282d3e500a5ecd55df8b6619647b91e44f1ea0c03384f230c78a9de014c69522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "e804b04697973c7304f82ac82f70e8505da1c66c2cdd1293643887a904dc3143",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "0 3045022100cdb498b4ce4028755afedde59dc5a4678f81ac0eef769400c4bbe88bad0c0822022044aff6bd5ca7e9bdd4a0be981d478890b9ab054aa8f84066b84f773abf409cc801 3045022100c1bbd5d7469a4ced95f1dc8ae5db8e9141ab5f25d835ee43037ec4a28bd25f1602204a2c46a49c069910d0723a425aa32c3e512d46ad29a46f3f20aed58c929c971601 522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae",
                "hex" : "00483045022100cdb498b4ce4028755afedde59dc5a4678f81ac0eef769400c4bbe88bad0c0822022044aff6bd5ca7e9bdd4a0be981d478890b9ab054aa8f84066b84f773abf409cc801483045022100c1bbd5d7469a4ced95f1dc8ae5db8e9141ab5f25d835ee43037ec4a28bd25f1602204a2c46a49c069910d0723a425aa32c3e512d46ad29a46f3f20aed58c929c9716014c69522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "625889a1b52554ce024019f0ee46d727b1c53e7f25f889d62807e2a8da5e1502",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "0 3045022100c32e46672706d7eb5823cfcff3ec0fb86cc7cbe10f555d4828e39a0e023f222a0220152cef78079b9220360102b1d4007b6bc90dac5c5872d89369003928babafc0001 30440220519e360d7192fad442858d0d00db6b341a6c2bc8543b36123f6919df73b15353022035bdce1f700a668483ad4efdda158ddf8ff403dadb84705dbcd4f6d10e3e33a901 522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae",
                "hex" : "00483045022100c32e46672706d7eb5823cfcff3ec0fb86cc7cbe10f555d4828e39a0e023f222a0220152cef78079b9220360102b1d4007b6bc90dac5c5872d89369003928babafc00014730440220519e360d7192fad442858d0d00db6b341a6c2bc8543b36123f6919df73b15353022035bdce1f700a668483ad4efdda158ddf8ff403dadb84705dbcd4f6d10e3e33a9014c69522103f7a7174ee664978d1884dd1b0f89f2e3edcd0fb256349eb67e6d1a8cd1966cce21022951c076e7edb096f8f8386fcfb67f5fc52cf8cd8d6b0af137135732f49a0d842103c320da380ca359af1fa393b0f3e7088b456c4bef80e050b216670f7ad441f7ad53ae"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 10.00000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 4b07f6645ab0008c0857e272d48c22bd29af66de OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9144b07f6645ab0008c0857e272d48c22bd29af66de88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "SU8jFUH9yThpL6KYUSKLkKXoV4kRdS4DAV"
                ]
            }
        },
        {
            "value" : 20.24975000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 3bb2618a84d8946535a646a6007bfcb2f507a061 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9143bb2618a84d8946535a646a6007bfcb2f507a06188ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "SSjebHo3EG3fKiM6GrNhjyTMDfnis13Bxa"
                ]
            }
        },
        {
            "value" : 10.24975000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 6302900260d686dab3a41424fb8242a22b717e9a OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9146302900260d686dab3a41424fb8242a22b717e9a88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "SWKWzt4YEZfYuGGQYSzg1btp4MpKmwody4"
                ]
            }
        }
    ],
    "blockhash" : "0a4b5d908ad166687458b53be3e38026cc0739fe6bdc07f5d1b3fab56d1ab450",
    "confirmations" : 35219
}

Note, it has timestamp 1409130103.
Also, note, that it has three inputs and three outputs with approximately the same amounts (minus fees). So, this transaction have been specially crafted as it has no change output. Was it crafted by human or automatically - has no importance, the key point it is unusual transaction.

Let's look at it's first input source transaction:

Code:

gettransaction b6603f95330e3bc35ee55c553d456d262821671369ee5e11bc64343910136214
{
    "txid" : "b6603f95330e3bc35ee55c553d456d262821671369ee5e11bc64343910136214",
    "version" : 1,
    "time" : 1409130117,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "73259d469d621e9b6c5ab18f9692025aab1598fb92f63d1389b9210cd06de987",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304502210091deba8388ec111d5ff15ec58f990fd9c5be96e7ca4487489ef9671d9c73e3800220579a43fda3943457229c98593b1ddaf8d4328b29d4fcde555b709a88b20f277d01 0202697e3e01c730f832705ed1f67f1dd264538b55aaabd4f20e5621ccb1028706",
                "hex" : "48304502210091deba8388ec111d5ff15ec58f990fd9c5be96e7ca4487489ef9671d9c73e3800220579a43fda3943457229c98593b1ddaf8d4328b29d4fcde555b709a88b20f277d01210202697e3e01c730f832705ed1f67f1dd264538b55aaabd4f20e5621ccb1028706"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 29.49980000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 8509d7a3e07af07ede52b544896ac952935bc793 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9148509d7a3e07af07ede52b544896ac952935bc79388ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "SZRShDKwFbpGyWfzWhsRNsoG5c2kXYRpxC"
                ]
            }
        },
        {
            "value" : 20.50000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_HASH160 cadc04751928af98d2793d4c2551e66daaeb12c3 OP_EQUAL",
                "hex" : "a914cadc04751928af98d2793d4c2551e66daaeb12c387",
                "reqSigs" : 1,
                "type" : "scripthash",
                "addresses" : [
                    "CaxWdsLq6hxSnRemfQNmRNXUqmRBG8QgUJ"
                ]
            }
        }
    ],
    "blockhash" : "e13d587bf843a67e617bbac11236e9834bddcaa26eb6dfbe4acaeed69f855e85",
    "confirmations" : 35628
}

It has the timestamp 1409130117, i.e., 14 seconds later than the transaction spending its output! Also, it is included into the block e13d587bf843a67e617bbac11236e9834bddcaa26eb6dfbe4acaeed69f855e85",
at height 412420!!!

The standard implementation of the bitcoin protocol would never accept such a transaction or a block containing such a transaction. Let's look into the Supercoin's publicly available source code, the CTransaction::ConnectInputs function:
https://github.com/supercoinproject/supercoin/blob/3db664be97960b3acc2d074d72e70f7828c9a61b/src/main.cpp#L1515

Code:

            // ppcoin: check transaction timestamp
            if (txPrev.nTime > nTime)
                return DoS(100, error("ConnectInputs() : transaction timestamp earlier than input transaction"));

So, the check is in place. That means that the block 0a4b5d908ad166687458b53be3e38026cc0739fe6bdc07f5d1b3fab56d1ab450 have been mint with a wallet that has at least this check relaxed.

The interesting point is that the "official" block explorer hides this from us at least the negative time difference between these transactions:



this means that either the cryptoid's op is in the same boat with the Supercoin's dev or the dev made him to install special version of the wallet.

So, the fork happened on  Wed Aug 27 10:27:50 UTC 2014.
You informed the exchanges on Sept 2:

We informed from our thread about wallet updates, fixes, released 2 wallets, alerted twitter also i opened ticket each exchanges (early today) this is exchange responsibility to follow forks. We cant do much here. I have not seen in my 2 nodes any fork.

Now, what we have. We have two blockchains. The one has many protocol violations and in advance of the second one by 16k blocks, that means that people spent electricity on this chain and thus made investment. The over one is the correct from the protocol perspective and had huge deposit, trade and withdrawal activity since fork. So it will be unfair to abandon any of these chains as some part of investors would be cheated.

What you can do, dev, to save your face? As things described above are consequences of your mistakes/intentional actions, it will be completely fair if you cover all loses.

How this could be accomplished? This way:

first, all exchanges should stop the trading (at least two already did). Then you arrange with the exchanges bitcoin multisig address, where you deposit some amount of BTC at their (or community) discretion, that is good enough to protect the community from any further scam. Next, one (or all exchanges) switch to the longest (that you call official) fork and enable trades.
Then you should credit all addresses that have unspent to the date of freezing trades on all exchanges inputs on the shorter fork with equal amount of coins on the longest fork. Where do you get these coins? You could spend your own, you could by them from exchange on the 'official' fork.
When these unspent inputs are covered in the 'official' chain and you release the open source code that is capable to download the blockchain from scratch  - your funds on locked multisig address may be released back to you.

Unless you do so - you are SCAMMER!

P.S. I am crossposting this in the original Supercoin thread so you could not delete this.

I find alot of things that are currently going on odd...

Like how only the exchanges were forked and yet the seed nodes that supercoin controlled where not showing any forks which then delayed the response from the dev.  Its as if someone found a way to fork the supercoin system and use it to their advantage to then dump imaginary coins on to the exchanges leaving the exchanges as the bagholders once the fork was corrected.  Obviously these coins were sold otherwise why would these exchanges have a problem with accepting the dev's fork?  They can retrieve supercoins but not bitcoins.

I also find it odd that someone with only two posts would some how magically figure out exactly where this fork happened well before the dev would post in this thread.. hmm almost as if you knew where to look...

This whole situation boils down to one fact:  Someone wanted to destroy SuperCoin before it could ever take off.  I am keeping my coins all 136K of them I don't even care if all of you panic and sell it down to a satoshi...  I will just buy them too

I looks the price every day, there are not enough buy support about 400k supers above now price, that means even though he do that, he just receive 2 bitcoins, it is not worth to do that

[ThisNameIsAlreadyInUse]

The interesting point is that the "official" block explorer hides this from us at least the negative time difference between these transactions:

The explorer shows the block time there, which is the "official" blockchain time, while the time field is client generated (so it's only visible in the explorer under the raw tab), cf.

http://bitcoin.stackexchange.com/questions/5233/which-is-the-reliability-of-a-transaction-timestamp

The explorer wallet are always compiled from GitHub, and the version is visible in the about tab.
However the blockchain db I used was the one provided as download (as can be seen in this thread) as I couldn't synch quickly, and CPU usage was very high.

High CPU usage is btw what prompted me to post about it and suspiciious debug.log entries on the 28

https://bitcointalk.org/index.php?topic=736705.msg8575023#msg8575023

I try to post or notify coin devs ASAP when my explorer monitoring flags "suspicious events", and I'm regularly refining what qualifies as "suspicious events" fwiw

The answer you pointed to says:

The timestamp is not a part of the standard transaction as per Bitcoin Protocol Specification. It is most likely generated by the standard client during the api call. The standard client might use its internal time (that might differ from the machine time), which is vulnerable to timejacking. I might be wrong, however.

Now:
rpcrawtransaction, line 51:

Code:

entry.push_back(Pair("time", (boost::int64_t)tx.nTime));

The transaction signing procedure is quite complex and heavy to cite here, but the tx.nTime field is signed with input's private keys, i.e. one can't alter it without changing the hash of transaction, merkle tree hash, hash of the block, containing this tx and, finally, the complete subchain of that block.

I have no idea and I don't want to know why your explorer code shows the time that is 1 hour before. I believe my eyes: I tried to download the blockchain with the wallet I built from source provided and I failed to get synchronized. Then I started to look into the bits.

Anyway, if your software monitors for inconsistencies, can you explain why it is quiet about the fact that transaction in block #412717 spends an output of the transaction in block #412420 that has a time in the future? This is a rhetoric question. No need to answer.

[Grgechkapitalac]

From my 2 cents here - We - small investors, and ordinary people are screwed anyway. It's not even matter who's guilty anymore.

If developers accept the terms - coin is dead.

If not - coin is also dead.

Some of us couldn't even dump, regardless of the fact would they want it to, or not. I tried sending small ammounts to the exchanges - 0 has arrived.

So, we could just sit in our chairs, frozen, unable to do anything, and watch it die. Slow painful death.

Apologies to those who I told to not to dump... I hope they did.

It's not anymore about the money, it's about the trust - and that's gone.

After this, I will never enter the cryptoworld again.

It is better to be stupid and lose everything in a bad trade than loosing it for being naive, optimistic, and trying to believe in something like child does when playing in the ground and thinks about future. That's foolish. There is no future. It's a scamworld.

Lesson learned.

And now, excuse me, I must go back to the real world...Super fast, lightning speed ...sobering.

P.S. Thank you SuperBull for everything. I know it's not your fault. Maybe you have lost a money, but got yourself a friend. If the road gets you here, you are more than wellcome.

[fairglu]

The transaction signing procedure is quite complex and heavy to cite here, but the tx.nTime field is signed with input's private keys, i.e. one can't alter it without changing the hash of transaction, merkle tree hash, hash of the block, containing this tx and, finally, the complete subchain of that block.

The signing means the time field can't be changed, not that it's correct or trustable.

I'll readily admit I haven't investigated more, the time (even at block level) is often inconsistent in the various blockchains, it's common to have the next block in a chain with a time stamp in a relative past, and that's the case for bitcoin as well. There are limits to the allowed drift, but they vary between coins.

The consistency checks in that area by the explorer are thus only based on the precedence in the blockchain.

That said I can confirm the synchronization issues with the blockchain (which I posted about, though my wallet got stuck at a different height), and the explorer shows the blockchain db that was downloaded from the dev, not the result of a synchronization from scratch.

As for the time discrepancy you refer to, for long forks like here things are usually a mess with clients on different forks sending transactions that get accepted at different points on the various forks. It's really a case of a "blocktree" more than a blockchain.
Not saying there couldn't have been an attack, but the super network was (and still is) vulnerable because few wallets are staking (this btw the whole purpose behind the staking stats I've been adding to the explorers).
Only 46 addresses did the staking for the last 1000 blocks, and rich #1 accounted for 30% of blocks, despite holding 4.6% of coins...

I've recently had two other blockchains that forked when a whale's wallet came online, probably with limited connectivity (like a PC on a wifi at home) but had enough staking funds for a low difficulty to stake and make the blockchain progress on his own.

This is a very real and non-rethorical problem with staking coins, way too many rely on a handful of staking wallets, which are run on PC/Mac and thus aren't even online 24/7. Couple that with fast difficulty retargets, and wallet with a few percents of the coins can achieve dominance at certain times of the day.

[supercointeam]

There is so many negativity, do not allow others confuse your mind. We are here everyday and we know who is new here and why!

It was very simple, we have some reports about forking, some said yes some said no, we could not be sure, we checked our nodes, no problem there. We watched the issue few days.

Then once we got few more we decided to force sync. Then we released new wallet with more secured points.
During this time i was here and did my best to understand and act.

We have paid actually 3 block explorers first one did not want to update and asked too much btc or so then we reached fairglue and btcltcdigger.
both made block explorers, we made our efforts to help  our users to see better in blockchain.

As explained many times as soon as bittrex an exchange contacted us
we answered back to the exchange with best of we can. The Exchange asked to cover its loss with new fork We rejected. This is not our problem that they discipline us for their irresponsibilities.

Because these rejecting we have seen new members in this thread both forcing the fork and trying to blur the reality of the efforts being made to solve problem. 

I will read them and see what we can do under the light of good for all.

[supercointeam]

This situation is becoming a problem.

Both sides need to come to an agreement soon. And also supercointeam, exchanges are a must. In business you need to often set aside differences for the good of making money. A coin without exchanges like bittrex, mintpal, cryptsy, is like a car without an engine, it won't go anywhere. Please do not say we are simply going to dump these exchanges and move on. That would be a terrible business move for supercoin. Everyone must settle their differences an be on the same page so we can all move on.

Exchanges should update their wallets so we can move coins that are just sitting there. Its quite hypocritical of bittrex to say "dev provided no plan for aiding those impacted in recovering lost funds" when the main reason we have lost funds is because exchanges aren't updating their wallets and many of us have coins at exchanges or in transit waiting to arrive to or from exchanges once a wallet is updated. Where is bittrex plan in aiding lost funds? A simple update would be a good plan.

Also where is mintpal? They haven't even disabled trading or supercoin transactions. Not every holder is able to check this thread daily, mintpal should be aware enough to not let people withdraw thousands of Super on an old chain, pretty irresponsible.

It's strange that other 3 exchanges though i contacted by tickets, tweets they did not disable the markets or answered back to me. Maybe they are on true fork or they simply deny.

As you can see i can do nothing about an exchange adding or removing or disabling us. They never asks before adding or removing to dev team. We try with best of we can to understand and solve the problems.

I plan for the future we focus only 1 exchange (bter or btc38 or c-cex or etc) and i will remove the rest. This one exchange we will closely monitor network. In worst case we can build our own exchange by community.

[ThisNameIsAlreadyInUse]

The transaction signing procedure is quite complex and heavy to cite here, but the tx.nTime field is signed with input's private keys, i.e. one can't alter it without changing the hash of transaction, merkle tree hash, hash of the block, containing this tx and, finally, the complete subchain of that block.

The signing means the time field can't be changed, not that it's correct or trustable.

I'll readily admit I haven't investigated more, the time (even at block level) is often inconsistent in the various blockchains, it's common to have the next block in a chain with a time stamp in a relative past, and that's the case for bitcoin as well. There are limits to the allowed drift, but they vary between coins.

The consistency checks in that area by the explorer are thus only based on the precedence in the blockchain.

That said I can confirm the synchronization issues with the blockchain (which I posted about, though my wallet got stuck at a different height), and the explorer shows the blockchain db that was downloaded from the dev, not the result of a synchronization from scratch.

As for the time discrepancy you refer to, for long forks like here things are usually a mess with clients on different forks sending transactions that get accepted at different points on the various forks. It's really a case of a "blocktree" more than a blockchain.
Not saying there couldn't have been an attack, but the super network was (and still is) vulnerable because few wallets are staking (this btw the whole purpose behind the staking stats I've been adding to the explorers).
Only 46 addresses did the staking for the last 1000 blocks, and rich #1 accounted for 30% of blocks, despite holding 4.6% of coins...

I've recently had two other blockchains that forked when a whale's wallet came online, probably with limited connectivity (like a PC on a wifi at home) but had enough staking funds for a low difficulty to stake and make the blockchain progress on his own.

This is a very real and non-rethorical problem with staking coins, way too many rely on a handful of staking wallets, which are run on PC/Mac and thus aren't even online 24/7. Couple that with fast difficulty retargets, and wallet with a few percents of the coins can achieve dominance at certain times of the day.

As you used the blockdata prepared by dev, your checks (these that are in place) seems not been triggered.

I would not argue that there are many things that could happen with timestamps in the blockchain. But two things could never happen with the commonly used PoS coin design implementation and, particularly, Supercoin, a fresh fork from Novacoin codebase:

1) a block may not contain a transaction with time in the future compare to coinstake transaction.
2) a transaction may not spend an output of the transaction with timestamp in the future.

While the first rule has no relation to the case, the second one is violated by the transaction in question. This could not be achieved with a wallet built from published source code. That wallet would not process such transactions nor accept blocks containing such transactions.

I just checked the time of block #412420: it is 2014-08-27 09:02:22. Most likely, you use block time instead of the transaction time to show in the transaction details. If this is true then I apologize for accusations. But I would change this to actual time of transaction if I were you, as your current implementation is inconsistent with the data that might be acquired by other means.

[supercointeam]

When my other team friend come i'll post once more the final situation and what we can do and if any technical explanation. Have no worry, we are like first day fresh and will get the Supercoin back to the line. We will clear any issue pop ups.

Our job is to protect  the network. I will not allow exchanges blocking our developments.

We made world first Multisig based trustless wallet. We were rising before fork issue happens. We had many attacks saved ourself well. We will also overcome this.

[ThisNameIsAlreadyInUse]

When my other team friend come i'll post once more the final situation and what we can do and if any technical explanation. Have no worry, we are like first day fresh and will get the Supercoin back to the line. We will clear any issue pop ups.

Our job is to protect  the network. I will not allow exchanges blocking our developments.

We made world first Multisig based trustless wallet. We were rising before fork issue happens. We had many attacks saved ourself well. We will also overcome this.

I do hope you'll take the right decision.

[supercointeam]

When my other team friend come i'll post once more the final situation and what we can do and if any technical explanation. Have no worry, we are like first day fresh and will get the Supercoin back to the line. We will clear any issue pop ups.

Our job is to protect  the network. I will not allow exchanges blocking our developments.

We made world first Multisig based trustless wallet. We were rising before fork issue happens. We had many attacks saved ourself well. We will also overcome this.

I do hope you'll take the right decision.

Thank you. As said many times before i want to protect all or most parties involved. stay calm pls thank you.

[digi123]

If an exchange looses coins and it isn't the fault of the particular exchange.

If it turns out that coins are needed as a part of a fix to this.
To make up the amount of coins that are needed would it be possible to -

 1/ Take of say 25% (or any amount agreed upon) of the normal 100% minting payments, to pay off those who have lost coins.

or

 2/ What if the extra 50% minting payment for having over 100,000 coins went to make the exchanges whole again the amount of coins they are out.
I don't know if this extra payment has started yet, if not then this is used first to pay exchanges until all is paid off, then back to normal payments.

 3/ Use 1 or 2, but whatever is easiest to implement, and agreed upon.

If exchanges end out loosing coins it is only right that something should be done to help make up for it.

Remember any overall lose is better than the coin being removed and being discontinued, for the exchange and coin holders and developers.

As has been mentioned similar to this has occurred before and fixed. There should easily be a fix to this, but everyone needs to be flexible.
 
This method of raising coins could further be used by management for use with such things as promotions video's or whatever is needed in the future instead of asking for donations all the time.

[supercointeam]

The transaction signing procedure is quite complex and heavy to cite here, but the tx.nTime field is signed with input's private keys, i.e. one can't alter it without changing the hash of transaction, merkle tree hash, hash of the block, containing this tx and, finally, the complete subchain of that block.

The signing means the time field can't be changed, not that it's correct or trustable.

I'll readily admit I haven't investigated more, the time (even at block level) is often inconsistent in the various blockchains, it's common to have the next block in a chain with a time stamp in a relative past, and that's the case for bitcoin as well. There are limits to the allowed drift, but they vary between coins.

The consistency checks in that area by the explorer are thus only based on the precedence in the blockchain.

That said I can confirm the synchronization issues with the blockchain (which I posted about, though my wallet got stuck at a different height), and the explorer shows the blockchain db that was downloaded from the dev, not the result of a synchronization from scratch.

As for the time discrepancy you refer to, for long forks like here things are usually a mess with clients on different forks sending transactions that get accepted at different points on the various forks. It's really a case of a "blocktree" more than a blockchain.
Not saying there couldn't have been an attack, but the super network was (and still is) vulnerable because few wallets are staking (this btw the whole purpose behind the staking stats I've been adding to the explorers).
Only 46 addresses did the staking for the last 1000 blocks, and rich #1 accounted for 30% of blocks, despite holding 4.6% of coins...

I've recently had two other blockchains that forked when a whale's wallet came online, probably with limited connectivity (like a PC on a wifi at home) but had enough staking funds for a low difficulty to stake and make the blockchain progress on his own.

This is a very real and non-rethorical problem with staking coins, way too many rely on a handful of staking wallets, which are run on PC/Mac and thus aren't even online 24/7. Couple that with fast difficulty retargets, and wallet with a few percents of the coins can achieve dominance at certain times of the day.

Thank you for sharing this data.

[some138]

I found a lot nonsense here in the thread. The forks occur from time to time in coins, when this happen, what do the devs do? They identify the correct chain, and put some checkpoints to support the chain, and that's it. People who use the new version will be in the correct chain.

The supercoin dev team did the right things. Now if the fork is not fully supressed, then they need to put more checkpoints and eliminate other forked chains.

[CoinMin3r]

Ok the situation suggests that it'd better give other chain the official one for now as all exchangers are with it & majority is there.
Because if we go with new chain many investors will loose their coins which they bought from exchangers.
But if we go with old one only some of us will loose some stake which we got within this fork time.Then we can go with mandatory new wallet upgrade.

Sorry if I am wrong.It is just my thought.

[supercointeam]

We are not an exchange manager who decide and paid for the coins he add we cant follow forks as their staff members. Does satoshi alerts exchanges when fork happens?

But they dont question it but question Supercoin and other altcoins "pay this or we shut down your exchange" style.
We cant do much here. They play unfair. We were gentlemen offered them more ad space. I try to show them how good super was doing before fork and they can think to cover their accidental loses in the future.

We released new wallet with more secure checkpoints like usual. Other exchanges seem to have no issues. (As they keep opened the market)
We dont know but we alerted all to protect our community from irresposible exchanges. And just to be sure i removed all exchanges will put once one of them confirm that they are on true chain.