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

[capulo]

will rejected tx destroy coin age?

[1714835653]

1714835653

[1714835653]

1714835653

[1714835653]

1714835653

[1714835653]

1714835653

[1714835653]

1714835653

[bible_pay]

will rejected tx destroy coin age?

No, it will be like it was not sent.

[bible_pay]

again update all MNs,wallets? omg

Yes, entire network.

[sunk818]

Creating more wallets will be counterproductive, as you need coin-age to tithe.

This would be a one-time destruction of your coin-age... A savvy person could just move the coins that were just tithed to another wallet. Since the coin age is 0 anyway, there's no coin age loss. This makes me feel the tech savvy users will again game PoG and newcomers will be negatively affected.

[shorty34]

Creating more wallets will be counterproductive, as you need coin-age to tithe.

This would be a one-time destruction of your coin-age... A savvy person could just move the coins that were just tithed to another wallet. Since the coin age is 0 anyway, there's no coin age loss. This makes me feel the tech savvy users will again game PoG and newcomers will be negatively affected.

Hey, can't we sell this as the next innovation?

"Proof of Seniority" - I don't think many have thought of such a concept

[bible_pay]

Creating more wallets will be counterproductive, as you need coin-age to tithe.

This would be a one-time destruction of your coin-age... A savvy person could just move the coins that were just tithed to another wallet. Since the coin age is 0 anyway, there's no coin age loss. This makes me feel the tech savvy users will again game PoG and newcomers will be negatively affected.

- POG was never gamed
- You don't understand POG
- Splitting wallets is counterproductive

Please proof-read what you write before posting here.  You know the rules are not to spread FUD or make assumptions.

If you need more help understanding POG first please e-mail me with the questions or MIP.

[bible_pay]

again update all MNs,wallets? omg

How accurate is your explorer node that we pre-paid for 3 months for, is it synced properly?

[sunk818]

again update all MNs,wallets? omg

How accurate is your explorer node that we pre-paid for 3 months for, is it synced properly?

He gave up and took down the explorer.

[sunk818]

- POG was never gamed
- You don't understand POG
- Splitting wallets is counterproductive

If you say splitting wallets is counterproductive, then can you please explain why? Balance requirement remains the same?

[bible_pay]

Under the newest version of PoG there would be no need to split wallets.  Having a huge bankroll split into multiple denominations would be the same (more or less) as having multiple wallets with the same denominations and quantity.  The only gain would be if you needed to do more than roughly 720 transactions a day in which case multiple wallets would simplify that (as you can set tithe=2 which would try and tithe every 2 minutes or 720 transactions a day).  

We do need a detailed explanation of what was coded to change in PoG to better understand it, but from the way it appears, with the reduction in max tithe it will be hard to exceed the daily maximum at this point.

And I still believe that PoG doesn't really simplify things because at this point a six year old might be able to change the config to tithe=1 but won't have an understanding of how it's working.

Correction to your post:  Under any version of POG it would be counterproductive to split wallets.  We didn't change POG's rules to mitigate split wallets (we talked about this way back in the first page of testnet).

POG not only simplifies things, but its like day and night compared to PODC.  I'm sorry but I just can't tolerate the misleading nature of this post.  You and 99% of the people here know how complicated PODC can be.  (PODC has a dictionary of terminology, while POG is as simple as the POW mining algorithm itself with 3 tithe parameters in it).

[bible_pay]

- POG was never gamed
- You don't understand POG
- Splitting wallets is counterproductive

If you say splitting wallets is counterproductive, then can you please explain why? Balance requirement remains the same?

Sure!  I am always happy to elaborate. 

So with POG, the act of giving is governed by the ability to spend a Single coin with Age + Minimum Amount + Maximum value.
This means that it is equally beneficial (but more efficient) to store all your coins in one controller wallet.  For one, we will see distinct nicknames (thats good for accurate reports), for two we may have a Christian Economy feature in the future that ties to the address, and three- splitting the wallet offers no real advantage due to individual pool entries as the split coins age at the same rate (IE two wallets tithing more frequently are not capable of tithing more frequently than one wallet).  The single wallet will tithe just as frequently as possible for the difficulty level.

So in environment A, a user with a 100K balance split into 10 banknotes is exactly equal to a user with two wallets and 50K balance on each split into 10 banknotes (across 2 nodes).  All 20 of these banknotes age at the same rate and offer the same pool share percentage.  So there is no advantage to splitting the wallets - but its more efficient to have one (you have one miner running, you have one nickname), etc. 

If you want more POW mining you can still just set up the other nodes for POW only (without POG).

[bbptoshi]

I noticed when I have internet connection issue, PODCupdate will not recognize my RAC, and create a PODCupdate with stake of 10 BBP.  Even when I had a good PODCupdate ~30 blocks prior, this causes me to miss a payment sometimes.  So, this PODCupdate seems to be created when the wallet is offline and then sent when it comes back online.

Is there a way we could prevent this by only allowing a PODCupdate to be generated if the stake is greater than x, user input variable?

[bible_pay]

I noticed when I have internet connection issue, PODCupdate will not recognize my RAC, and create a PODCupdate with stake of 10 BBP.  Even when I had a good PODCupdate ~30 blocks prior, this causes me to miss a payment sometimes.  So, this PODCupdate seems to be created when the wallet is offline and then sent when it comes back online.

Is there a way we could prevent this by only allowing a PODCupdate to be generated if the stake is greater than x, user input variable?

I think the best way in your case is to set 'utxooverride=nnnn'.  This just sends the same amount every time it tries to send (therefore you should not have a low amount logged).

[sunk818]

So with the PoG change, will the new values for max_tithe be 10-1 (descending) and the min_coin_age stay 0-60 and min_coin_amount stay 1-12500?

If I'm reading the code right, min_coin_amount goes up to 25k. Does that mean combined "stake" of 62.5M BBP that was 30 days old becomes 125M BBP? It sounds like Rob is sacrificing donations received so users are guaranteed a BBP ROI until more participants arrive.

https://github.com/biblepay/biblepay/commit/52b3fe81ca2ada664d815f21d090aa7ac12b5448

Code:

td.min_coin_age = R2X(Quantize(.25, 60, nQLevel));
td.min_coin_amount = R2X(Quantize(1, 25000, nQLevel)) * COIN;
td.max_tithe_amount = R2X(Quantize(10, .25, nQLevel)) * COIN; // Descending tithe amoun

[coinsinspect]

I am on this coin over a year now.
i am aware of frustrations from everyone due to price decline.
If I would bail out, I will lose thousands of dollars.

However, I am so shocked on the time and effort Rob put into this coin,
it seems that he put into it all his time and a lot of his money.

I appropriate it a lot Rob, Thanks for your effort supporting us,
with this effort continuing we cannot fail.

God bless you good man.

[capulo]

my another opinion

for me, podc was not complicated, it just takes few days to make it work, few days of waiting of course
boinc setup - third party soft, many webs about it... no problem
then assigning wallet and team - few steps
adding new computers - one line in cmd
it works without any interventions
you can predict your payout

pog - you will probably wait much longer to see payments
preparing coins on wallet (bankrolls, coin ages, amounts etc..) - i dont think this is easy for newbies/normal users
maintaining coins - you need from time to time exec bankroll and collect low balances stacks into one bigger
you can just guess your next payout

of course both requires buying coins

and what about simplyfying podc? is somebody working on it?
what if we will have one common wcg/rosetta account and new users just add their pc there? so they can bypass 2 dasy of waiting for accounts etc and starts mining instantly
they just need to identify, maybe wallet address as pc hostname? (if it is possible due to length). of course there is stacking, but if we set this account as stakeless and pay only 30% then it could work. and if somebody will have anough bbp and skill, he can switch to own accounts with stake

[bible_pay]

So with the PoG change, will the new values for max_tithe be 10-1 (descending) and the min_coin_age stay 0-60 and min_coin_amount stay 1-12500?

If so, then to achieve median difficulty would take 5000 tithes a day, but those users would have to have a combined "stake" of 62.5M BBP that was 30 days old, meaning to sustain that level (just median) would take more coins than currently exist (1.875B).  And at that level, tithers would see a return of approximately 16 BBP for each 5 BBP tithe.  Since the level of difficulty would have to be lower, you're looking at a much much higher reward in practice which becomes very troubling as, again, it would be no net cost - no risk and have no psychological floor (whereas someone generating coins that cost them 1 cent per 100 to make, has a reason to not sell for less that 1/100th of a cent).

If the min_coin_age and min_coin_amount decrease, then it diminishes the impact of decreasing the max_tithe.

I make no bones about being a PoDC supporter, but PoG is not a system that brings much benefit when I look at it objectively.   No risk mining means no real price floor.  When coin age exceeds a few weeks, it reduces the ease of entry for new users, but without it, the whales would rule the system.  It has the potential to be very inconsistent with both rewards and how often a user can tithe, both of which make getting new users difficult.  It doesn't sufficiently constrain supply...unlike Proof of Burn which eliminates coins from the economy, or Proof of Stake which typically locks coins in for longer terms for rewards.  PoG adds network traffic that we can sustain for now, but when you compare to our theoretical maximum transaction limit (which I've ballparked before and don't have the numbers in front of me), 5000 additional transactions a day could start to have an impact.  In short, even though I feel PoG would benefit me personally, I don't see it being beneficial for the coin at large.

I ask with all due respect, that when the PoDC vote occurs, one option is to eliminate PoG.  I also request that the community at large be heard and to that end would ask for a commitment from Rob to not vote more than a handful of the Sanctuaries under his control.

1)  No; the new values are 10 max_tithe descending yes, but coin_age starts at .25 a day minimum - 60 ascending, and the min_coin_amount stays the same. 
2) On the median difficulty and 'much higher reward' in practice; no, everyone works with a relative share weight which is related to their applicable coin count from #1, and the tithe cap remains the same and the max reward per day (90k) remains the same, so no this is not true, actually I dont even follow the logic here.  Once coin age is spent, the newbie who waited 7 days to stake that coin has to wait until the coin age matures again to get back in the pool, so there is no additional reward in phase 2 compared to phase 1.  What we do see is more participants in the pool and lower average difficulty for everyone.
3) If the 'no risk-no price floor' were true then a coin like PIVX would be worthless.  Obviously people value each share of their crypto with more facets than electricity as an inputs.  I listed some of them 50 pages back:  future price target, innovation, expectation of dash to have more success, expectation that our devs are good, central bank expectations, many things go into pricing each share other than electricity.  So you might be right about going from 7 satoshi floor to 6, but even that is laughable because Im not holding BBP to appreciate from 7 satoshi to 8 because of electric.  Its laughable.  Were holding biblepay because we know biblepay is deflationary, will provide real world value in the future and we believe in the devs and the technology that is entering the project.  We know that some day Rob and MIP are going to succeed in the killer feature and biblepay will be in the top 100 list.  At the same time the Christians will catch on and out of 1 billion, we see a certain sliver that likes crypto.  Thats the expectation.  Not a measly 10% increase in electric cost over 10 years .
4) If you are concerned about the PODC vote level I recommend you buy enough bbp to have more sanctuary count than me.  Obviously every one who buys a sanctuary has the right to vote with it the way they please.  It would be foolish not to use that right.  On a side note, I still believe in POG and think PODC is too complicated for the average Christian.  In addition I think adding in PODC is not completely aligned with our vision (of having a high percentage of believers who contribute in development to this coin). 

[bible_pay]

So with the PoG change, will the new values for max_tithe be 10-1 (descending) and the min_coin_age stay 0-60 and min_coin_amount stay 1-12500?

If I'm reading the code right, min_coin_amount goes up to 25k. Does that mean combined "stake" of 62.5M BBP that was 30 days old becomes 125M BBP? It sounds like Rob is sacrificing donations received so users are guaranteed a BBP ROI until more participants arrive.

https://github.com/biblepay/biblepay/commit/52b3fe81ca2ada664d815f21d090aa7ac12b5448

Code:

td.min_coin_age = R2X(Quantize(.25, 60, nQLevel));
td.min_coin_amount = R2X(Quantize(1, 25000, nQLevel)) * COIN;
td.max_tithe_amount = R2X(Quantize(10, .25, nQLevel)) * COIN; // Descending tithe amoun

Bingo!  You got it.  We are sacrificing donations per day but guaranteeing that everyone can participate (IE 10-20,000 concurrent pool participants).  Then we can also see clearly what our trend is toward the public. 

And in reality I think all this is going to do (as far as not having enough donations per day, not filling up the pool) is difficulty will drop for us (because everyone network wide will spend the coin age), then 4 hours later everyone will tithe again at a low diff, so we will still have a chance at filling up the pool from repeating low difficulty tithes.

The main improvement is capacity.  When more people come we can handle it for a couple years in the future (which would be a very good problem to have).

[bible_pay]

I am on this coin over a year now.
i am aware of frustrations from everyone due to price decline.
If I would bail out, I will lose thousands of dollars.

However, I am so shocked on the time and effort Rob put into this coin,
it seems that he put into it all his time and a lot of his money.

I appropriate it a lot Rob, Thanks for your effort supporting us,
with this effort continuing we cannot fail.

God bless you good man.

Thanks, and I am happy you are on board, and I pray people like you make up the majority of this project in a year.

[bible_pay]

Todd from Cameroon One thanks us from Honduras!

https://pool.biblepay.org/SAN/images/CameroonOne2019.MOV