[ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!

[sandor111]

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.

[1714469729]

1714469729

[1714469729]

1714469729

[AizenSou]

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]

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]

Could people post their

./slimcoind getblockhash 15934

and

./slimcoind getblockhash 15935

[sandor111]

Could people post their ./slimcoind getblockhash 15934

0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
15935: af377a2f3be16d3c3d82ad9158a3c24b5e8a7a1af6e315b486a390c651d70ff5

[jamestown2035]

No need to be greedy 15000 is when the issues started.

[primer-]

[root@CentOS-64-64-minimal .slimcoin]# slimcoind getblockhash 15934
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c

[bitspender]

im still receiving pool payouts...

[jadefalke]

~/slicmoin-executable-master$ ./slimcoind getblockhash 15934
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c

~/slicmoin-executable-master$ ./slimcoind getblockhash 15935
af377a2f3be16d3c3d82ad9158a3c24b5e8a7a1af6e315b486a390c651d70ff5

[CryptoHobo]

still like this coin, hope it can be saved

cant get blockhashes, getting .dat error when running wallet 

[reflector]

Code:

slimcoind getblockhash 15934
0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c

slimcoind getblockhash 15935
000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264

[AizenSou]

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]

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]

Could people post their

./slimcoind getblockhash 15934

and

./slimcoind getblockhash 15935

0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c

000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264

[mumus]

Could people post their

./slimcoind getblockhash 15934

and

./slimcoind getblockhash 15935

15934 - 0000003144e8cfc1e1a937978dccb1146abc0d0aba1afeb7fbfe8dc9fd71af8c
15935 - 000000346f9386b3f4b17c7a7d4fa7928650f10479d401fe8313ef24017ef264

[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

Code:

//Burn addresses
const CBitcoinAddress burnOfficialAddress("SfSLMCoinMainNetworkBurnAddr1DeTK5");
const CBitcoinAddress burnTestnetAddress("mmSLiMCoinTestnetBurnAddress1XU5fu");

[primer-]

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..

[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#msg6535095

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://bitcointalk.org/index.php?topic=144158.0

EDIT: Indeed as hashmaster3000 noted above, generating a vanity address like the Burn address will take an eternity so we can feel safe.

[TheRealSteve]

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]

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.