im on the same fork as you, and this is the same as the one on http://www.blockexperts.com/slm but the difficulty (0.0235) and network hash (64420h/s) is completely off. any idea which is the main fork?

I'm using the settings "maxconnections=1 -connect=76.127.202.17"

Good discovery. I have been getting an orphan rate of around 20% for PoW which has been rather annoying.

I'll have a script monitor the pools and send SLMs around once my block gets stuck; will update if this works.

I might be noticing the same issue. I'm running a custom front-end that interfaces 2 daemons on separate machines at highest priority, over 2 different ISPs through 2 different continents (Asia and US, via SOCKS proxy) and feeds the miners the highest block count work, and the front-end regularly reports de-synchronisations (> 1 block difference) that resolves only after many blocks.

In spite of this, I still occasionally get consecutive chunks of orphan chains, that seem somewhat dependant on network load (I.e. I don't see any orphans when network hash is ~ 3 mhps, but now I'm seeing like 20% orphan rate, and they come in chunks: i.e. t+0 accepted, t+1306 orphan, t+1418 orphan, t+1530 accepted, where t is about 3 hours before this post) so I assume even these two daemons don't seem to be working well.

However, the mining pools don't seem to be orphaning as much, so it might just be an localised latency issue for me, so I'll be grateful for any advice.

the difficulty has been this high before due to PoS blocks. but the network hash rate of 9mh seems to be a all-time high.

thanks for the changes, it looks substantial!

perhaps there's no need for a new enable-pos-minting flag, but just make it reservebalance true largenum by default? user can then unset reservebalance after they've consolidated their txns.

would also like to re-iterate request for implementation for signrawtransaction / sendrawtransaction eventually on your timeline. this would help make it easier to develop services for the slimcoin ecosystem.

recently i was thinking that slimcoin's nature of discouraging heavy mining in the long run may also make the coin succumb more easily to 51% double-spend attacks. since PoB blocks can only tack on to an existing PoW block, PoB cannot itself form an alternate correct chain. a legitimate PoS and PoW/PoB combined chain however would likely orphan the malicious chain.

PoS would thus still be an integral part of maintaining the blockchain integrity and not just an optional/extra sideshow? Not sure if my understanding of the matter is right.

Actually I didn't meant for each 1000 block range to mean a day, but its a decent approximation. The timestamps are as follows.

24351  :  2014-06-29 10:32:33 UTC
25351  :  2014-06-30 13:22:53 UTC
26351  :  2014-07-01 12:41:12 UTC
27351  :  2014-07-02 11:39:50 UTC
28351  :  2014-07-03 11:30:02 UTC
29351  :  2014-07-04 11:56:36 UTC
30351  :  2014-07-05 10:33:39 UTC
31351  :  2014-07-06 13:06:41 UTC

(edit: So incorporating the fix will push the PoW block time to about 90 to 100 seconds, and PoB block time to about 3x of that. As of right now at block 32441 it appears to be about 178 seconds estimated, based on difficulty and network hash power.)

If I understand it correctly, increasing the PoS reward this way will make the number of PoS blocks found drop 10-fold, but each reward proportionally rise by 10x. This would not affect PoS reward, but increase coin generation rate.

PoS currently generates way too much dust, and screws up the difficulty adjustment for PoB and its consequent discovery rate, which is your coin's main selling point.

Block Range  [PoS, PoW, PoB]
23352 24351 [466, 394, 140]
24352 25351 [342, 479, 179]
25352 26351 [384, 457, 159]
26352 27351 [693, 222, 85]
27352 28351 [653, 252, 95]
28352 29351 [661, 256, 83]
29352 30351 [693, 232, 75]
30352 31351 [465, 401, 134]

Currently, the PoS generation rate varies from 34.2% to 69.3% of each 1000 blocks. I assume a 10-fold drop should cut it to 3.42%-6.93%; this will likely allow PoW/PoB to dominate and achieve a PoW block rate of ~90-100 seconds.

Also, the average reward for PoS from blocks 30353 to 31352 appears to be 0.07796 per block for the 464 PoS blocks that appear in this range. A 10x reward will bring the average reward to about 0.78 SLM / block, with a PoS block rate of about once every half an hour.

If this is the case, then I think keeping PoS with the 10x reward amendment will allow Slimcoin to maintain its status as the coin with tri-hybrid block and still allow PoB to shine.

(Edit: You could make the changes on the testnet; I'll be happy to contribute say 50 to 100 khash for some testing)

I'm just a lurking miner, generally don't like to post. Though admittedly a little more frustrated recently with the ups and downs of difficulty.

As I understand it from a couple of pages back, PoW is linked to block generation rate. Since PoS block generation was a rather recent phenomena (height >16000), thought it might be interesting to have a community discussion.

a rough overview of the blocks generated. don't count on it for accuracy.

there just seem to be too many proof-of-stake blocks generating dust-like amounts of slm. which would be fine if it doesn't throw the proof-of-work difficulty completely out of whack - the POW difficulty jumps about not because of hash rate but because of POS crazy jumpy variations.

perhaps increase the POS difficulty and raise the block reward correspondingly by say, 10x? will allow POW and POB to be less affected by the vagaries of POS and more linked to the hashpower thrown at the network, while not taking away the POS interest aspect.

I support the POB update; burnt coins without a client running currently just hampers the rest of the network from generating POBs.



Block range [POS, POW, POB]

17290 17589 [227, 56, 17]
17590 17889 [230, 55, 15]
17890 18189 [222, 59, 19]
18190 18489 [236, 47, 17]
18490 18789 [220, 59, 21]
18790 19089 [224, 57, 19]
19090 19389 [229, 52, 19]
19390 19689 [261, 29, 10]
19690 19989 [246, 40, 14]
19990 20289 [197, 74, 29]
20290 20589 [194, 78, 28]
20590 20889 [180, 93, 27]
20890 21189 [121, 134, 45]
21190 21489 [170, 93, 37]
21490 21789 [220, 63, 17]
21790 22089 [216, 62, 22]
22090 22389 [163, 102, 35]
22390 22689 [111, 139, 50]
22690 22989 [112, 137, 51]
22990 23289 [130, 121, 49]
23290 23589 [120, 138, 42]
23590 23889 [143, 114, 43]
23890 24189 [170, 96, 34]
24190 24489 [118, 132, 50]
24490 24789 [107, 136, 57]
24790 25089 [119, 134, 47]
25090 25389 [79, 163, 58]
25390 25689 [67, 173, 60]
25690 25989 [102, 148, 50]
25990 26289 [162, 102, 36]

Oh I get this issue as well. Wasn't sure if it was just a display glitch or a gpu screwed up. So I guess I had better reset it then.

Wow so much has changed since I last checked in!

Sent some token BTC along to C+C, thanks for your work so far

we need a deviantart bot or smthg post a bounty for tt?

happy bday cbuchner! just sent you 0.5btc to 16hJF5mceSojnTD3ZTUDqdRhDyPJzoRakM. prolly a small token sum compared to what you've mined alr

i'm in

Thanks Christian for your generosity. A forum lurker mostly. Just wanted to thank you for your work and effort. 1LTC in as requested, hope more will come your way (217fdc8b8d4071d04344eef7fea90a6150487a244783884009e8e5111121e7a2)

also, usually I modify the autotune to limit the search space via something like (GRID_BLOCKS *WARPS_PER_BLOCK / LOOKUP_GAP < 50) continue; really speeds up the search by ignoring the really slow low warp counts, but not sure if I'm missing something?

Experience with the Y and Z kernels also indicate there's about a 10-15% gain on my cards.

Sent in 100 NXT. Online wallet had a minimum, and I was lazy, so...

TrID:11293929413885999346.

darn still no pm access. tragedy o_o looks like its more posts and more waitzzzz

a123 from singapore; was mining on cpu when it was actually possible to get blocks but not possible to change them for cash. quit and came back after one year just after the crash, and boy, surprise.

now trying to get it work on xilinx virtex-6 boards from work, wrote a python miner to getwork from pools, and pushing out 300Mhashs using sha256 code i adapted from opencores.org (2 cores fully unrolled and each round a two-stage pipeline @ 150mhz, 90% LUT util). now if only they will stay stable for more than 1 minute before crashing... contact me if you're on a virtex devel and wanna swap tips.

incidentally, willing to sell btc for sgd w 0% spread, pm me if interested.