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 ... 123 124 125 126 127 128 129 [130] 131 132 133 134 135 136 137 ... 264
1936
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.


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


1938

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.


1939
** 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".




1940
I voted for the Kanye West proposal:

gobject list all proposals

Let me know if you receive the funds.


1941
Does anyone have an IP to use in addnode for this testnet? seems the one I had from past test is no longer valid.
Thanks.

We had our primary DNS server->node for testnet running on the wrong port.

Fixed.  Now we have two running on the right port.


1942
Archived Proposals / Payroll Nov 2019
« on: November 19, 2019, 10:18:52 AM »

MainNet commits:

Commits on Nov 1, 2019
1.4.5.2-Leisure Upgrade …

@biblepay
biblepay committed 18 days ago
 
Commits on Oct 30, 2019
1.4.5.1c-Leisure Upgrade …

@biblepay
biblepay committed 20 days ago
 
Commits on Oct 24, 2019
1.4.5.1b-Leisure Upgrade …

@biblepay
biblepay committed 26 days ago
 
Commits on Oct 23, 2019
1.4.5.1-Leisure Upgrade …

@biblepay
biblepay committed 27 days ago
 
Commits on Oct 21, 2019
1.4.5.0d-Leisure Upgrade …

@biblepay
biblepay committed 29 days ago
 
1.4.5.0c-Leisure Upgrade …

@biblepay
biblepay committed 29 days ago
 
Commits on Oct 14, 2019
Merge pull request #22 from sunk818/patch-1 …

@biblepay
biblepay committed on Oct 14
 
Merge pull request #23 from sunk818/patch-2 …

@biblepay
biblepay committed on Oct 14
 
Commits on Oct 11, 2019
1.4.5.0b - Leisure Upgrade …

@biblepay
biblepay committed on Oct 11
 
1.4.5.0-Leisure Upgrade …

@biblepay
biblepay committed on Oct 11

Also I worked on NOMP for 60 hours this month.



Capping @ 3 mil due to budget constraints.


1943
Is this what chainlocks is all about? I cannot spend anything on any of my wallets in testnet. Hence am unable to revive my two sancs.

Error code:-4
Signing transaction failed

Chainlocks are not enabled yet, but LLMQs are, so lets discuss this in the new POBH thread.

Its almost time for us to start testing chainlocks!


1944
I don't know how I ended up on a fork? But have half a dozen peers.

Check your log to see if you rejected the last superblock?  You can do this by getting the height of it (exec health, go to last block height) and analyze very close to that height and see if block rejects started to happen at that point.  If not find the exact height your rejects started.  That usually is one of the superblock heights.  If it is it means the node version you were running was probably running the old rules.  (Or, the node had gobject propagation issues).  You can also type 'gobject count' and make sure your gobject count is roughly what the other nodes are; and exec health should have the same number of votes as the other nodes.

Looking at the infrastructure now I dont see a fork.  All the sancs made it and my node is still in sync.

One nice thing about LLMQs is when a fork occurs, they start pose-banning each other very quickly (cause they cant hold the quorum), so technically the deterministic sancs should be a benefit to us in the next version.



1945
Some Dynamic Whale Stake took but not all.



Ok, so you mean 'I tried to send out multiple whale stakes from the rpc in succession, and they returned from the console successfully, but were not picked up by any of the other nodes - and - the status of the transaciton when I double click is Offline'.  Ok, this usually happens when the coins are locked by the prior transaction and the wallet prevents the next successive transaction against double spending those.  To find out if this is the exact cause copy the transactionID to the clipboard (after double clicking the transaction on the gui row).

Then do a 'cat debug.log | grep txid'.  It should say something like attempt to spend locked (or already spent) coins.  This is primarily a new feature in the .14 branch because Dash tries to autolock coins now for free instantsends. 

You can then recover by restarting with -zapwallettxes=1 and they will dissapear.

This is not really related to sending DWS's.

I maintain that we bubble the DWS error to the console now.

On DWS, we should wait until we see "In memory pool - broadcast through N nodes" before sending another one.


1946
BiblePay - TestNet
1.4.7.5 - Leisure Upgrade


- Fix crash during sync from zero reported by Sun
- Add extra DWS BL rule to prevent stakes from exceeding 5 mil on any future date (in addition to 5 mil in new burns per day)
- Check in POBH R&D class for MIP and the GPU contractor
- Add help message notes in exec associate to explain the missing steps
- Show the whale icon on Received stakes


1947
None of my dynamic whale staking went through on the latest version. I don't know if all the slots are filled up already...?




I also could start the chain fresh and BBP would crash every time around 12k. I don't know if it was peers on old versions, but I kept getting invalid block errors. I thought we had mandatory, but I kept seeing 1.4.7.2 and 1.4.7.3 peers. Even testnet1.biblepay.org was on 1.4.7.2.


Ok, I confirm the crash during sync from zero.  So, I debugged this issue and indeed we have a bug.

The fix is checked in.

We will release a leisure fix for this bug.

On the dws burn issue, I believe the answer on that is to just ensure the version is 1.4.7.4+. 



1948
None of my dynamic whale staking went through on the latest version. I don't know if all the slots are filled up already...?




I also could start the chain fresh and BBP would crash every time around 12k. I don't know if it was peers on old versions, but I kept getting invalid block errors. I thought we had mandatory, but I kept seeing 1.4.7.2 and 1.4.7.3 peers. Even testnet1.biblepay.org was on 1.4.7.2.

Could you please explain what you mean by "none went through"? 
(On a side note, now we show the user immediately if it is going to fail right in the rpc, you will receive a nice error message now).  I just burned one: successful.
You are probably running the pre 1.4.7.4 version; if you run an old version it tries to use the "old" dws format which is no good. 

In the mean time, Ill try to sync from zero on the latest version to verify it can sync.

Yes, also, 1.4.7.4 only sync with its peers; and the sancs must be on 1.4.7.4 too.  Was MIPs binary released yet?  Or are you on windows, it could be my issue? 


1949
i cleaned up my cpk address so i had only 1x 1m coins there, but then at time of automatic gsc sends, it takes whole 1m for kairos and then nothing for wcg... :) so whole coin age was spent on nothing and not saved for wcg..
is it possible to reorder somehow that wcg will goes first?

Well to be entirely honest with you, I think that will do damage.  Since we will have 4 campaigns (Kairos, cameroon, wcg and maybe healing) I think it will still be key for the user to use bankroll command, if they have any type of massive RAC like you.

So as long as we do the bankroll, what will happen is Kairos or Cameroon *will* pick the smallest bill and only use one bill.  It is already programmed to pick the smallest coin age for each GSC transmission as possible.

So in this case I think the best answer is for all of us to run exec bankroll knowing that we may have more than one tx per night.


EDIT:

However we can reorder them also.  Remind me in prod if I forget, we do have control of the iteration order; in Prod when we set the spork, we can set it to : WCG (0), then Cameroon-One (1) ... etc.   Yes, no problem.


1950
I got my DWS rewards last night, but there is no whale icon.  So if you are looking for yours look for smart-contract-reward.

Ill look into this issue.

Ok whale icon fixed, will be in the next release.


Pages: 1 ... 123 124 125 126 127 128 129 [130] 131 132 133 134 135 136 137 ... 264