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 - Rob Andrews

Pages: 1 ... 120 121 122 123 124 125 126 [127] 128 129 130 131 132 133 134 ... 262
1891
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?


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


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




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


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

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.




1896
Archived Proposals / Re: Dynamic Whale Staking
« on: November 26, 2019, 08:50:29 AM »

Do you feel investors will feel comfortable losing control over their coins by burning to an address they do not own? It is quite nerve racking to lose your coins, then wait and hope the code will send you back the original plus reward. Don't you want investors to feel safer by keeping funds in the wallet and time locking it via a smart contract? This is what Dai Savings Rate (DSR) does (https://web.archive.org/web/20190730215041/https://medium.com/makerdao/dai-reward-rate-earn-a-reward-from-holding-dai-10a07f52f3cf) and I feel a lot safer with a mechanism like this than "burning" and "unburning". In the end, both methods keep supply locked up and Dai Savings Rate feels much safer to investors than Dynamic Whale Staking.

I suppose with all the projects going on, and prioritization of gospel features, it would be quite impossible to do both and also to integrate in a new ecosystem, add smart contracts, and add a couple more developers to help me code review that release and verify it was successfuly integrated; so at this time my best advice is to not use DWS if you feel uncomfortable.


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


1898
We seem to get a fork at the GSC height after every mandatory upgrade.

I have a hypothesis for this:  When I put it out it usually takes 12 hours for MIP to compile it, and then maybe about 24 hours longer for the sancs to upgrade.
During that span, if we miss the "common voting" on the GSC contract, this causes the POW miners to mine a POW block in place of the gsc.

Other miners probably mine their own view of a block with the GSC voted in - hard to say which side of the network wins.

Then we all resync and end up on the chain with the most work.
I am still thinking about this dirtyblockindex; not sure if its doing more harm than good for us.  It is the reason we need to resync when our node has one bad block in the chain.

Ill talk to MIP about this logic.


So as we get a little more complicated our checklist is increasing.

In my case, I was able to overcome the fork by doing this:

rm instantsend.dat
restart client
exec reassesschains


The problem was the instantsend transmissions done between mandatory upgrades were memorized as IX locks.

Now my 3 sancs are syncing to the same height.



1899
sorry guys, i dont have time now, i'm redesigning house so whole day without pc ... :D
but i think i'm on some fork now... downloaded new version and did reindex, will see tomorrow...

We seem to get a fork at the GSC height after every mandatory upgrade.

I have a hypothesis for this:  When I put it out it usually takes 12 hours for MIP to compile it, and then maybe about 24 hours longer for the sancs to upgrade.
During that span, if we miss the "common voting" on the GSC contract, this causes the POW miners to mine a POW block in place of the gsc.

Other miners probably mine their own view of a block with the GSC voted in - hard to say which side of the network wins.

Then we all resync and end up on the chain with the most work.
I am still thinking about this dirtyblockindex; not sure if its doing more harm than good for us.  It is the reason we need to resync when our node has one bad block in the chain.

Ill talk to MIP about this logic.


1900
did we need something in our biblepay.conf to send out wcg tx regularly?

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

PODC_Height:

1901
Will we have InstantSend default or ChainLocks in the recent merges?

Yes, now InstantSend autolocks is on by default, and also, chainlocks is on permanently now (in testnet).

But all sancs need to be on the highest protoversion first, and I see one of my sancs failed to upgrade.

Lets re-test hashes once we all do that, lets post here if your sanc is running 1.4.8.1.

1902
Hi all,
I was out for a moment, but it looks, that it's all working good for me.
What is needed to test? Some special scenarios? (but except MN)
It looks that taking tBBP to WCG only from CPK address is working for me good.
But I don't know if it's instantsend working good.
When I sent tBBP to myself, it everytime needs 6 block to confirm.
BTW. It'

We need to verify the sancs have upgraded before we re-test IX.

These sancs who are running a lower protocol version will refuse to handle the IX request.

You can also help by verifying that we covered the other test cases in post #2.  I think you can safely skip by Kairos for now, as Kairos is about to go online in testnet with Andys side, so dont test that and also dont test Cameroon One.


1903
I'm still having same issue with mixing, cant find random masternode

https://github.com/biblepay/biblepay-evolution/blob/develop/src/privatesend-client.cpp#L1170

https://github.com/biblepay/biblepay-evolution/blob/develop/src/privatesend-client.cpp#L1040

How does vecMasternodesUsed variable work?

Code: [Select]
int nCountEnabled = mnList.GetValidMNsCount();
int nCountNotExcluded = nCountEnabled - vecMasternodesUsed.size();

LogPrintf("CPrivateSendClientManager::%s -- %d enabled masternodes, %d masternodes to choose from\n", __func__, nCountEnabled, nCountNotExcluded);

We first need to verify every sanctuary upgraded to the new version, then we can re-try private send mixing.

I recommend trying the mixing from a new wallet (so we dont intermingle the new external purse and PODC testing with this).


1904
BiblePay - TestNet
1.4.8.1 - Mandatory Upgrade for TestNet


- Update private send denominations
- Ensure exec bankroll spends coins with depth > 0
- Release dash 0.14.0.4 :  https://blog.dash.org/product-update-november-22-2019-1dc02575ce58

** This is the windows release only. **

1905
BiblePay
1.4.7.9 - Mandatory Upgrade for TestNet

- Fix privatesend denominations mismatch, and increase privatesend defaults, and allow up to 5mil instandsend in the QT gui
- Increase solominer's efficiency, to approx 90% of the external miner
- Improve instantiation of a new DWS to be atomic.  Ensure all nodes assess the DWS metrics live (from the memory pool).
- Free up RAM used by Pobh.h for MIP

* This is the windows release; MIP will be compiling all the rest asap.  Please post when ready, MIP.


Just to save everyones time:  Dash just released two PrivateSend fixes into prod that are required to be merged in, so please don't test this version of privatesend. 


A new version should be out within 2 days.


Pages: 1 ... 120 121 122 123 124 125 126 [127] 128 129 130 131 132 133 134 ... 262