Dev has not confirmed anything yet. There are doubts he has skills to fix the current issues.
No date for re-launch confirmed
No list of bugfixes confirmed
Topic: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer! - page 90. (Read 284956 times)
June 17, 2014, 09:28:11 AM
June 17, 2014, 09:19:44 AM
what happend i can get sync now ,and block is 17144 now.
Ha, yeah. Just started my wallet up and it's synced to 17151.
I think this is irrelevant though as it seems we're going to be re-launching from 16000.
Can we get a definitive statement from the dev about this if possible?
The hard fork is at block 15934.
The dev has confirmed this then?
There's absolutely no point in anyone having their wallet running at the moment is there? Likewise for mining?
June 17, 2014, 08:46:05 AM
{
"blocks" : 17182,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00025813,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkghps" : 0.00001066,
"pooledtx" : 0,
"testnet" : false
}

{
"blocks" : 17191,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00026683,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkghps" : 0.00001135,
"pooledtx" : 0,
"testnet" : false
}
"blocks" : 17182,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00025813,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkghps" : 0.00001066,
"pooledtx" : 0,
"testnet" : false
}

{
"blocks" : 17191,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00026683,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkghps" : 0.00001135,
"pooledtx" : 0,
"testnet" : false
}
June 17, 2014, 08:32:08 AM
what happend i can get sync now ,and block is 17144 now.
Ha, yeah. Just started my wallet up and it's synced to 17151.
I think this is irrelevant though as it seems we're going to be re-launching from 16000.
Can we get a definitive statement from the dev about this if possible?
The hard fork is at block 15934.
June 17, 2014, 08:15:38 AM
what happend i can get sync now ,and block is 17144 now.
Ha, yeah. Just started my wallet up and it's synced to 17151.
I think this is irrelevant though as it seems we're going to be re-launching from 16000.
Can we get a definitive statement from the dev about this if possible?
June 17, 2014, 08:02:42 AM
There actually is no label for PoB
Oh ok, that just got me confused. 
Yeah, hopefully that's one of the things that could be addressed while things are being poked at anyway
June 17, 2014, 07:53:46 AM
what happend i can get sync now ,and block is 17144 now.
June 17, 2014, 07:35:55 AM
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....
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...
Oh ok, that just got me confused.
June 17, 2014, 07:35:40 AM
Regarding 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.
One way is to use the string you like (avoid forbidden characters), prefix with the necessary prefix, and vary further prefixes/suffixes/checksum until you get an address that passes the address checks. This would give you a valid address without ever having the keys that belong to it - or even knowing whether it ever could be derived from valid keys; can't find the stackoverflow / stackexchange discussion, but I think the consensus was that as long as the address validates, then in theory there should be keys to match it. But yes, as mentioned several times, generating keys to match the address would be extremely difficult. June 17, 2014, 07:25:55 AM
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. ...
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...
June 17, 2014, 07:24:34 AM
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.
June 17, 2014, 06:08:12 AM
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://bitcointalksearch.org/topic/m.6535095I'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.
Regarding 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://bitcointalksearch.org/topic/110k-premined-nvc-is-successfully-destroyed-144158
EDIT: Indeed as hashmaster3000 noted above, generating a vanity address like the Burn address will take an eternity so we can feel safe.
June 17, 2014, 05: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
Code:
//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..
June 17, 2014, 05:11:21 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 [edit: and SHA256] - but in this case, the attacker won't bother with SLM and steal some BTC instead
)main.h:110
Code:
//Burn addresses
const CBitcoinAddress burnOfficialAddress("SfSLMCoinMainNetworkBurnAddr1DeTK5");
const CBitcoinAddress burnTestnetAddress("mmSLiMCoinTestnetBurnAddress1XU5fu");
June 17, 2014, 02:35:09 AM
Could people post their
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
15934 - 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
15935 - 000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
June 17, 2014, 02:28:57 AM
Could people post their
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
./slimcoind getblockhash 15934
and
./slimcoind getblockhash 15935
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
June 17, 2014, 02: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.
June 17, 2014, 02: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.
June 17, 2014, 01:33:45 AM
Code:
slimcoind getblockhash 15934
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
slimcoind getblockhash 15935
000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264
June 17, 2014, 01:28:30 AM
still like this coin, hope it can be saved
cant get blockhashes, getting .dat error when running wallet
cant get blockhashes, getting .dat error when running wallet
Jump to: