Messages

1891

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 28, 2019, 09:35:35 AM »

I am in with a Gridcoin account. Exponent seems to be working. Here is the output of exec rac:

"Command": "rac",
  "cpid": "82e63a509a38e2201f08c819457df57f",
  "CPK": "ybf862FujX5RZ2G3ENTzNmywA58xkHjL3m",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 18757,
  "team_name": "Gridcoin",
  "researcher_nickname": "amygdala",
  "total_wcg_boinc_credit": 57690.09,
  "total_wcg_points": 403830.63,
  "external_purse_total_coin_age": 0,
  "coin_age_percent_required": 0,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "coin_age_required": 286924.2504116587,
  "wcg_id": 1027347,
  "rac": 2576.941353

Thank you sir,

Do you need any extra tBBP for more testing?
EDIT: I sent you 3 mil.

1892

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 01:42:12 PM »

1.4.8.2 - BiblePay
Mandatory Upgrade for TestNet

- Add Checkpoint at 18610, bump up min_governance_proto_version to 70749, set IX confirms required to 1
- Set GRC Req Researcher coin age to ^1.6, and BBP ^1.3, and reject other teams from the GSC
- During cold boot, reassess chains if necessary, and, during GSC checks (this is after a bad block is received, but no more than once per hour)
- Change the GSC block rejection rule to freeze the network for up to 8 hours if the GSC is not being generated (this keeps forks from forming, and also makes it more lkely to pay all DWSs).
- Remove the monthly superblock from the daily GSC rejection rule
- Remove Log Spam
- Do not reject IX autolock block failures unless the IX block filter is on and the autolocks are on
- Change the DM snapshot size to 205 (BBPs daily block size)

** Ready **

1893

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 12:39:00 PM »

One cannot tell the version of sanc other than if you are in control of the server running the sanc? I thought DIP3 the owner and operator could be separate parties. Surely one should be able to verify that information?

Also in the classic, when a sanc was on a different chain or offline, watchman would cause it to appear in a state other than ENABLED.

I still do not know how PoSE works on DIP3 sancs? Previously they were reported enabled when the servers were off. Then they began to be PoSE banned even though as far as i could tell they were on the same chain. Now even though the 2 sancs were clearly on a different chain, they appeared ENABLED when checked from the sanc on the main testchain.

"One cannot tell the version of sanc other than if you are in control of the server running the sanc? I thought DIP3 the owner and operator could be separate parties. Surely one should be able to verify that information?"
-> No, the only info available to a deterministic viewer, are the fields in 'masternode status' that you see on your own sanc.  Governance protoversion is not one.

Also in the classic, when a sanc was on a different chain or offline, watchman would cause it to appear in a state other than ENABLED.

->  Yes, classic version used pings, and each node kept track of its own status, but in DM, they do not use pings, so all of those fields have been removed.

I still do not know how PoSE works on DIP3 sancs? Previously they were reported enabled when the servers were off. Then they began to be PoSE banned even though as far as i could tell they were on the same chain. Now even though the 2 sancs were clearly on a different chain, they appeared ENABLED when checked from the sanc on the main testchain.

->  You can be POSE banned in DM whether on the right chain or not, as now, POSE works by checking to see if your BLS key signed the current rounds quorum.   So imagine if us three create a secret club, with a seed number, only us 3 can sign with the BLS key and only the insiders will succeed in continuing that quorum for chainlocks.  So POSE is saying:  I will not ban you if you can continue creating good quorums, one per frequency (I think these are roughly one per hour, actually there are 3 frequencies, but for all intents and purposes its about every 7 blocks).

Yeah, I checked also and we cant ban by proto version, but we can kick the sanc out of the quorum, and also offline if they dont have the min protoversion so Im going to go to this method next.

1894

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 12:28:56 PM »

I see one more change that is to be in the next version is increasing the GRC exponent requirement:
https://forum.biblepay.org/index.php?topic=476.new#new

Do we have any volunteer that wants to switch over to team Gridcoin, so we can test the coin-age-requirement is correct in the next version?

1895

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 12:13:43 PM »

2/3 sancs went on a parallel chain diverging at the block 18475, in fact both these appeared to be stuck on the previous block for some time after the two (1 sanc and 1 wallet) already accepted the block.

I left them till block 18514 to see if they will correct themselves but they did not and hence manually intervened to reassesschains.

All 3/3 sancs and the controller wallet have been in sync since block 18514.

Ok, thanks.  I will add a checkpoint, and, I will look into possibilities to prevent this next.
I would like to POSE ban the sancs who are below the minimum governance protocol version, but it looks hard for us to do now, but Im still investigating this among other things.

1896

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 12:08:36 PM »

Togo, the Kanye proposal looks like it will pay this time, please double check @ 18655.

The prior proposal just missed the automatic trigger, but I see the trigger was created this time.

1897

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 08:46:57 AM »

at Block 18514,
exec reassesschains
wait for mnsync status to finish

>cli getblockhash 18514
1f280bd0f1bb8796980493b54ed71c7fb5f35d16400ad0e3f0bca7d774f5e93d

So all wallets are back in sync again.

I was not awake at that particular height, but looking at my 4 wallets (I have 3 sancs) they all agree with your getblockhash 18514.
So the height you mentioned - 18475 - thats right after the last GSC.

Was it just one of your 3 sancs that went out and required manual intervention, and after that, did all 3 stay in sync?

Yes, we really need to get to the root of this and prevent this entirely, it might require me adding a checkpoint and all of us doing some testing from a certain height forward.

1898

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 27, 2019, 08:41:10 AM »

InstantSend (IX) used to say 5 out of 6 confirmations. Now it is just 1 out of 6, but with the key checkbox icon in the column? I notice the transaction line continues to be blue.

That should be OK, there is a separate path in the code for the base confirms - and we can fix the final value, either way the result is the same:
https://forum.biblepay.org/index.php?topic=465.msg6701#msg6701

1899

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 06:15:57 PM »

I kept trying to erasechain but kept getting to a lower block height than you guys
I had to totally nuke my testnet3 folder (delete everything except the biblepay.conf, deterministic.conf, masternode.conf and wallet.dat files)

So now my 2 nodes and my 1 masternode are all synced with oncoapop
https://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml

Yeah, the issue is -erasechain=1 does not erase instantsend.dat.
So I added that into the next version.

Cool that you are synced now.

I suppose we need to find reliability in testnet before we consider this version to be stable.

1900

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 05:40:48 PM »

Thank you, Rob.

Whatever you did appeared to bring some stability to the network as sampled by my VPSs on the testnet chain, after deletion of instantsend.dat, exec reassesschains and waiting for mnsync status to finish.

currently, all my clients and sancs appear to be on the same chain

https://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml

I turned off the IX autolocks spork, then sent out a reconsiderlast 100 blocks spork, and now I see that your sanc page matches my hash also.

Lets let it run on this version overnight, until we surpass the highest bad block that these other straggling nodes have.

Ill keep looking into this issue deeper .

1901

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 04:50:09 PM »

I realized that I reported too soon... reassess got me to a higher height.

Code: [Select]

getblockcount
18380
cli getblockhash 18433
error code: -8
error message:
Block height out of range

cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 65
}
cli mnsync status
{
 "AssetID": 0,
 "AssetName": "MASTERNODE_SYNC_INITIAL",
 "AssetStartTime": 1574804204,
 "Attempt": 0,
 "IsBlockchainSynced": false,
 "IsSynced": false,
 "IsFailed": false
}

wait for sync to complete.

Code: [Select]

cli mnsync status
{
 "AssetID": 999,
 "AssetName": "MASTERNODE_SYNC_FINISHED",
 "AssetStartTime": 1574807022,
 "Attempt": 0,
 "IsBlockchainSynced": true,
 "IsSynced": true,
 "IsFailed": false
}
cli getblockhash 18433
5e76b6e223aafa7ceb64e7bf187454425ba7856828974f05d104ed41d07c4f9d
Getblockcount
18448


Yeah, Im looking through the heights on my node that has 21 connections and everyone is at a different height, so its not the GSC block at all, it points to LLMQ and IX locks.

Unfortunately what it looks like is something like this:
Half of the sancs were forming their own version of the LLMQ quorum, so they have a different cache of IX locks.
The other half, has a different quorum.
The reason I can tell, is I found I can end up on a different height after erasing the chain twice, and, I can see what height some of the sancs are at by looking them up by IP.

This is interesting because it appears that the chain you end up on depends on which governance data you synced from.

So let me look deeper into the issue.  The answer is probably going to be marking a checkpoint block, and then ensuring our LLMQ all adheres to one chain after we upgrade.

This is much more complicated than plain old POW in bitcoin.

1902

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 03:25:04 PM »

I find it very odd that we have 21 testnet nodes, all on the newest version I see.

This last release does not feel right.  After deleting instantsend Im getting different heights now on my sancs.

I'm dissapointed in the latest stable branch.  Right now we are running what Dash prod is running.
Looks like we need to dig deeper into the problem.

1903

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 03:19:59 PM »

other than healing and pog (or dws) which are manual transactions anyways... it makes sense to to add POOM to auto payments like WCG? If the accounting is correct and you trust the oracle data, then I don't think it should matter whether it is BOINC data or POOM data.

Yes, poom makes auto gsc transmissions now, but it requires the transaction fee amount.

All GSCs are sent at the WCG height.

1904

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 02:35:50 PM »

am i on correct chain?

20:59:05

getblockhash 18428


20:59:05

0fa85496c3c05dc10054905e4b0daf41bd4bafdec2f828765a504d992192ecb3


i'm not sure... but i cant do dws. it just do nothing...



21:00:09

exec dws 100000 2 1


21:00:10

{

Code: [Select]

  "Command": "dws",
  "Staking Amount": 100000,
  "Duration": 2,
  "Reclaim Date": "11-28-2019 20:00:10",
  "Return Address": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "DWU": "91.9857",
  "Test Mode": "By typing I_AGREE in uppercase, you agree to the following conditions:\n1.  I AM MAKING A SELF DIRECTED DECISION TO BURN THIS BIBLEPAY, AND DO NOT EXPECT AN INCREASE IN VALUE.\n2.  I HAVE NOT BEEN PROMISED A PROFIT, AND BIBLEPAY IS NOT PROMISING ME ANY HOPES OF PROFIT IN ANY WAY.\n3.  BIBLEPAY IS NOT ACTING AS A COMMON ENTERPRISE OR THIRD PARTY IN THIS ENDEAVOR.\n4.  I HOLD BIBLEPAY AS A HARMLESS UTILITY.\n5.  I REALIZE I AM RISKING 100% OF MY CRYPTO-HOLDINGS BY BURNING IT, AND BIBLEPAY IS NOT OBLIGATED TO REFUND MY CRYPTO-HOLDINGS OR GIVE ME ANY REWARD."
}

and no tx created

First I think you are on the wrong chain - not your fault, most likely this IX issue.  Please delete "testnet3/instantsend.dat" then restart, then type exec reassesschains?

Then check to see the hash matches the oncapop hash?

As far as the burn itself, you have to add "I_AGREE" to the last param to get it to go, otherwise it just prints out the current quote.
So that part is OK.

1905

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 02:33:05 PM »

Don’t know how long I have to wait after reassesschains.

VPS1

Code: [Select]

cligetblockcount
18431
cli getblockhash 18431
7a28fc55fb6ac41d1987c2b93d093d8302526b63ef4a26ea67547aaeb895e14b
cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 11
}
cli getblockcount
18433
cli getblockhash 18433
5e76b6e223aafa7ceb64e7bf187454425ba7856828974f05d104ed41d07c4f9d

VPS2

Code: [Select]

cli getblockcount
18446
cli getblockhash 18431
3ee3f6e9dae4761c0f4f90707dd928bb5b336a470f9ca430f983bb54e48290f2
rm ~/.biblepayevolution/instantsend.dat

cli exec reassesschains
{
 "Command": "reassesschains",
 "progress": 69
}
cli getblockcount
18447
cli getblockhash 18431
3ee3f6e9dae4761c0f4f90707dd928bb5b336a470f9ca430f983bb54e48290f2
cli getblockhash 18433
b8b7e44b896afceda97a4bfa20c187db4ec582b61be6942028d096855ae0399f



Ok, I think we are on to something.
Your second node is now in sync with my nodes  - getblockhash 18433:
b8b7e44b896afceda97a4bfa20c187db4ec582b61be6942028d096855ae0399f


Try this now on the first node:

Stop it
then delete
~/.biblepayevolution/testnet3/instantsend.dat
Restart it
then exec reassesschains
And see if it matches?


On a side note guys, I found out that Dash prod is using the switch IX_LLMQ_BASED , and we were not.
So I am setting that now, to enable it .

Lets go in baby steps 2, first Oncoapop, please tell me what hapens with this one, then we can regroup.