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. #!/bin/bash coindir=~/.memorycoin miner=memorycoind
echo ${coindir} -- $(date)
conf=$(${miner} getbalance) transaction=$( ${miner} listtransactions "" 9999 ) immature=$( echo "${transaction}" | grep -A1 immature | grep amount | awk -F':' '{ print $2 }'| awk -F',' '{ s1+=$1 }END { printf "%5.8f", s1 }') total=$(echo "scale=4;${conf} + ${immature}" | bc) mybalance=$(cat ${coindir}/mybalance)
if test ! "$mybalance" = "$total" then echo -en "\033[46m " minted=$(echo "scale=8;${total} - ${mybalance}" | bc) echo -e "${minted} \033[0m" echo -n "${total}">${coindir}/mybalance fi
echo "Stats: $(${miner} getmininginfo)" printf "Confirmed Balance: %*s\n" 13 "${conf}" printf "Immature Balance: %*s" 13 "${immature}" echo " TX: " $(echo "${transaction}" | grep immature | wc -l) printf "Total Balance: \033[32m%*s \033[0m \n" 13 "${total}" echo echo Last 3 minted date : echo "${transaction}" | egrep -A9 "\"generate\"|immature" | grep timereceived | tail -n 3 | cut --delimiter=":" --fields=2 | while read VAR ; do date -d "@$VAR" ; done echo
numligneA=$( grep -n "Startup time:" ${coindir}/debug.log |tail -n 1 ) numligne=$( echo "${numligneA}" | awk -F: '{printf $1}' ) numligneDate=$( echo "${numligneA}" | awk -F: '{print $3":"$4":"$5}' | sed 's/^ *//g' )
echo -en "Blocks since start ( \033[35m${numligneDate} UTC\033[0m ) : " tail -n +${numligne} ${coindir}/debug.log | grep SetBestChain: | grep -c date
echo "Connections: $(${miner} getconnectioncount)" echo
Edit : you have to run it once to initialize the balance.
|
|
|
You cant give 100% reward to someone, that would mean the others won't get anything. Or I didn't get from what you are taking your 100% ...
What I meant by 100% reward is share value of an exactly diff matching submitted chain. Still don't get it sorry, but may be it's because you are referring to your way of calculation. Anyway, the reward should try to match a % of the chain/day that the miner have, if this indicator is proven to be reliable. But since chain/day cannot be used as a prof of work, you will have to finely tune the repartition of the shares.
chain/day is probably a deterministic model, the I could look at Sunny code and implement it on pool side I think. But as it's not accurate, does it worth it ? I don't think so, but it can be used to see if the reward system is fair for small miners. if we allocate different value for each length, we should take : S(L) = percentage of share allocated at length L. C(L) = number of chain of length L found by all the pool miners. M = block value in XPM
If a miner found F chain of length L he will gain for this length : G(L) = M*F(L)*S(L)/C(L)
Your model is nice, but it's still discrete; to be reliable, share value need to be continuous as proof of work and diff are in primecoin network. That was my previous point. No the difficulty been continuous is because we need it to be like that so it can be increased/decreased continuously. But it's merely an artefact that work by accepting only a % of the chains at right length. But the effort to calculate it is the same so it should be rewarded the same. .../ But S is also function of total chains accepted during a round. If we call R the network block reward and Ci, each of these chains therefore we have to calculate S such as sum of all Ci weighted by internal reward percentage equal R. /...
In my formula M is the network block reward and is equal to the sum of all weighted shares, by design. As a side note, I would like to emphasis that in a fair-play situation, you should reward more the lower chain length (globally), so that small miners are taken into account. Big miner won't be harmed, because they also mine a proportionally high number of smaller chain too. May be I should write it this way : G(L) = M*S(L) * F(L)/C(L)With M*S(L) being the allocated XPM for length L, and F(L)/C(L) being the ratio the miner got for length L.
|
|
|
SEVERAL COINS HAVEE AIMED TO DO THAAT THE FIRST BEING DEVCOIN TO PROMOTE scholarshiip, primecoin calculates prime im pretty sure orbitcoin calculates asteroid orbits\ curecoimnnn iss being developed
orbitcoin is a scam
|
|
|
FreeTrade, can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro" that would be nice. you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too... It miss some leveldb building too, I have to build the daemon to make them available. or remove the comment in front of : genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a and genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $
Still it crash on Ubuntu 32bits
|
|
|
The problem is you have to find a "puzzle" that fits right with the requirements of a crypto-currency. - Puzzle should be hard to solve
- Puzzle solution should be easy to check
- Puzzle should provide a difficulty scaling (and it should be continuous)
- Puzzle should be unique for each block (no previous solution, or anticipated calculus)
- Puzzle solution should not be too large, to not clutter the block-chain
- Puzzle should not depend on an exterior puzzle provider (this one can be discussed, but it' because otherwise it would bring a single point of failure)
There may be other constraint I didn't saw, if some real coin creator could add to this list.
|
|
|
The big problem for making pool is shares check.... Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view. Well you can check if someone is getting a fast paced flow of 6-er chains and nothing else, then the pool put his share on old, until either the luck is coming back, or he is proved to be unfaithful.
|
|
|
This one will list only those unknown grant hoarder to see what they are doing (mostly just stacking the grant to win more grant) tail -n +1 ~/.memorycoin/debug.log | grep --color=always -E \ "Candidate Elected:|Total of Voters' Balances:" \ | grep -Ev "MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN|MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3|MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z|MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N|MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh|MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6|MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb"
Donate/Vote for me : MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
|
|
|
Are you sure the daemon works fine ? (bitcoind) Each time I send something he create a new address.
I'm using the last version from github
|
|
|
I'm willing to do some script to help with the use of memorycoin.
if you want to encourage me, please send for example 0.00000001 memorycoin to this address : MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
The MemoryCoin Foundation would like to encourage you, but don't want to vote for you to receive grants just yet. Can you post a non-voting address and I'll get some coins to you. Here it is : MJu2Eg9pGjbLbvob9Y7iD4VkUqEpgTXEc3 Thanks
|
|
|
I'm willing to do some script to help with the use of memorycoin. if you want to encourage me, please send for example 0.00000001 memorycoin to this address : MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb And here is a first script to see the grants winners : ColorOff=$'\e[0m' ;Colorgreen=$'\e[32m';\ tail -n +1 ~/.memorycoin/debug.log | grep --color=always -E \ "Candidate Elected:|Award Round:|Total coin issued|Total of Voters' Balances:|Percentage of total issued coin voting:|Droop Quota:|Surplus Transfer Value:|Grant Voting" \ | sed -e "s/MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN/${Colorgreen} MemoryCoin - Foundation${ColorOff}/g"\ -e "s/MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3/${Colorgreen} FreeTrade - Dev${ColorOff}/g"\ -e "s/MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z/${Colorgreen}21st Century - Network and Clients${ColorOff}/g"\ -e "s/MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N/${Colorgreen} EFF - Charity${ColorOff}/g"\ -e "s/MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh/${Colorgreen} Amnesty International - Charity${ColorOff}/g"\ -e "s/MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6/${Colorgreen} No restart - Vote${ColorOff}/g"\ -e "s/MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb/${Colorgreen} Revolution - Pool${ColorOff}/g" With nice color and name instead of address for the known ones. Just copy paste to your linux command line.
|
|
|
My first transaction of 10 satochi ( for voting) went good. My 2nd transaction of 20 satochi : it created a 2nd address for the remaining 23.99979970 After that it seems it switched to a 3rd address for the generated coins.
I thought that you modified the code to send the remaining to the sending address ? ( to get your address balance : listaddressgroupings )
|
|
|
I think you are not flushing the debug.log every line ! My "tail -f debug.log" is one block behind the getmininginfo block number.
|
|
|
We need more vote for EFF and Amnesty, so that the 2 unknown rich men don't get all the grants, and too show that the voting is not cheated.
Or may be the richest could stop voting for themselves to forge more confidence in memorycoin...
The pool voting exploit is a problem too.
|
|
|
* 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 ?
|
|
|
If you want to get an estimation of your block/day : Take one minus the decimal part of the difficulty and multiply it with your chain/day.
block/day = (1 - dec(difficulty) ) * chainsperday
From your example : "chainsperday" : 0.28633614, "difficulty" : 9.68146938, block/day = (1 - 0.68146938) * 0.28633614 = 0,091206828 = around one block every 11 days !
|
|
|
* 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.
|
|
|
.../ On reward side, after discussions with mtrlt and mikaelh_ on IRC, I decided go with and exponential-based scheme with diff-3+1 (the +1 part is like a modulo and bonus parameter). As we have to deal with the integer nature of primecoin chains and the exponential diff adjustments, diff based reward needs to be differently calibrated.
For example at current difficulty (9.5) submitting 6-chain would give you 1% reward while submitting a 10-or-more-chain will give you more than 100% because 100% reward will be target to match the actual decimal number of diff and therefore the more we get closer to diff 10.0 the less your 9-chain worth. /....
You cant give 100% reward to someone, that would mean the others won't get anything. Or I didn't get from what you are taking your 100% ... Anyway, the reward should try to match a % of the chain/day that the miner have, if this indicator is proven to be reliable. But since chain/day cannot be used as a prof of work, you will have to finely tune the repartition of the shares. if we allocate different value for each length, we should take : S(L) = percentage of share allocated at length L. C(L) = number of chain of length L found by all the pool miners. M = block value in XPM If a miner found F chain of length L he will gain for this length : G(L) = M*F(L)*S(L)/C(L)For example :S( 9) = 10% S( 8) = 20% S( 7) = 70% C( 9) = 4 chain of length 9 found buy all miners C( 8) = 160 C( 7) = 4000 M = 10 XPM If a miner found 1 chain of length 9 he will gain for this length : G( 9) = 10*1*0.10/4 = 0.25 XPM 40 chain of 8 : G( 8) = 10*40*0.20/160 = 0.50 XPM 1000 of 7 : G( 7) = 10*1000*0.70/4000 = 1.75 XPM Total : 2.5 XPM
|
|
|
I support this voting innovation !
However we need more clear explanations, or a full protocol graph/description.
Thanks for your work.
|
|
|
No this is when it pass to the next chain lenght (ie: from 7 to 8 ). Difficulty is not linear !
|
|
|
Now in HD! Up to block 88877, 2013-07-29 22:48:52 UTC, anyway. What is that small fall after 78000 ? Is it real or you have error in your data ?
|
|
|
|