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

@ SlyWax: Thank you

Thanks, yes there's rounding down going on - the numbers are usually pretty large so it shouldn't matter too much.

Stas, you should run it from the commande line :
memorycoind --daemon -debugvote=1
or
memorycoin-qt -debugvote=1

But you should check first your .memorycoin folder for a grantawards folder, in witch the most recent version of memorycoin will put the grant logs.

Nice stuff by the way FreeTrade.
But you are rounding the display ?
Because the sum is not correct (because of the fractional part I guess).

@SlyWax: I have voted for the Pool.

I get an error when I am running this command "-debugvote=1" though the console.
Is there a version where it works?
where do I get it?

Thanks

We have already 4667 votes in one day.
We can do it !
Don't miss your spot and get the reward by voting for the pool now.

I see a list with known problems there, but no new client
I have taken my 6-core and 4-core machines off this coin and put them on something that runs overnight without crashing.
Looking at the difficulty that has dropped down again, more miners have done this too or their machines hang and they don't know they are not mining.
As soon as there is a stable release I will get back on board again.

MemoryCoin Auction - 500 MEG to Highest Bidder
https://bitcointalksearch.org/topic/memorycoin-auction-500-meg-closed-0006-btc-meg-277147

Start the latest version with the -debugvote=1 switch - should have these available on the web soon.

Is there a way to find the results of rounds of voting - either just the latest, or historical?

I meant the largest memory Scrypt you are using. So if 64MB, then it would use the most time agreed if you were running them each the same number of times. Now I see you are running the shorter Scrypts more times to compensate. And still the 6GB on the GPU means it can run 96 threads on the 64MB Scrypt to defeat memory latency (and take advantage of the 10 times higher main memory bandwidth in the GPU), whereas the CPU can't. So 2/3 of your scrypts the GPU can trounce the CPU by 100 to 1000 times in theory.

I am expecting roughly, 0.33 x 10 + 0.67 x 100 (or 1000), so roughly the GPU 70 - 700 times faster.


I am thinking 99% of the 2% per annum could go to GPUs.

Tangentially, I don't understand how you expect to maintain interest in your coin for enough years for it to gain traction, when 90% will already will awarded in one year. You need new adopters continuously, not just the few who got in early.

Hi,

Something is wrong :-(

I started my client with the -gen switch and started mining, after a night I got 2 blocks and the client crashed.

After start it again and synchronize with the network, I don't have my 45 MCoins any more :-(


I was checking the get miner info from time to time and was geting around 10 mh and the "green" tick was alwas on.  I thought that I was on the safe side.

How can I check that everything is fine, and not get the sad surprise the day after?

Cheers
  MC

I bet you'll find (on a CPU) the 64MB Scrypt takes twelve times as long as the 2MB Scrypt which takes ten times as long as the 128K Scrypt, so that when the 128K Scrypt is run 120 times interleaved with the 2MB Scrypt that is run 12 times and the 64MB Scrypt that is run once, they each take 1/3 of the time required for the overall hash.


Thanks, looking forward to it. Consider also that the clock is ticking for any GPU implementations. Should have 90% minted within a year, and 10% the next year. It would be regrettable if GPUs or ASICs were to capture the 10% and/or the 2%/year distribution, but not catastrophic.

I bet you find the 2MB Scrypt is the dominant time factor.



Understood. I just discovered my deeper insight into Scrypt and Litecoin this week.

I will get back to you when I have something concrete to grab your attention, even if it proves I was wrong, so that the issue is resolved.

Now that we have some nice script, let's try something :

I'm calling you, the small miners, to make a revolution and take those grant from the hand of the wealthiest.
We need to kick the butt of those hidden rich people who are taking our grant away!

That is why I'll open a new REVOLUTION POOL GRANT MINING.

The pool will give you back a % of the grant proportional to your vote (coin in the voting address).
You have to vote for this pool address :

MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb

The address has to be your first choice (send the smallest amount to this address), so that I can calculate your reward.
Feel free to vote for other address like memorycoin foundation as second choice.

When we reach a grant, I'll calculate your share and send it to you.
For the few first grant, I'll double check manually to see that every thing is working well (so expect some delay), then I'll go on fully automatic, so you get your reward earlier.
For this work I'll only take 1 coin from the grant, and it might be even lower after some time if automatic works flawlessly.


PS: I'm reusing the previous grant address since it wasn't used anyway.

Well it's anticipated that specialized hardware will be able to run parts of the algorithm more efficiently. However to run the whole hash efficiently you'd need to run all three parts efficiently (four counting SHA512), and specialized hardware to do that would look a lot like . . . . . . a CPU.



Interested in any diagnostics you're seeing on the CPU miners we've got available.



I would have been interested in a detailed discussion on these points 2 weeks ago when there was more scope for re-engineering. As it stands now, the show is on the road so I don't want to be switching the engine unless it's clear the one we've got is failing. If you can demonstrate that you will have the pleasure of my undivided attention.

I think it is better I let you launch as is, then later when I build my test suite, I will confirm if I was correct or incorrect.

Agreed?

I don't have the time immediately right now to create a build environment and compile and test your code, thus the best I could offer would be code or pseudo-code and without a test suite you are not likely to believe my hypothesis, thus you wouldn't be motivated to make my code work properly.

So at least I made you aware of this possibility, then we deal with it later when I have the goods in hand.

I am not sure until I run some tests, but my strong belief (based on good analysis) is that that you are hitting memory latency in your CPU with the 2MB Scrypt, but the GPU will not be. Thus it is going to toast your CPU. This is not a minor problem, rather I conjecture it is total failure to get what you intended. The reason I suspect this, is because the GPU can run 6 x 1024 MB ÷ 2 MB = 3096 threads and thus entirely mask away the latency. Whereas you do nothing to mask the latency on the CPU as far as I can see in your code.


I think yours is worse than Litecoin's by a factor of 10 or 100, i.e. 100 to 1000 times slower CPU than the GPU since Litecoin is already 10 times slower CPU than GPU!   At least Litecoin stays within L2 cache, and it is not just the memory bandwidth but the TLB and L2 cache reloads that run 100+ cycles that kill you.

You appear to have a serious fail here, but I would need to build a CPU miner to test my hypothesis.



Yes I am, but as I said, if I can help you and at the same time benefit from having my idea tested earlier, then it is win-win for both us, in spite of our disagreement on orthogonal features of MemoryCoin. There is no need for me to comment further about your grants. Best is you try it, then we all learn from the result. I wouldn't copy your grants, nor your 2% deflationary coin, so there is no competition coming from me against MemoryCoin on those features. I am delighted you introduced a coin with continuous inflation (albeit only 2%) and not ridiculously high as Inflatacoin, so if you get adoption then it opens the door for a coin with slightly higher rate of inflation.

If instead you don't want to share synergy or simply have other priorities demanding your attention, then that is fine too.

Here is a new script,

It's meant to recap every thing when you come back to your mining PC.
What I like about it is that if I've mined some block since the last time I checked, it will display a blue bar with the number of coin mined for this period.
There is always some suspense when I run it, and the good thing is I don't have to remember my last balance to see if I catched something.

The output :
path to .memorycoin -- the date/time you executed the sript
New minted coin or balance change since last run (nothing if nothing new)
Stats: {
    "blocks" : 2993,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 0.00023274,
    "errors" : "",
    "generate" : true,
    "genproclimit" : X,
    "hashespersec" : xx.xxxxxx,
    "pooledtx" : 0,
    "testnet" : false
}
Confirmed Balance: xxx.xxxxxxxx
Immature Balance:  xxx.xxxxxxxx        TX:  x
Total Balance:          xxx.xxxxxxxx 

Last 3 minted date :
date in your local time (system pref)

Blocks since start ( date of start UTC ) : XXX
Connections: XXX
--
Save the sript below to a file named mpeek for example, type : chmod 700 mpeek to make it executable.
To use it type ./mpeek or just mpeek if it's in your $PATH.
replace the line "miner=memorycoind" with "miner=/pathTo/theNameOfYourExe" if you changed the name of the memorycoin executable.


Edit : you have to run it once to initialize the balance.

The MemoryCoin Foundation -
http://memorycoin.org/foundation/

So it's not just that the improvements in adding cores are not linear . . . it's that they appear to be converging to an upper value, suggesting that they're hitting a limitation other than cycles per second. I'm assuming that's related to memory access, either cache memory size or main memory access.  I'm assuming too that a GPU will hit that limit too, and any increased performance because of wider memory bus, speed or cache would be offset by the slower cores.

You make other good points and I don't have the time to give them the attention they deserve immediately. I'm sure there are improvements to be made in the hashing algorithm to make it more GPU resistant, but I'm more concerned with having one that is 'good enough' rather than a perfect one that might fork the coin or cause loss of momentum.


Yes, there's a lot we disagree on. Have you considered implementing your ideas in a new coin? That's what I did when I decided all the other coins had it wrong!