Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 154. (Read 243386 times)

For pog, can I use the gui to send the gscc so I can control the inputs? Or will the "exec sendgscc" consolidate small amount entries from inputs?

Thanks.

Awesome, now it works as it's supposed to do. I don't think I'll need an extra script for this since I won't use it too often and it's not really complicated once you know the trick. 


On a completely unrelated note: I can't delete workers from my workers list on pool.biblepay.org
There is the "garbage" symbol at the end of the line, but this is not clickable. Tested in Firefox and Vivaldi.

There is a small chance, if I leave everything as-is, and a couple new ones are added, that we would not emit a contract (IE it would get voted down), but our GSC code does have a special condition to handle emergency this type of emergency situation - but I really don't want to test that condition out in prod.

So I'm working on a backup plan now.  If it looks necessary, we can recover by forcing a mandatory sanctuary only upgrade and this would cause certain conditions to occur that would allow the block to pass based on the current contract type.

I also enhanced GSCs rules to allow a more graceful upgrade plan next time (so that the 49-51% type scenario wont threaten us again).

So what happens to the contract if these sancs are not upgraded in time?

Ok - great that you are happy about reconciling the points, awesome!

So on this headless password, sorry, I gave you the wrong info.  We made the first part of it an argument instead, this is to keep it out of the bash log (like FTP clients do).
So please try this (I think special chars will be OK):

biblepay-cli -headlesspassword


Then step 2:
biblepay-cli autounlockpasswordlength


The password that is memorized by the command will be used in the auto-unlock feature.

P.S.  To script this, you can use an FTP-type script.  MIP has one and I have one I could send you if you need it.

Thanks Rob for your dedication! I think I found my mistake now. The moment that I associated my CPK (which I had to unlock my wallet for) the wallet itself sent out my very first GSC Transmission, whose details are:I didn't know this and was therefore confused. Sorry about that.

The new command seems awesome and easy to use, I'll check it out in the upcoming versions.

Regarding the headlesspassword: This doesn't work for me, unfortunately. First, I discovered that the -cli in windows specifically looks for the biblepay.conf in the standard folder, whereas my biblepayevolution folder is located somewhere else. After I copied a dummy .conf to appdata/roaming... it responded fine (e. g. with getinfo etc.), but "headlesspassword" still throws an error:
I think the problem is, that my wallet password contains a special character (followed by [rest of my password]).


@MIP: Don't stress yourself for supporting Armbian, I don't think alot of people use this. Maybe I'll just try Ubuntu on my Odroid, when I have the time ...

If I don't hear back within 24 hours from whoever owns these sancs and we still aren't upgraded by midnight tonight, we will need to have a Mandatory Sanctuary upgrade tomorrow.

This actually works in windows, just go to :
cd c:\program files\biblepay-evolution\daemon
Look for exe "biblepay-cli"

Then run like this (while biblepay-qt is already running in windows):

biblepay-cli getmininginfo

It should respond.  If it throws an RPC error, just add "server=1, rpcuser=youruser, rpcpassword=yourpassword" lines into the biblepay.conf file in windows.

Happy Mining!

So this next command will make analyzing these a lot easier  (this will be in the next relase):

exec analyze 124250 dave_bbp

08:58:01

{
  "Command": "analyze",
  "Totals": "HEALING|BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U|0|0.00000000|dave_bbp|724778\nPOG|BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U|71397967|0.01334747|dave_bbp|5081715323\n",
  "0": "User: BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U, Diary: , Height: 124083.00, TXID: e6f08a34e85b21ff590e9e6a1b389a9e0ff572e626033c32ef3ad760de0af5c4, NickName: dave_bbp, Points: 4130788.55, Campaign: POG, CoinAge: 413078.8549, Donation: 1000.0000, UserTotal: 4130788.55",
  "1": "User: BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U, Diary: , Height: 124099.00, TXID: 503e10c5a24b2dc4a4be9b0a7891b2c3434f4e19fd57352ac6ed4a36ba0fb521, NickName: dave_bbp, Points: 1560104.66, Campaign: POG, CoinAge: 156010.4661, Donation: 1000.0000, UserTotal: 5690893.21",
  "2": "User: BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U, Diary: , Height: 124101.00, TXID: ced211ae7eee0093a7d649f16f2c5454a9b4329a627d60526a8555f957aba85e, NickName: dave_bbp, Points: 43763039.43, Campaign: POG, CoinAge: 4376303.9431, Donation: 1000.0000, UserTotal: 49453932.64",
  "3": "User: BM2e5zvdEf8jcosQdhP6e7NRs8kEMqJy7U, Diary: , Height: 124114.00, TXID: a87676267511f3bb4a7abb4207d9ef361624832ccd38f19de54e20b5e6911fe7, NickName: dave_bbp, Points: 21944033.91, Campaign: POG, CoinAge: 750475.4031, Donation: 25000.0000, UserTotal: 71397966.55",
  
}


Take a look at rows 2 & 3.  These two TXIDs have 43 MM points + 21.9MM points.  You can now see the TXID on the same row.  It appears these had much higher coin-age than the others.


I'll look at biblepay-cli headless next.

1) There is something wrong with your first getpoints query - you were supposed to have 64 million points in your 15,068 reward (not 6,732,621).
2) You made the following rewards per superblock height:
124250 - '71mil points - 1.33% of the superblock - 12,818 reward
124045 '6.7mil points - .14% of the superblock - 1305.25 reward
123840 '64 mil points - 1.64% of the superblock - 15068.12 reward

Notice how the payments correlate to the Prominence % of your points as compared to the total superblock (IE You had 1.6% of the points in the 15K reward, you only had .14% in the 1305.25 reward - you can see its one magnitude less points therefore reward was 10 * lower).  

3)  The points are completely relative to the total points in the block.


4) I don't understand what you mean about "cant see current superblock", the leaderboard is always about 7 blocks behind, taking into consideration unconfirmed tx, etc, I see you have jumped to 3.4k in the current leaderboard.


5)  I will release an analysis command that lets you drill into the historical height and see the details, and the total points in the block.  Then you can see the actual tx that gave you the 64 mil points.  

6) I'll test the biblepay-cli with QT GUI, it should be working.

I have a very important question.

I saw that someone add 60 new sanctuaries over the last 24 hours, and I believe they are installing an older version, below 1.4.3.3. (Probably 1.4.3.1 or 1.4.2.9 from testnet).
(The reason I mention this is those sancs are voting against the current contract).
I was trying to avoid the nuisance of doing a mandatory Sanctuary upgrade (for 21 days like I posted a few pages back) but this is sort of forcing my hand, so I would like to know whats going on.

If you are the one installing 60 new sancs, please upgrade to the latest version today.
If we get a few more upgraded to the old version we will need to force a mandatory Sanc upgrade, so please revert this.

(I upgraded to the latest a few days ago when the code was released to try to make it easy on everyone else - and that held for about 24 hours).

Yep all the binaries are ready for Ubuntu linux (and probably for Debian), but not for armbian. I'll check if I can do something about it.

Edit: from what I read, it should be possible to run ARM version also in armbian. Are you using aarch64 binary? Also, what error is the system showing?

Sorry, for the "normal" Linux I just realized that I got confused with the organization of the downloads on the webpage and apparantly had the wrong one.

For ARM: the new version works if you have Ubuntu for ARM installed, but it fails for armbian:

Thx.

Can you please give me details on which platforms you are executing those binaries respectively?

Output from


should be enough for each system.

Nope, that's not it. Actually the second coin age was even higher. Here's the details:
=> POG payment 15k

=> POG payment 1.3k

=> POG payment unknown right now, but leaderboard shows me with only 0.1 prominence and "owed" 980. [edit: payment was 15.1k, no idea how this had anything to do with what the leaderboard stated earlier ...] If not even the "pog_points" correlate with the reward, then what does?


AFAIK this only works for CLI, but not for the GUI wallet I use in Windows. It only returns "method not found"



Edit: the new Linux binaries don't work anymore. The Arch Linux x64 gives an "error in binary file", the Linux 32 can't even be executed (only gives "no such file or directory"), same goes for the ARM version.

Yes, what you said is correct about 500K * 1 day == 250K * 2 days old, yes.  Yes, on the cubed root, perfect.

Fragmented piles: In GSC, we do the exact math of the vouts, so the internal calculator would do this from your example:
500K*2 = 1 MIL +  2M*5 = 10MM = 11MM of coin age.  Then it would continue to calculate the rest of the Points calculation.
You can probably reconcile this by looking at the vins on a GSC transmission, then type exec getpoints txid and see if it reconciles to your assumption also.

Will be back in a little while, but in the mean time Dave you can do an 'exec getpoints txid' on the first tx, then on the second.
I hypothesize on the first one you had all that unspent coin age (like the guys said here) and on the second you had very little age.

We do have the autounlock feature but its accessed from the command line now:
./biblepay-cli headlesspassword password

In the GSC world we have more a free-floating system where people can donate higher if they want at their own risk; I think it will stabilize once we have more like 500 participants and mature a little more then we will get a hang of what safe values we can tithe (also we will have a stable 24 hour coin age to spend daily by that time).  We can also make a wallet tool to output ROI, that would be a good one.

if i understood it, then # of coins and coin age increasing points linearily
so if you make transaction from 1m instead of 500k, then you will get 2x more points
or if you use coins with age 2 days instead of 1d, then also you will get 2x more points

donation amout is cubed root, so if you donate 1000 instead of 1 bpp, then you will get only 10x more...

but how it works if i have coins fragmented to many piles with different coin ages. for example i make transaction from these coins:
500k with age 2 days
2m with age 5 days

i make donation 1000bbp from amount 2.5m
will it be 500k*2*10 + 2m*5*10 = 10m+ 100m= 110m points?

If you use an excel sheet to plot it out using the formula in the wiki Rob pointed you to, It would appear that any coin age less than one unit (don’t know what the unit is though) actually reduces your points. Maybe someone else can clarify what unit is. Thanks.

it's all about how many coins you have and the coin age difference between 1k donation and 25k donation everything else the same would only increase your points by like 3x i think

if you get 500,000 points from 1k donation getting 1,500,000 points from 25k donation won't help given the current total number of points. also im not sure how it all works exactly but i think the first smaller transactions might've used up some of your coin age as well making the 25k extra not worth it

the formula to calculate points is on this page https://wiki.biblepay.org/Generic_Smart_Contracts