Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob A.

Pages: [1] 2 3 4 5 6 7 8 ... 45
1
Maybe it is easy, but I haven't any tx like this imy tx list. There are only two types of tx: mined block and superblock reward, like you can see im my tx export.
I run it on my VPS and it gives me this error:
Code: [Select]
error: Error parsing JSON:all_projects_list.xmlOK, i'll be waiting. In less than 3 hours it will be more than 24 hours since "hiding", so we will see.

No, listtransactions works:
listtransactions "*"
(No json error)

Also, in -qt mode, you must have the PODCUpdate, otherwise we wouldnt be seeing your UTXOWeight.  Maybe you didnt scroll far enough back.


2
Rob, I'm sorry, but I'm not able to find that PODC update block number. I watched all of my superblock tx, but I didn't found there something like that. How can I find it? I'm sending you my tx export, if it helps.

In the -qt client its easy because its in the txlist.  In the headless you would have to find a way to run listtransactions with "*" and filter things sent to you.

Instead of doing all that lets leapfrog forward and just improve the tools we have in PODC because I think we will need them.

Im adding timestamps to some of the tools now to ensure the network datavalues are : A) Getting cleared so that we dont bloat the users memory over time, and B) are actually clearing after 24 hours for a PODC consensus.

So far I have added this timestamp:


11:00:35

exec datalist utxoweight


11:00:35

{
  "DataList": "UTXOWEIGHT",
  "04FBA56D89A5EB38B1B82F8A6240132C (02-23-2018 19:26:49)": "75",
  "4FD1BF6C6900D92B226E16C6A6935661 (02-24-2018 13:23:45)": "75",
  "6785DED1F65063EF8F01F42DEB31CF1D (02-24-2018 13:54:18)": "100",
  "71F1F1F46DEB2F25961C7D9AF06F2B31 (02-24-2018 00:15:48)": "100",
  "93138F032BDD027FA3246B48BB715A77 (02-24-2018 16:51:54)": "100",
  "95A79CD5829E8315B0B946709930DF18 (02-24-2018 15:21:23)": "100",
  "C9085154B7CC0CA2B5189672559DD6D8 (02-23-2018 19:41:35)": "100",
  "CA895B47AACFFBDBF906201821AF2F9F (02-23-2018 19:41:35)": "100",
  "CC37D0EF74A621379974484F43D3B1C5 (02-24-2018 14:52:32)": "100",
  "D9B22FCCFAE5582D4EE7838883AAA3CF (02-24-2018 15:07:13)": "75",
  "E7AE6ABD6284B05F3FD5F7C780E60BC7 (02-24-2018 13:35:32)": "100",
  "E94C1704C75F731F8BFDE303F08408EE (02-24-2018 14:20:35)": "100",
  "F80AB050AB53459EC937879A046D603E (02-24-2018 10:43:28)": "100"
}



But now I need to do some more work to check the values.

3
It is more almost 20 hours since I hid my PCs but nothing has changed till now. My taskweight and UTXO are the same. PoC payment was decreased (but it is caused my UTXO fell to 75 before). And my magnitude is still rising. You were writting that it should change after approx. 8 hours, but nothing happens till now. Is it OK?

Lets wait the full 24 hours to see your magnitude go to zero.
I see exec leaderboard still shows your 04fb* CPID to have a magnitude of 37.1, and my sanctuary shows you with a UTXO weight of 75 and taskweight of 100.  Id like to see those show as zero before you change your settings to unhide the machines.

In the mean time can you give us the blocknumber that your PODC update was sent out on?  You can see it in the transaction list.

EDIT:  The 8 hours is when the client tries to send more updates (thats called a PODC Update).  The 24 hours is when the network loses your records.  Lets try to make distinctions between those things.

4
Great! I must say beforehand: Both AMD rigs I was telling you about were using the windows wallet. Looking back, could it be possible that the windows wallet (pre 1094c) wasn't using the 250ms setting yet?

Because just now I tested the new wallet on my linux rig, and out of the box (250ms) the cpu usage is already much lower than before. When I set it to 0ms it's back up to it's old values again.

I now set it to 500ms, and I'm able to get BOINC running along nicely while also mining (it's a véry slow AMD E-450 laptop) . I think it's great to have a 'one-go-solution' to tweaking the settings so that BOINC and one-thread-mining can go hand in hand, because I can imagine that a lot of people will be using only one computer to generate BBP.

Great on the improved results!

Yes, before it was definitely true both win & linux were not sleeping the full default value, primarily because the nonce break didnt allow the wallet to sleep when it was told to.  Now in 1094c+, the windows wallet looks for its &HFF nonce break (thats about 256 hashes) and does what it is programmed to.

Yes, I agree I think if we can make some intelligent decisions then using biblepay will be more like using an iPhone.  My old boss used to say Oh that was a developer decision (implying that it was a horrible decision).  I agree that there are a lot of brainless decision out there that creep in from crazy PR discussions.


5

But to answer your question more specifically, since you left podcupdates off, which is good so we can see the effects of it, you were asking why is my magnitude still 8 in getboincinfo?  Its because getboincinfo takes the last 7 days of magnitude-payments and averages them to be your Last 7 Day mag.

However your exec leaderboard should show you dropped out of the leaderboard with 0 mag. 

Also your exec getboincinfo  Last superblock payment should be 0.  <- Thats a good test, please see if you missed out on a research payment in a block where others have received research payments?


I think Ill add 24 hour magnitude and 7 day magnitude in exec getboincinfo, to make this clear.

The UI shows the 7 day magnitude value, for smoothing.

Then the user will see trends more clearly.


6
I know this is going to sound a little complicated.. and Im thinking of ways to simplify this but with advanced system comes some advanced business logic:

The getboinc info values are current as of right now, so this is what Your client feels your RAC and your UTXOWeight and your TaskWeight are right now.  However, it takes a while for those to propagate through into the Sancs memory.  Because the Sanc has to allow 6 confirms for utxo weight in order to trust it and memorize it (it memorizes each cpids utxo weight into memory with a global key, called CPID_UTXOWeight_ with a 24 hour deadline on the timestamp, where new stamps erase old stamps, so its a complicated thing to explain).  This way all sancs are memorizing the utxo weight and task weight at the same time - all their memories should be equal.  They actually vote on what *they* agree on.

Now the Magnitude in getboincinfo is actually your reverse engineered magnitude over 7 days period. 
Your Superblock magnitude however , seen in exec leaderboard, is actually your "realized" mag as of the last superblock.

So from a cosmetic point of view, Im working on homogenizing this to just give the average biblepay-qt user a few numbers to look at on the GUI.

For the techies though, this means:  Your getboinc info is current debug info, but what the sancs vote on (they are always voting on the Next contract) is slightly different, as their memories are lagging slightly.

To see what a sanc *will* be voting on, go to one of your sancs and type exec testvote.  That particular contract can be dissected to see what they see about the network.


But to answer your question more specifically, since you left podcupdates off, which is good so we can see the effects of it, you were asking why is my magnitude still 8 in getboincinfo?  Its because getboincinfo takes the last 7 days of magnitude-payments and averages them to be your Last 7 Day mag.

However your exec leaderboard should show you dropped out of the leaderboard with 0 mag. 

Also your exec getboincinfo  Last superblock payment should be 0.  <- Thats a good test, please see if you missed out on a research payment in a block where others have received research payments?


7
No wonder I was so confused!  I made the assumption the code was still working the way it was when I tested it last week.
So anyway when I added the podcupdate feature, it broke a couple of the return codes (or circumstances) inside the 'éxec  associate' feature.  So those are now fixed, and now people will see "ALREADY_IN_CHAIN" or "INVALID_CREDENTIALS" during the proper circumstances, in the next version.

Im checking in 1.0.9.4d now for linux if anyone wants to test that tonight.   Starting windows build over.

Lets check this out tomorrow when we have a chance to ensure reassociation works now.

Thanks for pointing out this bug!
1.0.9.4d for windows is now out there, if anyone was experiencing the Invalid Credentials bug or the miner-cpu-usage issue.


8
If Taskweight and UXTOweight are zero, should my magnitude be zero? I forgot to turn PoBH on.
Code: [Select]
"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 14328660.49245012,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 6700,
  "timeoffset": 0,
  "connections": 12,
  "proxy": "",
  "difficulty": 0.2833186345714879,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

"Command": "getboincinfo",
  "CPID": "4fd1bf6c6900d92b226e16c6a6935661",
  "Address": "yWQfYmBCAQrcn9RkjM9DJwWGfgjHdvpZwn",
  "CPIDS": "4fd1bf6c6900d92b226e16c6a6935661;",
  "CPID-Age (hours)": 422068,
  "NextSuperblockHeight": 6732,
  "NextSuperblockBudget": 1359680,
  "4fd1bf6c6900d92b226e16c6a6935661_RAC": 820.6,
  "4fd1bf6c6900d92b226e16c6a6935661_TEAM": 15044,
  "4fd1bf6c6900d92b226e16c6a6935661_TaskWeight": 0,
  "4fd1bf6c6900d92b226e16c6a6935661_UTXOWeight": 0,
  "Total_RAC": 820.6,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 546564,
  "Total Budget (One Day)": 13700330,
  "Total Budget (One Week)": 67535384,
  "Superblock Count (One Week)": 63,
  "Superblock Hit Count (One Week)": 49,
  "Superblock List": "6633,6534,6435,6336,6237,6138,6039,5940,5841,5742,5643,5544,5445,5346,5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 6633,
  "Last Superblock Budget": 1359680,
  "Last Superblock Payment": 0,
  "Magnitude": 8.09300203283067

I know this is going to sound a little complicated.. and Im thinking of ways to simplify this but with advanced system comes some advanced business logic:

The getboinc info values are current as of right now, so this is what Your client feels your RAC and your UTXOWeight and your TaskWeight are right now.  However, it takes a while for those to propagate through into the Sancs memory.  Because the Sanc has to allow 6 confirms for utxo weight in order to trust it and memorize it (it memorizes each cpids utxo weight into memory with a global key, called CPID_UTXOWeight_ with a 24 hour deadline on the timestamp, where new stamps erase old stamps, so its a complicated thing to explain).  This way all sancs are memorizing the utxo weight and task weight at the same time - all their memories should be equal.  They actually vote on what *they* agree on.

Now the Magnitude in getboincinfo is actually your reverse engineered magnitude over 7 days period. 
Your Superblock magnitude however , seen in exec leaderboard, is actually your "realized" mag as of the last superblock.

So from a cosmetic point of view, Im working on homogenizing this to just give the average biblepay-qt user a few numbers to look at on the GUI.

For the techies though, this means:  Your getboinc info is current debug info, but what the sancs vote on (they are always voting on the Next contract) is slightly different, as their memories are lagging slightly.

To see what a sanc *will* be voting on, go to one of your sancs and type exec testvote.  That particular contract can be dissected to see what they see about the network.


9
Yes, I tried exec asssociate with and without force multiple times and it continued "INVALID_CREDENTIALS", both when manually typing and cut and paste from the original file I used as well as trying the form on the main wallet as well as debug.  I didn't understand what you meant by "retry association" on [email protected] site, didn't see a link that was similar to that which is why I tried Quit and Rejoin Team Biblepay.

The only solution was restoring an old wallet backup from my testnet backups I maintain, works fine.  So not sure if there is a bug out there or if doing what you intended with retry association would have been sufficient but thought you should know.
No wonder I was so confused!  I made the assumption the code was still working the way it was when I tested it last week.
So anyway when I added the podcupdate feature, it broke a couple of the return codes (or circumstances) inside the 'éxec  associate' feature.  So those are now fixed, and now people will see "ALREADY_IN_CHAIN" or "INVALID_CREDENTIALS" during the proper circumstances, in the next version.

Im checking in 1.0.9.4d now for linux if anyone wants to test that tonight.   Starting windows build over.

Lets check this out tomorrow when we have a chance to ensure reassociation works now.

Thanks for pointing out this bug!


10
Yes, I tried exec asssociate with and without force multiple times and it continued "INVALID_CREDENTIALS", both when manually typing and cut and paste from the original file I used as well as trying the form on the main wallet as well as debug.  I didn't understand what you meant by "retry association" on [email protected] site, didn't see a link that was similar to that which is why I tried Quit and Rejoin Team Biblepay.

The only solution was restoring an old wallet backup from my testnet backups I maintain, works fine.  So not sure if there is a bug out there or if doing what you intended with retry association would have been sufficient but thought you should know.

Oh your right, I just reproduced that with my cpid, something changed.

Let me debug that problem next...


11
That was actually one of my ARM single-board computers. Not an Android mobile or tablet. But since it is running Linux, although I was able to connect it to [email protected], I wasn't able to solve any task with it, since Rosetta does not support ARM on Linux (other boinc projects do). And I tried very hard :-)

In general, you cannot assume that any ARM processor is a mobile or tablet: there are very high-performance multicore ARM servers (e.g. https://cavium.com/product-thunderx-arm-processors.html), there is even a 99$ ARM notebook (https://www.pine64.org/?page_id=3707).

BUT, the fact that you cannot leverage Linux-based ARM machine in Rosetta protects us a bit.

Ok great, thanks!  Yeah, I added that ARM (with blank proc) to the list in a way that it wouldnt disqualify you as an unbanked individual.
Regarding someone with only arms, and running in high power mode with the benefit of no controller wallet, I think all they really gain is not having a controller wallet anyway, so big deal, as long as we get our 98% integrity rating for the rest of the farm, Im ok with that :).  But if you guys see any heinous advantage, please, raise it as an issue and we can then put a Magnitude limit on the ünbanked CPIDs.  Those ARM tablets still only receive the same compensation as the banked cpids, (except they arent staking any capital so they get a free 100% utxo weight).


12
Update on the next version - 1094c:

So I did a lot of expirimentation with the threading today, and have come to the conlcusion Jaap had a point, the wallet was using too much power even with the new settings in distributedcomputing mode.

So what I have done is in Distributed Computing mode the miner behaves slightly differently (in the next release).  It respects the CPU's thread priority meaning that it can run slower, and we now allow you to tweak the setting.

There will be a new setting called minersleep (the default is 0 for Prod and 250ms for Testnet).  If you set a numeric value you override it.
Now Im seeing about 10% proc usage by default, and when I raise the value, it does allow the machine to sleep more (down to more like 4% or so).

1094c is now out there for linux if anyone wants to expiriment.  This is a pretty minor change, so if you want to wait for the next release its no big deal.

Im compiling Windows now so we will have this to play with later tonight.

PS I did get the unbanked report working for the sanctuary validation system in unit test mode, but its not going to be ready til sometime tomorrow.


13
One suggestion for the wallet to improve readability.  Could there be different mining categories?  So a Bible Icon for PoBH, a Church Icon for Sanctuaries and perhaps the atom (?) icon for PoDC?  And perhaps allow for these each to be shown  collectively under mining but also broken down by subcategory?

Icon's would definitely be nice.  That would be a nice cosmetic addition to the wallet.

Maybe you can reach out to Togo and see what kind of help he needs in recruiting a co-developer so we can have a dedicated testnet branch with features like that merged in for testing?


14
So I wasn't sure where"retry association" was, so I quit Team Biblepay, then rejoined.  But the error continued.  I was able to restore a previous wallet.dat file and it is correctly associated, but am unclear why the process would have failed on a new wallet (which is an unlikely situation to be in but...)

You won't have to ever quit Team Biblepay, it won't change any association business logic.
"The error continued", you mean Invalid Credentials?  - Answered Earlier.
If you change wallets, you should receive an "ALREADY IN CHAIN" message, once you enter the correct credentials.


15
I had an issue with my wallet, it kept crashing, tried all the normal recovery steps and nothing worked.  Since it was a pure test wallet, I ended up downloading a fresh copy of the biblepay client and cleaned out all files in the biblepaycore window (including my wallet).  After installing, mining a block and waiting for it to mature, I tried exec associate email pass and it responded "INVALID_CREDENTIALS", adding force to the end of the command did not change it.
Invalid credentials means the credentials are not correct.  Try logging into the web portal first, then retry association. 
Btw, if you keep a copy of your wallet.dat, you will not need to reassociate.

EDIT: Force is only required if you receive the error: ALREADY IN CHAIN.



Pages: [1] 2 3 4 5 6 7 8 ... 45