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

[TheRealSteve]

Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ?

Hey, I'm not saying the figures reported are actually correct (both the rpc and the pool) - only that 0.00205548 * 1000 = 2.05548

you have approximately the amount of POB / day ?

Barely a day has passed, I think?  I'll parse the last 24 hours in a bit, though, see what rolls out.

[yang5034]

Steve  uses to provide us table of stats. It could be interesting now to see if we have a diff. 

I plan to - starting at the latest hard fork [...] I can't help but think the current block generation rate appears to be higher, at least.  But that might be psychology after the days of nothing happening

Block generation was definitely lots faster - I guess the network took a while to balance out all the hashing power thrown at it that was ready to go as soon as the update was posted.


Here's some basic graphs from the re-launch:


Yep, those who got in early on the relaunch made a mint

Keen observers might see a single dot in the otherwise 'down' period.  That's block #15936, minted 2014-06-20 06:58:03 . (15937 and 15938 were also minted before the relaunch, but only by about an hour).

There's also a metric somethingsomething of PoS blocks now, so that's got its own bits and pieces in some of the graphs.

Perhaps also of interest - the massive block generation just after relaunch.
In the first 4 hours, ~420 blocks.  Counting just the PoW blocks, ~331.  That gives an interval time between PoW blocks of ~43.5s.
Compare that to the last 4 hours, ~194 blocks.  PoW blocks, ~26.  Interval: ~553.8s.

The vast majority of the later blocks appear to be PoS.  I think the last 12 hours or so in the dataset were relatively stable, so breaking down blocks in that period:
PoW: 98
PoB: 28
PoS: 445

Like this post? Donate Slimcoin: STDpqwvEC6banMNzfNYDTuZy8xspHpGuNj

 can you count pob and pow recent statistics under the daily output, always feel pob a lot less than before the re-launch, not normal.After the re-launch, I burn a lot of coins to keep the ratio of the burning coins.Day mint by pob reduced by at least 60%.

[glop]

my slm got stolen!  

The coins had been transfered automatically to the address:


Now I encrypt the wallet.  But I don't know if I can still get the PoB block when the wallet is locked.

   Yes you can, but needs to unlock your wallet to do so.

   type:  "help walletpassphrase"  into the console for the syntax.


 

[yang5034]

now it's hard to find pob now .Currency becomes pointless to burn coins.  all  the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.

[primer-]

now it's hard to find pob now .Currency becomes pointless to burn coins.  all  the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.

I have found many PoB today, make sure you are :
1. Synced
2. Minting (unlocked wallet)
3. Running the latest client

[glop]

now it's hard to find pob now .Currency becomes pointless to burn coins.  all  the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.

I have found many PoB today, make sure you are :
1. Synced
2. Minting (unlocked wallet)
3. Running the latest client

  I have the same problem,  I am synced , Minting 24/7 and running last wallet........

[primer-]

now it's hard to find pob now .Currency becomes pointless to burn coins.  all  the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.

I have found many PoB today, make sure you are :
1. Synced
2. Minting (unlocked wallet)
3. Running the latest client

  I have the same problem,  I am synced , Minting 24/7 and running last wallet........

Well one last trick i use is to run several wallets. I know the dev says it makes no difference but try it and post results..

[glop]

now it's hard to find pob now .Currency becomes pointless to burn coins.  all  the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.

I have found many PoB today, make sure you are :
1. Synced
2. Minting (unlocked wallet)
3. Running the latest client

  I have the same problem,  I am synced , Minting 24/7 and running last wallet........

Well one last trick i use is to run several wallets. I know the dev says it makes no difference but try it and post results..

   You run several wallet with the same wallet.dat ?

[primer-]

   You run several wallet with the same wallet.dat ?

Yes

[glop]

   You run several wallet with the same wallet.dat ?

Yes

    Ok, I am sync 2 more wallet, will see.

[sandor111]

"networkghps" : 0.00205548,  How much is this in MH/s ?

Last I checked, there were a thousand megas in a giga.  So approximately 2Mhash/s.  You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well.

Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ?

slimcoin   2014-6-24 15:02:22 UTC   19485   000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3   9.36   immature
slimcoin   2014-6-24 13:29:25 UTC   19431   00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db   8.64   immature

last two blocks pool found - 1hour 30min difference

This time you are right primer

Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please!
My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all

There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted.
Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480
It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row.

[primer-]

"networkghps" : 0.00205548,  How much is this in MH/s ?

Last I checked, there were a thousand megas in a giga.  So approximately 2Mhash/s.  You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well.

Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ?

slimcoin   2014-6-24 15:02:22 UTC   19485   000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3   9.36   immature
slimcoin   2014-6-24 13:29:25 UTC   19431   00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db   8.64   immature

last two blocks pool found - 1hour 30min difference

This time you are right primer

Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please!
My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all

There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted.
Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480
It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row.

There were only 4 PoW blocks (which should spawn every 90 secs) in 1.5 hours ?? D
Dont patronize me with basic statistics, instead of wasting characters about statistics you should have wrote something about a broken algo - PoW block should be created every 90 secs not one every 30 minutes!

EDIT : I did check 20-30 blocks from 19431 and they all seems to be PoS or PoB.. Algo is obviously broken, PoW blocks are not created as stated in the whitepaper, one every 90 sec. What is causing this, PoS and PoB blocks ?

[sandor111]

"networkghps" : 0.00205548,  How much is this in MH/s ?

Last I checked, there were a thousand megas in a giga.  So approximately 2Mhash/s.  You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well.

Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ?

slimcoin   2014-6-24 15:02:22 UTC   19485   000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3   9.36   immature
slimcoin   2014-6-24 13:29:25 UTC   19431   00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db   8.64   immature

last two blocks pool found - 1hour 30min difference

This time you are right primer

Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please!
My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all

There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted.
Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480
It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row.

There were only 4 PoW blocks (which should spawn every 90 secs) in 1.5 hours ?? And dont patronize me with basic statistics, instead of wasting characters about statistics you should have wrote something about a broken algo - PoW block should be created every 90 secs not one every 30 minutes!

Where does it say that PoW blocks are created every 90 seconds?

[primer-]

Where does it say that PoW blocks are created every 90 seconds?

Here ? https://bitcointalk.org/index.php?topic=613213.msg7019069;topicseen#msg7019069

Posted by the dev himself, "A PoB block is found every 1-3 PoW blocks, (every 90-270 seconds). "

[sandor111]

Where does it say that PoW blocks are created every 90 seconds?

Here ? https://bitcointalk.org/index.php?topic=613213.msg7019069;topicseen#msg7019069

Posted by the dev himself, "A PoB block is found every 1-3 PoW blocks, (every 90-270 seconds). "

Max target for PoW is actually 15 min.

[primer-]

Where does it say that PoW blocks are created every 90 seconds?

Here ? https://bitcointalk.org/index.php?topic=613213.msg7019069;topicseen#msg7019069

Posted by the dev himself, "A PoB block is found every 1-3 PoW blocks, (every 90-270 seconds). "

Max target for PoW is actually 15 min.

Where did you get that number, out of your ass ? "Actually", looking at your pool stats (possibly bug-driven) or devs posting history?

[TheRealSteve]

Where did you get that number, out of your ass ? "Actually", looking at your pool stats (possibly bug-driven) or devs posting history?

It's in the code.

Code:

main.h
STAKE_TARGET_SPACING = 90; // 90 second block spacing 

main.cpp
static const int64 nTargetSpacingWorkMax = 10 * STAKE_TARGET_SPACING; // 15 minutes

Then there's a whole section that deals with the interval some more.

[primer-]

Where did you get that number, out of your ass ? "Actually", looking at your pool stats (possibly bug-driven) or devs posting history?

It's in the code.

Code:

main.h
STAKE_TARGET_SPACING = 90; // 90 second block spacing 

main.cpp
static const int64 nTargetSpacingWorkMax = 10 * STAKE_TARGET_SPACING; // 15 minutes

Then there's a whole section that deals with the interval some more.

If so, this was implemented in the last fork, i am 100% positive this was not the case before the fork. Fucking developer retard.

[TheRealSteve]

If so, this was implemented in the last fork, i am 100% positive this was not the case before the fork. Fucking developer retard.

This has been in since at least the codebase of 2014/05/28, the first time I grabbed the code.
(github history should show any changes there as well anyway)

[primer-]

If so, this was implemented in the last fork, i am 100% positive this was not the case before the fork. Fucking developer retard.

This has been in since at least the codebase of 2014/05/28, the first time I grabbed the code.
(github history should show any changes there as well anyway)

You acting stupid too ? There were no PoS blocks before the last fork, it was broken.