Testnet - Test Proof of Giving

I think you can (given your availability) port the GetTitheParams function(s) (just the math function(s) like quantize, not the UpdatePogPool stuff) into the mobile wallet, and call the Pool API for the pindexBestHeader->chainTip() POG difficulty level (IE 0-65535) (only because the pindex during sync wont have your current diff since the blocks arent stored but instead computed in the large client), once you have that int you can then call for the GetTitheParams, and that gives you the 3 things we can quote the user (age, max, min).

I see this clear, POG diff level must be retrieved from sowhere else.

The POG transaction does not require, but we should, transmit the <nickname> XML and the <tither> address in the ".sTxOutMessage" field - I dont know if you have implemented that field in the mobile client yet, would that be hard to add that field to the broadcasted transaction?  Then you would need to ask them for their nickname somehow during setup (not sure if there is a config in there).  It actually is OK to skip those two as users will receive POG payment rewards back to the sending address but I still recommend us going the extra mile to add the ability to send the message, because it is frowned upon to send rewards back to the change address (in addition a lot of clients try to anonymize the change address, and also it creates more spam, IE mobile user jumping around in the pog pool with many addresses etc).

sTxOutMessage is already supported as it's part of TxOut structure (otherwise mobile app outcoing txs would not be accepted by the network once broadcasted). So far the string goes blank but I don't think there will be any problem to send nickname (once configured by the user) and other data.

BTW on a more long-term discussion, Dash-rebased version we will probably have to move all this sTxOutMessage dependant behaviour into "special transactions" infrastructure provided by DIP002 (which is conceptually the same but using the "payload" concept instead sTxOutMessage).

At this point, the tithe should be accepted in the pogpool, so I think it should be doable....  Of course we should talk more about our apple situation as what is the use in doing all this if we cant even get listed in the Apple store.

Well it could be available on Android version... and even if we can't get listed on App Store we could someday provide the iOS app as downloadable like Binance does (if we ever obtain an enterprise dev license)

I see this clear, POG diff level must be retrieved from sowhere else.

sTxOutMessage is already supported as it's part of TxOut structure (otherwise mobile app outcoing txs would not be accepted by the network once broadcasted). So far the string goes blank but I don't think there will be any problem to send nickname (once configured by the user) and other data.

BTW on a more long-term discussion, Dash-rebased version we will probably have to move all this sTxOutMessage dependant behaviour into "special transactions" infrastructure provided by DIP002 (which is conceptually the same but using the "payload" concept instead sTxOutMessage).

Well it could be available on Android version... and even if we can't get listed on App Store we could someday provide the iOS app as downloadable like Binance does (if we ever obtain an enterprise dev license)

10-4 on the diff level, and being able to transmit the sTxOutMessage.

On the DIP002, I agree on doing this on a longer term scale - for "best practices".  That is picking apart the object types we store in MemorizePrayers and making each one a DIP002 conformant object over the long term.  However, I believe we will not need to do this as an emergency during the rebase (we might do at least one to get the feel for it), but, I believe our TxOutMessage will need to be ported to our new Dash rebase code for prior compatiblity.  The reason I say that, is in working with Stratis, I found the sTxOutMessage altered the hash of the transaction.  That means in order to sync from zero, the Dash rebase version must have the sTxOutMessage present in order to sync.  So another words, its not an emergency, but Im on board for a side project to convert to dip002 for best practices.  (Syncing prior blocks requires the existing sTxOutMessage message handler).

10-4 on the android version.  Yes, it sounds worth it, to have the code ready either way.  Im up for discussing ways to get us in the apple store.

One more 'on the radar post'.  If things go as expected (and this is an assumption), that means if POG goes over well for 90 days, and if we attempt to replace PODC with POG in the future, I'm thinking that we might keep a form of PODC superblocks (and repurpose them) to be something like 'Christian economy superblocks' (with a much lower value - IE based on our P2P budget, or P2P budget * 3 ~ whatever the discussion and vote bears).

The idea is that by then, we will have certain objects in the wallet that can be voted on.  I envision Outbound orphan letters, Gospel Links (or uploaded Christian videos into IPFS), Christian testimonies (in Christian spaces).  I dont want to discuss all of these individual objects quite yet - as I plan on creating dedicated threads for these once pog is running.

I just wanted to mention that we could utilize the Sanc superblock to renumerate an upvoted letter writer a reward.  As this would eliminate the pools entire letter writing system and upvote/downvote system.  Putting the reward in the daily POG superblock could cause problems (IE it ruins the POG consensus), but putting the letter reward in the repurposed Christian Economy superblock would most likely work very well.

This would of course require us to keep "some" of the rpcpodc.cpp code, but it would still allow us to retire the lions share of it and move to a simpler contract - one that calls out for hard transaction summaries (IE sum of votes per object).

Some other rewards might be IPFS hosting rewards (for IPFS supporter nodes), Christian video review rewards, etc.

I envision the user to have lists of objects to review each day, the Christian User will enter the list (of videos, or letters) and be able to right click and vote an object up or down.

Later the contract would call out for summaries of things that are not paid on a daily basis and set up a contract for payment for those items.

User A:
In the Rapture room: watched Rapture Video 1,2,3: 100 bbp * 3
Upvoted Outbound Letter #5: 100 bbp
Wrote an outbound letter 1 week ago: 5000 bbp
Watched Jesus Testimony in the "Jesus Testimony room":  100 bbp

...

etc

All objects are stored in IPFS - our txid pointers point to these object ids.

Could someone please test that the wallet does not spend any dedicated bankroll denominations in a podc update in testnet?

Denominations have .001 as suffix? I remember doing `exec bankroll` in prod a few builds back (1175) and PoDC update culled all the balances together. In TESTNET, the one wallet I have CPID registered doesn't have this behavior. Last PoDC update had just one input and two output even though I have hundreds of balances in the wallet.

On the DIP002, I agree on doing this on a longer term scale - for "best practices".

Completely agree on this. We will have enough  "fun" even making a workable devnet on the first approach so this would go on a later stage.

Denominations have .001 as suffix? I remember doing `exec bankroll` in prod a few builds back (1175) and PoDC update culled all the balances together. In TESTNET, the one wallet I have CPID registered doesn't have this behavior. Last PoDC update had just one input and two output even though I have hundreds of balances in the wallet.

The bankroll denominations have a .00100000 suffix in coin control (they also say sent to your 'TITHES' rec address) .  From my initial debug testing, the code appears to properly skip over them now - and the podcupdate is definitely sending in the argument to not spend them - so I feel 'relatively' confident its working.

The podcupdate combines as many inputs as it needs to make the target amount.

Completely agree on this. We will have enough  "fun" even making a workable devnet on the first approach so this would go on a later stage.

Yes thats for sure!

I believe all of the current issues are now addressed, and v1.0 of the Orphan Letter Writing system is ready to test (for testnet only, its disabled in prod).

I'll start a build.

So looking at the code on this, the "tithe_balance_available" is really just the total of the RPC output; another words, I think this should be recaptioned.
I just recaptioned it to "total".

To ensure its working right, if you look for your largest coin in value, say 1 million, try :
exec getdimensionalbalance 0 Largest_Coin

It should then just show 1, with a total of the large coin (I just tried and it worked).

So in summary this command just shows you the coins that meet the specs you provide.

Rob how it works behind getdimensionalbalance order?
I've tried it with different heights and it was still the same.
My bigest available balance was around 560k tBBP (with getdim... 0 1) and then it goes lower with higher min_coin_amount.
I have more than 8M tBBPs.

Are available for tithing only coins which are "stated" in getdimensionalbalance?
Or can I use all from my balance?
Why I cannot see there all my coins?

Rob how it works behind getdimensionalbalance order?
I've tried it with different heights and it was still the same.
My bigest available balance was around 560k tBBP (with getdim... 0 1) and then it goes lower with higher min_coin_amount.
I have more than 8M tBBPs.

Are available for tithing only coins which are "stated" in getdimensionalbalance?
Or can I use all from my balance?
Why I cannot see there all my coins?

Dimensionalbalance is just for a power user.
As a user you can see your available tithe balance by using 'titheinfo'.  These six rows should summarize the amount you have available:
Tithable_Coin_Quantity": 17,
  "Tithable_Largest_Coin": 1654774.9398551,
  "Tithable_Coin_Avg_Age": 23.5834477124183,
  "Tithable_Total_Coin_Balance": 1881249.03864134,
  "Tithability_Amount": 239.42,
  "Tithability_Summary": "YES"

On getdimensionalbalance, you must pass min_coin_age and min_coin_amount, and those two parameters filter the coins in the result.  IE they have nothing to do with the current difficulty or tithe parameters.  You are just seeing a filtered result set.

NOTE:

Please wait for 1.1.8.1. 

Rob how it works behind getdimensionalbalance order?
I've tried it with different heights and it was still the same.
My bigest available balance was around 560k tBBP (with getdim... 0 1) and then it goes lower with higher min_coin_amount.
I have more than 8M tBBPs.

Are available for tithing only coins which are "stated" in getdimensionalbalance?
Or can I use all from my balance?
Why I cannot see there all my coins?

EDIT:  Please wait... Let me do some testing on this for a different reason.

Rob how it works behind getdimensionalbalance order?
I've tried it with different heights and it was still the same.
My bigest available balance was around 560k tBBP (with getdim... 0 1) and then it goes lower with higher min_coin_amount.
I have more than 8M tBBPs.

Are available for tithing only coins which are "stated" in getdimensionalbalance?
Or can I use all from my balance?
Why I cannot see there all my coins?

I'm starting to reconcile my testnet balance with exec getdimensionalbalance; but before we start will you please do this:
Write down original balance
Relaunch with "-rescan" (this rescans your wallet transactions)
Go to coin control
Click Tree View
Send yourself some coins to get the transaction count down below 1000 (to make this easier) but ensure each transaction size is less than 100,000 bytes (see the red number in upper left corner)
Ensure your 'exec getdimensionalbalance 0 0' matches your entire Overview page balance

(If the balance changed when you did -rescan then the entire problem was the rescan).

In the mean time, I will attempt to reconcile mine with getdimensional.

I'm starting to reconcile my testnet balance with exec getdimensionalbalance; but before we start will you please do this:
Write down original balance
Relaunch with "-rescan" (this rescans your wallet transactions)
Go to coin control
Click Tree View
Send yourself some coins to get the transaction count down below 1000 (to make this easier) but ensure each transaction size is less than 100,000 bytes (see the red number in upper left corner)
Ensure your 'exec getdimensionalbalance 0 0' matches your entire Overview page balance

(If the balance changed when you did -rescan then the entire problem was the rescan).

In the mean time, I will attempt to reconcile mine with getdimensional.

So, I've made it.
At the beginning balance 8 623 901.99.
After rescan the same. Sent some BBPs to myself to reduce tx number.
Then with 'exec getdimensionalbalance 0 0' result: 668975.
I don't know where is problem. Let it be. Maybe it's only my problem.
Or I can send you my wallet.dat to check it