Topic: [ANN] MemoryCoin - page 29. (Read 100338 times)

I am on 1573 too

im on block 1573 now. is this correct?

Sounds like you're on the right branch. Other updated nodes are -

addnode 24.6.21.198 add
addnode 180.183.154.90 add

it took few minutes , now both of my clients synchronized

actually one of my clients did synch to 1570

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

Looks like a disagreement at block 1569 or 1570.

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.

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.
 

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

If someone is not updated by then?

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

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

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.

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.

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?

Can an alert be posted to the client or no?

100 blocks (about 10 hours) to go.

Still undecided.

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.

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.

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

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