Messages

3241

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 11:18:56 AM »

it looks like possible problem:

Code: [Select]

{
  "Command": "stakebalance",
  "StakeBalance": 0
}

Yeah, in UnitTest I just fixed it - its trying to use aged coins > 24 hours in coin_age only, fixed.


So that will be resolved in the next version.

Im thinking to kick the botnet off, we are going to need a flag set anyway to allow us to "be" the new prod network.

Any other issues we can think of for the next build?

3242

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:54:31 AM »

Ok, Togo you made it!  Your in exec leaderboard in Test now.

So thats one huge thing out of the way.  All we have left now is:
- Large podc update handling (field size) in prod
- Sanc supermajority by version
- Non-Aged utxos

I think that sums it up.  Id like to form a game plan for prod before proceeding.
Im thinking with the botnet out there, judging by the fact that 68% are on a heinously old version, we may need to also add a mandatory upgrade flag for prod (IE we become the new network) in this next version.

But lets continue testing and ensure we squashed all the bugs before I create 1099.

3243

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:51:35 AM »

Same problem here.
Testing in prod.
CPID associated without problem. getinfo, getmininginfo, getboincinfo without problem.
but after podc update it gives false with debug "PODCUpdate::Unable to create PODC UTXO::Balance too low"
I've send funds to my CPID address more than 40 blocks ago.

Oh Ok, I think we found a minor thing should not be a showstopper but will require another tweak in the final prod version-
Do me a favor, type 'exec stakebalance'.  Let me know what your Real unlocked balance is vs your stakebalance?

I believe the PODC update system is only looking for coins older than 24 hours.  We can remove that rule for Prod, as we are going by total balance, not by aged balance (as far as PODC UTXO's are concerned).  Yeah, that looks like the problem.  Fixing this now.

3244

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:30:23 AM »

My Zotac hard drive blew out 4 days into use!  So much for reliability...

3245

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:28:38 AM »

Well actually, I sent BBP to the CPID wallet address because it seemed to work with Mike, but it made no difference in my case. It still returns the ' Insufficient funds' error.

Try doing exec datalist dcc, picking your address to the clipboard for that particular CPID, then send some BBP to that address with
sendtoaddress address amount
Then doing the exec podcupdate again?

Im adding a feature now to show your address per cpid in exec getboincinfo, so this will be easier in prod.

3246

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:25:18 AM »

I just remembered "why" its sending the UTXO stake amount from the CPID wallet address.
Its for security - we check the signature of the sender to ensure the senders address owns the CPID that sent the coinstake, and we check the CPID is related to the association tx, and we check the signature of the message is a valid sig for the cpid.  So this gives us the integrity of Address->UTXO->CPID->Tasks and the validation. 

We will need to add something to the instructions to send 60K or so over from yourself to the primary CPID BBP address on file.  As the CPID receives rewards it will be less of a problem.

Ill add the BBP address to getboincinfo, so we can see the addresses easier.

3247

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:17:27 AM »

Heres another thing that sheds light on part of the problem in prod, giving the false perception that utxo weight is taking long long time to confirm:

In one of the prior versions of PODC between 1092-1095 or so, we expanded the size of the vout transaction message field for PODC tasks.  However most of Prod is running the old version (68% on 1.0.81 and 23% on 1087), heinously bad situation, so basically Prod will not propagate the long fields required for PODC updates.  Until we start getting some updates going.  So we are sort of DOA in prod until we take action.  Note, the short PODC updates will propagate that explains why some work.

In reality, a PODC update should propagate in 6 confirms.  Then everyone sees the UTXO weight as 100 on block #7.

As far as requiring the actual wallet address of the CPID to be filled with BBP, thats probably happening without me realizing that that particular "feature" was programmed in - its kind of important, as otherwise UTXOs will fail to send, Ill have to take a look at that in detail.  Maybe we should allow it to choose any coin available.

3248

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:04:16 AM »

My UTXO is still zero after 9 hours, I think I remember you saying I need to wait 24 hours? I updated my production sanctuary and wallet and everything seems to be working fine. I'll let you know when I receive a Sanctuary payment.

Code: [Select]



exec getboincinfo

{
  "Command": "getboincinfo",
  "CPID": "e94c1704c75f731f8bfde303f08408ee",
  "Address": "BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN",
  "CPIDS": "e94c1704c75f731f8bfde303f08408ee;",
  "CPID-Age (hours)": 422293,
  "NextSuperblockHeight": 33620,
  "NextSuperblockBudget": 760165,
  "e94c1704c75f731f8bfde303f08408ee_RAC": 4746.2,
  "e94c1704c75f731f8bfde303f08408ee_TEAM": 15044,
  "e94c1704c75f731f8bfde303f08408ee_TaskWeight": 100,
  "e94c1704c75f731f8bfde303f08408ee_UTXOWeight": 0,
  "Total_RAC": 4746.2,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 0,
  "Total Budget (One Week)": 0,
  "Superblock Count (One Week)": 0,
  "Superblock Hit Count (One Week)": 0,
  "Superblock List": "",
  "Last Superblock Height": 0,
  "Last Superblock Budget": 0,
  "Last Superblock Payment": -1,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

exec datalist dcc

{
  "DataList": "DCC",
  "04FBA56D89A5EB38B1B82F8A6240132C (03-05-2018 08:37:48)": "04fba56d89a5eb38b1b82f8a6240132c;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;1981529;INQ84/j9PlIAiksMlIWytRUWeT1Oy1IUearmIBEQwhSGPyv91yrspBm6SoYXiLQ3g5XTKXBNWBQcrs+GQfLbuzI=;0",
  "6785DED1F65063EF8F01F42DEB31CF1D (03-04-2018 23:17:49)": "6785ded1f65063ef8f01f42deb31cf1d;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;1981965;IHbjBdincaH8YS/XL7k6VR9n8dHysachVwo63vwZk732SkG4+Q4qx/qObz2VsYPdBL8RtBpxv5pv3/gmmqtGFPY=;0",
  "8791A036B545F35E9EBD9333922738AC (03-04-2018 20:56:07)": "8791a036b545f35e9ebd9333922738ac;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;1986929;IH0X/f06jDB7DGrsuew6YOgCwq5DPEcPZjW1hvd11BmvbNlPVOo/O6/RNYi028zk6i2pef0hh4dSMw9j3rqpFYU=",
  "8F273B30F8E0A298ED26E242762DF701 (03-05-2018 02:22:28)": "8f273b30f8e0a298ed26e242762df701;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;1981270;IN1loec110Y97Y9OILSxtkY1e5o1C9V/xOlrmfqwyD1IS9LA8yczMyFAgRa5nN/KQt+JxU+icBIQpKyJT7UsNUA=;0",
  "CA895B47AACFFBDBF906201821AF2F9F (03-05-2018 13:27:33)": "ca895b47aacffbdbf906201821af2f9f;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;475629;H1QQr77z7khrCeX3CJn6iUAQRqmqRZyIAl1CJdfeJx3oG9wfeJknjhmBvuokvJSUhqC+3+nzWhsr7T3MOkSoFqg=;0",
  "D9B22FCCFAE5582D4EE7838883AAA3CF (03-05-2018 13:22:45)": "d9b22fccfae5582d4ee7838883aaa3cf;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;1981615;IO9jRoYdWOO9iSFJ+yBLrlIqAhzyxKAv16jrpLrB3sqfEBhHuO+Tu8UWNQISXmp1cUePVOKJm8TBvY8gN8DsVuY=;0",
  "E94C1704C75F731F8BFDE303F08408EE (03-05-2018 02:22:28)": "e94c1704c75f731f8bfde303f08408ee;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;1981209;IG2r+VxRlr+3ceKJhbLnldsMVoZv/uoKgx4SukL9Z+bJdIjpjCMaoceE1Aog7hFOSGJd70eU6bgLJM56hCRwV1k=;0"
}


Mike-
In testnet your e94 CPID has a 100 weight as of a few hours ago: E94C1704C75F731F8BFDE303F08408EE (03-05-2018 12:31:08)": "100
(exec datalist utxoweight) alluding to the fact that since you have multiple cpids, you probably didnt leave the controller wallet on long enough to send 5 UTXO's out.  Each CPID requires a separate UTXO.  So it might have looped through 4 of your CPIDS and Failed to send the 5th until you manually triggered  it a few hours ago... 

This is a good reason in Prod we should have One cpid, of course for testing, I realize this is why we have multiple CPIDs.

3249

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 10:00:41 AM »

I think there are only 4 testnet sanctuaries enabled?
Mine are both on v1.0.9.8

How to Setup Testnet Sanctuary:
http://wiki.biblepay.org/Distributed_Computing_2#PART_F._.28OPTIONAL.29_Setup_Sanctuary_.28Masternode.29_in_Testnet

Nice avatar Togo, thats wild!


1.0.9.8 is out there now for windows...

3250

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 09:58:00 AM »

I think there are only 4 testnet sanctuaries enabled?
Mine are both on v1.0.9.8

How to Setup Testnet Sanctuary:
http://wiki.biblepay.org/Distributed_Computing_2#PART_F._.28OPTIONAL.29_Setup_Sanctuary_.28Masternode.29_in_Testnet

Yeah I only updated one of my two so far, but I did jump in 15 mins ago to see how 1.0.9.8 is propagating on the sancs, to see if your CPID, the 9313 made it into any contracts yet, and so far I see since all these sancs are supermajority the old version you have not yet been included- But, I see the next contract : at block 16236, looks like it will have you in it.  I was waiting for this to happen before recommending anyone upgrade Prod sancs.

Ill go ahead and upgrade my other testnet sanc, and wait til we see you receive payment, then if no other bugs occur, we can try to upgrade some of our prod sancs.

Mike, UTXO weight shold not take long - should take 6 blocks - let me do some testing on that before I reply, it might be the conditions in Prod are different - are you referring to your UTXO weight in prod or test?

3251

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 05, 2018, 07:19:48 AM »

I think Biblepay usese deterministic wallets so this does not apply. Rob, can you confirm this?

On walletbackups, the dash subsystem does create a copy of wallet.dat once per boot and copies this file into \backups.  Something like mmddyyyy.dat. 
I recommend keeping a copy of a good wallet offsite - maybe on a CD and USB flash if possible in a safe.

Anyway regarding the necessity to make constant backups:  There is truth to both sides but let me explain this nuance.
It is true, that if you only have one plain vanilla address with all your BBP allocated to that address, no matter how big the physical wallet.dat file gets, you can always get back all your bbp, if you had a backup of that original small file somewhere.  The wallet will expand in size as you resync the chain and you will gain all your BBP back.

The specific issue that requires you to back your wallet more often is this:  If you *add* a receiving address to the wallet, it comes with 1000 keys, if you have been mining for a while, if the action of creating a new address (doing that creates a keypair - a private key and a public wallet address), if that resulted in creating a new keypair that was *not* in the original backup, *and* you send BBP from somewhere to that new address, now that part of your balance is *not* in the original wallet.  Now you need a new backup.

So you either have to cognizently re-send your BBP periodically to your *original* address, and then you are fine, *or* keep backing it up.

Btw, an easy way to understand this is if you loop through your addresses and balances, if you were to type:
dumpprivkey publicbbpaddress
For each address with a balance, you could print those keys out to a printer and have a way to gain access to the BBP if you ever lost the cold wallet backup...

Its also beneficial to consolidate your wallet as the core will run faster, but it also risks a loss of privacy.  The reason the devs made so many keys it to obfuscate your identity.  If you dont care about anonymity, by all means send it all back to one address.  If you do care about anonymity let it bloat and keep backing it up on a regular basis.

3252

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 04, 2018, 10:26:19 PM »

I also associated my account to the same wallet twice because I forgot it takes a while before the CPID shows up in the GUI. Oh, I see waht address your talking about now. I wonder if that's why I'm having issues, I don't have enough BBP in that address.

Hmm, I dont think it requires a specific sending address to send funds though - can you instead go into coin control and see how much is available that is not locked?  It could be that all is allocated to sanctuary locked funds?

3253

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 04, 2018, 10:05:48 PM »

I used the GUI to send some to myself:
Transaction ID: edd8348af06de7463e3f95bf7381736581d4c03a932c3efee6f75b931bc3f974-000

So far haven't got a confirmation. But I did double check that my wallet is unlocked when I ran podcupdate.

UPDATE:
Looks like no confirmations after 13 min.

Looks like exec podcupdate has about 5 possible reasons to return false.   It should log the reason then return false.
So please try 'exec podcupdate' again, then immediately look at the log for the error.

Here is the most likely one:
   LogPrintf("\n PODCUpdate::Failed to Sign CPID Signature.  %s ",sError.c_str());
            

I believe that is happening when you dont have a CPID in the chain as of yet...


NOTE to all users:  You will never need to manually run exec podcupdate under normal circumstances; this is just to force it if your machine was off for long periods of time.


As far as the waiting for confirm:  Check the last block timestamp, its probably a lagging block.

** We just solved 33049; it probably confirmed

3254

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 04, 2018, 09:49:21 PM »

The staking percentage command is suppose to be in the controller wallet config file right?

Yea, and just to clarify the UTXO staking wallet is always the one with the DC association.
You could have a controller for sanctuaries with 10 million in it, and a separate controller with 100K in it with your CPID associations and the unlocked wallet.  The important thing is to put the funds in the one with the association, because that wallet will then know how to loop through your CPIDs Tasks and send the PODCUpdate properly.

On a side note, if you associated 1 cpid on a laptop and then tried to use your home PC as your staking controller it wouldnt send PODC updates because it would not know your CPID list....

3255

TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: March 04, 2018, 09:45:37 PM »

** Rosetta Leaderboard Fixed in pool.biblepay.org **

It was an unrelated SQL issue, you should now all see yourselves and your machines, as long as you have not Hidden your machines.

I also made the pool refresh the leaderboard every hour.