I totally agree with this.  Really don't like the app running automatically at startup, with no way to disable it.  Why is this necessary?  At the very least, allow users to control this feature with a checkbox, so that it can be enabled or disabled as desired.  It's a great app, and it syncs to the Bitcoin network very quickly upon demand, so it shouldn't be necessary to have it always running.

(Edit) It's worse now!  Unfortunately, there has been an insidious new thing added to this app.  It now automatically starts up in the background, on a timer!  Every few minutes, it pops up.  That's maddening, to say the least.  This happens no matter if your phone is on battery or on charger, so not only will it waste your network, it will waste your battery as well.  Beyond frustrated.  The developer, unfortunately, does not understand that this would be a problem to many people.  I have no choice but to empty my wallet and delete this app.

Nice!

Thanks for not hooking the "charger connected" event any more.

I also see you added a direct link in the app's settings menu to the Android "Data usage" panel.  Touché.

It still syncs at reboot, though.

Ultimately, checkboxes would be the best approach:

[ ] Sync when charger connected
[ ] Sync when rebooted
[ ] Sync automatically in background every [ ] minutes

I really don't like the idea of carrying around a device which makes unwanted connections behind my back every so often.  Does anybody else feel bothered by this?  Sometimes, I think I'm alone.  Am I the only one who doesn't want apps making all sorts of connections everywhere in the background?

Josh

These are bugs in your compiler and libcurl, fixed in newer versions of such, and harmless in any case.

Cool, thanks!
Josh

I just upgraded to bfgminer 3.1.4, rather impressed by the new display layout, I like the summary line and blue highlight at top!

The program runs perfectly, hash rate is good, but should I be concerned about these compilation warnings?


Josh

Wow, LIGHTNING FAST shipping!!

Always a class act to deal with.  The Erupters were put in the mail on Monday, and they showed up at my post office (California) on Wednesday, that's lightning fast!

They are now all happily installed, twinkling like little fireflies in the night!

The little Erupters are very elegantly packaged, they would make a great stocking stuffer.  QC sticker, cardboard box, thin plastic baggie, hard plastic case, foam inserts, then finally the miner itself, just waiting to be plugged in.  Even the size of the cardboard box seems carefully thought out, they divide evenly into the size of the most common USPS Priority Mail shipping box, making shipping really easy!  Nice!  Will definitely order again as funds permit.

Nice!

Is the "data" folder the only folder that should be copied from the old to the new, or are there more?  Does the p2pool program write to any files outside the "data" folder?  I should save a before-and-after copy so that I can compare and see what it changes.

Good news, it's settled down now, and starts to work.  It now sees the rest of the pool.  Thanks for letting me know that the timeouts/errors are normal when downloading the initial sharechain.

Josh

This might be the wrong place to ask, but I'm wondering if anybody else has done this.

I don't want my port 9332 open to the world (p2pool Web stats and RPC interface).

I have a Web server on my machine, so tried to redirect it, so that this would work:

URL typed into browser of https://mysite.example.com/whatever/p2pool/ --> proxy to http://127.0.0.1:9332/ on the inside

Although I wanted to keep port 9332 closed from the outside world, I still want to be able to peek at it remotely, and so have added https and HTTP basic authentication to it (old style username/password) on my Web server's configuration.

This works, but unfortunately it's fooled by the JavaScript and HTML in the page, having lots of links to places like "/static" and "/local_stats" and such.

I know my Apache proxy is working, because I get p2pool's redirections, such as when you go to port 9332 without a location and it redirects you to the "/static" webpage: https://mysite.example.com/static

This doesn't work on my setup, because I need to have p2pool be under a path, not at the toplevel.

So, I tried the "mod_proxy_html" Apache module.  This seems to be failing to parse the HTML generated by p2pool, and rewriting it correctly, because then, after doing that, I no longer get toplevel redirects, but I get p2pool to tell me "No such resource/No such child resource".  This text is an error from p2pool, not my Web server, so I know that at least the proxy is getting through to p2pool and making the internal connection to port 9332 correctly.  However, something's getting garbled in my attempt to rewrite the HTML, so it's not getting forwarded to the correct URL, I think.  Unfortunately my debugging trail goes cold there, I have no visibility into the internal workings of mod_proxy_html unfortunately.

Has anybody else confronted this problem?

I wonder if it would be possible to rewrite the links in p2pool's Web interface to be relative, not absolute, paths?  Would there be a technical problem with this, or would it be a good improvement to have?

Thanks!
Josh

Just upgraded p2pool from 13.1 to 13.2.

It's downloading the sharechain again now, and seemingly having a rough time of it: there's lots of Python exceptions all over the place, about connections lost.  My Internet connection is reasonably good, though, so unsure why it would be doing this (13.1 was fine).

What's the preferred way to upgrade from 13.1 to 13.2?  Is there a way to do it without losing the downloaded sharechain?  I just did a rough upgrade, unpacking a new directory and then running Python in there, as if I had never used p2pool before.

Also, what version is best to use?  The tarball release of 13.2 from github?  The master branch from github, cloned with "git clone"?
 
Thanks!
Josh

Krellan; 8; 4.4; 1u9AnCrajNbKNCmMc6jmVAM73VVjmkn6N

Nice, great price!

I remember nervously buying my first Erupter at over 2.2 BTC *each*... wow, times have changed!

I'm also on 4.2.2.  Got a Samsung Galaxy S4 Active (I would have preferred the stock Google ROM, no Samsung or AT&T bloat, but didn't know that at the time).


Does 127.0.0.1 count as "network is down"?  That address should always be reachable, even if device is completely isolated, since it's talking to itself then.


I'm trying it now.  Even if the app takes more battery life, at least I'll be able to recharge my phone at work again!


Thanks for the update.  I noticed that CPU usage did increase, but not enough to be a real concern.  I'll let it go for a while, though, and see how it makes a difference.

A little of both.

I haven't noticed it using a lot of bandwidth, which is good.  I rather like the per-app metering of bandwidth that Android provides.  Still haven't found a way to constrain "Restrict background data" to a single app, though.  When checking this checkbox, it then applies to every app that I have.

Other apps in the background I have running because I want them, they do useful things to me.  However, when I'm not running Bitcoin, I don't want that running.  Not at all.  Not even in the background behind my back.  Also, because it's a peer-to-peer protocol, Bitcoin will be making all sorts of connections to random IP addresses everywhere, and that could look suspicious.  Unlike my computer at home, I often bring my phone into corporate environments and whatnot, where they look suspiciously at activity, especially P2P.

I don't like being forced to deal with a carrot and stick approach, where in order to get a carrot (plug my phone into power in order to recharge it), I have to also take a stick (mandatory starting-up of the Bitcoin app and its background connections).  Really makes me feel like I'm being manipulated.

Again, I'm not the only one who feels this way, although you might think it strange.  Just take a look at the recent reviews on the Google App Store.

Damn.  That's unfortunate.

Thought I had found a good workaround.

That's a nasty bug, that it will just loop the app and try again in an infinite loop upon failure to connect, draining the battery.  I verified that in "OS Monitor": it wasn't using 100% CPU, but it was using more than any other process.  Really frustrating that it would have that behavior.  Was this intentional, perhaps as a punishment to discourage people from trying to prevent the app from making connections?

Can't set "Restrict background data" on a per-app basis, it's global.  Unless there's a mod/tweak somewhere that I don't have.  And, besides, if the data is restricted, wouldn't that just cause the app to be thrown in a loop also?

Getting really discouraged by this.  Seeing no choice but to send away my bitcoins and uninstall.  Sucks, because that's one of the reasons I bought an Android phone instead of an iPhone.

Thanks.  I want to restrict this app's usage, though, not set a global setting in Android which would apply to all apps.

I think I found a reasonable workaround:

Go into "Settings", enter Trusted Peer of "127.0.0.1", and check the checkbox "Skip Regular Peer Discovery".

This will keep it from making any unwanted connections whenever it wakes up.

You can use the "Skip Regular Peer Discovery" checkbox as a toggle.  Uncheck it when you want it to sync up (takes less than a minute).  Then, before closing the app, check that checkbox again, and it will obediently stop using the network again.

Josh

I don't want to disable mobile data entirely.

Would it be too hard to add a checkbox to disable sync from ever being automatically started?  I don't mind sync being done if the user explicitly opens the app, that's a good thing.

I don't like the idea of connections always being opened in the background (especially P2P connections which are banned on many corporate networks and could get me into trouble if I take my phone in there).

Thanks for listening.  I'm not the only one who is unhappy about the app's background connections, with no way to disable them, just look at the recent reviews on the Google Play store.

Josh

If you look in Google Play, you will see a lot of other people reporting the same problem.

https://play.google.com/store/apps/details?id=de.schildbach.wallet

Previous versions of this app used to have checkboxes, "Sync on Power" and "Sync on Wi-Fi".

The current version of this app no longer has these choices exposed to the user.  Instead, it adds a nice feature, that is, the ability to have these checkboxes be cumulative (requiring BOTH power AND wireless in order to sync).  However, there's no way to disable this.

Please, please, please, restore the ability of the user to disable the sync, so that the user can stop the app from syncing automatically.

You are very lucky in Germany, but here in the USA, unlimited data plans on cellphones seem to be disappearing.  I want to be able to charge my phone without fear that a peer-to-peer app is going to start up whenever it sees power, and start burning up my bandwidth outside my control.

Please, please, please.

Nobody likes apps that do things behind their back.

Thank you for listening!

If developer is unable/unwilling to restore this feature, then I would be curious to hear suggestions for a workaround.  The "Trusted Peer" feature might work, I could set a peer of 127.0.0.1 (thus preventing it from connecting it anywhere), and using the "Skip Regular Peer Discovery" checkbox to control whether or not I want it to search for additional peers or not.  Also, the "Autorun Manager" app looks promising, I could revoke the event listeners of Bitcoin Wallet and thus prevent it from seeing events that would cause it to begin syncing.

Josh

"fc19" is Fedora Core 19, that's really new, I'm unsure why they don't have a higher limit by default.  On a modern Linux system, with a lot going on, you should give yourself as many open file descriptors as you can.

I don't use Fedora, but the file should still be in the same place (I hope).  Edit the /etc/security/limits.conf file, put this at the bottom, don't forget the stars in the far left column:


Get rid of any other lines in the file that have "nofile" in them.  Unfortunately, it seems the maximum is 65536, the system simply won't let you set a higher limit (even though I wanted to).

Then, log out and log back in.  You should have a much higher limit now, verify with "ulimit -n" as you said.

Also, in your text you pasted, it says (in the big loud message) your Bitcoin daemon isn't running.  Something's seriously wrong on your system.  You should always have 3 programs running: bitcoind (or Bitcoin-Qt), p2pool, and bfgminer (or whatever miner you use).

Josh

Nice guide!

Just read it, glad to see it's been updated for the new fork (30 second share clock, instead of 10 second).

I don't think I have a problem with latency.  Had a big problem with total bandwidth consumption, though.  My cable ISP doesn't like large users of bandwidth.  So, I'm glad I keep a backup DSL line.  Ports 8333 and 9333 now go there.  Works great, my DSL is ideal for continuous P2P background traffic like this: it has a slow top speed, because it's DSL, but it has good response time, and it's unmetered.

Thanks for the tip about tuning the bitcoin.conf settings, so that bitcoind is more generous about the transactions it accepts.  It was worth a Bitcoin restart, so I did that.  Also gave me the chance to test my restart scripts.  I rather like how P2Pool does true mining (your node gets to dictate the contents of the block if you win).

Here's my stats (don't laugh):


Josh

As others have already pointed out, I went back through my scrollback and saw when the fork happened.  It was at about 15:33 (in my US/Pacific timezone, so that's 22:33 UTC) on 14 July.  Nice!

I also noticed a disruption in network traffic.  My node lost 3 connections, and then they were almost immediately replaced by new connections elsewhere.  I am guessing this is P2Pool rejecting the obsolete nodes (below the fork's version cutoff) and kicking them out of the pool?

To see something interesting, look at your P2Pool graphs (on your localhost).

* In the "Desired version" graph, the little amount of red at the bottom has faded away, it's all blue now.  I'm guessing red was obsolete nodes (lower version)?

* In the "Pool rate" graph, there are less DOA/Orphan shares now, which is a good thing.  The pool is more green.  Still not perfect, but a big improvement.

* In the "Traffic rate" graph, there's a huge change.  There was a sudden spike near when the changeover happened, but that was a one-time thing.  Network traffic has nicely gone down a large amount.  It's about 1/3 what it was before, to reflect the new, slower, pace of share generation/synchronization.

Interestingly, the expected time for my node to find a single share, is now longer than the expected time for P2Pool to find a Bitcoin block!  Previously, it was the other way around.  Guess that means that my node will fall out of blocks entirely (0 shares/block) but that's the price to be paid for finding blocks more often, so in the long term it should even out.

I'm glad the changeover went smoothly!  If it were me, I would have been really nervous when it happened, crossing my fingers, especially since such a dramatic change to a distributed network is a tough thing to fully test in advance...!

Josh

I upgraded to p2pool 13.1 and it works great!

Question though, when I run it, version is reported as this:

Version: unknown 666f7272657374762d7032706f6f6c2d38333235366538

Is this the correct version?  I installed the p2pool 13.1 snapshot from Github (downloaded the snapshot tarball itself, did not use Git to pull the source).

Thanks!
Josh

Works great for me, under Linux.  I haven't noticed any problems with bfgminer 3.1.2 crashing or taking 100% CPU.  Maybe the problem could be isolated to Windows?

Compiled my entire Bitcoin stack from source, on Gentoo:

bitcoin 0.8.3 (bitcoin-qt target)
p2pool 13.1 (no compilation needed, it's a Python program which is interpreted)
bfgminer 3.1.2

I rather like bfgminer, it follows the "configure" standard, and drops right in!  Rather impressive.

Even the Satoshi bitcoin client wasn't this cleanly written, as it still required a little tweaking before it would compile: http://forums.gentoo.org/viewtopic-p-7344252.html#7344252

Command lines I've been using for the stack, which mines on my little Erupter:


If scripting, be sure to change "cd" commands to the directories you are using on your system (it is critically important to start from the correct directory for p2pool).

And, you probably want to change your payout address accordingly

Josh