Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - oncoapop

Pages: 1 2 3 4 [5] 6 7 8 9 10 11 12
61
Unfortunately, Dash took out the masternode version in the deterministic branch, so now we have no way to tell what version they are running.

I tried to put it back in 'masternodelist all', but it is actually missing everywhere in the code.

10-4 on the upgrade speed; Im pretty much in the same boat with my QT sancs, because I self compile and it puts a strain on this small hosting companies server.

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.

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

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.

63
Hmm, blockhashes appear to diverge from block 18475 on testchain. No intervention on my part.

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

>cli getblockhash 18514
1f280bd0f1bb8796980493b54ed71c7fb5f35d16400ad0e3f0bca7d774f5e93d

So all wallets are back in sync again.

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

Hmm, blockhashes appear to diverge from block 18475 on testchain. No intervention on my part.

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

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






66
After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.

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


67
After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.

Sorry i meant instantsend.

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

After deleting instandsend.dat, and restarting I can only get to height 18380 even after reassesschains.


69
Well although we lost some of the fields, I do think there will be alternatives to the same info for example we have to consider these LLMQ quorums are only supposed to work within the quorum group themself who are creating the quorum from the currently allowed protoversion (another words, after a mandatory, when I increase the minimum govnance version, only those sancs can participate in the LLMQ, so theoretically, the lower sancs would fall out of the quorum and get POSE banned).

But first could we check those two as guinea pigs that have the wrong hashes?  Id really like to get to the root of the problem so we can always blame it on one specific thing.  Up til today, I blamed a chain fork on failure to pass the last gsc height.  It was not til this version where I saw all these instantsend autolock failures.

Could you please try this:
On one, try 'exec reassesschains' and on the other, delete the instantsend.dat, then try exec reassesschains?  Lets see what fixes each one?

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




70
So in the spirit of my last bitcointalk post, I feel God wants me to focus in on giving the users the ability to : instantiate a treasure trove item, and see the list of treasure trove videos that have been archived (with high scalability).  I have a plan to offer very high scalability even with our feeble network.  Basically I plan on making a cloudflare account, and through some type of abstraction we will give the ability to archive a copy of a youtube Christian video (with permission) into a cloudflare servers mp4 storage "stream" version, so we can host the cloudflare version through DSQL.  This would theoretically stay live even if google or youtube goes down - since the idea with cloudflare is to be part of the backbone of the net.  More on this later.

But first, the highest priority.  I feel like Satan has been running rampant through this project trying to paralyze us.  I saw all these issues over the last few days, with sancs going into new start required, with gobject propagation appearing to be on the feeble side, with the bad sanc list increasing in prod (now fixed), and just in general, things I feel should not be happening in prod.

This leads me to the state we are in- we must have a solid future version that is fork free permanently, that has perfect GSC blocks, perfect gobject propagation, and none of these sanctuary expired issues, or instantsend problems etc.

So, I feel we really must slow down and fix this right now, as production support and maintenance stops new development (and gives us a black eye) etc.

In light of this Im going to stop everything to take a look again at gobject propagation, superblock heights, and how we make the calls.
What I really would like to see, is the ability for our nodes to recover by themselves onto the chain with the most work.
Im questioning whether this dirty block index rule is doing more harm than good.

My goal is to add some code to testnet that can theoretically handle a situation for example, a mandatory upgrade, where the node can auto-recover after the supermajority upgrades (in contrast to sitting on a private chain, due to having a bad block in memory).

I do support slowing down. When I upgraded all my sancs and clients were on the same testnet chain.

Today two were not running when I checked and the others were on different hashes for the same block but all sancs still appeared to be enabled on the masternode list. It should noted that previous versions could be left unattended for days.

Maybe its my VPS machines, I cannot tell, but stability has be altered since the last upgrade, whether it is due to the temporal instability in network, I cannot conclude either as there is no way I can discern the state of the network beyond the servers I control.

In addition the masternode list currently is in contrast to the non DIP3 sanc situation where the state of the network could be quickly and rather accurately discerned from the masternode list.

71
Ok, my 3 sancs are on 1.4.8.1 now;  if we can get a confirmation that Oncoapops are on 1.4.8.1 then I think we can test IX and PS.

My 3 sancs are on 1.4.8.1
As you previously observed, my sancs are all running Linux and it does take time for the linux binaries to be available for download. My machines are also not powerful ones so they take an age to compile them from source. With all these said, mine are now current.

Is there a command to see which version the sancs are running without logging into the sancs themselves? Like version report for sancs?

72
Yes thats interesting, because we do support the storage of unicode in BiblePay, and, QT can display the characters.

My wife said the sentence was probably missing this word : 没有   (Which I believe is NO).  That makes the entry Ephesians 5:3 right?
There should be no mention of sin, impurity of any kind or greed even mentioned among us - as we become saints?  Ill have to try to reproduce; maybe when you get a chance try to expiriment by breaking it up into two sentence etc.

Yes that’s the verse! Is your wife Chinese?

73
I pasted the Chinese script from a bible verse into the diary entry and it appears to work with only one malformed  character.

74
Did you do a ‘exec join cameroon-one’ ?
And a ‘exec join kairos’? I noticed that it allows us to contribute to the gscc project with having officially joined it and hence you won’t receive rewards for it.

Sorry.... it should say “allows us to contribute without officially joining”...

75

23:13:54

{
  "List Of": "POOM Children",
  "Charity": "cameroon-one",
  "Child ID": "6d9e2b38",
  "CPK": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Biography": "https://biblepay.cameroonone.org/bios/6d9e2b38.htm",
  "Balance": -44,
  "Notes": "Good job, nothing due!",
  "---------": "--------------------------------------------------",
  "Charity": "kairos",
  "Child ID": "ad7ec463",
  "CPK": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Biography": "https://kairoschildrensfund.com/bios/ad7ec463.htm",
  "Balance": -60,
  "Notes": "Good job, nothing due!",
  "---------": "--------------------------------------------------"
}

23:15:01

sendgscc kairos


23:15:01

{
  "Error!": "Sorry, CPK is not enrolled in project. [User is not enrolled in CPK-KAIROS.].  Error 795. "
}


23:15:19

sendgscc cameroon-one


23:15:19

{
  "Error!": "Sorry, CPK is not enrolled in project. [User is not enrolled in CPK-CAMEROON-ONE.].  Error 795. "
}

Did you do a ‘exec join cameroon-one’ ?
And a ‘exec join kairos’? I noticed that it allows us to contribute to the gscc project with having officially joined it and hence you won’t receive rewards for it.

Pages: 1 2 3 4 [5] 6 7 8 9 10 11 12