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 ... 121 122 123 124 125 126 127 [128] 129 130 131 132 133 134 135 ... 262
1906
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.



1907
I couldn't do mixing with my 1 masternode server, it gives an error, I guess masternodes cant mix?,
"client side mixing is not supported on masternodes"
so I have it down while I use another data directory and wallet for mixing,
in addition I also spun up 2 other servers

I'm getting this message on all 3 servers:

Code: [Select]
2019-11-23 19:42:35 CPrivateSendClientManager::GetRandomNotUsedMasternode -- 7 enabled masternodes, 0 masternodes to choose from
2019-11-23 19:42:35 CPrivateSendClientSession::StartNewQueue -- Can't find random masternode!

biblepay.conf settings:
Code: [Select]
enableprivatesend=1
privatesendamount=1000000
privatesendrounds=2
privatesendmultisession=1

Ok, I see the problem.

Yes, we need a fix for this, and I have a couple more rules I added in for DWS; and something is coming for POBH in testnet ;

Please let me release a new release.



1908
Archived Proposals / Re: PODC TEAM REQUIREMENTS
« on: November 22, 2019, 04:16:23 PM »
We don't have to think in binary terms. How about different exponential coefficients for BBP members and non-BBP crunchers? That way we would still be providing some BBP incentive to people beyond our ecosystem (thus raising some awareness), and still locking funds for collateral (supporting price). A coefficient of 1.5, for example, would require 10 times the BBP team collateral for an outsider (31M BBP for 100k RAC).

Another very wise idea being floated here!

Ok all, I restarted the poll!  Please see the updated poll and re-vote!




1909
Archived Proposals / PODC TEAM REQUIREMENTS
« on: November 22, 2019, 11:51:35 AM »
I believe this poll is relatively self explanatory  :o , but please ask any questions if I missed something.

Thank you for voting!


1910
BiblePay
1.4.7.8 - Mandatory Upgrade for TestNet

- Require depth of at least 1 for new DWS stakes, Enforce DWS max limit in every area to ensure the burn can't enter the chain resulting in an overlimit condition (and include memory pool totals)
- Add spork rejecting new child sponsorships when there are none available



1911
Hey Rob and MIP,

Im trying to download
Linux 64 bits QT: https://biblepay.org/biblepay-qt-evo-testnet-x86_64-pc-linux-gnu.tar.gz
But I think its a 0kb file right now?
Tested on Ubuntu with wget and downloading through web browser on Windows

I've got one for deployment coming in a little bit; so we can keep testing DWS; let me finish it up tomorrow morning and then we can redeploy.


1912
So I updated the test cases in Post #2.  Please let me know if you all can think of any more test cases reqd.  You can also execute the test cases that we have not executed.

I also started an unbanked researcher with 90 rac. 


1913

We could probably prevent this by requiring coins with at least 1 confirm for DWS.

Let me look into this.

Ok everyone please stop testing the DWS burns until the next version, I added a couple more rules.

Lets test everything else.


1914
If we repeatedly send dws - there's no way to prevent this message? I can foresee a lot of tech support around this. You can tell people to send only one tx, but you know that will not happen. With PoG v1, people sent multiple tithes in a block... same scenario here.


2019-11-21 13:44:39 ERROR: AcceptToMemoryPool : Transaction b869f42c5188368c5f9a8541b48f384e6bbf79fed89f7d38f437161bc731956e conflicts with completed Transaction Lock ef650256b9e1d1fcb79f138f53baa5220bdc28d13f0c42dfce5db0eab4360616
2019-11-21 13:44:39 CommitTransaction(): Transaction cannot be broadcast immediately, tx-txlock-conflict


We could probably prevent this by requiring coins with at least 1 confirm for DWS.

Let me look into this.


1915
All, lets please test instantsend thoroughly, lets verify the quality of IS is what we expect for prod in testnet?


1916
I do not believe I got the funds for this proposal, looks like superblock passed recently,
I believe the proposal had 4-5 yes votes and 0 no votes,
I do still see the proposal in the proposals tab, hmmm

Togo, will you please test the Private Send mixing in testnet to ensure denominations are now correct, and mixing is faster and correct?


1917
I do not believe I got the funds for this proposal, looks like superblock passed recently,
I believe the proposal had 4-5 yes votes and 0 no votes,
I do still see the proposal in the proposals tab, hmmm

I took a look at it this morning when the monthly budget was about to pass, and I believe what happened is the proposal was entered a couple blocks after the late-duration cut off - this is the cut off where its too late to create a trigger for payment.
So I copied the proposal into a new one, and now we know its at the beginning of the cycle again; lets see if this one pays.

Part of the challenge in testnet is the cycle is 4* per month instead of 1, so Im confident if it picks it up this time it was just the late-duration cut off issue.
(Especially since we had 7 sancs running at that time).

Lets defintely follow this through though.  I did test a few proposals in this branch a while back (back when we had 3 sancs) and they all paid, so I don't "believe" we have a payment issue with watchman but nevertheless lets watch it.


1918
BiblePay - TestNet
1.4.7.7 - Mandatory Upgrade for TestNet

- Add mandatory (prod) cutover height 166,000 for PODC 2.0
- Increase deflation to 20.04% after PODC2.0 cutover height, and, enable DWS.  Ensure we have a spending cap in prod for each DWS day.  Add anti-fork DWS rules.  Ensure burn payments never exceed the cap (decrease them if this happens).
- Fix instantsend lock behavior
- Fix privatesend mixing denominations and mixing behavior
- Remove QT
- (MIP): Merge in all Dash prod changes from July up to the current date

** Windows is ready, the rest are compiling **

Please note:  All sancs and the entire network must upgrade as this includes all the Dash changes up to the current date and a consensus change.


1919

Seems to be okay now, I quit the testnet wallet and tried again and both are on 17308:
"hash": "0975df866939ada03b79d06fc5a087178b3f89931105ec5aaa02cd57345b8a78",

I grepped my dev log and don't see any chainlock errors, and it looks like our quorum is holding up from the sanc perspective so far.  No sancs are POSE banning each other.


1920
** SPORK_19 : CHAINLOCKS HAS BEEN ENABLED FOR BIBLEPAY TESTNET ! **


- Now that we have 7 running sancs in testnet (we need a minimum of 3), theoretically we will keep the chainlocks LLMQ quorum.
- Chainlocks theoretically makes it almost impossible to perform a 51% attack on BBP.  This is because the chain will no longer be allowed to "roll-back" for reorgs.  Because, each sanctuary will be assessing the chain block by block.
- Additionally, biblepay should have higher security.  This is because not only do we have POW security, but sanctuary security.  An example here would be someone trying to alter the business logic in a fraudulent client.  The sanctuary quorum will already have each official block memorized that has been seen.
- Therefore, we now benefit by not only proof-of-work (strongest decentralized hashes provide security) but we also benefit from a form of proof-of-stake (because you must have capital to control N # of sancs).  This gives us a much higher total level of decentralized security than POW or POS alone.
- Because of this, BiblePay's GSCs just became stronger.  In addition, we can do "cool" things now, such as save energy, or provide subsidies for future items such as letter writing that simply were almost impossible or dangerous without chainlocks.
- Exchange Security:  Theoretically, with instant send autolocks and chainlocks, our exchange security just rose by a magnitude.  We will technically not need to have more than 7 block confirmations, since rollback risk is almost eliminated with chainlocks.
- What happens instead of reorgs now:  One strange side effect of chainlocks is the POSE ban sanc effect.  Theoretically what will happen in place of a fork is :  Sanctuaries will POSE ban each other and many small chains will exist.  This should not happen in prod, because of the massive number of sanctuaries (any number > 10 or so will keep the main chain rolling forward).  However in testnet, if we take down 75% of the sancs, we should see the chain split into multiple small and useless forks (meaning that they will be harmless).  This is in contrast to two big forks in pure POW mode.  Why is this?  This is because the chainlocks rules dictate that when a quorum cannot be maintained, the network will keep trying.  This prevents reorgs, and keeps everyone on a harmless "segment".




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