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

[Thistleblower]

what is the thing called official explorer? does Bitcoin has such a thing or concept? We alerted fairglue about update and you can see his posts on the matter.

I am still behind my word about better advertisement for you.

That would be the explorer released or promoted by the Supercoin Team, along with the Wallet, and referred to on Page One of this thread, along with all the elaborate promotional material.

[1714641026]

1714641026

[1714641026]

1714641026

[1714641026]

1714641026

[fairglu]

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

Blockdata only affects wallet db, explorer db is synchronized from it, but does its own checks.

However as I wrote, time is not part of the explorer checks, only block order / precedence.

Most likely, you use block time instead of the transaction time to show in the transaction details.

Yes, that's what I explained. I've updated the transaction page to make it more obvious.

I wasn't aware of the time constraint for PoS, and only assumed that block order & time served as reference like for PoW chains.

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.

I'll see about surfacing it in the "raw" technical data. As far as regular users are concerned, I think the block time makes the most sense, as it's the one that matters for confirming things with exchanges, merchants, etc. when looking up a transaction.

Assuming the time field in the transactions is created by a client (is it?), it is not as important as someone could have created a transaction with no or poor connectivity (and the tx would then only be seen by the net after a rebroadcast), or a de-synchronized clock, or just plain faked it by voluntarily adjusting his clock.

(that said, if you feel like other info could be clarified or added, feel free to PM me or open a ticket, might be easier to discuss technical details)

[supercointeam]

Because exchanges never asks when they add a crypto or when they remove. This is their job to watch for forks, willingly added cryptos, they know fork risks, they can build block explorers and follow our thread and github. Or simply they do not add. if exchange sees reports of missing coins, exchange should suspend the trading and investigate. If an exchange missed that or ignore these which serves a good lesson for the future.
we offered  the solution. We will do again if needed. This is not our first fork fix with bittrex. they acted without problem in the old one.

We love bittrex and we have no problem with them. We still want to see them opening our market and will keep them first line within other exchanges if they want to cooperate. Next time i will closely care and alert bittrex before any other exchange. I also suggest them they make a system can follow github updates and they set up own block explorers so it will not be issue there again.

[fairglu]

Please read my previous response.  If you don't understand the ramifications of your actions and are not willing to work with us, there is nothing more I can do to help this community.  Given your stance, we will be reverting to the old fork.  If someone can explain the situation and the necessary solutions more clearly, please do so

And for the record

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.

If you knew of potential problems and didn't tell anyone, and then didn't update the official block explorer when you "fixed" the problem.  The fault lies with you.  We already made sure we followed your block explorer.  

Thanks
richie@bittrex

sounds reasonable, it would be the best if supercoinDEV could respond to this so we have every necessary detail at hand to sort it out.

Well ideally, the checkpoint should have validated the exchanges fork, apparently it validated the other fork, hence the trouble.

If MintPal is on the same fork bittrex was before suspension, then a better solution would be to revert the last update and make the exchange fork the official one.
Then bittrex get their coins back, deposits return to their original wallets, no minting is required, MintPal withdrawals are ok, and the only losses are the stakes performed on the other form (which I guess should be a minor evil).

Of course if MintPal is on a third fork... that would make thinks complicated.

[some138]

Please read my previous response.  If you don't understand the ramifications of your actions and are not willing to work with us, there is nothing more I can do to help this community.  Given your stance, we will be reverting to the old fork.  If someone can explain the situation and the necessary solutions more clearly, please do so

And for the record

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.

If you knew of potential problems and didn't tell anyone, and then didn't update the official block explorer when you "fixed" the problem.  The fault lies with you.  We already made sure we followed your block explorer.  

Thanks
richie@bittrex

I don't get your point there. If you see many reports there for missing coins, you should suspend the trading and investigate. You did not do that, you missed it, now you try to blame the dev. It is your job to watch all the coins trading in your exchange. You are the only one to watch it, not dev, not other people. When you have issues, consult with the dev or check the coin thread. It is as simple as that, I don't see your points trying to find a scapegoat there.

[supercointeam]

@fairglue the chain we picked is the official one we  don't know which chain is in the exchange.

[Thistleblower]

Please read my previous response.  If you don't understand the ramifications of your actions and are not willing to work with us, there is nothing more I can do to help this community.  Given your stance, we will be reverting to the old fork.  If someone can explain the situation and the necessary solutions more clearly, please do so

And for the record

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.

If you knew of potential problems and didn't tell anyone, and then didn't update the official block explorer when you "fixed" the problem.  The fault lies with you.  We already made sure we followed your block explorer.  

Thanks
richie@bittrex

I don't get your point there. If you see many reports there for missing coins, you should suspend the trading and investigate. You did not do that, you missed it, now you try to blame the dev. It is your job to watch all the coins trading in your exchange. You are the only one to watch it, not dev, not other people. When you have issues, consult with the dev or check the coin thread. It is as simple as that, I don't see your points trying to find a scapegoat there.

When the wallet was updated the Block Explorer was Not updated. The Block Explorer is the tool used to investigate the Blockchain. Maintenance of the tools (wallet and explorer) is the responsibility of the Developers.
But neither side is willing to compromise in order to help Investors. And if it's left like that then whichever fork wins, this coin has zero chance of survival. The situation creates no confidence for the future.

[supercoindev]

As supercointeam said, as soon as we found out there are possible forks, we released a new version with new checkpoints. If you use the new version, you can only sync to the correct block chain.

And because the sync time is usually very long (the program will take long time to find out the right chain from the forked ones), we posted the correct block chain files a few days ago. So as long as you download it, and sync from there, it should be pretty fast to sync.

Use block explorer to check if you are on the correct blockchain.

Answers to a few questions:

Q1: Is the github 1.6 version wrong? why I am blocked at block 428419?
A1: The github 1.6 code is correct. If you are blocked at 428419, it means you are on a forked chain. There's a checkpoint at block 428420. This is the purpose of checkpoint. We compiled directly from github and tested a few times, there is no problem at all. Both released 3.1 windows client and the github 1.6 code are correct.

If it takes too long for you to sync, download the blockchain file and sync from there.

Q2: Why fork happen?
A2: Fork happens due to network hash / pos generation unevenly, and also faster block time (which makes transactions a lot faster) may cause forking problems. This fork problem is very common in the alt coins. Most coins have fork issues at one point. Nothing is strange there. When fork occurs, dev team usually release a new version with more checkpoints that block the forked chain. Once everyone use the correct chain, fork will die.

Q3: Why after sync my balance is different?
A3: After fully sync'ed, use repairwallet command in console.

Thanks all for your patience and support.

[supercoindev]

Please read my previous response.  If you don't understand the ramifications of your actions and are not willing to work with us, there is nothing more I can do to help this community.  Given your stance, we will be reverting to the old fork.  If someone can explain the situation and the necessary solutions more clearly, please do so

And for the record

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.

If you knew of potential problems and didn't tell anyone, and then didn't update the official block explorer when you "fixed" the problem.  The fault lies with you.  We already made sure we followed your block explorer.  

Thanks
richie@bittrex

I don't get your point there. If you see many reports there for missing coins, you should suspend the trading and investigate. You did not do that, you missed it, now you try to blame the dev. It is your job to watch all the coins trading in your exchange. You are the only one to watch it, not dev, not other people. When you have issues, consult with the dev or check the coin thread. It is as simple as that, I don't see your points trying to find a scapegoat there.

When the wallet was updated the Block Explorer was Not updated. The Block Explorer is the tool used to investigate the Blockchain. Maintenance of the tools (wallet and explorer) is the responsibility of the Developers.
But neither side is willing to compromise in order to help Investors. And if it's left like that then whichever fork wins, this coin has zero chance of survival. The situation creates no confidence for the future.

Explorers are not done by dev team, we informed as soon as possible the dev for explorer and helped to get it fixed.

Again fork is a common problem. Exchanges are responsible to watch it and suspend trading as needed. The dev team will help as much as we can to resolve the issues.

[brookefinancial]

Lets get first get those on wrong fork go into the right one. We are still working on the issue.

I have some SUPER stuck on bittrex and know people who has some too. We can't really get into the new fork from there and if you change to new fork we will lose them.

??

So if you move to new fork we lose coins on Bittrex?

[ThisNameIsAlreadyInUse]

Q2: Why fork happen?
A2: Fork happens due to network hash / pos generation unevenly, and also faster block time (which makes transactions a lot faster) may cause forking problems. This fork problem is very common in the alt coins. Most coins have fork issues at one point. Nothing is strange there. When fork occurs, dev team usually release a new version with more checkpoints that block the forked chain. Once everyone use the correct chain, fork will die.

bullshit. Everything is explained here:

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:

http://i58.tinypic.com/33kw3fn.png

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.

[jakiman]

Aug 27 20:50 (their time zone )

Hi,

I have deposit issue with Supercoin.

Those are transactions made this night:

Status: 358 confirmations
Date: 8/28/2014 03:42
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -20000.00 SUPER
Transaction fee: -0.0002 SUPER
Net amount: -20000.0002 SUPER
Transaction ID: 1b5954927d98f3b6531c66d33f6454e6ac2c8705a999bb37e677fd5850fe9c99

Status: 308 confirmations
Date: 8/28/2014 04:09
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -793.00 SUPER
Transaction fee: -0.0001 SUPER
Net amount: -793.0001 SUPER
Transaction ID: d2bf4a33bba0b6d380848cde578f7e51764c10e8a12beef3235d1c2d05c1f746


Status: 47 confirmations, broadcast through 3 nodes
Date: 8/28/2014 05:32
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -17.00 SUPER
Transaction fee: -0.0001 SUPER
Net amount: -17.0001 SUPER
Transaction ID: de1bee0788053e4fbc3909c899bb4ed8ef05d8be977ff818662a6730dff638ac

First transaction was sent @ 3:42 am (gmt +1) and now is 5:48 am. Supercoin transactions are very fast, and they should be there in a matter of seconds, not hours :/

All was sent to your bittrex wallet, so, it should be there.

Best regards,

----

No , no, see the date . They had time to respond. They just didn't.

And now I'm guilty? Dev is guilty? Devs didn't do perfect, but they are trying to resolve...

I didn't wrote full mail because of privacy, but at p.m i would printscreen it, no trouble at al...

Richiela, potential fork issue was reported to Bittrex over a week ago it seems right about the time of the first fork.
I would expect an exchange to take these very seriously and perform own checks/tests or disable trade? (and ask the dev here etc)
Heck, even I knew about the potential fork last week and stopped any new transfers after some tiny transfer tests that failed.
Supercoindev fixed the issue very quickly and have official block explorer was updated within a day of the fork fix wallet.
How could they have done better? I believe it was all publicized on twitter when this happened also...

[Thistleblower]

Q2: Why fork happen?
A2: Fork happens due to network hash / pos generation unevenly, and also faster block time (which makes transactions a lot faster) may cause forking problems. This fork problem is very common in the alt coins. Most coins have fork issues at one point. Nothing is strange there. When fork occurs, dev team usually release a new version with more checkpoints that block the forked chain. Once everyone use the correct chain, fork will die.


Thanks all for your patience and support.

Fork will die along with any coin on that fork.
So is this the roadmap for the future? More forks more fixes and more losses? Because uneven pos generation and faster block times will continue to be fundamental properties of the coin.
I should add that my remaining coin are in the latest wallet and staking with approx 30% rejects. This compares with Mammothcoin staking with about 2% rejects. Both using the same codebase.

[jakiman]

Devs, I recommend you guys setup an IRC channel so it can be sorted out more quickly instead of back & forth forum posts here.

[Thistleblower]

Please read my previous response.  If you don't understand the ramifications of your actions and are not willing to work with us, there is nothing more I can do to help this community.  Given your stance, we will be reverting to the old fork.  If someone can explain the situation and the necessary solutions more clearly, please do so

And for the record

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.

If you knew of potential problems and didn't tell anyone, and then didn't update the official block explorer when you "fixed" the problem.  The fault lies with you.  We already made sure we followed your block explorer.  

Thanks
richie@bittrex

I don't get your point there. If you see many reports there for missing coins, you should suspend the trading and investigate. You did not do that, you missed it, now you try to blame the dev. It is your job to watch all the coins trading in your exchange. You are the only one to watch it, not dev, not other people. When you have issues, consult with the dev or check the coin thread. It is as simple as that, I don't see your points trying to find a scapegoat there.

When the wallet was updated the Block Explorer was Not updated. The Block Explorer is the tool used to investigate the Blockchain. Maintenance of the tools (wallet and explorer) is the responsibility of the Developers.
But neither side is willing to compromise in order to help Investors. And if it's left like that then whichever fork wins, this coin has zero chance of survival. The situation creates no confidence for the future.

Explorers are not done by dev team, we informed as soon as possible the dev for explorer and helped to get it fixed.

Again fork is a common problem. Exchanges are responsible to watch it and suspend trading as needed. The dev team will help as much as we can to resolve the issues.

The day after the wallet update. So exchanges were left watching the blockchain with the wrong explorer and Investors were led to the wrong fork.
This is essentially a Management Problem and the fault lies in the complacency of the Supercoin Management Team. Refusal to accept any responsibility merely compounds the errors.

[Grgechkapitalac]

Aug 27 20:50 (their time zone )

Hi,

I have deposit issue with Supercoin.

Those are transactions made this night:

Status: 358 confirmations
Date: 8/28/2014 03:42
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -20000.00 SUPER
Transaction fee: -0.0002 SUPER
Net amount: -20000.0002 SUPER
Transaction ID: 1b5954927d98f3b6531c66d33f6454e6ac2c8705a999bb37e677fd5850fe9c99

Status: 308 confirmations
Date: 8/28/2014 04:09
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -793.00 SUPER
Transaction fee: -0.0001 SUPER
Net amount: -793.0001 SUPER
Transaction ID: d2bf4a33bba0b6d380848cde578f7e51764c10e8a12beef3235d1c2d05c1f746


Status: 47 confirmations, broadcast through 3 nodes
Date: 8/28/2014 05:32
To: ShFY8rm8VCFcUy2FxPXkmYFoR8Wdc2fMUU
Debit: -17.00 SUPER
Transaction fee: -0.0001 SUPER
Net amount: -17.0001 SUPER
Transaction ID: de1bee0788053e4fbc3909c899bb4ed8ef05d8be977ff818662a6730dff638ac

First transaction was sent @ 3:42 am (gmt +1) and now is 5:48 am. Supercoin transactions are very fast, and they should be there in a matter of seconds, not hours :/

All was sent to your bittrex wallet, so, it should be there.

Best regards,

----

No , no, see the date . They had time to respond. They just didn't.

And now I'm guilty? Dev is guilty? Devs didn't do perfect, but they are trying to resolve...

I didn't wrote full mail because of privacy, but at p.m i would printscreen it, no trouble at al...

Richiela, potential fork issue was reported to Bittrex over a week ago it seems right about the time of the first fork.
I would expect an exchange to take these very seriously and perform own checks/tests or disable trade? (and ask the dev here etc)
Heck, even I knew about the potential fork last week and stopped any new transfers after some tiny transfer tests that failed.
Supercoindev fixed the issue very quickly and have official block explorer was updated within a day of the fork fix wallet.
How could they have done better? I believe it was all publicized on twitter when this happened also...

I have even worse problem:

Those coins showed by jakiman - if we are on the new fork - they would be at bittrex , and since they would be on the old fork - i'm losing it

If we are on the old fork - coins are not at the bittrex , so, where are my coins then? Maybe would be in wallet, maybe not...  Either way I could lose this coins, and that's same result as  if I would be scammed.

Before i leave crypto world once and for all, I'm waiting epilog of this situation...

[Grgechkapitalac]

And I'm not the only one.

There are people who could lose more than I.

I am mentally preparing myself as I would have lost everything, because, with this kind of events, that's real possibility too...


If I had remembered well, when vericoin was stolen, they restored the blockchain to earlier state, right?

I am not competent to say does that solves the problem, but...

[jakiman]

I can see reasoning in every side of the story...

- Bittrex could have acted faster. Reports of missing coins to Bittrex started 7 days ago! You can't just blame the devs surely.
- Devs could have acted faster. Faster block explorer update could have helped although it was a bit outside of dev's control.
- Users acted fastest. Many stopped transferring very early on. Reported it to Bittrex, devs etc. But we are losing out...

[Thistleblower]

And I'm not the only one.

There are people who could lose more than I.

I am mentally preparing myself as I would have lost everything, because, with this kind of events, that's real possibility too...

The Community (even those of us who think our coin are safe) would like a fair solution. The developers and exchanges remain obdurate. I have suggested a reduction in pos reward to allow losers a fresh stake on the current blockchain. But the principle players will only act if the community shows solidarity... even at a cost to ourselves. I reject the arrogance and complacency of the Management Team.

[richiela]

I can see reasoning in every side of the story...

- Bittrex could have acted faster. Reports of missing coins to Bittrex started 7 days ago! You can't just blame the devs surely.
- Devs could have acted faster. Faster block explorer update could have helped although it was a bit outside of dev's control.
- Users acted fastest. Many stopped transferring very early on. Reported it to Bittrex, devs etc. But we are losing out...

Just to be clear, when missing coins reports come in, we do investigate and verify on the block explorer that it does not exist.  This is what we do with every coin and why we require an explorer.  It gives us a second point of reference to ensure we are on the right blockchain.  Additionally, we check with other exchanges to make sure we match.  Blockchains are NOT suppose to fork contrary to what the devs are saying.  There is no way to tell what is the "right" or "wrong" fork when the point of reference and all our peers match... in essence, by definition, we are on the right fork.

Does that make sense?