Messages

1891

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

« on: November 29, 2019, 08:38:42 PM »

I've been following BiblePay for the last 18 months, but if I'm having a difficulty time getting this work... this does not bode well for new members. Maybe I'm just dumb... Usability is critical, but adding complexity has only made the product more difficult to use.


I DMed you my exec rac output.

Obviously PODC 2.0 is supposed to be easier to set up than PODC, so I'm not sure how you can come to that conclusion. 

But a non-working PODC transmission does not equal hard-to-use software. 

1892

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

« on: November 29, 2019, 07:11:10 PM »

i'm giving up. I can't get my cpid registered. tried several times now.


exec rac works but haven't gotten a podc payments for days now.

I will need the full exec associate command you typed so I can reproduce.  Unless you are saying your 'exec associate' was successful days ago, then I only need your CPK and CPID.

And also your CPK and CPID would be helpful.

EDIT:  And also if you successfully performed exec join wcg and also if you successfully performed exec associate, and also your block # and blockhash currently.

Also, what is the last txid of your WCG GSC transmission?

1893

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

« on: November 29, 2019, 10:28:39 AM »

OK, sent a GSC transmission. Required coin-age was 324.976, and I had 200.833. Let's see how it rolls out.

Yeah, I saw yesterday you did have reduced RAC.  1 point in the leaderboard equals 1 rac currently.

1894

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

« on: November 29, 2019, 10:28:04 AM »

couldn't the wallet version be enough to ban sanctuaries not on that version as well?

No, actually, in dashcore, we know both the governance protocol version and the wallet version.
So, no that wont work either.

But I believe the last release did fix it.

1895

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

« on: November 28, 2019, 10:52:42 AM »

Thanks for the funds, Rob ! Otherwise I would have to mine for a couple of days while testing the minimum coinage requirements for a reward 

Do I have to send a manual PODCupdate to show up in the leaderboard?

Sure, and I will reply asap to the message btw.

On appearing in the leaderboard, the researcher will appear about 5 blocks after a PODC transmission is made; but now the way it works is, if you type exec rac, note how it says 18757 is the next wcg transmission (Fixed), add 205 to that, thats when the wallet sends out the PODC transmission automatically.  But, you will have to see if exec rac shows that you have the coin*age. 

So same issue, if you manually type 'sendgscc wcg' now, the coin age will not be sufficient (until you let it grow a little more).  You know we should also tell the user that (duh) upon manually completing that command.  EDIT:  Ok, the next version will actually give you a reply if you don't have enough coin-age, with a warning, explaining that the RAC may be reduced resulting in a lower reward. 

EDIT: But btw, when a user stakes insufficient collateral, we do reverse engineer it down to the amount staked, and lower the leaderboard RAC, so if you want to try now, you can then look at the leaderboard and see a reduced RAC.

1896

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.

1897

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

1898

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.

1899

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?

1900

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.

1901

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.

1902

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.

1903

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

1904

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.

1905

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 .