Messages

1936

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 19, 2019, 02:31:35 PM »

I voted for the Kanye West proposal:

gobject list all proposals

Let me know if you receive the funds.

1937

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 19, 2019, 10:27:44 AM »

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.

1938

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.

1939

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: November 19, 2019, 09:30:06 AM »

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!

1940

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 19, 2019, 09:01:26 AM »

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.

1941

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 19, 2019, 08:58:10 AM »

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.

1942

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 18, 2019, 03:59:45 PM »

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

1943

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 18, 2019, 03:42:05 PM »

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

1944

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 18, 2019, 02:45:49 PM »

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? 

1945

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 18, 2019, 09:27:38 AM »

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.

1946

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 17, 2019, 02:12:30 PM »

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.

1947

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 17, 2019, 12:17:23 PM »

I wonder if there's value in always forcing it true. Seems like a point of confusion to use true or not. Any harm in making it the default?

Yes, harm because forcing it negates the path of code that explains common reasons it failed, like username already taken, etc.
Force=true is only for reassociations already in the chain.

1948

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 17, 2019, 12:02:58 PM »

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.

1949

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 17, 2019, 11:46:54 AM »

Will someone please test unbanked, to ensure you get auto payments each day and dont need to post a stake?

Im going to start a 2nd cpid soon but havent got around to it.

You just need to lower your rac down to below 250 and above 1.

I started an unbanked CPID; waiting for RAC to increase.

I noticed that on brand new WCG CPIDs, we cant associate them right away because there is a delay on the WCG side.  Ill see if I can detect the condition and maybe we can add one more result code - something at least explaining the expected amount of time to wait between a new account and the time the 'associate' will actually work.   I emailed IBM about it - from the boinc side I can see the CPID, from the WCG side - their XML api returns 'name does not exist' but from the WCG web page the name does exist.  I also will re-clarify what we need to do about the data export reqs.  Im still not 100% sure if we need to demand the radio button be set to export stats or not.

1950

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 17, 2019, 11:44:16 AM »

What happens if we send funds to DWS but don't get it back? For example, in this last situation we lost all the test tBBP. Is there a way to recover in case of catastrophe?

1) Yes we lost the tBBP, but thats because the test format changed; in prod that would never happen.  Obviously, we would not release the change without a smooth cutover between ended payments and new payments in prod.
2) As far as the question though, if there is a technical glitch or for some reason, the payment is not paid back, it would be lost.  There is no mechanism in BBP for it to re-send it if the sancs don't send it to you on the due date.  To clarify though, I originally planned on making the algo detect 'unpaid items that need paid today' and then I realized that adds risk.  Right now the sancs are forced to pay things that are due from a certain block range; and the only risk would be the GSC contract fails that day.  BBP only risks sending out a max of 5mil per day.  If I started adding in the "possibility" of missing a day and sending 2* the amount that opens us up to way too much capital risk.  I think 5mil deflating is manageable, since our great deflation lowers this continually.  And allowing 5 mil per day in burns is good enough for most of us etc.  So at this point I feel the simplicity is safer than the riskiness of adding complexity and capital risk.  I will continue to explore other options for prod, such as 'longer term maturing coinbases and timed transactions', but those are not guaranteed to work for this use case.

  Its currently a use-at-your-own-risk feature, and this way it passes the Howey test also.