Bible Pay

Read 93924 times

  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.



  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.



  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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?



  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more

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.



  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.



  • orbis
  • Full Member

    • 189


    • 6
    • February 08, 2018, 04:37:14 pm
    more
When we are talking about visual. I don't know if it is only my problem, but I'm not able to reduce wallet window size below some px (It is approx 90% of my screen height) And in testnet I'm unable to reduce it below maybe 110% of screen size, so I'm unable to see status bar and I must maximize my window to see everything. I have Win10. It is only my problem or it is common? Is possible to solve it?
I think, that I've found the cause of my problem. I'm using biblepay-taditional as interface theme. When i change interface theme it is no problem to change (decrease) window size. But it is impossible for me to decrease it in biblepay-taditional.


  • orbis
  • Full Member

    • 189


    • 6
    • February 08, 2018, 04:37:14 pm
    more
Yes, could you please be our guinea pig?  Lets just leave it hidden til you reach 0 reward and let us know when that happens (how many hours it took) then unhide it and watch it go back up.
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?


  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.
« Last Edit: February 24, 2018, 09:45:21 am by Rob A. »


  • orbis
  • Full Member

    • 189


    • 6
    • February 08, 2018, 04:37:14 pm
    more
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.
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.


  • T-Mike
  • Administrator

    • 398


    • 2
    • February 06, 2018, 06:12:58 pm
    more

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?

OK, my last superblock payment before I set setgenerate to true was zero. Everything is coming back up now.

Code: [Select]
"Command": "getboincinfo",
  "CPID": "4fd1bf6c6900d92b226e16c6a6935661",
  "Address": "yWQfYmBCAQrcn9RkjM9DJwWGfgjHdvpZwn",
  "CPIDS": "4fd1bf6c6900d92b226e16c6a6935661;",
  "CPID-Age (hours)": 422080,
  "NextSuperblockHeight": 7326,
  "NextSuperblockBudget": 1359680,
  "4fd1bf6c6900d92b226e16c6a6935661_RAC": 823.29,
  "4fd1bf6c6900d92b226e16c6a6935661_TEAM": 15044,
  "4fd1bf6c6900d92b226e16c6a6935661_TaskWeight": 100,
  "4fd1bf6c6900d92b226e16c6a6935661_UTXOWeight": 75,
  "Total_RAC": 823.29,
  "Total Payments (One Day)": 167155,
  "Total Payments (One Week)": 713719,
  "Total Budget (One Day)": 14956480,
  "Total Budget (One Week)": 75693464,
  "Superblock Count (One Week)": 69,
  "Superblock Hit Count (One Week)": 55,
  "Superblock List": "7227,7128,7029,6930,6831,6732,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": 7227,
  "Last Superblock Budget": 1359680,
  "Last Superblock Payment": 33431,
  "Magnitude": 9.429070388428782


  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.


  • orbis
  • Full Member

    • 189


    • 6
    • February 08, 2018, 04:37:14 pm
    more
In the -qt client its easy because its in the txlist. 
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.

In the headless you would have to find a way to run listtransactions with "*" and filter things sent to you.
I run it on my VPS and it gives me this error:
Code: [Select]
error: Error parsing JSON:all_projects_list.xml
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.
OK, i'll be waiting. In less than 3 hours it will be more than 24 hours since "hiding", so we will see.


  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
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.



  • Rob Andrews
  • Administrator

    • 2032


    • 27
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Looking a little closer at these 3 entries:
"04FBA56D89A5EB38B1B82F8A6240132C (02-23-2018 19:26:49)": "75",
  "C9085154B7CC0CA2B5189672559DD6D8 (02-23-2018 19:41:35)": "100",
  "CA895B47AACFFBDBF906201821AF2F9F (02-23-2018 19:41:35)": "100

These 3 are going to expire in 1 hour 45 minutes.
Lets see if they drop off.  Im going to leave my node up and not do anything.
These 3 are Me and Orbis.





  • orbis
  • Full Member

    • 189


    • 6
    • February 08, 2018, 04:37:14 pm
    more
Also, in -qt mode, you must have the PODCUpdate, otherwise we wouldnt be seeing your UTXOWeight.  Maybe you didnt scroll far enough back.

Ouch... I found where was problem :)
I had a filter set up to view only "mined" tx. But i don't know why :) Sorry, my big fault.
Here is my PODC tx:
Code: [Select]
Transaction fee: -0.00177080 tBiblepay
Net amount: -0.00177080 tBiblepay

Height: 6337
Difficulty: 28.704485
Time: 02-23-2018 19:26:49
Subsidy: 590.7047

PODC_UPDATE:
Transaction ID: d292be23f1d21cd688f10878937321dfd4bb331a7276abc6a606edc6e4bd3ff3-000