|
It's very recently done, but without a fee so we need to find the block to confirm it before it will show up.
Edit: Also, the minimum payout will be 42.94967296 NMC for now.
|
|
|
|
its ok to have the same NMC address tied to multiple BTC addresses that are mining on Eligius correct? Correct |
|
|
|
I'm back, and most of the way done sorting through the big pile of papers waiting for me at my desk. We have a church picnic to go to today, and then a little bit left to catch up on when we get back. I expect to be ready to do the first SMPPS-based payout tonight (Eastern US). Anyone who hasn't registered their namecoin address by that time will be considered disinterested and any claim to earned namecoins forfeit. If you are interested and haven't been able to register for some reason, please contact me on IRC immediately with your bitcoin mining address; I expect to see any such persons seeking help completing registration in the #Eligius IRC channel before PMing me to be taken seriously.  |
|
|
|
Waiting for work DOES hurt the miner. I can't think of a scenario where a longpoll should make a miner wait for work. Are you telling me a pool can universally throw out enough work for every single miner working for it in the microsecond after sending out a longpoll at a rate fast enough to guarantee their GPUs don't go idle? Let's close the discussion before I get more annoyed. Well, I think pools should continue to accept the old work until they've finished sending out the new, whenever possible... Eligius continues to accept shares against old work so long as they're possible to submit to the Bitcoin chain (ie, same prevblock)-- but the missing transactions that were in the longpolled work will get delayed by miners who don't update in a timely manner. |
|
|
|
Waiting for work DOES hurt the miner. I can't think of a scenario where a longpoll should make a miner wait for work. |
|
|
|
There is no benefit to ignoring longpoll results.
That's not true. cgminer can detect block changes before it receives a longpoll, especially when mining on multiple pools at once. Thus it will have already thrown out the work. Getting a longpoll again after that will make cgminer throw out yet more work. Why do you think I've been resisting dealing with this fucking issue? Throwing out work doesn't/shouldn't hurt miners. Issuing more work than necessary hurts the pool (CPU time), but in this case the pool has already taken the hit. |
|
|
|
If they're not merged mining the longpolls should match block changes and whatever other reasons the pools actually use - It's my impression that they're all theoretical arguments and non merged-mining pools ONLY use longpoll for a block change. This is not correct. Eligius does not longpoll for NMC block changes, but it does for other unrelated purposes. That being said, ignoring those will not hurt the miner (at least right now) who is only interested in obtaining bitcoins (though it can harm the bitcoin network). Therefore, throwing out work blindly with a longpoll that doesn't have a corresponding detected block change, without adding any more command line options, is the most unobtrusive change that I can think of and I will do so in the next version. There is no benefit to ignoring longpoll results. |
|
|
|
It has to do with the pool sending back information about different chains ... They never do. It is impossible to detect merged mining on the miner end. The definition of LP is to notify of a block change - LP in itself is badly implemented but that is how it has been done.
How this hack has been added on top of LP ... well I wonder if it is even works properly ... No, the definition of LP is to notify miners of new blocks, which could have the "prevblock" header changed-- or might not. As others have noted, there are plenty of other reasons a pool might do a longpoll without changing "prevblock". When receiving a LP response, miners are supposed to discard their old work (it's "stale", which is a term defined by your particular pool) and start working on the new work provided. Not doing so is a bug. Since most miners don't have this bug, it would fit in the "makes cgminer not the best bitcoin miner" category. |
|
|
|
|
MtGox users please test the Namecoin registration page, choose MtGox from the client menu.
Since I'm not going to be able to finish processing NMC payments until MtGox users are registered, and I'm about to walk out the door, I'll try to make time to get online on the trip to do it.
|
|
|
|
The seller can send you a bogus product and CC cant charge back. Paypal dont guarantee the merchant's advertisement. As long as you receive the product, the transaction has been done. Since when? Imaging buy a product from a local store without return policy, can your CC do a chargeback? Yes. |
|
|
|
Due to the law of large numbers, the buffer will get closer and closer to 0 over time.  |
|
|
|
LMAO. sorry was getting spam happy with it. Sadly, 2 of the larger ones, Slush and Davinci are both away atm I believe. :/ I know Slush has already upgraded at least. |
|
|
|
stats/payouts Also, please recall that I only do the pool core (ie, payouts) and APIs. Updating stats will need someone to step up to take over maintaining (or at least provide a patch for) it. Any volunteers? If someone does a major update and takes over maintenance, they're free to replace the donation address for the stats (currently, it's the address for the original author). One thing that I worry about as well is that now you have gone public with you plans to be away for 10 days you are almost certain to be the target of an attack (this exact same thing happened to slush if you remember around spring time) Well, considering the ramifications (potentially delayed NMC payouts), I really had no choice but to announce it. I won't be totally offline, though, so if there's an emergency I can probably get on to get things going again. I would suggest (as usual) having failover setup just in case. I know the last thing you (or your family) wants to do is be worrying about your pool while on vacation but If you have the means to monitor remotely and also have means to reboot remotely from smart phone etc that would be helpful... That being said, I don't have any way to automate monitoring it. The only way I will know there is a problem is if miners call or IM me. I can be reached at sip.voip.dashjr.org (SIP) or luke at dashjr / org (Jingle/XMPP/Google Talk) so long as I'm within a T-Mobile service area. |
|
|
|
|
So anyhow, we may have a problem, depending on everyone mining for namecoins... I've got a 10-day vacation coming up, starting this Wednesday. Realistically, it's not looking like I'm going to be prepared to finish, test, and deploy the rewrite by then. This means the pool will need to continue as-is for 10 days straight with minimal intervention from me, including no namecoin payouts. I still plan to do at least another manual payout of namecoin before I leave. If this is a big problem to namecoin-interested miners, come help me brainstorm for an interim solution on IRC?
The last difficulty's "round" is delayed payout due to not earning enough for full PPS (even combined with the last round's leftover funds). I expect that there will be plenty once non-namecoin miners are removed from the equation, which should happen a week after we started merged mining (so the day I leave). That is when I will plan to payout those funds, plus the mid-difficulty "round" after it.
|
|
|
|
Isnt the usually confirmation of a transaction 7? When i sent/received BTC, its unconfirmed until 6 confirmations. Hope you dont mind me asking.. The number of confirmations to make a transaction "confirmed" are an arbitrary point where you decide to trust it as permanent. The current network protocol has an arbitrary "new coins can't be sent until 100 confirmations" bug-by-design for safety. Everything else is entirely client-side and you can modify if you want. |
|
|
|
First time using this type of pool, so excuse my question
My BTC client says ".. generated 1.166xxx BTC.. matures in XXX blocks ". What does it mean? My balance is still 0.00
When i clicked on the transaction log of the address, there is one transaction to my address with the above amount.
It means what it says... it matures in XXX blocks (starts at 120). Once that countdown is done your balance will go up. The whole network produces 144 blocks per day on average, so it's about a 20 hour wait. Oh i thought the 120 confirmation count down was on the status page. There are several blocks found for the past 24hrs and the countdown is " 36 left, 42 left...., 103 left" So what are those countdown then? The same as being shown in clients paid in those blocks, for convenience. |
|
|
|
My BTC client says ".. generated 1.166xxx BTC.. matures in XXX blocks ". What does it mean? My balance is still 0.00 This is an issue with how your client displays it. 1.166xxx BTC was sent, but your client is neglecting to display it until it's confirmed XXX more blocks. |
|
|
|
kano: fork the client, remove stuff you don't like, problem solved  I don't agree with his concerns here— merged mining is, in fact, the _cure_ to the problem he's worried about. But your response is unreasonable and unfair. Forking the client doesn't solve the problems with _other_ people throwing garbage in the blockchain which you are forced to store forever in order to participate in bitcoin. Neither does preventing mainline from doing things already allowed. |
|
|
|
|
Show Posts
