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

[richiela]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

My decision is based on you and the community.  Our systems will not allow us to open the exchange or wallet back up when the balances are off.  It's how its designed.  We need a way to make our balance right... I'm open to suggestions ...

[1714036827]

1714036827

[supercointeam]

Our purpose here is to protect Supercoin for the good of all parties involved.

[Thistleblower]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

So, if I read this right, you're rejecting the proposals already on the table, and waiting for the exchanges to propose something that you find acceptable. In the meanwhile investors are facing the prospect of being left heavily out of pocket with a coin operating on Two (or more) forks. If this isn't resolved very soon the coin will be Dead and the matter will be academic. No other exchanges will trust a coin in terminal decline with developers and exchanges fighting over who's to blame.

It's not just the job of the exchanges to monitor the health of the coin. The developers have a responsibility to monitor it's progress and ensure that it is working without issues. Other coins have weathered similar storms through Hard Work, Hard Forks, Cooperation and Compromise. Pleas make it happen while there's still some goodwill left in the community.

[Ticked]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

So, if I read this right, you're rejecting the proposals already on the table, and waiting for the exchanges to propose something that you find acceptable. In the meanwhile investors are facing the prospect of being left heavily out of pocket with a coin operating on Two (or more) forks. If this isn't resolved very soon the coin will be Dead and the matter will be academic. No other exchanges will trust a coin in terminal decline with developers and exchanges fighting over who's to blame.

It's not just the job of the exchanges to monitor the health of the coin. The developers have a responsibility to monitor it's progress and ensure that it is working without issues. Other coins have weathered similar storms through Hard Work, Hard Forks, Cooperation and Compromise. Pleas make it happen while there's still some goodwill left in the community.

The fact that this post leads off with "So, if I read this right...." furthers the point that the largest trouble here is communication and understanding.

Dev, if you are working for the good of the coin, team, & community, you will be more fluid with your ideas for conflict resolution. Working through this whilst opposing exchanges will breed contempt and distrust from the investors. Working through this cooperatively with exchanges will show solidarity and build trust amongst investors.

Your counter proposal of 'I said you what i can do like putting in front of others more ads and future business.' speaks in terms of potential future payouts.  Your asking the exchange to take on more potential risk for one of many possible outcomes. In short, you're demanding respect from the exchange that isn't yet entirely deserved. There has to be a more neutral solution.

Why cant we just roll back trades & blockchain to before the fork and restart from there? [I'm not technical, so if this is absurd, excuse me.]

[CryptoJohn]

@Superteam

Once again you are letting your ego get in the way of progress. Do not fool yourself, you need the exchanges more than they need you. Should you blow this with the main exchanges those shitty chinese exchanges will not be enough the recover this coin.

We the community need for you to get your mind right and work this out with Bittrex. Richie has been more than respectful and offered a solution and again you have shown the inability to process the information and provide a respectful response.

You continue to boast about your "superior" technology and yet something as simple as a fork issue seems to stump you and the team. We now have a super problem.

[Thistleblower]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

So, if I read this right, you're rejecting the proposals already on the table, and waiting for the exchanges to propose something that you find acceptable. In the meanwhile investors are facing the prospect of being left heavily out of pocket with a coin operating on Two (or more) forks. If this isn't resolved very soon the coin will be Dead and the matter will be academic. No other exchanges will trust a coin in terminal decline with developers and exchanges fighting over who's to blame.

It's not just the job of the exchanges to monitor the health of the coin. The developers have a responsibility to monitor it's progress and ensure that it is working without issues. Other coins have weathered similar storms through Hard Work, Hard Forks, Cooperation and Compromise. Pleas make it happen while there's still some goodwill left in the community.

The fact that this post leads off with "So, if I read this right...." furthers the point that the largest trouble here is communication and understanding.

Dev, if you are working for the good of the coin, team, & community, you will be more fluid with your ideas for conflict resolution. Working through this whilst opposing exchanges will breed contempt and distrust from the investors. Working through this cooperatively with exchanges will show solidarity and build trust amongst investors.

Your counter proposal of 'I said you what i can do like putting in front of others more ads and future business.' speaks in terms of potential future payouts.  Your asking the exchange to take on more potential risk for one of many possible outcomes. In short, you're demanding respect from the exchange that isn't yet entirely deserved. There has to be a more neutral solution.

Why cant we just roll back trades & blockchain to before the fork and restart from there? [I'm not technical, so if this is absurd, excuse me.]

You can cancel all transactions form any point that you choose... but you can't force the return of any goods or bitcoin not connected to the blockchain. Reconstruction or reinstatement of those transactions would seem virtually impossible. So anyone who's bought coins or sold goods and services on the wrong fork has effectively lost out. And it's not yet certain which is the 'wrong' fork, as the exchanges control a significant portion of the blockchain.

[Majormax]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

So, if I read this right, you're rejecting the proposals already on the table, and waiting for the exchanges to propose something that you find acceptable. In the meanwhile investors are facing the prospect of being left heavily out of pocket with a coin operating on Two (or more) forks. If this isn't resolved very soon the coin will be Dead and the matter will be academic. No other exchanges will trust a coin in terminal decline with developers and exchanges fighting over who's to blame.

It's not just the job of the exchanges to monitor the health of the coin. The developers have a responsibility to monitor it's progress and ensure that it is working without issues. Other coins have weathered similar storms through Hard Work, Hard Forks, Cooperation and Compromise. Pleas make it happen while there's still some goodwill left in the community.

The fact that this post leads off with "So, if I read this right...." furthers the point that the largest trouble here is communication and understanding.

Dev, if you are working for the good of the coin, team, & community, you will be more fluid with your ideas for conflict resolution. Working through this whilst opposing exchanges will breed contempt and distrust from the investors. Working through this cooperatively with exchanges will show solidarity and build trust amongst investors.

Your counter proposal of 'I said you what i can do like putting in front of others more ads and future business.' speaks in terms of potential future payouts.  Your asking the exchange to take on more potential risk for one of many possible outcomes. In short, you're demanding respect from the exchange that isn't yet entirely deserved. There has to be a more neutral solution.

Why cant we just roll back trades & blockchain to before the fork and restart from there? [I'm not technical, so if this is absurd, excuse me.]

You can cancel all transactions form any point that you choose... but you can't force the return of any goods or bitcoin not connected to the blockchain. Reconstruction or reinstatement of those transactions would seem virtually impossible. So anyone who's bought coins or sold goods and services on the wrong fork has effectively lost out. And it's not yet certain which is the 'wrong' fork, as the exchanges control a significant portion of the blockchain.

Yes, that's right.

However , it's important to distinguish 'Trades' from 'Transactions' . Transactions either happened on the correct fork, or didn't happen, and coins will be back where they started (not lost) when everyone is on the correct fork. 'Trades' are buys or sells for other currencies, and therefore there is a potential loser if they are rolled back. That is the important distinction for an exchange and its customers.

[pak]

If we cannot come to a solution, we will just close the market and leave the wallet open on the old for for people to withdraw.

This is not correct, I have bought the super on your exchange, but I bought super, not air, and I paid in BTC, not air. Why do I get the air? Give me super (the good ones) or BTC.
Can I trust in a currency or an exchange, which makes me lose 0,41BTC = 195$ ?
Find a solution, is the only way.
Problems can happen, success depends on how you manage it.
I apologize for my bad English.

[Thistleblower]

@Richie i want you to understand, we as dev team are not trying to lose you. I told this also at irc chat. After your first post, i posted my answer and came to IRC in less than 2 hours

I speak about myself i am not the all dev team but decisions taken like fork or extra coin minting together as team.  I said you what i can do like putting in front of others more ads and future business. This is not a way of saying go away. We still hold bittex in OP and want to keep so.

So i wait from you the decision please do your best to handle, i am not an exchange manager. and certainly you are a good one. So you do your job and allow me i do mine.

thx. for post and hope you give our community some good news

So, if I read this right, you're rejecting the proposals already on the table, and waiting for the exchanges to propose something that you find acceptable. In the meanwhile investors are facing the prospect of being left heavily out of pocket with a coin operating on Two (or more) forks. If this isn't resolved very soon the coin will be Dead and the matter will be academic. No other exchanges will trust a coin in terminal decline with developers and exchanges fighting over who's to blame.

It's not just the job of the exchanges to monitor the health of the coin. The developers have a responsibility to monitor it's progress and ensure that it is working without issues. Other coins have weathered similar storms through Hard Work, Hard Forks, Cooperation and Compromise. Pleas make it happen while there's still some goodwill left in the community.

The fact that this post leads off with "So, if I read this right...." furthers the point that the largest trouble here is communication and understanding.

Dev, if you are working for the good of the coin, team, & community, you will be more fluid with your ideas for conflict resolution. Working through this whilst opposing exchanges will breed contempt and distrust from the investors. Working through this cooperatively with exchanges will show solidarity and build trust amongst investors.

Your counter proposal of 'I said you what i can do like putting in front of others more ads and future business.' speaks in terms of potential future payouts.  Your asking the exchange to take on more potential risk for one of many possible outcomes. In short, you're demanding respect from the exchange that isn't yet entirely deserved. There has to be a more neutral solution.

Why cant we just roll back trades & blockchain to before the fork and restart from there? [I'm not technical, so if this is absurd, excuse me.]

You can cancel all transactions form any point that you choose... but you can't force the return of any goods or bitcoin not connected to the blockchain. Reconstruction or reinstatement of those transactions would seem virtually impossible. So anyone who's bought coins or sold goods and services on the wrong fork has effectively lost out. And it's not yet certain which is the 'wrong' fork, as the exchanges control a significant portion of the blockchain.

Yes, that's right.

However , it's important to distinguish 'Trades' from 'Transactions' . Transactions either happened on the correct fork, or didn't happen, and coins will be back where they started (not lost) when everyone is on the correct fork. 'Trades' are buys or sells for other currencies, and therefore there is a potential loser if they are rolled back. That is the important distinction for an exchange and its customers.

If I charge you a fee for handing out advice, and you pay me say, 100000 Super, then that is a transaction. If the 100000 super are on the 'wrong' fork, then a rollback will return the 100000 super to your wallet, (unless you accepted them on the wrong fork, in payment for a BMW, say) leaving me to seek payment all over again. The same applies even without a fork, if the blockchain is rolled back and restarted. Needless to say, any POS coins issued after the rollback point will become void, thus adding to the confusion. And the chaos merely increases as the situation drags on, with (potentially) multiple forks each generating their own coin and transactions.

[ThisNameIsAlreadyInUse]

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]

So basically,

Bittrex received a lot of deposits from the wrong fork and is now in their system but not on the wallet.
Bittrex will not go to the new fork because they will lose out if they go to the new fork. Who's fault is that?

My questions are:

1. Why did we fork?
2. Can we all just go back to the fork that the exchanges are on?

I only made tiny test transfers during this whole fiasco so either fork works for me.
Dev, what's the problem with going back to the old fork which all exchanges are on?

[vegasguy]

Guys I know this seems complicated, but being in business for 20 years , there is always an answer. Here they are:

1. Above all else HALT ALL transactions with all wallets until this is sorted. Its just making it worse.
2. Figure out the right fork, and put an update to wallet 3.2 with the right fork on the op. This will stop the bleeding. Send new wallets to all exchanges.
3. ALL exchanges to send a list to superteam from exchanges on transactions. This will be from more than one fork, and it will be coins that are "double spent" or triplespent or more, this is the part thats gonna hurt. The superteam, can figure out whats owed and post new 3.2 wallet on op, if people dont upgrade, they dont get the new money. As user "Thisnamealready exists" pointed out, this is fault of superteam for bad code, and they should pay exhcnage in btc after its calculated. Bottom line is there are damages that need to be paid out. This is what happends when your in business. Walletholders will email superteam old 3.1 , or 2.1 wallet addresses so they can view transactions and calculate losses. Superteam will send existing balance from old wallet + any money sent  to or from exchanges or money withrawalled and not received.

There, DONE!


@Superteam: If you know there will be an intentional fork from V2.1 to 3.1 or whatever, you need to add a pop up in existing wallet warning users that there is a mandatory wallet upgrade in X amount of days and if they dont upgrade wallet will cease to function.

@Superteam, you are expected to do the right thing. Resolve it and move on, and build even more trust with all players involved. Superteam/Exchanges : You WILL lose money NOW, and gain in the future.

Vegas

[RJF]

Price is dropping fast. What you do in the next 12 hours will determine the future of Supercoin. I have a lot invested here, would really like to see this worked out without all the theatrics and drama. Thanks...

[brookefinancial]

I am surprised at the level inaccuracies by the dev team here.  Please get your facts straight before asserting them as fact.

We have great reward for exchanges daily %100 PoS coins. Usually  they don't share these coins with you. the longer they keep coins in their exchange more they can produce coins.

I am afraid we may have to interrupt the relation ship with these current 4 exchanges in our OP. Because they not answer back we don't know what's with them. I cant hold in my OP not working exchanges so long.

And we may have to find new one and continue from there. I am watching the issue.

1) This coin is not 100% PoS daily nor is it for us.
2) Exchanges never stake hot wallets.  It's not feasible.  So no, we are not producing coins.  I hope you understand why.
3) We have contacted you and told you what we needed to move forward.  You basically told us to go away.  To be completely transparent to the community:
          a) We monitor blockchains very closely for our deposits/withdrawals.  Problem is, when we use the official blockexplorer which is incorrect, and we were lead to follow a bad fork until it was too late.  All this without a single notification.
          b) When we tried to move to the "new" fork, we had 110 deposits that were orphaned which equated to approximately 700k of SUPER coins.
          c) We have asked that you mint the coins caused by the forks to cover the difference in the forks.

We are happy to work with the community on solving this, and we don't even mind covering some of the losses, like we have in many other forks, but the number of coins here is over 30% of our wallet size and not practical.  If we cannot come to a solution, we will just close the market and leave the wallet open on the old for for people to withdraw.  We have not heard back from Mintpal yet, but wanted to get ahead of this.

Thanks,
Richie

Thanks for the update. I'm not sure how 'minting' coins would work to cover losses. It would seem undesirable for developers to be able to mint coins at will. But perhaps a relaunch would work, with a reduced pos scheme for everyone, to cover losses, and maintain confidence in the coin. That would entail a hard fork with the whole community plus exchanges on board. The details could be thrashed out with input from experienced independent developers. If the price of a stable coin is a massive reduction in pos rewards, then in my own view it would be worth it.

Wow this situation is a mess, and it is developing soooooooo frickin slow I have been following this on the side for 3 days and there is no development.

Supercointeam? Supercoindev? Bittrex?

What are you guys doing to fix this issue? I have coins on Bittrex so am I going to lose them?

[smackii]

Basically, the coin is dying weeks ago and you can't even sync either the old wallet or the new wallet past 30% of the blockchain (i tried like 5 times for 2 days). I'm glad i sold before this fork happens..

[BTCgraphics]

[finity]

Im legit starting to wonder if Super and Mamm dev actually know what they're doing. We haven't actually seen any coding and both coins are kinda dying, and now this fiasco. Maybe I'm wrong but i feel like this is it as for these 2 coins.

They seem to be 2 egocentrical idiots. Like really, you think you can survive without proper marketing and exhanges. Let me break it to you, by the end of the year there will be 100 more coins with similar tech and doing everything you are not doing right now. Bound to fail, and if you ever speak to MAMM dev again you can tell him he's the biggest moron out of the 2 of you, atleast you have that going for you.

[mineforme]

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.

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

[jakiman]

I believe both supercointeam & supercoindev are asleep during these hours.
(not sure where they are but both come online later usually)

So yeah, let's hope the devs sort this one out. It's not like it can be solved with a few clicks anyways.
We just want better "more organized" communication from the devs on how they will resolve it & when.

Supercointeam, can we get Supercoindev to post about this fiasco in this thread please if he is the one who will fix it?

[Thistleblower]

I'm not saying (yet) it was a scam from the outset... but I'm seriously wondering if the 'trustless anonymous' claims were ever substantiated. In the meanwhile there's no cooperation between developers and exchanges, and the price is falling like a stone. Is a relaunch now even a viable proposition...  as ClusterfuckCoin perhaps?