BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[bible_pay]

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?

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.

[dave_bbp]

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.

Nope, that's not it. Actually the second coin age was even higher. Here's the details:

Code:

  "Command": "getpoints",
  "pog_points": 6732621.631641014,
  "coin_age": 673262.1631641014,
  "diary_entry": "",
  "orphan_donation": 1000

=> POG payment 15k

Code:

  "Command": "getpoints",
  "pog_points": 21944033.90635219,
  "coin_age": 750475.4030584025,
  "diary_entry": "",
  "orphan_donation": 25000

=> POG payment 1.3k

Code:

  "Command": "getpoints",
  "pog_points": 16899955.68905194,
  "coin_age": 577970.3545636164,
  "diary_entry": "",
  "orphan_donation": 25000

=> 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?

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

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.

[MIP]

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.

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

Output from

Code:

uname -a

should be enough for each system.

[dave_bbp]

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.

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

Output from

Code:

uname -a

should be enough for each system.

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:

Code:

Linux odroidc2 4.19.42-meson64 #5.86 SMP PREEMPT Sun May 12 19:04:28 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux

Thx.

[MIP]

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

Code:

Linux odroidc2 4.19.42-meson64 #5.86 SMP PREEMPT Sun May 12 19:04:28 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux

Thx.

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?

[bible_pay]

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

[bible_pay]

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.

Nope, that's not it. Actually the second coin age was even higher. Here's the details:

Code:

  "Command": "getpoints",
  "pog_points": 6732621.631641014,
  "coin_age": 673262.1631641014,
  "diary_entry": "",
  "orphan_donation": 1000

=> POG payment 15k

Code:

  "Command": "getpoints",
  "pog_points": 21944033.90635219,
  "coin_age": 750475.4030584025,
  "diary_entry": "",
  "orphan_donation": 25000

=> POG payment 1.3k

Code:

  "Command": "getpoints",
  "pog_points": 16899955.68905194,
  "coin_age": 577970.3545636164,
  "diary_entry": "",
  "orphan_donation": 25000

=> 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?

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

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.

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.

[bible_pay]

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.

Nope, that's not it. Actually the second coin age was even higher. Here's the details:

Code:

  "Command": "getpoints",
  "pog_points": 6732621.631641014,
  "coin_age": 673262.1631641014,
  "diary_entry": "",
  "orphan_donation": 1000

=> POG payment 15k

Code:

  "Command": "getpoints",
  "pog_points": 21944033.90635219,
  "coin_age": 750475.4030584025,
  "diary_entry": "",
  "orphan_donation": 25000

=> POG payment 1.3k

Code:

  "Command": "getpoints",
  "pog_points": 16899955.68905194,
  "coin_age": 577970.3545636164,
  "diary_entry": "",
  "orphan_donation": 25000

=> 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?

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

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.

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.

[bible_pay]

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

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!

[bible_pay]

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

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.

[dave_bbp]

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:

Code:

"Command": "getpoints",
  "pog_points": 64935191.18979269,
  "coin_age": 6493519.11897927,
  "diary_entry": "",
  "orphan_donation": 1000

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:

Code:

error code: -32601
error message:Method not found
[rest of my password]

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

[bible_pay]

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:

Code:

"Command": "getpoints",
  "pog_points": 64935191.18979269,
  "coin_age": 6493519.11897927,
  "diary_entry": "",
  "orphan_donation": 1000

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:

Code:

error code: -32601
error message:Method not found
[rest of my password]

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

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 <enter>
<Enter password here>

Then step 2:
biblepay-cli autounlockpasswordlength <enter>
<Should report the length of the pass>

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.

[SEO_Account]

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

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.

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

[bible_pay]

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

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.

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

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

[dave_bbp]

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 <enter>
<Enter password here>

Then step 2:
biblepay-cli autounlockpasswordlength <enter>
<Should report the length of the pass>

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.

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.

[seeksilence1]

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.

[inblue]

Prod requires contracts to have at least 20% of the enabled sanc count (thats about 26 now) in order for the GSC to pass.  So that explains the required_votes value.
The reason we end up with barely enough every day is because the sancs are currently programmed to only vote if they need to (IE they check to see if the contract is passing) and ignore it if its already got more than enough votes.  However, they have a very intelligent rule.  If the sanc finds the popular contract hash disagrees with its internal view of the contract it will always vote against the popular one (and then it will create a new one and vote for it).    So remember at the time we had 500+ sancs, I was thinking along the lines of efficiency (IE not to make every sanc do the work if we had 20% in agreement).  I also think with this current logic - the other facet is if the contract changes - the sanc quorum must be nimble enough to make a quick change (and not have to reverse the entire farms votes of 100% being wrong) - since they do actively watch and monitor the voting outcome every 5 blocks, so they *will* jump in and vote for it if necessary.  So Im thinking this is still predominantly good given the volatile potential nature of a competetive change in contract(s).  Now on the downvote, that can happen if the contract changes (like right now we had a leisure upgrade that changed consensus).  You will see the nodes who upgraded will be voting on the new style contract, and the old nodes on the old and only one will win.  (We have a tie breaker piece of code in there also).

I am reading this again for this occasion. So the sancs which did not vote yet should now be voting before the next superblock to ensure that this contract passes, so there should be no concern? I see the votes are steadily increasing closer to the required number.

[bible_pay]

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 <enter>
<Enter password here>

Then step 2:
biblepay-cli autounlockpasswordlength <enter>
<Should report the length of the pass>

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.

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.

10-4 on the trash can.  I just added this to my punchlist and will fix it asap.

[bible_pay]

Prod requires contracts to have at least 20% of the enabled sanc count (thats about 26 now) in order for the GSC to pass.  So that explains the required_votes value.
The reason we end up with barely enough every day is because the sancs are currently programmed to only vote if they need to (IE they check to see if the contract is passing) and ignore it if its already got more than enough votes.  However, they have a very intelligent rule.  If the sanc finds the popular contract hash disagrees with its internal view of the contract it will always vote against the popular one (and then it will create a new one and vote for it).    So remember at the time we had 500+ sancs, I was thinking along the lines of efficiency (IE not to make every sanc do the work if we had 20% in agreement).  I also think with this current logic - the other facet is if the contract changes - the sanc quorum must be nimble enough to make a quick change (and not have to reverse the entire farms votes of 100% being wrong) - since they do actively watch and monitor the voting outcome every 5 blocks, so they *will* jump in and vote for it if necessary.  So Im thinking this is still predominantly good given the volatile potential nature of a competetive change in contract(s).  Now on the downvote, that can happen if the contract changes (like right now we had a leisure upgrade that changed consensus).  You will see the nodes who upgraded will be voting on the new style contract, and the old nodes on the old and only one will win.  (We have a tie breaker piece of code in there also).

I am reading this again for this occasion. So the sancs which did not vote yet should now be voting before the next superblock to ensure that this contract passes, so there should be no concern? I see the votes are steadily increasing closer to the required number.

I think we have a way to make the new contract backward compatible and resolve this for now without a sanc mandatory upgrade tonight. 

(I'm going to add a spork over the next hour that will make the contract backwards compatible with the first version).

Then over the next 10 days we can deal with easing in the new rule that allows smooth transitioning to upgraded business logic.

[bible_pay]

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.

I don't believe coin-control works properly yet - with GSC transmissions, however sending a Diary entry with coin control and Send "may" work, but I haven't specifically tested that (that is only good for HEALING anyway).

But to answer your question, 'exec sendgscc' gives you some control.  It skips over locked coins and sancs.  It does consolidate all applicable coins into one transaction - coins whose coin-age adds up to the "pog_coinagepercentage=.nn" percentage.  So if you set that at .50, it would keep adding inputs that are not locked until half of your coin_age is accumulated in the transaction.