Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 347. (Read 837101 times)

Yes, please all cgminer users grab the new version. And BitMinter users use the regular and not the beta version until the next beta is out. Then we can get NMC stales well under 1% I think. It's currently just over 5%.

Last night we had another NMC stale that would have created namecoins had it not been stale. I hate seeing that - maybe I should stop logging those.

I know NMC isn't worth much, but we should always strive for max performance.

cgminer 2.0.8 is out.  It handles merged mining LP better.  It *should* improve stale rate on NMC blocks.

Hold on to that feeling. 

But seriously, no, there's no donation possible yet.

What I'm planning right now:

• More numbers on website - especially regarding namecoins
• Updates for the client/miner: fix performance degradation in the beta, fix stale handling in the beta to better work with merged mining, add some automation options
• After that: donations and some other stuff. Not 100% sure what I will do first yet.

I should have new web updates done this weekend and hopefully get some work done on the miner.

Is there a donation option somewhere now that Ive missed? Since it seems you are not charging any fees, Im beginning to feel guilty.

Yes, I think so too. I could add separate shifts for NMC, but it might add more hassle and confusion than it is worth.

Really bad luck on block #81, but I'm glad we finally finished it. Even with the block creation that failed due to a stale, it would have been one block at 350k and one at 900k proofs. I looked around at other pools to see if they had any namecoin blocks that big. But, strangely, several pools don't seem to show any info on the namecoin blocks.

Most merged mining pools go with
good bitcoin = valid
bad bitcoin = stale

Technically the "perfect" way to do it would be to keep seperate stats for both NMC block and BTC block and record stales individually but AFAIC nobody does that yet. 

Example: each share could be
valid BTC & valid NMC
stale BTC & valid NMC
valid BTC & stale NMC
stale BTC & stale NMC

records blocks, shifts, and valid shares seperately for each coin type and issue rewards separately.  Granted it is a huge amount of work but that would be the most accurate and fair method of handling rewards.

Given NMC is at best a 7% bonus (and going to 5% after next difficulty) I think counting stales vs good based on BTC is "good enough".

I just realized there's an inconsistency in how stales are being registered now.

• You only get your proof of work counted in the shifts if it is valid (non-stale) on the bitcoin side. Otherwise it is counted as rejected in the shift (not shown on website yet).
• Your miner is told that the proof is accepted if it is valid on bitcoin OR namecoin.
• Work done on blocks register accepted/rejected individually - no problem here. Not shown on website yet though.

I think it makes sense to change it so the miner is told the proof was accepted if it was included in the shift as accepted, otherwise the miner is told it is rejected?

Question is, should it be accepted if it is valid on either bitcoin or namecoin, or only when valid on the bitcoin side? I'm leaning towards shift+miner acceptance only when proofs are valid for bitcoin. The reason for this is 1. I think bitcoin is more important and 2. I don't want the pool to "pretend" everything is fine while you are actually producing massive stales (most proofs would still be valid for bitcoin OR namecoin).

Yes, the beta client is trying to be smart about stales, but instead creating extra stales on the namecoin side. I had not yet thought about merged mining when I made those changes.

So it's better to mine with the non-beta client for now ?

Still only fixed in git, afaics.

Congrats!


They were completely separate networks until merged mining was invented. Merged mining is what makes it possible to create a namecoin block with a proof of work for a bitcoin block. So ever since merged mining, if a pool implements it, things work like DeathAndTaxes just explained. Very good explanations, by the way, DAT.

Before anyone asks, no, we can't add other coins. The auxiliary chain that you "merge" into your bitcoin mining has to support merged mining, and at the moment this is only supported by namecoins.

By the way, this morning we had a proof of work that could have created a namecoin block, but it was stale on the namecoin side. It's not good having 5% of proofs be stale on the NMC side. I'll get out an update for the BitMinter beta client soon (regular non-beta should be fine already). Does anyone know if a new cgminer has been released that works better with merged mining?

Ah, very good. Thanks

Almost all pools use difficulty 1, which means on average 1 valid hash in 2^32 nonces.  This is a somewhat arbitrary decision.  There is no reason a pool couldn't use x difficulty (as long as x is less than actual difficulty).  The higher the difficulty the more variance in share generation.  The lower the difficulty the more shares the pool needs to verify.

One example of higher difficulty is p2pool.  Since shares have to be distributed p2p and verified by every peer obviously one wants a much higher difficulty.  I believe p2pool uses a difficulty of 1024.  Thus 1 p2pool share = 1024 Bitminter/slush/ars/etc shares.

Whoa.. I realize I know nothing of the mechanics now..

I just thought they were separate networks of sorts.. Im surprised to find it works like this..

for curiosities sake, and since I didn't know the 'shares' we do submit qualify for a difficulty, what is that difficulty for an acceptable share?

Is that something that is set by the network, or by you DrHaribo?

Hmm not sure how to make it simpler.  There is no such thing as "finding a block".  Block are already known.  What we are looking for is a hash which is SMALLER than the TARGET required by the current DIFFICULTY.

Thus if a hash (any hash) is smaller than both Bitcoin and Namecoin targets it "solves" both blocks.  Since Bitcoin target is higher than namecoin target any hash which is small enough for Bitcoin will be by default also small enough for Namecoin.

I also dont understand why people are finding both, I read this a few times.. and it makes little sense to me..

Its very odd to me..

in a short concise sentence, why should who ever finds a Bitcoin block also find a namecoin.. ?

wOOt. Found my second ever BTC block

  ahh thanks for that explanation !

We should find a NMC block EVERYTIME we find a BTC block.

Remember there is only one block header.  The prior NMC block hash is put into coinbase transaction of the BTC block.


So
1) You get a block header to hash from the server.
2) You hash it and check if it matches difficulty for a share.
3) If it does you submit it to the server.
4a) Server checks if it matches difficulty target for BTC
4b) Server checks if it matches difficulty target for NMC

So each share can be:
a) worthless (just used to track work by miners to ensure fair payout)
b) solution for BTC block
c) solution for NMC block
d) solution for both BTC & NMC blocks.

Now right now (and likely in the future) BTC difficulty is HIGHER than NMC.  Thus any share which meets BTC difficulty target meets NMC target.  Using smaller numbers may make it easier to understand.

Say to solve a block you pick a random number between 1 & 100 for each share.
The current target for a valid BTC share is < 10.
The current target for a valid NMC share is < 40.

So:
a share w/ value of 41 is worthless. (type a above)
a share w/ value of 14 is valid for NMC but invalid for BTC (type c above)
a share w/ value of 9 is valid for both NMC & BTC (type d above)

Now you may be wondering how you get a type B.  It would only occur as a timing issue.    While any BTC hash meets the target for a NMC hash if the NMC block has changed the miner is working on a block that can never be a valid NMC hash (no matter how low of  hash is found).  A "perfect pool" (which isn't possible with current miners) would have a way to tell miner the to update the block but still submit work because it might be good for BTC.   Luckily this should be relatively rare.