Exactly. At least on my distro & local node.

Hello FallingKnife & Bryce Weiner,

There seems to be an issue with the Unobtanium daemon & p2pool merge mining. While using the daemon on Xubuntu 14.04 64bit I am not receiving any merge mine payments at all, but if I switch to using the QT wallet - payments resume as normal. I've tested this over a 4 day period, it is constant. I get no errors when compiling the daemon or QT wallet as well as no errors in my p2pool logs - everything appears to be working fine, but the payments are not appearing in my wallet when using the daemon. Both the QT wallet & daemon use the same startup command & wallet database. I've posted in the p2pool thread about the issue:

https://bitcointalk.org/index.php?topic=18313.msg11556398#msg11556398

I'm not sure if the issue is the same on other OS's.

Thanks.

EDIT: Issue raised on github.

Hi all, just a heads up.

I'm using Xubuntu 14.04 64bit & have found that when using the Unobtanium daemon for merge mining I'm not receiving any payments, but if I use the QT wallet - payments are received in the normal way. I've recompiled the daemon a few times with no errors & I get no errors in my p2pool logs either - the payments just don't appear in my wallet, yet as soon as I use the QT wallet, payments resume as normal.

I will report the issue on the Unobtanium thread, but I recommend that anyone using the Unobtanium daemon on NIX to check that they are receiving their merge mined payments & if not, to switch to the QT wallet instead. Unfortunately it seems that previous lost payments are just that - lost.

I'm not sure if this issue is the same for other OS's, but I'd check anyway, just to be sure.

Update: Well, I just received my first payment using the QT wallet, so now I know for sure there's no problem with my settings. I'm gonna switch back to using the daemon to see if the payments stop again.....

Yep, double checked all passwords & ports - although there's no need to forward the rpc ports as they are only used locally on 127.0.0.1 for merge mining. None of my rpc ports are forwarded on any other wallets & they work fine - it's only the UNO wallet that seems to be having issues. I'm compiling the QT wallet now.....

EDIT: QT compiled & running, I'll keep an eye on it for payments. In the meantime, if anyone else using the daemon hasn't received any payments - please post here, thanks.

Hmmm....everything seems in order:





Port 65534 is forwarded on my router, allowed on the ufw firewall, upnp is also activated on the router & daemon & is showing on my router logs. I've got no errors in my p2pool logs either - looks like there's a problem with the UNO daemon. I'll SSH into my rig, build the QT wallet & run with that for a while - that should give me a clue as to if the daemon is working properly or not. I'm hashing @ ~10TH

Has anyone else who is using the UNO daemon received any payments? If not, I'll contact FallingKnife & let him know there might be a bug.

EDIT: I've been running the daemon for about a week now, so should have received a few payments according to your wallet. I never installed QT as it's not needed for the daemons, so I'll have to do that first......

Are those payments from merge mining? I've been using the daemon for a few days now but didn't receive any payments as of yet.....

I'm looking for a good decompiler for software that doesn't provide source code.

Hi FK,

Thank you for making UNO available to p2pool merge miners    It's a good coin with a great community - always nice to see a dev who contributes to the community.....

I'm currently working on an updated p2pool set-up guide for noobs, as previous ones are now a little outdated - git repo's especially, and will include UNO & all other available merge mined coins in an effort to attract more miners to p2pool, as well as increase UNO hash rate 

That's not to say that there aren't any trustworthy pools out there, there are, but IMHO there's not so many truly trustworthy pools to choose from out of the many available - with more springing up every week it seems. I spent weeks combing through this & other forums looking at different pools trying to decide what pool I felt comfortable using, & came to the same conclusion as you - p2pool seemed to be not only the safest, but also the decentralized nature of it appealed to me.

Although stealing hashrate is a grey area, I did find a case where a certain pool admin used their miners hash power to kill a coin by way of a 51% attack simply because he didn't like it. This was done without any consultation with the pools miners & without their knowing - which of course meant that that pool was immediately crossed of my list, you can read about it here:

https://bitcointalk.org/index.php?topic=56675.0

https://bitcoin.stackexchange.com/questions/3472/what-is-the-story-behind-the-attack-on-coiledcoin

Then of course there's the double spending attack done by another (very large at the time) pool:

https://bitcointalk.org/index.php?topic=327767.0

To me, the two examples above could be considered stealing, weather directly or indirectly. At the end of the day, if you're concerned about weather a pool will "steal" your hashing power it's safer & easier to use either p2pool or one of the very few reputable pools out there that provide not only open & transparent support, but do so in a timely manner. Doing plenty of pool research will pay dividends, I'm certainly glad I took the time to do so. One thing's for sure, biggest is by no means best.

Anyone......?

Thanks kano, I realised my mistake while at work earlier.....

Can you recommend a suitable (cross platform?) decompiler for regular applications/binaries?

P2pool miners using their own local node not affected 

Ah, I know why - I kept my settings........

OK - I'll bite the bullet & try it out on one of my S5's - will report back in a few hours with the results.

It flashed fine btw - good work  

Greetings to Russia  

Edit: First thing I've noticed - the queue setting is set at 1, not 0.........

Hi markm,

According to the git repo, it uses bdb 4.7 & I can't find a link for that on trusty. I tried using the --with-incompatible-bdb flag with v4.8, but it still failed with the same error.....all my other wallets compile with v4.8 no problem.

Any chance you could upload a copy of yours? sil vous plais? with cream on top? 

Hello all,

I'm looking for a good (free ) decompiler that is capable of decompiling Bitmain firmware - can anyone give me a suggestion?

Thanks.

Yes, p2pool can find blocks with stale shares, so submitting stale shares on p2pool is a good thing. I believe cgminer submits stale shares as standard, it was bitmain who changed this with their cgminer bork fork - which made it bad to use their firmware on p2pool. That was one of the reasons why kano kindly made the revised code available.

That's good - just need to change the --no-submit-stale setting then  

Aaaaand another BLOCK! 

I'd much rather see the code - if possible. By not submitting stale shares, this firmware shouldn't be used with p2pool - you're losing potential blocks. This was fixed with kano's binary here:

http://ck.kolivas.org/apps/cgminer/antminer/s5/

Unfortunately, it is not persistent through reboots