TestNet - PODC 2.0 (Proof of Distributed Computing)

I just tested 5 IX tx's from 100 bbp to 100,000 bbp and they were all successful.

Note that as long as you see the Key and the Check (IX verified) next to the transaction, that is all that needs to be done (and optionally check on the receiving side to verify the IX funds were received).  The QT wallet still goes through the 6 normal confirms before showing "confirmed", but that does not mean IX is taking 6 confirms.  Because stores who accept IS funds have a boolean available to see if the funds were IS sent and they can optionally accept the funds immediately.  Some wait til the funds are IS sent and in a block, but that is up to each retailer.

I believe IX is working properly in testnet.

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

All,

Now that everyone is on the new version, go ahead and pound DWS.
Do whatever you want to try to break it.
It should be able to handle overlimit conditions, and should pay back everything burned each day (as long as the GSCs are voted in).  And on a side note, these have always been voted in prod.  I think we missed 1 in two years (due to having no sancs or something in the middle of PODC 1.0). 

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.

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

{
  "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

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.

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?

No, nothing.  If you type 'exec rac' it should reveal the height in which the daily tx goes out (automatically).

PODC_Height:

When I type exec rac, I don't see podc_height.


I see a next_podc_gsc_transmission. the block is 18347, but I think we are on 18422 (although I could be on the wrong chain).



  "next_podc_gsc_transmission": 18347,

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



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.

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.

i erase the chain started over... now exec rac says


looks like I missed the one in between



"next_podc_gsc_transmission": 18552,

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.

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.

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.

had to erasechain and delete instantsend.dat - settled on 18446. was on 18459



2019-11-26 21:41:27 UpdateTip: new best=8b1ad9df4a08823a7b1cb36c7671d21e8b549334e322ff6e1bfebfaf0e7e8170 height=18459 version=0x20000001 log2_work=46.18226809 tx=29113 date='2019-11-26 21:29:42' progress=0.258118 cache=0.1MiB(897txo) evodb_cache=0.0MiB
2019-11-26 21:41:27 CheckForkWarningConditions: Warning: Found invalid chain which has higher work (at least ~6 blocks worth of work) than our best chain.




If I had the foresight, I would have saved the old instandsend.dat and current so you could do some binary comparison.