Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck.
Since merge-mine-proxy 0.2.2 there's chance to use this proxy only for share submits and ocassional aux update by pool software, which cannot be bottleneck at all. However yet another custom implementation is giving some chance that those versions become incompatible  . In fact, people have already begun reporting issues with it.
Because they're using naive way of putting merge-mine-proxy between pool and bitcoind. It's not necessary at all. Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual).
Which can be done also with vinced's proxy version without a problem, as I did. Pleae don't spread the FUD  . |
|
|
|
How is merged mining coming along?
Pool is doing merged mining already, we have around 160 NMC blocks at this time. Unfortunately there were many technical issues to solve, so I didn't finish anything else than mining itself. I'm now working on GUI for entering namecoin wallets and then will need to finish rewarding system. Everything will be very simple at first moment, but it will be soon . Official announcement will probably come later today. |
|
|
|
Last 4 blocks found are all still processing reward...
Anything we should be worried about?
No, I just forgot (again) to setup maintenance in crontab after some changes. Blocks are already processed, sorry. |
|
|
|
Slightly OT: how do mining pools prevent miners from taking successes out of the pool and keeping them for themselves? Do they track the nonces used in recently minted bitcoins?
This is responded thousand times on this forum already, but let's say that for 1001 . a) Miner don't have complete block sources, only block header for finding corresponding hash. He don't know what to push to bitcoin network. b) There's special (coinbase) transaction inside block source for 50 BTC adressed to pool's wallet. If somebody somehow got block sources for that block he found and he'll submit this block to bitcoin network directly, 50BTC reward still come to pool. |
|
|
|
Im not going to Merge Mine someother "coin", Screw that, I want bitcoins.
I dont want to be in a 4.5th/sec pool thats seceretly using 2th/sec to mine Namecoins or someother Shit that i Do Not Want, But that im now mining for
You probably don't understand how merged mining works. If is pool doing merged mining, he don't "steal" your hashpower for mining some other weird coins. You'll still have the same BTC income as you did before MM. That's the beauty of merged mining. |
|
|
|
However if a pool op wanted to hide it all they'd have to do is when they won a bitcoin block don't send the solution to the aux chain. Then there's no link... They lose 1 block on the aux chain but they get all the aux chain blocks that meet aux difficulty but not bitcoin difficulty, which is most of the.
Nonsense. Everytime pool is doing MM on BTC network, his coinbase is different (much longer) than usual. So you can detect if pool is doin MM, lets watch "raw data" of his blocks. There's no way ho to hide this information. Example of coinbase while merge mining: http://blockexplorer.com/rawblock/00000000000008371089fddbdee1f7cf580d98e64c276c649102d2ab95fd9844 |
|
|
|
I know of some pools who are trying to implement merged mining. However ATM there are some perfomance issues that even MasterPool suffers from at about 50GHash/s for which I have workarounds in place but it needs to be fixed permanently. Not to mention that MasterPool architecture was designed to deal with this splitted blockchains stuff from the beginning. Everybody is working right now lowering the foot print of merged mining. You have to understand that big pools optimized their complete architecture for mining one blockchain. Now they have an additional blockchain, merged mine proxy and additional calculations in their backend. It feels like hitting a concrete wall with a jet  The problem is you CAN'T simulate large load easily on testnet. Thus I guess some pools are turning it on occasionally in order to make sure merged mining optimizations are working properly turning it off if they gathered enough data to do the next optimization iteration. So please don't panic and wait a few days. Nodemaster pointed that out very precisely. I want to dispel fears of any of you who's thinking that some big player is "stealing" coins for himself. Yes, I'm testing merged mining on my pool with some backends. And no, I'm not going to "steal" those blocks for myself. But implementing MM on pretty big pool is really pain and I didn't want to announce it before I'll be sure it will work *somehow*. But after spending ages on weird bitcoind crashes using MM together with my custom performance patches, I'm starting to be pretty optimistic. I need to finish GUI for NMC support, then I'll also start giving away all those mined blocks (already over 100 NMC block mined during my tests) back to pool users to spread Namecoins between people. Btw first merged mined block ever was #148744 (BTC) == #19274 (NMC) |
|
|
|
Is there any way to prevent the historical data from being displayed initially in SierraChart feed? It's running right now (through WINE in Linux) scrolling through all the historical data and trading time stamps only advance like 5 hours each second because there's so much historical trading data. I started the program 5 minutes ago and it's at 2011-07-01 right now, still scrolling.
You mean - don't download historical data from bitcoincharts.com and using only mtgox live ticker? Yes, it's parameter -y. Watch ./sierrachartfeed --help for all options... |
|
|
|
Did you initially mean the very short term one in the 4.20s?
No, I'm watching 60min graph. I think mtgox is too tiny to find patterns on faster timeframe. 1. Bear trendline since 07/10/2011 2. First leg of DB 3. Second leg of DB 4. Trend reversal is crossing trendline. It's also big green bar after Doji, indicates some bull thinking of the market. Time to buy at 4.0xx 5. Price is going thru EMA, time to be careful and expect correction. Green bars are also smaller and smaller as buyers are out of money. If you're short time speculator, time to go out. @5:32 "But I don't want to buy it just now, because price is crossing bear trendline, so correction is likely"
I'm hobbyist trader and I trade only tiny amounts on mtgox, but I like when I see that I was true :-).  |
|
|
|
|
Looks like this. But I don't want to buy it just now, because price is crossing bear trendline, so correction is likely. (I bought around 4.02 when DB formed and it came up above yesterday's high).
Edit: Oh, I see DB elsewhere. One leg is 07/10/2011 @ 3.78, second 7/10/2011 @ 3.82.
|
|
|
|
I trust in the technology to monetize the web in a decentralized way. There's a lot of services not possible with any other payment system. The currently existing uses of Bitcoin barely scratch the surface of its full potential.
+1 Btw only one thing is scaring me a little - that somebody find a major security bug. That can make Bitcoin worthless almost instantly. Otherwise there will be still many places where will be Bitcoins better than any other payment system. |
|
|
|
|
I think credit card backed by bitcoins is smarter idea than ATMs at this moment. Then you can pay directly anywhere in local currency and you'll be charged with custom market price for BTC. Unfortunately talking with credit card companies is pretty hard, too (although it's more doable than ATMs).
|
|
|
|
Yeah, I guess I'll come up with something like slush implemented on his pool. It's really neat. Only allow connections from known users. But I'll do it later Unfortunately it works only for small-midsize attack. Largest DDoS which I had come with 2+ milion connections per second, which overloeded routers in server room, so there was nothing to filter on pool servers . |
|
|
|
Slush, after the recent changes I'm getting higher-than-normal number of rejects (around 3.25%)
There was next big update of pool today, but some errors appeared, so I had to revert those changes. Unfortunately it mean there was outage around 15.00 UTC today. That might explain that higher rate. Now it should be back in normal. and occasionally LP errors, with a peculiar pattern:
It looks like something is cutting longpolling connection between your computer and pool. For example my phone operator is closing tcp connections every ~10 minutes, but I don't expect that you're mining thru mobile phone . Pool isn't closing LP connection in any fixed period like this, so - no, I don't think it's on my side. |
|
|
|
jaybones: I found that problem, I'm working on fix. It's actually race condition in bitcoind, so it was harder to find it out, but pool will be fixed soon . |
|
|
|
|
I'm really looking for paying beer in bitcoins! Good job :-)
|
|
|
|
|
jedi95: Thanks for the response. I found that I was still using SVN repository (unfortunately other pool users are using it too), which may explain my problems. Can you please write it in big bold letters somewhere (top post in this thread) that they should migrate to actual repository?
I understand that X-Roll-NTime has lower priority for you. However can you add at least simple timeout on job validity? Ideally 60-120 seconds. There are many reasons why miners should not use older jobs; some slow miners are using one job for 5 minutes or even more! And one request per minute or two cannot be considered as 'ineffectivity' or 'network overhead'. Thanks a lot!
|
|
|
|
|
great, I'll implement it tomorrow
|
|
|
|
|
Show Posts
