P.S. I still haven't read the namecoin code yet  please do that before posting about merged mining again. the bitcoin block gets 33bytes namecoin data in his coinbase (without a bitcoin block size change). there are several people who did run this on testnet (and you can do this right now). |
|
|
|
what i dont understand: why is cgminer not able to do that? other miners are.
This is a mistake it's not CGMINER it MY POOL's fault NOT CGMINER! yes i know... i just wanted the "1997 linux user" to explain why he thinks it couldn't work. sorry |
|
|
|
Lets say you mine 500Mh/s to Bitcoin
Please tell me how it is possible to add hashes to Namecoin, without reducing the hashs send to Bitcoin?
i.e.
thats is what merged mining is. it does not split your hashrate. you'll mine with you total hashrate on both chains simultaneously. what i dont understand: why is cgminer not able to do that? other miners are. ok..pool need patched bitcoind (to put 33 bytes namecoin data in the coinbase without a block size change), a proxy and default namecoind... but your end should stay the same (except that you get the same btc value as now AND additional to that namecoins [at least after nmc-block 19200]) EDIT: highlighted important part |
|
|
|
30 minutes to go 40 Gh and my 4 mirco servers on Amazon are yawning saying is that all you got!? BRING THE PAIN! LOL  joined a minute ago  btw, as i use cgminer i had put in your ip address instead of the domain name. are you ok with that solution? (ps: would be nice if you would offer to mine through port 80 too) |
|
|
|
Do I need to recompile bitcoind? Looks like probably yes.
Yes Do I need to compile namecoind? Is it a standard namecoind? Yes and yes? I dunno
its standard namecoind The proxy script, what needs to be done with it, other than to make it executable and run it in place of bitcoind and namecoind?
Can the proxy script even handle a high load or is it going to fail miserably when you dump 100 or 200 GHs at it?
have a look at PoolServJ which replaces pushpool, lp and proxy btw. thats the reason i've started this thread. i want all pool owners to know how merged mining works - so its up to them to get it to work. and i hope some miners do read this and will prefer merged mining pools (like i do) |
|
|
|
Would someone mind defining the term "merged mining"?
Sam
merged mining means that while you are mining bitcoins you ALSO mine namecoins (or other chains in the future) with the same hashrate. means: if you have 1GH you can mine namecoins with 1GH AND bitcoin with 1GH at the same time. if you dont mine solo you dont need a modified bitcoin for this: only pools need a modified bitcoind which writes 33bytes of namecoin data in the coinbase of bitcoin blocks (the blocks size does NOT differ). you do need a new namecoin which accepts "dual-mined"-blocks (the official namecoin daemon will accept merged-mining-blocks after namecoin block 19200) ^^ please correct me if i am wrong. |
|
|
|
I've been looking into merged mining, but right now I don't see it integrating itself into the main BTC Guild pool anytime soon. It will be a bookkeeping nightmare unless I hide the NMC part and do it as a side calculation whenever a round ends. It's difficulty to implement in a production environment, especially one where the database is not easy to make modifications to without slowing/halting the live servers.
I may put it onto the PPS pool for BTC Guild, since the code and DB schema is much more flexible on the PPS pool [no need to keep track of 'rounds'].
as far as i know PoolServJ is working on merged mining (thanks davinci!!!). bt- guild-pps seems to use it.. wouldn't that be a good test bed? |
|
|
|
Hi, I want to ask course of action as the other thread doesn't get the necessary attention. http://50.19.139.134/test.phpleaked thousands of mails with worker passwords but many are legit passwords of the mail accounts too for sure. Is there any place to go to get all these mail accounts locked down? please... DO NOT LOCK DOWN MY EMAIL ACCOUNT!!!!!!!!!! i can handle spam.... |
|
|
|
is it feasible to include the mining proxy (for merged mining) directly in PoolServJ?
if namecoin daemon dies bitcoin deamon could still deliever getworks (or vice versa)
I am working on that right now... You can thank Davinci for tempting me with a fat bounty or I probably wouldn't have. I'm waiting on some detail from one of the namecoin devs before I can start implementing... +1 to davince and you ,) |
|
|
|
|
is it feasible to include the mining proxy (for merged mining) directly in PoolServJ?
if namecoin daemon dies bitcoin deamon could still deliever getworks (or vice versa)
|
|
|
|
|
hi nodemaster,
i really like your pool. it's one of the fastest right now (0.02% stales constant is very good!).
but please consider another payout system (or make a vote).
i do prefer *PPS - but only reason is that i dont like the idea of some shares getting worthless.
|
|
|
|
I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.
To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):
CWallet::SendMoney() {
grab_the_wallet_lock();
solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
fee = compute_the_required_transaction_fee();
yesno = ::ThreadSafeAskFee(fee);
commit_transaction_and_release_lock(yesno);
}
Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.
If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.
I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.
maybe: client sets a default fee for every transaction and server just checks if currentfee<defaultfee and sends it? if its bigger it could return and the client could retry with another defaultfee. |
|
|
|
The guy owed me $995 after a forced liquidation. He has no incentive to pay me back.
Why can't I just block the account?
+1 btw if he would not have blocked the account he couldn't do anything anyway (as he had a negative balance anyway). |
|
|
|
i did the same with my best a week ago and we decided to use the average price per bitcoin of the last 30 days...
I hope you were selling! I'd say a fair price a week ago was around $6, but the average for the previous month was more like $9! I'd be worried about losing friends using that method. as we are good friends i do not really care... just wanted to find a fair price. It's an interesting approach to price things in bitcoins - the statement there today is 'Todays locked in Bitcoin value is $6.09' - indicates that it might be calculated once a day. That might leave him open to abuse in the event of a sudden drop in value of BTC.
you're right.,.. he changed it a few weeks ago (after the 9/11 drop) |
|
|
|
Let's imagine I agree to sell 100 Bitcoin to a friend for USD. We're friends, so we don't want to haggle or negotiate over half a percent, we just want to look up the 'market rate' at a current instant and fix the price to do the exchange. So we look up MtGox and notice that is plenty of data of what's going on in the market - what's a good way to use it to settle a 'fair' price?
We might use the last trade price . . but that might be right after a large buy or sell order.
We might use the difference between the current buy/sell price, but those might be very low volume.
We might use the current cost to buy 100 BTC on MtGox, but that favours the seller.
We might use the current amount to sell 100 BTC on MtGox, but that favours the buyer.
We might use the current cost to buy 10000BTC and the current amount to sell 10000BTC and average the two - but even that might be subject to manipulation and not represent a 'fair' rate.
In practice, all these figures will be within 1% of each other in typical trading, and my friend and I wouldn't lose any sleep over it. So I'm not interested so much in the practicality of it - more the theoretical idea of what figure represents a fair price, for a known amount, at a current instant, without trading on an exchange.
i did the same with my best a week ago and we decided to use the average price per bitcoin of the last 30 days... maybe the price of "cheaper in bitcoins" is a good indication too? he update his price on a monthly base - and you can actually buy stuff with bitcoins to the price he tells us ( https://cheaperinbitcoins.com/) |
|
|
|
|
i told a friend of bitcoinica and likes it very much... would you gave him the dollar too?
account: styx-it
|
|
|
|
|
hi combay,
really love your page; but i am a little bit confused.
if you keep it running and then do a page refresh: the graph and even the current price does change...
how is this possible? (current price could be, there is no big diff); but why is the graph is changing?
|
|
|
|
in 180 blocks i would go to masterpool. it is prop atm - but they will make a vote for a new payment system as soon as hoppers arive (and i will watch that VERY closely). its just the only pool which has merged mining then EDIT: for pure pps i like abcpool (0% fee, pays even for stales); but i am note sure if they are open for registration atm... |
|
|
|
|
Show Posts
