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

Is it possible to calculate future earnings from the shifts completed ?

I fail to see any info on this.. ?

One correction Falcon.

The two blocks chains are completely independent.  Remember a hash satisfies a specific target but to avoid someone saying "hey I found a hash 00000000000000000000000000001" it has to be a hash of the bitcoin header.  Well what we are mining (I hate that word) hashing is bitcoin block headers then how does that create a solution for namecoin.

The answer is inside the bitcoin header in the coinbase field (normally just contains random data for the "extra-nonce") is recorded the merkle-tree of namecoin transactions, last block hash, and size of last namecoin block are put into bitcoin coinbase.  All together 33 bytes of data.

This is essence links that header to a snapshot of the namecoin network.  With merged mining namecoin requires the bitcoin blockchain but bitcoin doesn't require namecoin.   That "extra namecoin data" is seen just as random bits by bitcoin protocol.

Not sure why you think this is/could be a disaster.  My prediction is that the value of namecoin will drop 99.9% of current value.  Simply supply and demand.   You can't get something from nothing.  Alternatively the combined price of bitcoin + namecoin will drop relative to price of bitcoin prior to merged mining thus miners will still get the same amount total reward.  So those thinking it is this massive gold rush are right but it will be short lived.  The good news is the namecoin network gains all the strength of bitcoin hashing network and becomes stronger/safer.  Sometimes miner profits aren't everything.

Whoa, reading the last few replies, I already get the general concept of what merged mining is... and I'd never heard of it before reply # 285 where it all made sense:
hashing -> found result goes to (user-run) bitcoin pool server -> credit in your bitcoin mining account
Merged...
hashing -> found result -> bitcoin pool -> credit in your bitcoin account
                  ^---> other secondary network pool -> credit in your other pool account
Since the two networks don't communicate or have any relation to one other (aside from protocol), the hashes from one network can be used in the other as well!

... And the results could be economically disasterous. O_O

If hash rate of the Other network (namecoin, in this case, which I don't care much for) increases as more people do this "merged mining" thing with hardware used for the high difficulty of Bitcoin, the difficulty of Other Coin's network will increase to adapt to the rate as well.

The other side of the matter is that people are essentially "double spending" their production - spending the same amount of resources hashing for one network, then "double spending" that redemption into other currencies, devaluing both of them in the process (if they spend it).

Will it work? Yes. Will it work really well? Yes. Easy to implement. Yes. Will people get more "money" out of it? Yes yes yes yes yes... is it something I'd do? Sure. Is it a "pure idea" with no "oh god, how long can we keep dumping nuclear waste into this small pond" behind it? Eh... nah. In other words, on the scale of "white and pure" to "dark and evil", it's somewhere light-grey.

I wasnt (joking) actually. Though I was thinking of a popup and some "jingle" when finally a block was found, like once a week (that was before fefox starting finding blocks per hour lol), so Ill try the beta later and find out what sort of sounds you implemented, Im curious

BTW, minor bug report: if you enable the minimize to tray, using ubuntu (vanilla gnome, not unity), it does minimize to the try, but I cant restore it. It keeps running fine, i just cant get it to the foreground anymore.

  thanks for the new version ! 

Sounds like merged mining is a popular choice.

I'll have a look at merged mining now and wait with signature banners and finishing the next miner version for later.

I'm releasing a beta version with how far I got with new miner features for the next version. Details are in the miner thread. It has some nice improvements to cut down on rejected work, and some weird stuff like sound effects. The sounds become quite annoying after a while so they are off by default.  Sound will be more useful when I finish the config stuff so you can turn on only the sounds you want, like the sound when creating a block.

P4man, not sure if you were kidding about wanting sound when you create a block, but here it is!

By the way, nice with two new blocks today. Thanks to indolering and Fefox.

Thank you, and the others for the explanations. It certainly makes more sense now..

In theory we should be knocking down a few namecoin blocks for every bitcoin block, with current difficulty of course..

Sounds like a good plan to me in that case

NO.  Yes.  Technically it is only one block.

Yes however namecoin difficulty is independent current it is lower than bitcoin thus any valid bitcoin block is also a valid namecoin block but that could change in the future.

A particular hash could be:
a) valid for neither,
a) valid for only bitcoin,
b) valid for both bitcoin and namecoin.

A and b remain exactly the same.  We keep mining and through all those invalid hashes (a) and when we find one that meets target difficulty (b) we sign the block and get 50 BTC reward.  Merged mining adds the possibility of (c) where a hash meets the target difficulty for both bitcoin and namecoin.

If that is the case we collect both 50BTC reward from bitcoin network and 50 NMC reward from namecoin network.


Currently any valid bitcoin hash would also meet target difficulty for namecoin however if namecoin difficulty rises faster it is possible at some point in the future some of the blocks end up in category b and only some in category c.  

Don't feel bad about misunderstanding it.  For such an important breakthrough it has been horribly documented and communicated.

It doesnt take anything away from the bitcoin efficiency.  the answer your miner submits to the BTC network is also submitted to the NMC network to see if it works there. a 2 for 1 deal.

Perhaps I misunderstand the merged mining concept..

If we begin participating in a merged system, does it take away from the bitcoin mining efficiency? Or is it the same hashing function, results which could be applied to either network?

IE - if we find a result which meets the bitcoin network difficulty, would that result also apply to the namecoin network? block created on both networks from the same hash?

Merged mining ftw ! Why not send results when the work is already done ?

Why would you want to do that?  I would say if you don't want the NMC simply donate them to the pool.

You understand that w/ merged mining the blockheader will already contains namecoin information.  If you find a nonce which meets namecoin's difficulty you would want the server to throw it away rather than publishing it.

Turning off merged mining won't make bitcoin mining faster it would simply mean throwing away rewards you have already earned (by not reporting namecoin hash to namecoin network).  If you don't want them why not give them to the pool operator to help improve the pool?

It would probably help draw more miners in, but please make it user selectable. I'd prefer to mine only BTC.

You guys want it?

I'm looking up info about it now.. what little is available.

Any plans to add merged mining?

ya, no? I was just wondering because i just send them to the exchange and i think the deposit address is temp( i dont know how long its valid) just didnt want to send my coins nowhere, if that is even possible.

Just wow... the fact that you can change the flow of the ocean just by having a power outage... gahaha. Wow.

I guess this is a good middle-ground solution. And it's what you get currently if you set payout threshold to 0.1 BTC. I have now set that as default for new users.


Thanks, I appreciate it

DrHaribo,

"An option would be to completely remove the minimum payout threshold and just pay out every user's complete balance every time a block is confirmed and money comes in."

I like this option.  Makes it simple.  If the pool gets very large you may need to change it but currently I would assume (you can check records) most miners get > 0.1 per block reducing the number of tiny transactions.


A hybrid could work.  All miners are paid INSTANTLY (once block is confirmed) as long as the balance is >= 0.1 BTC.  Miners that earned less than 0.1 on the block will have reward rolled over till next block.


BTW.  Keep up the good work.  As a show of confidence I moved another rig (+ 2GH/s) to bitminter.

Yep, we already do that. That's why it is better to run payments every hour (and now on every confirmed block). If you run payments when a user clicks a button, then you can't batch transactions together and you run the risk of paying lots and lots of transaction fees. This is why a pool needs to be a little smart about an "instant payout" button.

An option would be to completely remove the minimum payout threshold and just pay out every user's complete balance every time a block is confirmed and money comes in.

Upside:

• You get your money in your wallet sooner
• The servers become a less profitable target for hackers. I can sleep well at night and not be responsible for (as much of) your money.

Downside:

• The transaction history in your wallet (the bitcoin program or other wallet) becomes full of tiny transactions
• Negative for the bitcoin system in general: when you next send money from your wallet, the transaction will consist of many sources, each of a tiny amount of bitcoins. This means bitcoin has to handle more large (in number of bytes) transactions. We will contribute to that 600+ megabyte blk0001.dat file growing on everyone's harddisk.

Any thoughts?