[your payout] = [Loyality Bonus pool balance] / [all monthly valid shares] * [your monthly valid shares][/li][/list]
This part I don't like. What's the point using a hopping-proof method and then adding a hoppable feature? The method handles transaction fees as is as long as you determine B correctly. It needs to be the total block reward corresponding to a share's getwork. You can add namecoins by having separate Bitcoin Score and Namecoin Score, where the namecoin reward according to the method is converted to bitcoins before entering the confirmed balance. Agreed, thats a quick and dirty offer to stay competitive. Will work on this, as soon mm is enabled in order to offer a fair and transparent longterm solution.
|
|
|
Greetings, we are working on merged mining as well. Until we get a working solution, i'am donating 15 BTC to our miners to make sure you won't have a disadvantage. In order to gain full advantage of merged mining we will gather all nmc and trade them for you into btc as a service. Payout will happen in form of our so called Loyality Bonus. This is how it works: Everytime the pool gains additional income like transaction fees from solved blocks or merged mining earnings it will be gathered in our Loyality Bonus pool balance. - We gather all additional earnings in a Loyality Bonus pool balance.
- At the end of every month, the whole pool balance is payed to the pool and we start at zero pool balance again.
- Payout is calculated propotional on monthly shares:
[your payout] = [Loyality Bonus pool balance] / [all monthly valid shares] * [your monthly valid shares]
I hope you like it! Cheers, Chris
|
|
|
So what happens to the shares table with merged mining option enabled?
Can you confirm, that upstream result from each row refers to the parentchain (btc) only? So the upstream results from the merged chain is currently not in the database right?
The upstream result should be true for both chains for now and you just check your wallet to see witch block chain got it. In the future shadders can add column in the database or a new table (preferable) that indicates witch block chain found a block. Thanks DavinciJ15, this solution works fine for me. May i ask if you found a 4diff patch which can be compiled with the current bitcoind version vom vinced? Best regards, Chris
|
|
|
Yes a JK 4diff for the mm version of bitcoind is needed however I don't think it's really necessary for namecoind or other aux daemons. They do not deal with a torrent of rpc requests like the bitcoind does. Just some aux block updates every few seconds and submission of valid shares which is also rare.
I would really interested in a JK 4diff patch for vinced mm bitcoind version in order to test the poolserverj implementation. Is there any solution out there?
|
|
|
So what happens to the shares table with merged mining option enabled?
Can you confirm, that upstream result from each row refers to the parentchain (btc) only? So the upstream results from the merged chain is currently not in the database right?
|
|
|
I like the idea. This could be a good start: https://github.com/cdhowie/Bitcoin-mining-proxyAfaik it doesn't support that load balancing to each pool but right now the failover works well. Maybe cdhowie is going to improve it according to your needs for the bounty.
|
|
|
I totally agree with shads.
I won't take a huge risk on my pool and for all existing miner, if we don't know about any side-effects right now.
If any pool will take the risk with existing software right now, please consider:
- merged mining right now comes with higher risk for your whole backend -> is the software ready for highloads? -> what about stale rates? -> are your pool member ready to accept necessary downtimes and outages?
Maybe i'll regret it, but right now, i'am happy not beeing an early adaptor, even if some people see advantages of merged mining right now and are willing to change a pool.
It's my responsibilty as a pool operator to offer a solid and stable pool service and if i would rush into merged mining right now, i cannot guarantee for it.
|
|
|
Adjusting maxWorkAgeToFlush and maxCacheSize helps a lot. Try to raise maxWorkAgeToFlush to 300 and lower maxCacheSize to 1000 for example and take a look at your cpu usage again. Make sure you got bitcoind patched with 4diff. A more detailed documentation: http://poolserverj.org/documentation/performance-memory-tuning/
|
|
|
News Update: Our pretty young pool just solved block no. 4 a few hours ago. The average payout per share on block 148102: 0.00003789 BTC.
The pool is running a decent hashrate right now, so the average time to solve a block decreased.
We even got some new features:
* Worker Idle Notification Can be adjusted on every single worker now.
* Payout Notification Will be send everytime you receive BTC.
* Payout Address Change Notification For improved security.
* Average Hashrate Access over User Statistics -> Worker Lifetime
* Improve Geomap Even more colors now. If you like other colors, let me know.
You are welcome to join us!
|
|
|
The old API does a reset each new block, so it's somekind of worthless ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Just added a special API to show the lifetime shares for each contract: http://yourbtc.net/api_contract.php
|
|
|
mining proprtinally cuttently i make just a bit over what .000034 per share would
I don't see how that's possible - it should average out to the expected value in the long term. Unless you're pool-hopping the proportional pools... I think such a contract could be a perfect match if you use Pool Hopping tools. If your expected value per share is lower, switch to the contract. Since nobody is forced to finish the contract, you can only win.
|
|
|
Added some more contracts with a lower volume of shares, these should be attractive, if you run small rigs.
If you have any doubts, i can offer to payout in even smaller intervals than 20% shifts.
|
|
|
Greetings, i'am looking to buy some of your hashpower and willing to pay 0.00003400 BTC per Share. Status: no more contracts availableAvailable Contracts: https://docs.google.com/spreadsheet/ccc?key=0ApdMWMq4VC7cdDltb3ZRb0FEeWN4U204eElYWnAwRlE&hl=deJSON API to monitor your contract live stats: http://yourbtc.net/api_contract.phpIf you are interested, send me a PM with the ID of the Contract you are interested in. Rules: * Mining will happen on my own pool, you don't have to register, i will send you details on how to connect your miner. * Each contract expires either when the amount of shares are done or the contract expires over time. * I'am willing to pay +10% of the amount shares per contract, so you will be safe to switch or stop your miners, as soon as the contract expires. * I will pay even for invalid shares, if your miner reaches the average efficiency of the pool. If your efficiency is lower, this amount invalid shares won't be payed. * Payment will be done each 20% of total shares. Here is an example: on 1,000,000 shares you will receive 5 payments each 200,000 shares. * Progress will be tracked once a day and updated in the upper Google Docs sheet. * Please set up your own backup pool, if my pool won't be available. I will try to keep the availability > 99%. I won't pay for any share in your back pools. Hope to hear from you soon. Chris
|
|
|
Our lucky strike goes on! Another block bites the dust.
The average payout value per share and of round 3 was 0.00003795 BTC.
We can still handle a bunch of new miners, i would love to see some new miners soon.
|
|
|
We got lucky today and solved a block within a quick round.
Double Geometric Method is working really great so far!
The average payout value per share and of round 2 was 0.00008079 BTC.
|
|
|
Everyday another suprise: Server seems to be offline atm. I've already called my server hoster, they are "investigating" that issue... Hope it will brb soon!
Update: Problem is fixed. Seems like the whole datacenter was unreachable for about 2 hours.
|
|
|
Oops! Just realised I'd gone from looking at my User Estimated Payout to the pool Estimated Payout chart. All is good :-)
Would you mind explaining what this means on the pool website: Rnd. Share Val.: 0.00025292
Yeah sure, here is a quick example: We just started a new block and gathered 120,000 shares and the estimated pool payout at this time is 23 BTC. 23 / 120000 = 0.00019167 It should be called "current average value per share in this round" but that lenght doesn't fit into the header. I have deceided to remove it yet, because the value would only be true if we find a block at the moment the value is displayed. The final value per share can be viewed in your personal account under "Previous Rounds" when we know exactly how many shares were needed to find a block.
|
|
|
First Block found! Congrats everyone!
Still over 50% of the 10 promotion BTC left! Time to jump in.
|
|
|
|