Messages

2791

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 11, 2019, 11:24:13 AM »

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.

2792

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 11, 2019, 09:35:29 AM »

Ok noted. As long as tithing does not require to have full blockchain data loaded, it is possible to implement. Remember that mobile wallet only stores block headers and your own wallet's UTXOs and TXs.

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).

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).

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.

On a different subject, I did comment out the AboutRole and chat now appears; I will be checking in later today (working on the Writing to Orphan UI now).

2793

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 11, 2019, 09:26:25 AM »

11:42:18

exec getdimensionalbalance 0 Largest_Coin


11:42:18

bad lexical cast: source type value could not be interpreted as target (code -1)

I mean to first find your largest coin in Coin Control, then use that number, and that should yield one result and one total.

2794

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 10:36:10 PM »

MIP-

I wanted to make a small record of this so we dont forget - POG should theoretically allow us to help the unbanked - I believe all we need is the current POG difficulty level, a 'pog tithe' button, and the ability for the mobile wallet to send a tithe.  At that point, the user should enter the pog pool.

2795

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 04:14:48 PM »

I forgot to mention all, this 1179 also has a feature that prevents users from accidentally being deemed as an illegal tithe - remember mint pointed out when the block changed the quoted difficulty was still on the screen and the tithe became illegal?  We fixed that in 1179 by quoting the diff 3 blocks back, allowing a tithe to be entered even if late.

So I believe we should not receive any complaints in prod due to that.

2796

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 04:13:01 PM »

Looks good,  I will start working on the web interface for POG, now that things have stabilized (and migrated to a superblock) it should be easier to track.

I will look to add user stats info as well (payments / receipts) and some averages based on history.  I will post requesting feedback as I have something for folks to look at.

Thats great btw, but on a side note, just to clarify, we should never run into a situation where anyone misses a pog payment (if the tithe was legal and they entered the pool).  In this next version, the pog pool should match on everyone synced on the same chain, and therefore each daily superblock will always have all participants (IE no sanc contract is required to be agreed on in this case).  (If pog is off by 1 bbp, the chain will fork to two chains so everyone is technically required to be synced on the same chain).

However your history will still be nice, because pog wont let the user go back (very easily) and see what they missed; although, technically you can type 'pogpool height' and see the stats at prior heights (IE if you miss a day). 

2797

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 04:07:41 PM »

Nice, thanks.
Rob I have other question.
When I try "exec getdimensionalbalance 0 1" it says ""Tithe_Balance_Available": 480898".
Why?
My total balance is over 8M tBBP. Why there are not counted all tBBP'?

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.

2798

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 11:37:10 AM »

Yes that was my opinion...
Sorry if I was not clear

I think you were clear, I was just reading into the prior issue for some reason.  Anyway now they are separated and I think that was a good improvement.

I added the very basic POG Leaderboard last night.

Let me take a look at the entire feature before I do a build as we are close to finishing this version.  I can't think of anything else we are missing in this version.

(Either way Ill do a build sometime today so we can continue testing).

2799

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 11:20:38 AM »

Yeah, I'm not able to force donate too (because of coin age).

And Rob, it would be better to have it separate.
1st checkbox should be "Tithe" (mining) and 2nd checkbox should be "Donation".
And thay can be totaly independent. I think it's not neccessary to check two boxes for donation.

Well I think you mean clicking the Force donation box alone should also populate the foundation address, yes that could be good also (then you can click it alone).
And maybe we re-caption Donate to "POG Tithe".

Ok, Ill look into doing this now.

2800

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 10, 2019, 11:00:18 AM »

To test the functionality, Your Tithe Ability Qty should be 0. Unless you want the ability to bypass PoG also require a certain min coin age. Although, that wouldn't make sense as you'd want to accept donation to foundation (non PoG) not looking at coin age. If your test included Tithe Ability Qty 0, then I may need to test my configuration more to see if I can reproduce your success.

The rule is not this complicated - its just as simple as :  If you want to force a donation to the orphan foundation, click the Force button.

No - your right though, I didnt test it from a machine that had 0 tithability; I was able to reproduce the problem, and now its fixed in the next version.

Thank you for pointing out the flaw.

2801

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 09, 2019, 03:26:49 PM »

Force donation was supposed to allow you to force a donation through, even if you dont want the tithe credit (IE say you want to send 10,000 bbp this month).

I forgot to look at this, checking...

I attempted to reproduce but force worked for me - you have to click on both Donate and Force to force it (not just force), and enter an amount > 300 for example, and it goes through.
If you click just Donate without force, and try > 300 it fails.

2802

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 09, 2019, 03:23:34 PM »

Looks good,  I will start working on the web interface for POG, now that things have stabilized (and migrated to a superblock) it should be easier to track.

I will look to add user stats info as well (payments / receipts) and some averages based on history.  I will post requesting feedback as I have something for folks to look at.

Sounds great!

Yeah, I keep considering adding a UI for QT, but I kept backtracking on that because the 'pogpool' command is pretty simple to understand-but maybe not enough.  Maybe I should make a leaderboard for the UI:

Click POG Leaderboard from QT:
We list Tithers nickname, amount, and pog_pool_weight per row, in descending order, -- that might be cool.
Then a grand total.

Yeah, I think I can squeeze that in next.

2803

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 09, 2019, 03:20:34 PM »

Is Force Donation and Donate to Foundation still two separate options? I should in theory be able to check on Force Donation to donate... but doesn't seem to work for me. If Donate to Foundation works, then Force Donation works... but if Donate to Foundation with max tithe value doesn't work, then Force Donation doesn't work either. I hope I'm explaining this correctly. It was my understanding that Force Donation allows you to donate to foundation without participating in PoG.

Force donation was supposed to allow you to force a donation through, even if you dont want the tithe credit (IE say you want to send 10,000 bbp this month).

I forgot to look at this, checking...

2804

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 09, 2019, 11:58:19 AM »

While I jump back in to look at the state of POG, does anyone have any more last minute considerations for POG?  I have Orbis' recommendations about less exec, and maybe a POG UI grid, other than that any other issues or recommendations for us to add?

It appears everything is working properly now.  When I grep debug.log for SuccessfulCheck I can see all the nodes have been in agreement on this version (with 0 errors on any POG superblock since we upped to 1179) and the training wheels have already been removed - meaning this version is almost Prod ready.  The PODC superblocks are still working and paying the right amount.  The heat mining payments of ~115 appear correct, the masternodes still get paid when they are voted (as I can see some do successfully vote in testnet)- all the amounts appear to be correct.

2805

TestNet Discussion Archive / Re: Testnet - Test Proof of Giving

« on: January 09, 2019, 11:02:27 AM »

Only if  I pass it through command line, not config file. Same happens in Mac, I can try debug it when I find a moment.

BTW, the chat menu is not visible in MacOS, probably because the "About" menu role in QMenu has a special meaning in MacOS GUI (that moves the "about" menu options to the top-left position, besides the system "apple" menu option).

The only way for it to work ok is commenting both lines in src/qt/bitcoingui.cpp

ln 438 // openChatGeneralAction->setMenuRole(QAction::AboutRole);
ln 443 //  openChatPMAction->setMenuRole(QAction::AboutRole);

This way it shows fine as in Win version.

Ok, 10-4 on the chat menu, thanks.  I suppose I can just comment it out.  (On a side note, we appear to have all stayed in sync with POG, which is awesome, meaning we should see in the log the 'Success' for POG recipients, but, we do need a few lines of code added to cover one situation where the user -reindex (es).  Maybe I will team those two things together today.  But these are low priority and only for the release candidate).

On the nickname, btw, I do not have an issue when running from linux either (using the biblepaytest.conf).  What I do is:
cd ~/.biblepaycore
(This is the directory where the debug.log is for PROD).  I place the biblepaytest.conf file in that dir.
Then I start with
./biblepay-qt -conf=biblepaytest.conf
This could be a *mac* only issue then I think.... 
On a side note, maybe try copying the biblepaytest.conf to your Mac prod directory where debug.log is (IE the issue might have been the nomenclature of Prod working dir).