 Show Posts
|
|
Pages: [1]
|
WTB 100 MON for 0.05 BTC
I will have to disappoint you, expected price of 100 MON is much more than what you offer (0.05) maybe if you remove one zero - 100 MON for 0.5 BTC Specifications:
Premine: Zero
Algorithm: Scrypt-N, merge-mineable on the VTC chain
Total circulation: 8.4 million MON
Only 8.4 million MON less than BTC or LTC or VTC  Except you get MON for "free" while mining for VTC, so there's absolutely no reason to expect MON to approach such a high valuation. What this guy said. I spent 2 hours setting up merge mining on my local machine. I am still getting the exact same amount of VTC, but now also have a few hundred MON sitting around that I got for 'free' essentially. The cool thing about MON isn't the value. The cool thing will be once it is bug free, sharing resources like a real p2pool coin, it is now the perfect template for additional merge-mined coins for VTC. POS coin? Easy! Code carrying coin? Easy! |
|
|
|
I'm mining vert + mono from vtcpool, but for some reason I'm getting quite a lot (~10%) rejected shares;
[2014-05-03 08:33:22] Rejected 02402954 Diff 114/52 GPU 4 pool 0 (Invalid share)
Any idea whys' that?
15% is standard in p2p. As long as you are under that you are getting more then other peeps. |
|
|
|
Is it normal to have only 120-130 khs with 270x?
No - you should shoot for about 48% of what you get mining scrypt. Something is wrong...I've tried everything and nothing...1040/1400,intensity 18 and it wont go over 130 khs Try: intensity: 13 (or even 12) gpu-threads: 2 thread-concurrency: 6400 Clocks should be fine. I don't have a 270x but that seems to be what most people are having success with. Thanks...it works now I just tweaked my 270's (nonx) and am getting around 220khs with the following, note that one is on an underclock "gimpy" because I voltmodded them and he is unstable in the head. These are configs for the 'kev' miner, note rawintensity and 2 threads at once. "auto-fan": true, "auto-gpu" : true, "gpu-fan": "50-100", "temp-cutoff": "95", "temp-overheat": "85", "temp-target": "75", "gpu-threads" : "2", "worksize": "256", "rawintensity" : "5120", "gpu-engine":"600-1050,600-1050,600-850,600-1050,600-1050", "thread-concurrency": "7039", "api-port": "4028", "api-listen": true, "api-allow": "W:127.0.0.1", "failover-only" : true, "no-pool-disable": true, "queue": "0", "kernel-path": "/usr/local/bin" |
|
|
|
The payment system uses a variant of Pay-Per-Share, which involves storing a value for every single valid share whether the node finds blocks or not. The difference with this system compared to normal pps is that it will not pay out more than it earns (unlike some pps pools where users can get credited more coins than the pool actually has, one of the reasons pps pools have so high fees). Since you're effectively solomining on a network that currently has ~515Mhash you will not find blocks very often unless you have a very high hashrate. But it will still save all your shares for when the pool is lucky, because at those points it can pay more. This means that you haven't really earned those shares, they're just an indication of what you could be paid if the pool was super lucky (e.g was always finding blocks at the expected time or faster). You can read more at http://eligius.st/~gateway/faq/capped-pps-recent-backpayAlso, there are two settings in sharelogger.conf "minbalance" and "mon_min_tx", their default values are 1.0, this means that to pay you anything (assuming you are the only miner and 0% fees) the pool would need a balance of 2 MON. You can reduce these but keep in mind that there are no free transactions with monocle and the minimum fee is 0.01. This idea is to get people used to higher fees, which are needed later on to provide enough incentive for miners to actually mine the coin once the block reward goes to 0. That being said, you might have immature blocks, use "listtransactions" or "listaccounts" to see the immature blocks or see the total balance. Interesting - I thought by setting up the pool with 'merge' set I would effectively be mining both vtc and mon with everyone else in the network? I am still getting quite a bit of VTC, but yeah... sucks if the same doesn't hold for Mon. |
|
|
|
Maybe I am misunderstanding something, but does this seem right for my pool server?
mysql> select sum(monvalue) from stats_shares;
+-------------------+
| sum(monvalue) |
+-------------------+
| 4.443734682918838 |
+-------------------+
1 row in set (0.02 sec)
linux:~/monocle$ ./monocled getbalance
1.00000000
Showing I should have 4.44 mon, but the wallet only has 1?
Just my machines running on this p2pool at the moment. No payouts yet :|
Try getbalance "" You will find you have unconfirmed coins, so you can't payout just yet. Same result. ./monocled getbalance "" 1.00000000 My pool has been kicking out VTC pretty regularly - but maybe the Mon P2Pool has a huge delay? I assume that the local wallet is only for found blocks, not the actual shares that are being 'mined' on the p2pool network. |
|
|
|
|
Maybe I am misunderstanding something, but does this seem right for my pool server?
mysql> select sum(monvalue) from stats_shares;
+-------------------+
| sum(monvalue) |
+-------------------+
| 4.443734682918838 |
+-------------------+
1 row in set (0.02 sec)
linux:~/monocle$ ./monocled getbalance
1.00000000
Showing I should have 4.44 mon, but the wallet only has 1?
Just my machines running on this p2pool at the moment. No payouts yet :|
|
|
|
|
|
Boris - You rock! Busy Friday eh?
|
|
|
|
|
Running a pool here -
Seeing quite a bit of activity in the Mysql database
Seeing 1 Mon in the wallet
The python payout script is saying that no one has a balance to pay - I am still getting paid VTC pretty regularly though...
Sample from
mysql> select * from stats_shares;
| 3404 | 2014-05-02 13:02:10 | Vnrv2wrKabnuz1DMHC3ZbZHLMNmUgpmLKC | MQudPTCochGUcd6zkRUGJvVKVwpHC6RJkm | 0.002 | 0.001 | 0.000409597448 | 244.14214616 | 2 | 0 | 0 | 1 |
+------+---------------------+------------------------------------+------------------------------------+------------+------------+----------------+--------------+---------+---------+---------+-------+
3404 rows in set (0.03 sec)
errors from the payout script:
Payable shares: 1
2014-05-02 12:55:51.511093 No user with a high enough balance or not enough coins to payout.
2014-05-02 12:55:51.511615 All transactions failed.
2014-05-02 12:55:51.511705 Retrying in 5 minutes.
2014-05-02 13:00:51.613265 Fetching shares from database...
2014-05-02 13:00:51.643596 Available balance 0.00000000 MON, 0.00000000 VTC
2014-05-02 13:00:51.643676 Shares backlog 3360
2014-05-02 13:00:51.643719 Payable shares: 1
2014-05-02 13:00:51.643748 No user with a high enough balance or not enough coins to payout.
2014-05-02 13:00:51.644300 All transactions failed.2014-05-02 13:00:51.644395 Retrying in 5 minutes.
|
|
|
|
|
Correct me if I am wrong, I believe p2proxy.net belongs to one of the Vertcoin developers. Can the Vertcoin dev team share out how to get the stats out? Please?
pull them straight from the database
|
|
|
|
|
Whoever else is mining at freddingo.no-ip.biz, if you are trying to mine MON be sure to update your port to 9555 instead of 9171. I believe you are still mining just VTC at this moment.
The web stats will show your mining go to 0 - but that is normal since the p2pool web stats only show 9171 (vtc only) at this time.
|
|
|
|
|
Mon is going to take a few hours before ANY payouts because we have to get to block 120 first!! we are only on maybe 3??
|
|
|
|
|
Pool owners still need to compile the wallet and make sure the merge scripts are working. I expect around... 15 minutes till I am good to go.
|
|
|
|
Should we expect that the
"Python payouts.py" command will work without the Mon wallet running? I am getting 'cannot connect' errors that make me believe so.
Yeah the payout command won't work if it can't connect to the MON wallet. Rockin - thanks! I do believe my p2pool will be good to go within an hour after launch. Even did some work to get a ddns up and running. West coast of USA. http://freddingo.no-ip.biz:9171/static/To be fully clear - the version of the p2pool that I got last week should support the --merged option out of the box? |
|
|
|
|
Should we expect that the
"Python payouts.py" command will work without the Mon wallet running? I am getting 'cannot connect' errors that make me believe so.
|
|
|
|
Wanted to put out my quick findings with the 750ti since I went through a build and learned a bit, hopefully this helps some people. - EVGA Ftw edition, currently running 320khs for each, 5x cards
- Gigabyte UD3 motherboard, some random 4gb stick of Kingston ram that was cheap on amazon
- I was unable able to get the USB 1x-16x risers to work. Performance was all over the place, and I got random crashes and instability in Cudaminer. These same USB risers are now used on a r9 270 rig at 100% speed, so I just switched risers with that machine -see next note
- I was able to get a mix of unpowered ribbon 1x-16x mixed in with powered 1x-16x risers to work just fine at 100% speed.
- I can not overclock memory more then 600mhz
- GPU doesn't have much of an impact on the hashrate
- x86 miner is faster than the x64
- Cudaminer 750ti Settings I saw that work / made a difference: T10x24 performed slightly better then T5x24 and -H 2 is the best for stability.
- Windows 7 64bit, really wish there was a BAMT equiv for cudaminer though.
- Inside a heated home the 750's do not break 50-55c at full load and overclocked
I do get random OS reboots, but I set my windows build to auto login with the miner spinning up on startup. So a crash or 2 a day doesn't impact my mining for more then 5 minutes. Still not sure what that is all about... |
|
|
|
|
