Hi,

I have uploaded a copy of my blkindex.dat and blk0001.dat here:
http://en.file-upload.net/download-10868526/slimcoin_blockchain_blk429503_89e2ef43.7z.html
SHA256: 7dfc6146e8a988477b8827864502ed8521b25775e111ff3fb41b4c1f1545e269

It's synced up to block 429503.

Doesn't the reward per block increase automatically when increasing the diff (== increasing the PoS target spacing)?

I agree with the "more difficult to find" change because that would allow newcomers to mine more coins using PoB and PoW.
I also think that we might want to decrease nTargetSpacingWorkMax (the max PoW target time, currently at 15 minutes).
(Disclosure: I'd benefit from that, too )

I don't understand what exactly you mean with "reward increase". Do you want to increase the annual PoS inflation to 10% or do you simply want to compensate for the higher difficulty? (the latter is certainly OK, not sure about the former)

People (especially new people) might misunderstand it though.

Less than 24 hours ago. In fact, I never paid more than a fraction of 1 SLM. You could try sending a couple coins to yourself (assuming that the fee will be lower) and see if it resolves.

@all:
Everyone who blindly calls others "morons" is a moron. Except for me of course
That being said: Dev, you really should be more open and communicate more often - even if you didn't make any progress since your last post. Most people (except for primer) will understand that you can't code on this coin full time and thus won't make progress every day. However, if you don't communicate at all, people will lose confidence and new potential investors won't gain confidence.

I didn't have to pay 40SLM (or anything close to that) when I transferred SLM to BTER.

I didn't look at the total coin supply yet.

I might be wrong (seriously, I'm not an altcoin expert), but I think so.
When PoS blocks come in every 90 seconds, the POW target spacing should increase until it hits the 15min max limit.
Example calculation without PoB blocks, assuming that PoS "hashrate" (more accurately: the total eligible coin age in all PoS-enableed wallets) is fairly uniform:

PoW spacing_____	Expected non-PoW blocks since last PoW block_____	New PoW spacing
2*90	2	4*90
4*90	4	6*90
6*90	6	8*90
8*90	8	10*90
10*90	10	10*90 (max)

When there is a PoB block, the "non-PoW blocks since last PoW block" number gets increased by one, accelerating this process.
Thus, the PoW target spacing should indeed tend towards 900 seconds (15 minutes).

However, since sometimes (or maybe even quite often?) there will be less than 8 non-POW blocks during a 15-minute interval - causing the next PoW spacing to go down slightly.
Due to those temporary deviations, I expect that the average PoW target spacing will be slightly below 15 minutes.

If we drop the assumption that the PoS "hashrate" is fairly uniform (for example because some people don't stake 24/7 but just during a couple hours when their PC is powered on), the average PoW target spacing should drop another bit lower because the actual PoS block spacing will temporarily rise above 90s, increasing the probability of getting less than 8 non-PoW blocks during a 15min interval.

If I understand the code correctly, the total target block time is 90s, not the PoW target block time.

The PoW target block time is determined by this formula:
(main.cpp:1045)

STAKE_TARGET_SPACING is 90 (1.5 minutes) and nTargetSpacingWorkMax is 900 (15 minutes).
Thus, for POS blocks, the target spacing is always set to 90 seconds (because fProofOfStake is true for POS blocks).
For POW blocks, the target spacing is min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight)).
In other words, the target spacing gets set to 90s * (2 + number_of_non_pow_blocks_since_the_last_pow_block).
If this value exceeds 15 minutes, the target spacing is set to 15 minutes.

=> When there are many PoS blocks, the PoW block spacing gets increased in order to achieve the total average block time of 90 seconds.
This feature seems to be inherited from Peercoin.

Currently, newbies have to wait 360s between two posts (including PMs) and 90s between two searches (including switching the search result page!).
This is quite annoying when you want to respond to multiple threads / PMs at once (for example after logging in and catching up on your threads/PMs)
The search delay might even be counterproductive because it discourages newbies from searching.
I understand that some kind of rate limiting for newbies is needed in order to reduce spam attacks.
For this reason, I propose using the "token bucket" (https://en.wikipedia.org/wiki/Token_bucket) algorithm for rate-limiting newbies' posts and searches instead of a fixed delay.

Example:
Every user or IP gets an own "post bucket" that can hold 10 tokens.
Every [postDelay] seconds, a token is added to every non-full bucket.
When a user wants to post, a token is taken from his bucket. If the bucket is empty, he gets a "You're posting too often, wait n seconds" error.

This way, the annoying delay shouldn't occur anymore for most newbies but if they want to spam, they still get rate-limited.
The exact bucket size can be adjusted of course, 10 tokens is just some example number.
For searching, a seperate bucket can be used in order to implement different post/search delays.

Note that in the implementation, you don't actually have to call some "add tokens" script every N seconds.
In fact, there would be hardly any performance penalty if you do it like this:

At what price?
I'll sell you some SLM for 0.89mBTC each. (via escrow of course)

Since nobody wants to buy my coins, I'll just give 'em away for free!
Just send me a PM with your address and I'll send some.
Don't post your address in this thread because apparently that's not allowed.
All Bitcointalk accounts that have made at least 5 posts before 2014-06-23 00:00 UTC are eligible.
If you own multiple accounts, please don't request coins more than once because that wouldn't be fair.

The first 10 people will get 200 TGC each.
The next 10 people will get 100 TGC each.
The next 10 people will get 50 TGC each.

Clones? Are there any other clones besides TGC?

Both true.
If you sent coins after the fork, anyone can grab the transaction from the old blockchain and broadcast it to the new network though. (They can't change the recipient however.)
If you want to "reverse" transactions made on the old blockchain after the fork, you should send all your coins to a new address as soon as the new network is up.

Looks like initial diff is too high.
diff=0.00003052 => 131082 hashes / block.
If we've got 50 machines mining at 18 hashes per minute, the total network hashrate is 15 h/s
=> mining a block takes around 2.5 hours

hashblock.h

Does that mean that we need 15 GB of RAM in order to run the wallet?
Looks like MAIN_SHINY_CHUNKS should be 12582912 instead of 125829120.

Edit: MAIN_SHINY_ITERS seems to be a little high, too... Please make sure that a slowish CPU can solve a hash in less than ~1-2sec; if it takes too long, block propagation will slow down significantly (and we'll get a lot of orphans)

Edit2: Just had a look at a whitepaper and saw that those 15GB are intentional. I still think that this is way too much because most people who want to run this wallet probably don't have 15 GB of RAM to spare.

Lol you copy/pasted my offer

Update:
I want to sell some TGC for 0.29 mBTC / TGC (0.00029 BTC) each.
Minimum 200 TGC.
If you buy more than 1000 TGC, you'll get another 100 TGC for free!
If you're interested, please send me a PM.

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

I want to sell some TGC for 0.39 mBTC / TGC 0.29 mBTC / TGC (0.00029 BTC) each.
Minimum 200 TGC.
If you buy more than 1000 TGC, you'll get another 100 TGC for free!
If you're interested, please send me a PM.

Looks like we gotta make it to block 17000 before the fix kicks in.
@slimcoin: I don't think that anyone would be mad at you if you change that to 15500 or something that's closer to the current block count