 Show Posts
|
|
Pages: « 1 2 [3]
|
It might worth to look into original tx of thiese both. They do spent the same 10k input, so 4.5K just a change. Did you know how tx processing works? Although I could not say that the team behaves in a best way, your accusations could kill any good will that might remain. |
|
|
|
UPDATE: got my 20k back from Mintpal. STILL out over 20k from "Generated but not accepted". Ive had tried everything many times over, that has been posted about in the last few threads. Ive been polite calm and professional and have posted many times BEGGING the supercoin team to address my issue. They have never addressed my issues. Users have suggested the regular fixes, download the latest version, delete all in roaming except wallet.dat, go to old backup (done that dated 8/1/14), salvage wallet(done that), (repair wallet done that), import and export keys into new wallet (done that). I heard a phrase once about 20 years ago and it stuck in my head, and it goes like this "BE NICE, UNTIL YOU CANNOT BE NICE ANY LONGER". I have bugun to dump the super I got from Mintpal at stupid prices. Got it down to under 1500 sat , Im gonna pound at it some more today and see if I can get it near 1000 sat. Some nice bargains on Super guys at Bittrex, enjoy. Ive even been buying my own back and selling it lower..LOL. DO YOU HEAR ME NOW SUPERTEAM~!?!??!!?
You will hurt not only supercoin team. You also will hurt other supercoin holders, who just like you. Im out of options. Truth be told, this was a last and final resort. Im hurting myself, and everyone, and that sucks  I dont know what else to do . Ive already lost 27,000 super to the dev teams code, and was gonna sell it off anyway. IM STILL open to suggestions that are not already posted. Devs please send me the 27,000 coins you owe me for your error to : SbHRVj3SZBb9FNFBd89qUXQ2jjVjfwgYEN Vegas Just to remind: ....
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.
....
|
|
|
|
Explorer wallet now resynchronizing on the new branch, started from a partial blockchain download (around 400k blocks), and now around height 432k, though with 100% CPU usage...
Explorer is lagging behind the wallet but catching up slowly as wallet responds slowly.
Any idea what the height of the bittrex chain is? and/or some block hashes that could be used as checkpoints?
~432950 this is definitely when bittrex withdrawals were not disabled: {
"hash" : "75505ed5dbf3f82ff95bbc4ac9986864218703bbf3fe70379f56c9458fea205d",
"confirmations" : 2555,
"size" : 445,
"height" : 430400,
"version" : 6,
"merkleroot" : "1695bb88192c776dfb69670cefbb0850eb10b57ff8a4fa2595fafef9760a041a",
"mint" : 0.34246575,
"time" : 1409587904,
"nonce" : 0,
"bits" : "1e0fffff",
"difficulty" : 0.00024414,
"blocktrust" : "100001",
"chaintrust" : "77fe3ef38244c3",
"previousblockhash" : "7043d889a54af5ce03cdee37571f4bfcf3b793773c8b12f0ff1e3cea3b7c4cec",
"nextblockhash" : "59f7a31e0fb4a6e009f9ba36e85267eb1749ccc43ef1fd759ddd45cefc0eb867",
"flags" : "proof-of-stake stake-modifier",
"proofhash" : "00026f7352e4e8db6cdb5087f44693a95db6204ce57a977bbed619905df02b99",
"entropybit" : 1,
"modifier" : "751b08ba9d9d0933",
"modifierchecksum" : "416f1761",
"tx" : [
"10ad332beed081923942641d717c61803c28a010b271e3f98096d325f1570e2c",
"7b15662136655731115dc2b5ae71dfdc02be413267a33f8b07d3506c802dc832"
],
"signature" : "304402202c4bb8f327d13e5f7aed922ec9f72a1a83e3d14c47010d5fa15a146a02c1254e0220152c3ddae733efe9fbc766f026470a633d4620f0584e1be2aa2ad1d4cfbdebee"
} |
|
|
|
We came to hard decision after reviewing two block chains. and we will work in favor of exchanges.
this appear less harm for the most. We act on good of most or all.
we will revert check points in favor of exchanges.
Please ensure that All exchanges are on The Same Fork. Exchanges please Work With Each Other to resolve this issue. DO Not leave it all up to the Developers. They have decided to act in Everyone's Best Interests. Your Cooperation and Involvement will Make or Break this decision. We believe moving to bittrex chain will fix everything. allow us time. we are working on it. Do not forget, please, to restore the proper checking of the transaction times and other possibly removed checks in your black-boxed version of wallet. |
|
|
|
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: {
"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: 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: 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 // 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. |
|
|
|
There is a issue:
Wallet compiled from github can't sync across the block 428419. I don't like download the blockchain, I just want sync from scratch. I have mentioned it for many times, dev,why did you not answer it?
it does not sync because you are in the fork, this is what the checkpoint is for. I am sync'ing fine from scratch, even it takes quite some time. If you don't want to sync, just get the full chain and sync from there. It's easy and fast to sync from the existing chain. Did you use the wallet compiled from the github? I also sync correctly when I use the windows wallet. Yes, I do use the wallet compiled from the source. I did not lost my mind to run the program I can't verify myself. That means, the github code is different with the windows wallet, and it has a bug that may be very serious.
This is what I am trying to explain and already proved with blockchain data and many references. |
|
|
|
There is a issue:
Wallet compiled from github can't sync across the block 428419. I don't like download the blockchain, I just want sync from scratch. I have mentioned it for many times, dev,why did you not answer it?
This happens because it rejects that damn block #412717 and continues to sync with the 'exchanges' fork. Then it stops at block 428419 as at this block the source code has a hard checkpoint that does not exist in the 'exchanges' fork: https://github.com/supercoinproject/supercoin/blob/3db664be97960b3acc2d074d72e70f7828c9a61b/src/checkpoints.cpp#L38: (428420, uint256("0x0ecce796a51688a527bc0e05e2c663b8323cbeaf767424a2ebb48950a709c84e")) |
|
|
|
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.
It seems you either do not understand what happened or you try to make us think that you do not understand. This fork happened not because forks happens. This fork happened because you did a bug in your closed source wallet that lead to appearance of a fork starting with block that violates the rules that the open source wallet published by you follows. This is your fault and you can't just insist that exchanges are irresponsible. The source code 1.6 IS NOT ABLE TO SYNC FROM SCRATCH WITH THE NETWORK. Full stop. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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-timestampThe 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#msg8575023I 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: 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. |
|
|
|
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. |
|
|
|
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: {
"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: 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: 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 // 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. |
|
|
|
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: {
"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: 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: 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 // 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. |
|
|
|
|
