sandor111
|
|
June 16, 2014, 10:56:15 PM |
|
Definitely instamine after 15934
Of course. After your pool shut down nobody could be sure to connect to main fork so there was someone connected to his own fork and instamine. Relaunch after block 15934. Dev is inactive again ? Pool was actually shut down around block 16315.
|
|
|
|
AizenSou
|
|
June 16, 2014, 10:59:46 PM |
|
Definitely instamine after 15934
Of course. After your pool shut down nobody could be sure to connect to main fork so there was someone connected to his own fork and instamine. Relaunch after block 15934. Dev is inactive again ? Pool was actually shut down around block 16315. I remember seeing even higher block, but the network kicked the pool back everytime? So relaunch after block 15934 is a better option. I don't mind losing a few hundert SLMs.
|
|
|
|
sandor111
|
|
June 16, 2014, 11:07:04 PM |
|
Definitely instamine after 15934
Of course. After your pool shut down nobody could be sure to connect to main fork so there was someone connected to his own fork and instamine. Relaunch after block 15934. Dev is inactive again ? Pool was actually shut down around block 16315. I remember seeing even higher block, but the network kicked the pool back everytime? So relaunch after block 15934 is a better option. I don't mind losing a few hundert SLMs. Truth is, we mined about 750 blocks after block 16000, of which ~300 were accepted by the network, the others were kicked each time the network synced back ~40 blocks.
|
|
|
|
slimcoin (OP)
|
|
June 16, 2014, 11:13:40 PM |
|
Could people post their
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
|
-Much Donate BTC-1D5pnma7E1CP6cquHujycVy79EyXJ3eY
|
|
|
sandor111
|
|
June 16, 2014, 11:17:20 PM Last edit: June 16, 2014, 11:38:59 PM by sandor111 |
|
Could people post their ./slimcoind getblockhash 15934
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c 15935: af377a2f3be16d3c3d82ad9158a3c24b5e8a7a1af6e315b486a390c651d70ff5
|
|
|
|
jamestown2035
|
|
June 16, 2014, 11:30:55 PM |
|
No need to be greedy 15000 is when the issues started.
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
June 16, 2014, 11:34:03 PM |
|
[root@CentOS-64-64-minimal .slimcoin]# slimcoind getblockhash 15934 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
|
|
|
|
bitspender
|
|
June 17, 2014, 04:57:39 AM |
|
im still receiving pool payouts...
|
|
|
|
jadefalke
Legendary
Offline
Activity: 1456
Merit: 1014
|
|
June 17, 2014, 06:09:06 AM |
|
~/slicmoin-executable-master$ ./slimcoind getblockhash 15934 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
~/slicmoin-executable-master$ ./slimcoind getblockhash 15935 af377a2f3be16d3c3d82ad9158a3c24b5e8a7a1af6e315b486a390c651d70ff5
|
|
|
|
CryptoHobo
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
June 17, 2014, 06:28:30 AM Last edit: June 17, 2014, 06:51:53 AM by CryptoHobo |
|
still like this coin, hope it can be saved cant get blockhashes, getting .dat error when running wallet
|
|
|
|
reflector
|
|
June 17, 2014, 06:33:45 AM |
|
slimcoind getblockhash 15934 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
slimcoind getblockhash 15935 000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
|
|
|
|
AizenSou
|
|
June 17, 2014, 07:15:07 AM |
|
So everyone has the same hash at block 15934. We could discard all blocks after that and relaunch the coin. Don't let such a nice coin die.
|
|
|
|
yang5034
|
|
June 17, 2014, 07:27:31 AM |
|
i think dev should check the code first.we can relunch once,but can't be twice.People will lose their confidence. sometimes i recived coins form the pool,but it showed as mint by burn,and the number is wrong.
|
|
|
|
sleepdog
|
|
June 17, 2014, 07:28:57 AM |
|
Could people post their
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c 000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
|
|
|
|
mumus
|
|
June 17, 2014, 07:35:09 AM |
|
Could people post their
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
15934 - 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c 15935 - 000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
|
|
|
|
hashmaster3000
Newbie
Offline
Activity: 19
Merit: 0
|
|
June 17, 2014, 10:11:21 AM Last edit: June 17, 2014, 10:21:32 AM by hashmaster3000 |
|
I'd like to see mumus and other developers go through the source code and make sure no coins were premined by the developer. I'd also like to know if there is a chance the BURN address actually spends coins - if so that should also be addressed in the hard fork.
The burn address can't spend coins because generating a private key that maps to an address that consists of a sequence of words (like "SLMCoinMainNetworkBurnAddr") would take an eternity. (unless an attacker is capable of cracking both ECDSA and RIPEMD-160 [edit: and SHA256] - but in this case, the attacker won't bother with SLM and steal some BTC instead ) main.h:110 //Burn addresses const CBitcoinAddress burnOfficialAddress("SfSLMCoinMainNetworkBurnAddr1DeTK5"); const CBitcoinAddress burnTestnetAddress("mmSLiMCoinTestnetBurnAddress1XU5fu");
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
June 17, 2014, 10:15:28 AM |
|
I'd like to see mumus and other developers go through the source code and make sure no coins were premined by the developer. I'd also like to know if there is a chance the BURN address actually spends coins - if so that should also be addressed in the hard fork.
The burn address can't spend coins because generating a private key that maps to an address that consists of a sequence of words (like "SLMCoinMainNetworkBurnAddr") would take an eternity. (unless an attacker is capable of cracking both ECDSA and RIPEMD-160 - but in this case, the attacker won't bother with SLM and steal some BTC instead ) main.h:110 //Burn addresses const CBitcoinAddress burnOfficialAddress("SfSLMCoinMainNetworkBurnAddr1DeTK5"); const CBitcoinAddress burnTestnetAddress("mmSLiMCoinTestnetBurnAddress1XU5fu"); I think the address was different before, perhaps this was addressed in the recent update. If not i am surprised i missed the 'SLMCoinMainNetworkBurnAdd' . Let me check my old wallet.... EDIT : Correct, the BURN address all along was SfSLMCoinMainNetworkBurnAddr1DeTK5. Stupid of me for not noticing Waiting for someone to comb through the blockchain for a possible premine..
|
|
|
|
mumus
|
|
June 17, 2014, 11:08:12 AM Last edit: June 17, 2014, 11:26:38 AM by mumus |
|
Let me re-post again, important :
I'd like to see mumus and other developers go through the source code and make sure no coins were premined by the developer. I'd also like to know if there is a chance the BURN address actually spends coins - if so that should also be addressed in the hard fork.
This coin doesn't sounds like scam but I will try today to go over the code to see if has something strange though I'm not that expert in finding hidden tricks. I can check for tricks that others found in some scamcoins, like this: https://bitcointalk.org/index.php?topic=566870.msg6535095#msg6535095Regarding to the BURN address the only way I see to make sure that the dev doesn't has the private key is to show us exactly how was generated or to generate a new. As an example can stand here the destruction of some premined NVC coins, details here: https://bitcointalk.org/index.php?topic=144158.0EDIT: Indeed as hashmaster3000 noted above, generating a vanity address like the Burn address will take an eternity so we can feel safe.
|
|
|
|
TheRealSteve
|
|
June 17, 2014, 12:24:34 PM |
|
Waiting for someone to comb through the blockchain for a possible premine..
Not much combing-through needed. We know when it launched, and you yourself mentioned that you got a bunch of the first few blocks, if I recall correctly. height | date time | mint | hash | 0 | 2014-05-08 19:47:40 | 0 | 00000766...18d61bea | 1 | 2014-05-28 21:13:23 | 42.04 | 000006e0...fe37b5db | 2 | 2014-05-28 21:14:11 | 42.04 | 000004e9...fc111de7 | 3 | 2014-05-28 21:14:43 | 41.57 | 000000a4...c441c3b9 | 4 | 2014-05-28 21:15:12 | 40.91 | 00000099...c010d400 | 5 | 2014-05-28 21:15:37 | 40.24 | 000002da...95b27b96 | 6 | 2014-05-28 21:15:45 | 39.53 | 00000278...9dc5f7cf | 7 | 2014-05-28 21:16:50 | 38.64 | 00000453...c0cdd355 | 8 | 2014-05-28 21:18:01 | 38.38 | 000003f7...9610b0c4 | 9 | 2014-05-28 21:18:52 | 38.19 | 000000a8...d5114130 | 10 | 2014-05-28 21:19:36 | 37.78 | 00000524...7de0c194 |
From that it would at least seem there's no premine at the beginning (can't vouch for any potential instamine stuff happening since). Could probably dig around the transactions to group together blocks as likely belonging to a single entity.
|
|
|
|
TheRealSteve
|
|
June 17, 2014, 12:25:55 PM |
|
There are some anomalies in the blockchain, look at block 1000, 4000 and 11000 for example.
...
Maybe that's a PoB block mislabeled as PoW? Because the hash is just a random hash, and the block reward doesn't adhere to reward = 50/((diff*4096)^(1/4)) 50/(0.02457705*4096)^(1/4)) = 15.78...
There actually is no label for PoB, check the code. An easy way to identify them from the getblock() response is to check if the nonce == 0 (as is the case in the example you give). I'm not sure that's 100% foolproof, but it held in the first 12,345 blocks at least.
|
|
|
|
|