Topic: [ANN] MemoryCoin - page 35. (Read 100357 times)

One advice for managing git: Use a single branch as your main branch (typically master). Then use other branches for experimental features or work in progress. Then once you would like the general public to use those features merge that branch to the master.

This way, for example you push the change to "fasterstarup" while work in progress, ask more savvy people to try it out on different platforms, once satisfied then merge to master. At this time the general population including fresh users get this. This also means people who cloned master in the past just need to do a pull rather than checkout an alternate branch .

Changing the main branch on github is a little disorienting.

What is the "main wallet address"? I'm not sure Bitcoin has such a concept, is it a MemoryCoin thing?

Right now, seems like every wallet step I'm doing is generating a new address.  Currently from the cmdline, getaddressesbyaccount ""  shows about 9 addresses in the default account (plus I have others in separate accounts made for the MVTE addresses.)   Is the bottom one of the 9 the main one?  But I saw 2 different ones from this list show up on your voting results tally with my voting balance/weight split between the different addresses.  How do I consolidate all the coins to one voting address?  In progress, I am trying: send them all to one address that had a vote registered - and will see what the next round shows.  If that doesn't work, what next?  Send all coins to the bottommost address?  Or I'm thinking: start a new wallet, send all the coins there, and leave the grant addresses in the current=old wallet, and then re-vote from the new wallet?


Is there an rpc call to show those vote summary lists, or a separate program?  Or you are piecing it together from debug.log info?

There's some info in the Debug, but it's not complete and I need to tidy it up.


It uses the balance as at 20 blocks previous to the current block. So at block 640, it looks at how things stood at block 620, and awards grants based on that. You could work out what grants will be awarded in block 640 as soon as block 620 is settled.
(and balance at time of vote is not important).

It's one particular address. But they should be the same thing.


Yes, they'll be created by they won't be used. Change will go to your main wallet address.


Yes, it is probably this. Use a separate wallet for each address to keep it simple.

Probably.


Thank you kindly. I had a brief exchange with one of the Freicoin guys. He said they hadn't been able to work out a way whereby coin owners wouldn't just vote to give themselves the coins. Well I hope I've found a way. We'll see.

FreeTrade,

How does one list those voting results you are posting? Is it showing all the votes, or just the top few?

Does voting at each round use the current balance at the address, or the balance at time vote was placed?

Is the voting balance the whole wallet balance, or just the amount currently credited/received by 1 particular address/account?

Possible Bug?: I am seeing a series of new addresses generated in the default “” account, apparently related to the 4 txns produced by sending to MTVE addresses. From brief read through your design notes, I thought an objective was to preserve the sending address when generating change, so is this an error (?). The series of new addresses is confusing my voting, as it seems I'm not getting the whole wallet balance for the vote weight, just the amount accumulated at 1 address before it changed to the next. Could be related to: I have been importprivkey the grant address into the same wallet, generally before sending to it. Maybe it's better/necessary to use a separate non-mining/non-transaction wallet to receive grants?

Also I've had a vote “disappear” (not show up on your lists) -- I'm now guessing this is because the sending address had a 0 apparent balance, per the above.

Thanks for your great work on this interesting, innovative coin. If you are not already in touch, fyi the FRC Freicoin developers have also been working towards a distributed voting feature like this, and will surely be very interested in the developments and experimental results with MemoryCoin.

I'd like to add this. If anybody has step-by-step instructions on how to compile this library and include on Windows - help would be gratefully accepted.

Okay, fixed the slow startup problem - here's the link

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

You'll have one more slow startup as it indexes, and after that startup will be . . . you'll be pleasantly surprised.

Also I've bundled VanityGen with a .bat file - click on that to create your own open-ended grant award addresses.  The last grant awarded only had 253 coins voting for it. Beat that and you'll get a free grant award.

Just use the addnodes that are posted in this thread.
When I use these I have no problems connecting and I get 7 or 8 connections in a few minutes.

Actually it is working.
I have 8 connections to the network.
I have mined few blocks since it was lunched.
Didn't get any orphans.

right, it's not 2000 coins per minute like some other coins ... so because of that it's not working?

This coin network is not working because of lack of UPnP support in the compiled release.

For many people, '1 active connection to Bitcoin network' = All orphans

Doing a release without UPnP support is a scam, because like you said, you'll make sure the blockchain stays protected.

Sounds right, thanks for the figures. So someone mining on EC2 would have about 8cents per coin production cost. (Note, difficulty seems to be high at the moment.)


Yes, that optimization would likely improve hashrate. I'll bet someone has already done it.


Not yet.

I nuked the instance after an hour... but.. its currently ~$0.253 / hour on spot.

note 8 hour is the maximum time taken to try out all possibilities for a single block. A block could be found sooner, other users could find a block in meantime needing a restart...

Taking your 8 hour estimate, for EC2 mining to be successful, a single block needs to be worth > $2.024  at current difficulty.

Another thing i noticed was while mining, the memory usage for bitcoind was swinging wildly from couple of megs to > 1 GB . Is it possible to allocate memory once and re-use that? I think a lot of time may be wasted in memory allocation and subsequent garbage collection.

Is there some documentation about the hashing algorithm used? (Sorry im not fluent in reading c++ code)

block 585 - 10mins,
block 586 - 12mins,
block 587 - 1 hr,
block 588 - 41mins,
block 589 - 22mins,
block 590 - 9mins.

difficulty has fallen in the last hour or 2.

Yes, it looks like that.
I don't know how the difficulty adjustment on this coin is, but it looks as if some miners have stopped and left difficulty high for the miners that are left.
We will see if the difficulty will drop in the next hours. I'm adding another 4-core machine later today but that will not make the difference I guess

Some nodes for anyone having trouble connecting

180.183.156.19
79.113.210.220
37.128.134.26
72.23.76.121
192.241.232.80
46.98.142.139
178.74.103.10

looks like it's block per hour now

is NOT gone be

looks like this hour is gone be any better:)

Thanks - looking at this and the i5, I'm concluding the bottleneck is at L2 Cache - having about 2MB available per thread is ratio to aim for.

Now, if my calculations are correct, at current difficulty,  0.00028632, each hash represents about a 1 in a million shot at solving the block.

Your EC2 instance is giving about 35*60*60 = 126,000 hashes per hour - you'd expect to solve one block every 8 hours.

To calculate the current cost of mining a block, what's the lowest price Amazon does that type of instance for? (I had a look at their pricing, but couldn't work it out)

I restarted my computer and got 587 now as well. It was issued at 16:07 so that was a very unlucky hour for all the miners.

have restarted the client . now it's on block 587