[ANN] MemoryCoin

[FreeTrade]

Thanks Coinelius, I've rated your advice highly ever since I read your posts on Infinitecoin. The hard fork seems to dominate a restart with balances in Block 1 in every way, so I think I'll attempt that first unless coin-owners vote for their balances to be reset in a fresh start, which seems unlikely now.

[SlyWax]

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.

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.

[bahamapascal]

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.

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.

+1
Totaly agree on that, would be good if the blocktime could be set to 1min

[21stcenturymoney]

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.

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.

+1
Totaly agree on that, would be good if the blocktime could be set to 1min

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.

[SlyWax]

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.

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.

+1
Totaly agree on that, would be good if the blocktime could be set to 1min

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.

It's nice to think but what is your argument ?

[YukonCoinelius]

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

the block time needs to be more than several times the maximum end-to-end propagation delay.  This is needed to prevent competing nodes from generating blocks at the same time and convincing large parts of the network that their respective block is the winning block.  
...
So what is the maximum end-to-end propagation delay?  Bitcoin networks are constructed by randomly connecting to IP addresses.  This means that Bitcoin networks ignore geographic locations, so end-to-end communication can cross the globe multiple times.  The network construction also does not limit the width of the network, so end-to-end communication can require numerous hops.  Add processing delays on each node and you can easily get a maximum end-to-end propagation time that is tens of seconds.

[B.T.Coin]

I'm leaning towards a hard fork at 1566 - more details here -

http://21stcenturymoneytalk.org/index.php/topic,30.msg54.html#msg54

As mentioned before, I'm all for a hard-fork but as pointed out on th 21stcenturymoneytalk forum, block 1566 might be a bit too quick.
Not for me but maybe for other users and also for yourself to get the code in order. Why not take a little more time and double check everything before releasing the nwe code.
I really think this is your last chance to get it right before the coin dies so take your time to get it right.

[YukonCoinelius]

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.

[torbank]

If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv

If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

100 blocks (about 10 hours) to go.

Still undecided.

[torbank]

If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv

If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

100 blocks (about 10 hours) to go.

Still undecided.

Can an alert be posted to the client or no?

[FreeTrade]

Can an alert be posted to the client or no?

Yes, I've got the private key to do this - is there a command in the client to do it, or do I need to craft the message some other way?

[FreeTrade]

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.

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.

[FreeTrade]

Here's the code change proposals for the fork at 1566 -

https://github.com/memorycoin/memorycoin/commit/d907ac124e1a95fe5af58b27c9559a566203b100

If there's no objections, I'll have an updated binary in 1 hour.

[FreeTrade]

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

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

[stas]

Have updated both of my clients.
not that much time left until the 1566 block.

If someone is not updated by then?

[FreeTrade]

If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv

If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

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.
 

[FreeTrade]

At Block 1568 now, and block 1566 came and went without incident here.

There doesn't seem to be any disagreement in the blockchain yet . .  1580 or some multiple of 20 after that is where the first disagreement will occur.

[FreeTrade]

At Block 1568 now, and block 1566 came and went without incident here.

There doesn't seem to be any disagreement in the blockchain yet . .  1580 or some multiple of 20 after that is where the first disagreement will occur.

Looks like a disagreement at block 1569 or 1570.

[stas]

uhu, can't synch  between from block 1569 to 1570

[stas]

actually one of my clients did synch to 1570