Yes, basically it does mean that it is now unprofitable to tithe the rest of the day, as the pool took in 110K or so and pays out 92K.
The confusing thing we have going on right now is some of our reports are based on 40 blocks, some 205.  This is confusing.

I'll take a look at this as a high priority.

Fortunately I think we can fix both issues we have as a leisure.

Basically what we have going on is our difficulty swings too fast to 0.  Im working on an idea now and trying to do this in a way where we don't need a mandatory upgrade for the exchanges as a stopgap between now and when we vote the PODC vote.

Nice, that looks pretty good.

Now can we see someone capture a few hours for another coin, and see what % we are in comparison to the baseline?

200 meg does seem a little high since we only have 100,000 blocks.  But we do need a baseline to compare to.

I would rather not tell people to use win10 as a bandwidth meter as that is for the machine and all ports.

People are claiming BBP is using bandwidth. 

We want to monitor port 40,000 and just the BBP usage.

Just for BBP.

So the auto tithe feature will tithe from 1-300 bbp depending on the POG Difficulty, and on your applicable coin age.  Please type 'titheinfo' and see how many coins you have that meet the diff level.  If you had 1 coin, and the diff was 32767 , the wallet would tithe 150 for example (see this chart:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners

in the difficulty chart area).


Were having a pretty good pog day so fortunately you will be able to see this in prod within 15 blocks, as it looks like our pog diff is about to drop very soon today (IE down to 10K or so).
This would allow people with less coin age to auto-tithe.

So the answer is it depends on your coin age and the POG diff at each block during the day.  Each block the diff changes.

As far as the pool, if you are nervous and want to segregate out one dedicated machine for tithing, you could also add a pool worker if you want, thats completely up to you .

EDIT:  The max it will send is 300 bbp.  Per auto tithe instance.

Other than that, you would have to shut it off as there is no governor per day at this point.

Well we are all full nodes with the full chain, but we are only full nodes if we have a firewall forwarding port 40000 to the fullnode.
If you look at tools | info, see if you have inbound connections.  That will tell you if you are servicing other nodes both ways (IE accepting new users connections, people who aren't synced yet).

But lets try to hone in on this - you having multiple wallets will be very valuable to diagnose this.  Could you take a look at the tools | network traffic tab in biblepay, and compare it for 24 hours to one of your other popular coins and tell us the difference in outbound traffic?  

As far as the future, we are technically retiring podc (not heat mining, actually heat mining would be getting more popular with us- since more POBH users will jump on for POG).  The only bandwidth change would be less consumed by boinc and the boinc client and the boinc programs.  You would see an increase in node count, but this new bandwidth draw would be shared across the new nodes also.

Id like to know the baselines first before we assign a dev to add the feature that monitors the bandwidth by messagetype.

I see a sharp increase in POW difficulty.  This is what we needed.

On a side note the automatic option only tithes if its profitable (see titheinfo to see the ROI figure, its about 16% or so usually).
The only way to control it manually is to turn off auto (tithe=0) then send manual tithes, but of course that would be very tedious with the consistent high diff level.

To get a feel of the total per day see the "pog pool" and whatever your entry ends up being in 24 hours is roughly what the wallet is auto tithing.

Something is wrong there - I havent sent 1 gig since I booted it last, so first ensure you are completely synced.
Then clear the Tools | Network Monitor tab.
Then watch it for 24 hours and see if its too high and if it matches what gig monitor you are looking at - and verify all this is on port 40,000 if so.
(You might be running other things).

Well plus (they didnt believe me), but Pog uses less bandwidth than BBP+a pool.
A pool requires the work to be sent back and forth (each small subunit is solved once per 5 mins or so).
POG requires 0 bandwidth.

Technically we should be pretty low bandwidth once the network is synced.  I dont know how many nodes per minute are asking for an entire chain.
But let us not make the assumption its always blocks.  If we can get some legitimate complaints that its on port 40,000 and its excessive and its not a blockchain packet, then MIP and I can add a feature that will show exactly the count and type and size of what it was, but Im looking at my windows node and it doesnt look excessive on the network analyzer tab.   I received 198 megs and sent 1gig of data since the last boot.  (I can see sending 1 gig of blockchain data in a few days time to nodes who are resyncing, and asking 198 meg of blocks etc).

Although I agree with a certain element of this theory (that in pure POW each coin had a high electric cost), the new system is not quite the bank of Zimbabwe either.
In the new system, we still have individual single PC's running at least 1 POW thread of POBH, so that may drop electric consumption but its still there per distinct user-pc.
The other element is (and this is what I'm hoping for) is a change in our user base.

Before we had 200 rich people with 10 machines each.  Now we are hoping for 2000 average people with 1 machine each.
The question is, will this materialize, and, are 2000 thriving positive community members better for us than 200 who like to count coins every day (Im just joking, but you get my point).

Also we have PIVX to consider and they have 0 POW and are valued based on the ingenuity of POS with Dash alone.

For POG you can now solve blocks without a signed CPID, so you should no longer have to use the same copy of wallet.dat.

Its really up to you if you want to pool mine or solo mine.
Right now in Pog Phase 1, Solo mined blocks pay about 100 bbp. 

On the nickname:  The pool inducts one nickname per distinct BBP reward address.  So if you have 10 machines all with the same nickname and different wallet.dat's, then you will have 10 entries in the pool.  If you do keep your copied wallet.dat and use the same nickname across 10 machines the pool will induct you as one record.

This is ranting.

Yes, leaderboard should be sorted by sum of tithes descending, that would be cool.  I can do that today.

No but POG uses 0 bandwidth.  

What we need to do is determine if your traffic is inbound, outbound, for block inventory or governance objects.

How many inbound and outbound connections do you have on your node?   Its under connections : Inbound N / Outbound Y.

Also, just to clarify, does BiblePay's Network Monitor screen match your bandwidth use?  IE do we show 1.5 gig of use in the network monitor in one day?  If so what is the breakdown?

If you create some bank notes with exec bankroll, we mark them for POG only.  Then PODC Updates wont choose them.

Yes, I think it might fill itself up (but-its a victim of its own catastrophic change however - spikes to 128,000 cause no one to tithe for large periods repeating the issue), but also, if we tweak the params during the next mandatory then the diff of zero wont really be zero (if 0 would requires 1 day coin age) meaning no catastrophic move from floodgates open to 100,000 diff in just 3 blocks.

But having the 40 block lookback itself - I think it has positive benefits - for people who didnt have a chance to tithe during the morning will have another chance (with 205, you have a flat line slow moving diff, with 40 you have 5 elliott waves per day).

I think all it needs is a max tithe amount of 3bbp and a min coin age of 1 at the lower end of the chart (diff 0).  That would give us 20,000 tithes per day, people using up all their coin age if they attack, and probably 10,000 distinct users in the pool.  The vol would drop to normal vol with these params (theoretically, it appears).

It looks back 40 so that we can have more fair participation and chances per day for all, and also for performance reasons (a constant 40 block lookback is easier on the core).

When you say 'take care of this issue' what issue are you referring to?

We could probably do a couple things in our next mandatory to make things easier on newbies, and future proof POG with less pog volatility....

We could change the max tithe amount to 5bbp (from 300) -- (this would allow thousands of small tithes per day each using up the coin age of the single coin-owner) meaning more people would fit in the daily pool before exhausting the tithe cap of the pool.

We could require a minimum of 1 day of coin-age at difficulty 0 (IE at diff 0, 1 day of coin age and a max of 5bbp per tithe).  (And remember the 5bbp is descending, so at diff of 32000 the max would be 2.5 bbp).

As far as someone trying to hog a block despite owning a lot of coin age - (IE if someone tries to send in 25 tithes manually, they would use up all the coin age on 25 tx's) so that is not an attack vector.

I think these 2 things would enhance pog and make it relatively future proof.  For now lets see how this goes over the next 30 days.

The system as-is still requires a user to have the coin-age first of all - so these things are not necessarily attacks - but currently allowing 300 bbp chunks means less maximum users in the pool per day - which is something we can improve on with the above I think.

Pog diff was 0 for 3 blocks because we had 40 blocks with zero tithes behind it.  That normally doesnt happen so this will work itself out as more people tithe consistently.

The checkbox:  The gui doesnt update automatically so you just have to uncheck and check the pog tithe manually before you make a tithe.  (That refreshes the screen metrics).

Everything looks fine, Slovakia....

EDIT: I'm positive we throw an error on the GUI though if you click Send and the block clicked by (IE diff rose between blocks) and we reject the tithe.    I'm confident when you clicked Send the underlying diff was lower at that particular moment.