BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[sunk818]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

I told mip but United sci-fi has a split block feature in the GUI. It's like bank roll but on the GUI and let's you use coin control.

[capulo]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

You can manually select coins in coin control and send a chuck to yourself of the correct denomination.  Repeat that process with the change each time until you've broken it up into the right denominations.  It's a bit more work but shouldn't take more than a few minutes and you'll get what you want.

one by one? ufff, insane if i imagine that i will need to create 1000+ TXs manualy

[bible_pay]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

[bible_pay]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

You can manually select coins in coin control and send a chuck to yourself of the correct denomination.  Repeat that process with the change each time until you've broken it up into the right denominations.  It's a bit more work but shouldn't take more than a few minutes and you'll get what you want.

one by one? ufff, insane if i imagine that i will need to create 1000+ TXs manualy

No, the exec bankroll command was made for this.

[bible_pay]

Oh Ok, thanks, I just like to put words in others mouths; OK, great.  (Even if the words are synonomous to your spirit).  Oh and I do it "again" right, even though I can't remember doing it before, unless you mean quoting you in a more succinct way.  Maybe that's how we should communicate:  Remove the FUD, remove the misleading nature of the post, remove anything your not sure of first, then tell me if I've referred to your spirit incorrectly.

POG versions: we are up to two or three versions now, right?  Sure.  I wonder what the difference was between them, was it a configuration parameter between 1 & 2?  Yes.  So is it a new version of the algorithm?  But in reality we're on still on #1 and #2 is the only future version I'm referring to, the one with the configuration change in it.  But thats right you were too proud to help in testnet and didnt participate, and when I laid out the rules you had nothing to say.  But thats OK, we created it without flaws, as you have not found any.

My voting is not welcome because we're not democratic, Oh I see.

I maintain that we are 100% democratic and anyone who buys a 1.55 MM Sanc may vote in a poll which dictates the future of biblepay.

I don't understand the negative spirit you bring to biblepay in response to POG;  I see a lot of words here with incorrect terminology and assumptions.

All the coins in the world who offer high rewards and have a low miner count end up with an equilibrium of miners:rewards.  So its a fallacy for you to say that "we are hoping" that the miners fill in the void within a couple years or whatever - you are in error, and I have the historical proof available to prove that we will fill the void very quickly when PODC is retired.

I'm insulted that you want to hold a vote early, if you are concerned about being democratic then we should let everyone prepare for the vote so we have maximum vote exposure by sancs.  I believe you want the vote at a time when perception of POG is low, as you realize perception will be much more positive after block 102025.

This is sort of a hyprocritical attitude.  Its like saying Togo bought too much biblepay early so lets kick him out.  West has too many computers on PODC so lets not be fair and balanced to evaluate POG properly.

But, the truth of the matter is POG is fairer than Bitcoin's POW - as you are not up against an ASIC pool who can afford discounted chips, instead you receive a share percentage of the pool based on how much coin age you have and partially with 20% CPU-Mined distinct full node miners.  

Reaching a median network difficulty does not matter.

Thank you none the less for a reply.  But you have yet to address the supply vs median difficulty issue. And that shows one area where PoG needs at a minimum more revision.

I'm confused where objective discussion qualifies as FUD, yes I'm afraid this will damage BBP, yes I'm uncertain how PoG will suddenly bring in an influx of users and yes I'm in doubt it is ready to be in main net, but it is.  So at least I've cleared that up.

I'm not one to talk about my personal life.  You are correct that I didn't participate in testnet, but in fact was barely active on any crypto things during a majority of the time due to family issues.  So thank you for your compassion and just chalking it to pride (which I'd gladly rather it been than what I was going through).

I support this coin, I support it so much I cannot sit by idly while I see something coming so counter productive I feel it will hurt our community, our value and our mission.

As far as an early vote, my point you are missing is you under almost any reasonable circumstance you can steer the vote to success or failure. What is hurting the coin in part is the uncertainty so remove that and just impose your design and we'll live with it.  You've been a prolific coder and done great things.  You'll get the coin through PoG one way or another.  

Actually a lot of my replies fall on deaf ears.  20 pages later I never hear back.

I'm not sure if you read this in one of my prior replies:

Environment A:  Maximum Tithes Accepted per day:  52000.  Payout from Pog Pool per day:  75000.
Environment B:  Maximum Tithes Accepted per day:  92000.  Payout from Pog Pool per day:  960,000.


I don't see a problem with POG, nor a problem with the median difficulty, nor a problem with the supply.  I don't understand why you are linking fresh available supply with POG difficulty in the first place and blaming the algorithm for it.  I don't see any possible revisions.

Stepping back and looking at the POW (POBH) diff level, I see a low diff, a 3000 or so mostly.  What does that have to do with anything?  Other than tell us that its not "too hard" to earn 100 bbp if I mine now.

I still maintain that in Environment B, the miners will fill the void (they always do) they did from the beginning, they did after launch, they will in the future, jump from quantity 50 to at least quantity 150 and fill the void (and the 150 is if our price is low) - that is the facet you underestimate that miner count is linked to price.

Nothing wrong, a good algorithm, better than our original vanilla POBH (that was subject to botnet risk) that allowed a run up in our price to 25 satoshi.

[capulo]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

this one takes piles
5bab2b0f25dc2593d2d6ad89ab3312fba0f42140ba4a8d2334f0ef85487d615d

here i was trying bankroll and it was marked as ''çreate denominations''
5bc5250a15fd52b523467e120dec6989055a01a802074c2f13819735c6532a56

here was another bankroll which created piles mentioned above.. but this one was marked as ''payment to yourself''
d5378532d4b3e603cfb34b199c2a0cb61fd6c38ebec93e8060504192fe81a987

[bible_pay]

Nothing wrong, a good algorithm, better than our original vanilla POBH (that was subject to botnet risk) that allowed a run up in our price to 25 satoshi.

Someone on Discord asked me if there is risk of botnet again? If I recall right, CPID can't mine blocks sequentially? Testnet I think it was every other, prod is it every 4th (e.g. CPID a,b,c,d,a,b,c,d)?  So, if the proposal is for PoDC to go away, CPID will no longer be an external unique identifier (oracle?). So, do you have a plan for replacing CPID with something within the blockchain itself? I ask because PoG seems to only use blockchain data so the logical conclusion is that Proof of Bible Hash (modified Proof of Work) may be due for a similar enhancement?

Well let me break this into two distinct problems however first.  In Nov 2017 (roughly) the original botnet exploited us in a way where someone from Japan I believe installed 300 copies of biblepay in a setting where I believe it was hard for them to upgrade (maybe a plant or something).  We were not prepared, so we had a problem pushing mandatory upgrades.  Granted if I were to do this all over, I would have reacted by adding a non deterministic spork in our very first algorithm, but nevertheless thats water under the bridge now.  So that botnet risk is solved in POG in a couple different ways:  A) We are on multiple exchanges, so people have to upgrade or they cant sell, B) POG rewards the controller wallets now (not the distinct machine count).

We were happy with CPIDs being one per researcher with multiple machines - that busted the botnet in a different way - by demanding a unique ID per researcher (IE they could run as many sub machines as they wanted) and we didnt care, because PODC is modular (it runs outside of biblepay).

The distinct CPID rule was more related to 51% attack prevention.  It required an insider to solve blocks and guaranteed the same researcher couldnt solve back to back blocks.

We have a new 51% attack prevention mechanism now live in BiblePay.  I can't really explain it due to security concerns, but its about 1000* better than the cpid rule.

But in summary, as of this latest mandatory (we are already in pog phase 1) any heat miner can solve back to back blocks again.  This does not give us botnet risk primarily because of the low reaper reward that we now have.  IE botnets are formed when they are receiving the primary reward, so they go out and create as many machines as possible.

Im all for many machines mining for security if our price is going up, don't get me wrong- Im not aiming for cheap security, we want as much security as possible.

[bible_pay]

Under Environment B Median difficulty would mean:

46,000 in tithes per day (92,000 max, median difficulty is half that)?

max tithe of 5 BBP (based half the maximum tithe of 10)?

Is there a simulation that we could see as a Google Sheets and a chart? From using testnet, tithes and pog difficulty don't move linearly. If tithes are exhausted then min coin age and min coin value would come down until participants drive the difficulty back up. Do you consider a different set of parameters more optimal? I like linear because it is easy to explain to those curious. I'm not sure what the downside is... maybe giving too much reward w/ low buyer risk? Or difficulty that is too linear instead of logarithmic?

I'm also going to reply to him after I check Capulos issue. 

[bible_pay]

Actually a lot of my replies fall on deaf ears.  20 pages later I never hear back.

I'm not sure if you read this in one of my prior replies:

Environment A:  Maximum Tithes Accepted per day:  52000.  Payout from Pog Pool per day:  75000.
Environment B:  Maximum Tithes Accepted per day:  92000.  Payout from Pog Pool per day:  960,000.

I don't see a problem with POG, nor a problem with the median difficulty, nor a problem with the supply.  I don't understand why you are linking fresh available supply with POG difficulty in the first place and blaming the algorithm for it.  I don't see any possible revisions.

Stepping back and looking at the POW (POBH) diff level, I see a low diff, a 3000 or so mostly.  What does that have to do with anything?  Other than tell us that its not "too hard" to earn 100 bbp if I mine now.

I still maintain that in Environment B, the miners will fill the void (they always do) they did from the beginning, they did after launch, they will in the future, jump from quantity 50 to at least quantity 150 and fill the void (and the 150 is if our price is low) - that is the facet you underestimate that miner count is linked to price.

Nothing wrong, a good algorithm, better than our original vanilla POBH (that was subject to botnet risk) that allowed a run up in our price to 25 satoshi.

I'm not questioning the maximum tithes or the payout (beyond the ROI being astronomical).  I'm basically asking how can we gain more users in a system that if it were working at median difficulty would normally need more supply than exists.  I'm not asking if the system can support more tithes than it currently does, I understand the system under Environment B in theory could support 92,000 tithes a day but the issue is there is not supply to actually do that.


So to break it down I'll hit my thoughts step by step; stop me where I'm wrong.

Under Environment B Median difficulty would mean:

46,000 in tithes per day (92,000 max, median difficulty is half that)?

max tithe of 5 BBP (based half the maximum tithe of 10)?

If both are true, then you'd need roughly 9,200 tithes in a day (at 5 BBP) to maintain median difficulty.

Those tithes would have to come from coin stacks (or whatever you wish to call them) of at least 12,500 BBP each?

Those coin stacks would have to be at least 30 days old?

If those are both true, then in a single day, you'd see 9,200 * 12,500 coin stacks being used that were each at least 30 days old.  This is 115M BBP.

To continue this system at the same median difficulty, you'd need another 115M coins that had been idle for 30 days on day 2, another on day 3, and so on.

So to continue at median difficulty for a month, would require 3.45B coins sitting idly until they were used to tithe, then recycled and waiting another 30 days to tithe again.  This is more than the current supply.

If that is true, then to reach max difficulty, would require 92,000 tithes from 25,000 BBP stacks that were 60 days old.  In one day, that would mean you'd need 2.3B coins that had been idle for 2 months tithe, again beyond the current supply.

If this is incorrect (beyond the idea that some small percentage of tithes will be coming in below target difficulty and the actual numbers would be slightly smaller) please explain.

So on "I'm basically asking how can we gain more users in a system that if it were working at median difficulty would normally need more supply than exists":
We're not expecting to hit median difficulty when we are hoping to gain users; we are expecting to hit very low difficulty at first.  I think we will hit difficulty around 1000 in Environment B - simply because of all the tithing capacity available.  I wouldn't expect us to come anywhere close to hitting the sum of (single tithes per user) being > total money supply (until we do gain more POG users).  I expect a user to tithe 20 times per day in Environment B, using all their bank notes up, with minimum coin age being almost .25 and minimum coin amount being almost 1, and re-using the same banknotes 2* per day.  I could see us collecting half of the foundation tithes per day in a low difficulty environment like this, that is until new users join.
The new users are not joining because we didn't tithe our entire money supply, they are joining because POG difficulty is too low and POG profitability is too high.  We would shoot from 50 POG users to 500.  Why you would disagree with that is beyond me, but thats what would happen if we are paying 1 mil in rewards and only have 50 miners on POG.

On these medium diff figures, the other thing about POG that is different than the math done here above is we have 5 sets of 40 blocks per day with difficulty based on the last 40 blocks, and that will sweep in a lot of tithers who missed the boat up to 5 times per day (IE diff will be a little more volatile) giving them opportunities.  What Im implying is if diff is high in the morning in environment B, we will still see it drop once those 40 blocks pass, allowing a lot of low diff users potentially in the pool (unless things are constant through the transition period).

So in summary, I expect difficulty to be as low as 1000 and everyone to tithe 24 times per day.  Each time they re-use a coin, it has a minimum coin age requirement of .25 - so theoretically they could re-use the stacks of coins up to 4 times per day.

With 500 users otoh,  I would expect difficulty to rise to 20,000 and then the users tithe frequency will drop to what we see now (4* per day, etc) because more coin age will be required per user to maintain the status quo.  This is the kind of environment Im hoping to hit, and more than that, 20,000+ users.  This algo is tuned for mass adoption.

[bible_pay]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

this one takes piles
5bab2b0f25dc2593d2d6ad89ab3312fba0f42140ba4a8d2334f0ef85487d615d

here i was trying bankroll and it was marked as ''çreate denominations''
5bc5250a15fd52b523467e120dec6989055a01a802074c2f13819735c6532a56

here was another bankroll which created piles mentioned above.. but this one was marked as ''payment to yourself''
d5378532d4b3e603cfb34b199c2a0cb61fd6c38ebec93e8060504192fe81a987

Ok, I found the bug, thanks for pointing this out.
The exec bankroll function does spend existing bankrolls to make new ones and it should not do this.

I will make a leisure release to fix this first thing in the morning.

[slavino]

hello,

i have problem with upgrade my wallet to 1187 with MIPs package, im tried this, second wallet upgraded to 1187 without problem

Update
stopped running wallet and then this 2 commands
Update apt: apt-get update
Upgrade all packages: apt-get upgrade

and is still on 1185

any help?

thank you

[capulo]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

this one takes piles
5bab2b0f25dc2593d2d6ad89ab3312fba0f42140ba4a8d2334f0ef85487d615d

here i was trying bankroll and it was marked as ''çreate denominations''
5bc5250a15fd52b523467e120dec6989055a01a802074c2f13819735c6532a56

here was another bankroll which created piles mentioned above.. but this one was marked as ''payment to yourself''
d5378532d4b3e603cfb34b199c2a0cb61fd6c38ebec93e8060504192fe81a987

Following the command at https://discontinuo.us/biblepay-unofficial-wiki/proof-of-giving/how-to-setup-biblepay-proof-of-giving-pog-using-new-wallet I had to first unlock my wallet.  But then I was able to perform two back to back

Code:

exec bankroll 5 500

Which made 5 coin stacks of 500.001 with the label TITHES each time.

The only thing that I can think possibly you had some locked transactions that you weren't able to actually make the amount you needed without reusing previous stacks?  So as an example, did if you were trying to exec bankroll 500 1000 but you only had 750,000 free, I'm not sure if it would re-use 250 of your stacks from the first go around or if it would simply fail the second time.

i never had locked wallet, few days ago i sent 400k and did 50x8k without problem, now i sent 500k and 50x10k failed

[capulo]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

this one takes piles
5bab2b0f25dc2593d2d6ad89ab3312fba0f42140ba4a8d2334f0ef85487d615d

here i was trying bankroll and it was marked as ''çreate denominations''
5bc5250a15fd52b523467e120dec6989055a01a802074c2f13819735c6532a56

here was another bankroll which created piles mentioned above.. but this one was marked as ''payment to yourself''
d5378532d4b3e603cfb34b199c2a0cb61fd6c38ebec93e8060504192fe81a987

Ok, I found the bug, thanks for pointing this out.
The exec bankroll function does spend existing bankrolls to make new ones and it should not do this.

I will make a leisure release to fix this first thing in the morning.

how it will work now? bankroll will never touched already splitted coins? (with .001 at the end?)
even if i will have only 200k new coins and exec bankroll 300 1000? or in this case it will use some splitted coins?

[Dimarzio123]

If I thought PoG would lead to a doubling of our active user base over the next year, I'd probably feel differently as user base would support the price and make up for the production cost deficiency.  But I don't see Pog as being a magic bullet that will fix everything.

Make up in volume. Sometimes organizations go out of business thinking they can make it up on volume. Sometimes you can, but you really need a good plan to succeed and gain market share. I think PoG has that potential. Once the algo is locked down and proven to work (although I have my reservations currently), it'll be a marketing game. Good marketing includes word-of-mouth, so having more participants definitely helps with that. My concern is that greed is a very powerful motivator... and there will likely be many participants... but is that the kind of community we want to attract with BiblePay? It seems anti-thetical to Christian values.

If we want to support orphans, we need volume - EOS

Regards
PM

[bible_pay]

hmm coin control is little bit crazy
i have ~ 500k already splitted to many piles
i sent another 500k, wait for 20+ confirmations and wants to split them
and exec bankroll 50 10000 takes already splitted piles with coin ages ~3 days and resplitted them
500k what i sent was untouched
next exec bankroll takes 500k pile finally

but how can i split only coins which i want? to not risk already gained coin ages?
if this will happen again with coin ages 30+ i will be very baad (when podc will be replaced with pog and i will be moving coins)

Looking at the code, 'exec bankroll' does supposedly ignore the bankroll mask denominations and it does not look to have a flaw - you are supposed to do this and it skips by already denominated coins with the .001nnnnn suffix on them.

Can you please give me the txid of the flawed 'exec bankroll' transaction and let me analyze it?

(One that spent a denomination coin).

this one takes piles
5bab2b0f25dc2593d2d6ad89ab3312fba0f42140ba4a8d2334f0ef85487d615d

here i was trying bankroll and it was marked as ''çreate denominations''
5bc5250a15fd52b523467e120dec6989055a01a802074c2f13819735c6532a56

here was another bankroll which created piles mentioned above.. but this one was marked as ''payment to yourself''
d5378532d4b3e603cfb34b199c2a0cb61fd6c38ebec93e8060504192fe81a987

Ok, I found the bug, thanks for pointing this out.
The exec bankroll function does spend existing bankrolls to make new ones and it should not do this.

I will make a leisure release to fix this first thing in the morning.

how it will work now? bankroll will never touched already splitted coins? (with .001 at the end?)
even if i will have only 200k new coins and exec bankroll 300 1000? or in this case it will use some splitted coins?

Yes, exec bankroll and podcupdate will skip by bankroll denominated coins and not spend them.
(We already skip by locked and sanc locked also).

[bible_pay]

New user reward raised to 9000 bbp!

https://bitcointalk.org/index.php?topic=5109110.msg49709617#msg49709617

[bible_pay]

So on "I'm basically asking how can we gain more users in a system that if it were working at median difficulty would normally need more supply than exists":
We're not expecting to hit median difficulty when we are hoping to gain users; we are expecting to hit very low difficulty at first.  I think we will hit difficulty around 1000 in Environment B - simply because of all the tithing capacity available.  I wouldn't expect us to come anywhere close to hitting the sum of (single tithes per user) being > total money supply (until we do gain more POG users).  I expect a user to tithe 20 times per day in Environment B, using all their bank notes up, with minimum coin age being almost .25 and minimum coin amount being almost 1, and re-using the same banknotes 2* per day.  I could see us collecting half of the foundation tithes per day in a low difficulty environment like this, that is until new users join.
The new users are not joining because we didn't tithe our entire money supply, they are joining because POG difficulty is too low and POG profitability is too high.  We would shoot from 50 POG users to 500.  Why you would disagree with that is beyond me, but thats what would happen if we are paying 1 mil in rewards and only have 50 miners on POG.

On these medium diff figures, the other thing about POG that is different than the math done here above is we have 5 sets of 40 blocks per day with difficulty based on the last 40 blocks, and that will sweep in a lot of tithers who missed the boat up to 5 times per day (IE diff will be a little more volatile) giving them opportunities.  What Im implying is if diff is high in the morning in environment B, we will still see it drop once those 40 blocks pass, allowing a lot of low diff users potentially in the pool (unless things are constant through the transition period).

So in summary, I expect difficulty to be as low as 1000 and everyone to tithe 24 times per day.  Each time they re-use a coin, it has a minimum coin age requirement of .25 - so theoretically they could re-use the stacks of coins up to 4 times per day.

With 500 users otoh,  I would expect difficulty to rise to 20,000 and then the users tithe frequency will drop to what we see now (4* per day, etc) because more coin age will be required per user to maintain the status quo.  This is the kind of environment Im hoping to hit, and more than that, 20,000+ users.  This algo is tuned for mass adoption.

The entire only looking back 40 blocks thing is going to introduce mass confusion for new users.  If user A and B both are new users and have the default set to tithe once per day, and User A's system tries on block 40 of the string...can't because the diff has spiked to 25,000 and he's got no coin stacks older than 23 days and literally ten minutes later, his friend, User B, is able to max tithe 10 BBP from his 1 day old block of coins because he's on block 1 of a new cycle...people will believe they have done something wrong or it's just not working.  Then 18 hours later, when User B gets this giant stack of rewards (probably on a 25:1 or better return) User A is really going to be mad.  The next day when it happens again, User A will likely just give up and when User B finally gets to the wrong part of the 40 block cycle and suddenly cannot tithe, he'll get confused.  He'll stay a few days longer than A because he thinks this coin is supposed to have these crazy rewards but for some reason he's not getting them either.  He'll call User A and say "I guess you were right, this coin doesn't work right".  They'll both tell non-User C, "avoid BBP, it doesn't work".

The 40 block look back is a big problem in a system that strives to be fair.  A look back should be 205 blocks but a look back of 410 blocks would smooth out most the bumps and give a lot more stability to the expectations of users and be much harder to game for unwarranted gains.

While a crazy large ROI will draw in some users initially, at best it's only a temporary influx and quite frankly with the price where it is at and trending towards I cannot see a good retention rate.  How we shoot our user base ten fold as you seem to think is feasible, is not so simple.  There are MN coins out there with crazy ROI, but they're still low end coins with low user bases.  We have one of the cheaper MN costs right now for established coins, but we're not seeing the volume on the markets that would imply we're getting new users from it.

Getting to your point that the algo is tuned to mass use...20,000 users should be nearly impossible with the current parameters.  The system (if fully implemented) at median difficulty (which I think we both agree is unlikely in the near term and I'll say is unlikely even in the long term) can only support 10,000 tithes a day.  Since most power users will be tithing multiple times each day (even you expect everyone to tithe 24 times a day) this math doesn't add up.

I think you misunderstand my dislike of PoG.  It's not that it is inherently a bad system.  And it's not that I'm a PoDC-or-die sort of user.  It's merely right now we have a system (PoDC) that works for the advanced users and could be simplified for the intermediate users (in fact, it's what was democratically voted to be done a few months ago instead of PoG).  I freely admit a new user will be able to put tithe=1 in their config file but that doesn't show an understanding of Pog any more than them putting gen=1 genproclimit=1 minersleep=750 in their config file means they understand PoBH.

Thank you for your reply and despite my disdain for PoG, I do thank you and MiP for your hard work on the coin and the PoG system.  At the end of it all, I just think we'll have to agree to disagree.

Well I think you all realize by now I answer in a non biased fashion even at my own expense.  

This argument about the 40 block lookback creating confusion is something that is being blown way way way out of proportion.  The 40 block lookback is internal and not intended to be communicated to miners - its not something that affects the everyday use in a way that should be in a training guide.  Its really the same system that we have with DGW anyway.  The lookback period is used by algorithms to get a barometer or a feel going as to where the trend is.  Its exactly the same as our 28 block lookback that is hardcoded in to DGW.  (Its used so the wallet can be efficient and not slow down).   Miners dont know about it - they dont know exactly how the POW difficulty changes - they just know that when its high, its very hard to mine the current set of blocks.  This is exactly the same with POG.  They dont need to know how exactly the clocks internal mechanism works, but they know how to mine it because they have a steering wheel and a gas pedal.  This is an unfair argument, its very clear that POG is easy to use and exposes a simple difficulty that reacts properly to the current pools tithe level.  We will be able to get the exact feel for it after block 102025 and before Environment B, because the capacity will be here in just a couple more days (IE the pool capacity and behavior will be in prod at that point) so we will know very clearly how it will behave in Environment B within 7 days after that (short of the hopeful influx of users that would fill up the pool later).

I know the web vote shows strong support for POG and 3 votes more for Improving PODC, however we also didnt get this far by misleading the users or not being democratic.  Togo raised the potential issue that the web votes could be being swayed by illegal votes.    We spoke about the untrustworthiness of the attackers that swear, that dont really care about the orphans or Jesus, that are here just because they are greedy, and I even watched, yes I WATCHED the 10 new users per minute come in when I ran the forum.biblepay site before Snat got it, and even had to shut off new user registrations to keep the polls from being corrupted.  At that point I went ahead and added the official poll as a sanc poll to get support to finish writing and then to deploy POG to prod for this phase.  We even commented about the untrustworthiness about web polls.  As I said when the poll was on, Im not anti-PODC itself, I just have reservations about its ability to bring mass adoption.  I feel the Holy Spirit wants POG over PODC because of that reason; we are supposed to be spreading the gospel otherwise God may not bless this platform.  That means my job is to come up with a killer feature that exposes miners and users to the Gospel in new ways (ways that arent here yet) - for example an event list in the wallet, a spiritiual warfare campaign with compensation, we need to inundate users with gospel reminders somehow, but who are we inundating if they are all PODC miners (IE 300, with 10 computers each), why not try to inundate those horizontally, IE 3000 users where we might save one per week (IE let them reach Jesus)?  Thats the kind of system God would bless.  But Ill clarify, Ill get back on the PODC wagon if its voted for and Ill construct the vote in a way that makes it clear that POG would stay in environment A, and PODC would stay.  However I will add a couple catches, that we enhance PODC to address the oracle concern (IE I will virtualize it) and address the concentration in another way (IE I will concentrate PODC in a way that any miner can mine it) but Im not going slate this 300 hours of work for PODC if its voted to be retired.  So at this point realize I agree wholehartedly the only secure voting system that exists is our sanc voting system and the next poll should be a Sanc poll for this (around block 106000 or so).

Thank you for bearing with me.

[bible_pay]

New user reward raised to 9000 bbp!

https://bitcointalk.org/index.php?topic=5109110.msg49709617#msg49709617

Where is the funding for this coming from?

Right now Im paying out of my pocket for the BBP reward and the SMS service and the Google Adwords campaign.

I might ask some back later but at this point I dont care.

[bible_pay]

Kudos for paying for the new user reward.

My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners.  Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.

I do have concerns that you aren't willing to spend time on PoDC upfront if it's going to be retired, when that is exactly what you're doing now with PoG.  By your labor, you are pushing a winner.  It's your right to do so, but to use the lack of revisions to PoDC while PoG is being tweaked and refined is not a good argument against PoDC.  I think you have the best intentions and your skills can get around many issues.  But PoG is not ELI5 simple to understand even if it is trivial to set up.

A longer look back would mitigate one of the bigger issues with PoG.  I beseech you to rethink your position there.

This is where we have to agree to disagree:

* The 40 block lookback is necessary, just as a 28 is in DGW, its an IT thing, and I weighed the efficiency vs the volatility; Youll see in prod in a couple days that vol is low with it.  This decision is a good one
* There is no flaw in POG - there was only a configuration issue (all the params were wrong in the first release).  This is an incorrect assessment.
* On dev time: Already wearing at least 3 hats; I don't feel this assessment deserves a proper reply - because your not fairly taking into consideration what Ive done for this coin. 
* Longer lookback is not a necessary change nor an enhancement
* POG is ELI5 once the user manual for 5 year olds is created.  I can say this because I know that the first gas lawnmower had more exposed controls than the 2000 version.  Thats where we are.  Im telling everyone that POG is going to be simpler than POW mining.  Its POW with one gas pedal. 

So lets be man enough to agree to disagree on these points.

[sunk818]

My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners.  Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.

The mechanic of tithe=1 being every 4 hours only, could be tweaked so after 4 hours of unsuccessful tithing, client will try every 5 minutes thereafter until a successful tithe. The impact could be many users could all try to tithe at the same time, but something like this could prevent any missed windows.

I reserve judgment until we see how PoG behaves after block 102k. The dynamics are hard for me to comprehend and would like to see it in action with real users tithing.