I don't see how 6 mn/block is a feature for security, you have to wait at least 18mn to get some sort of confirmation and 36mn to be sure.
1 mn/block works well for XPM, transactions are fast.

Plus if this coin is to be for the small cpu solo miners, it's better to have more blocks so the chances of getting one is more averaged.

Of course going under 1mn is not wise considering network latencies.

No it would not.   I strongly agree with YukonCoinelius on this issue.  I think the one minute block time may prove to be primecoins undoing if it ever started to really take off.

6 minute block time is actually a wise design parameter choice by FreeTrade, and indicates dedication to having a strong network, while still being somewhat improved over Bitcoin's 10-minute time.

You cannot just randomly twiddle key design parameters and expect everything to keep working.   (not that it's stopping anyone in most of the altcoins, of course

Neither can you just randomly compare different coin designs.  Primecoin has PPCoin's *distributed checkpoint system* which offers a 2nd layer of security (along with its own plus/minuses), and is probably the reason SunnyKing felt 1 minute was long enough there.   BitCoin does not have that, thus neither does MemoryCoin which derives from it.  (it has checkpoints, but of a different kind.)

The strong advantage of a longer block-time is that it gives plenty of time for each block to percolate through the whole network and all nodes to settle and agree on a coherent distributed picture.  This improves network stability and resistance against certain types of attacks.    (For example, with short block times it becomes much easier for an attacker to get in front of the network, out-orphaning everybody  because they cannot even "see" the front of the blockchain, let alone mine on it.  Attacker does not even need a sustained 51% to do that, just "get lucky" a few times in a row.)

The reference below estimates potential end-to-end latencies in the "tens of seconds" = say 15-40 seconds, that's just for the network transmission.  Apply a 10x factor for security, reliability, processing, databasing, actually getting in a little mining... and you're at 10x (15-40) = 150-400 seconds = 2.5 to 6.6 minutes.

So we've got LTC at 2.5 minutes, MemoryCoin at 6 -- both reasonable.  I could see MemoryCoin maybe at 3 minutes, but it's not a clear-cut improvement, rather a trade-off.

The 30-60 second coins are really operating right at the margin of what is possible.  And they have not been proven against attacks  (on the contrary, several of them have been exploited).  And they strongly advantage the clustered GPU farms, because while everybody else is spending much of the blocktime just trying to receive the blocks, the clusters have tight internodal transmission and thus  proportionately more mining time as well.   (this is why small/solo miners often get continuous orphans on these coins).  So the longer block time in MemoryCoin does help solo miners.  (Also remember, these are average, not exact blocktimes.  At 3 minutes, some blocks will take only 1 minute; at 30 seconds, some blocks take only 5 or 10 seconds, and lots of miners never even got a chance.)

Another issue with short block times is they are just generating a lot more data = significantly increased overhead.  Especially early in the life of the coin, the blocks are nowhere near full capacity in terms of the number of transactions they can hold, so why spew out dozens in place of 1.  Remember a main point of these coins is to carry transactions.


See also:
https://bt.irlbtc.com/view/211535.20

Block 1566 is much too early for the hard fork for the changes under discussion, as we are in block 1400s now.  At 240 blocks per day, that's less than 1 day time and the code is not even released.  Can't be done.

The first immediate challenge is shepherding everybody thru the upcoming 1680 fork, in about 24 hours.  This version needs to be clearly marked and available.  (This is really an "implicit" fork; it's the first time the reward scaledown code activates, but anybody not on the new code will not see it, so they will produce wrong blocks.)   Since this code was already released, I think you have to stick to that schedule, otherwise it will just be too confusing.

Once this transition is accomplished and given a couple days to stabilize,  then the next batch of protocol changes we are discussing here can be rolled out.  There should be at least a few days from when you release the code to when the new protocol goes active.

Also you might promote/version these updates as sort of a paired unit (like "1A 1B"),  so people expect the imminent next part and don't get surprised/fatigued by having to update again.

It's very important to get a majority of miners forward onto the new protocol before its activation time.  If most miners stay on the old protocol/software, it sort of 51%-attacks your own coin.  You can/should have checkpoints to protect the blockchain, but really it's crucial to alert everyone forward to reduce user (and software) confusion.

So we are looking at a schedule like this:  (Note: PROPOSED, NOT FINAL)

Block 1680: protocol switches to latest current release ("1A"), fixing the block reward scaledown.
1680 + 2 days = block 2160:  1A transition confirmed stable and good.  Code Release update 1B, protocol switch time at least 3 days into future.
2160 + 3 days = block 2880:  protocol switch time for update 1B.

If 1B needs more time to get ready, then just adjust as needed.

Can an alert be posted to the client or no?

This is important that cpu miners can see a stream of rewards from their activity, but hoping to address this by building easy connection to a pool into the client.

I think the shorter block times in the Bitcoin/Litecoin clones are gimmicky - included mostly because they don't have many other features to separate them. MemoryCoin has 2 big new innovations already - no need to try to innovate on this front too.

Okay here's the binary ready for fork 1566. Please update ASAP

https://docs.google.com/file/d/0B-5Ax5kejTpMemdkYkVXcXJZVU0/edit?usp=sharing

So that was rather decisive -

Candidate Elected: MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6 (5345)
Candidate Eliminated: MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv (191)

Coin owners have voted to maintain their balances. Shock! As the hard fork idea dominates the restart with block 1, I'll pursue that unless it becomes untenable. Roll on block 1655.

To reset your vote, you can send a small (but slightly larger than usual) amount of satoshi to the address you voted for. This should send it to the bottom of your list of preferences. The two addresses I chose were for fixed size large grant amounts 7000, 5000 . . as they're unlikely to ever meet the threshold, only a small amount of satoshi should ever go to either.

In any case it's been interesting to have held a proof of stake vote - we know we've got that capability now, and it's preference voting, so it can be used to choose from a range of possibilities. It does impinge a bit on the grant award system though - some grants will have been lost to hold this vote.
 

Looks like a disagreement at block 1569 or 1570.

actually one of my clients did synch to 1570