BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

[Rob Andrews]

Did the block times improve?
Do we need more hash power on PoBH?

I just analyzed the last few hundred blocks, and no it didnt improve.  Im still seeing 30 hour completion time for 205 blocks (about 20% slow still).

Ive triple and quadruple checked the rule - there is no way the rule is not being used, so let octuple check some things, and if need be, our exchange mandatory can reflect yet another change at a future height to make this right, Ill get to the bottom of this.

I strongly believe our rule kicked in and lowered our diff by 17%, and our block times with CPIDs happened to lag by 17% offseting the change, which is kind of hilarious but I believe it to be the case.

Im committed to fixing the emission system in 10 days - to decrease the DC budget by 20% and at the same time speed the blocks up by 20%.....  My, lots of fun.

[Rob Andrews]

I started mining on this account again, and now my boincinfo is as expected:

Code Select Expand


13:29:54

exec getboincinfo


13:29:56

{
  "Command": "getboincinfo",
  "CPID": "c852da1a620ad630b70c8ec1ccdee366",
  "Address": "BT4PgVhnWKfonixcNGCbngA5vXEpqWCAWZ",
  "CPIDS": "c852da1a620ad630b70c8ec1ccdee366;",
  "CPID-Age (hours)": 422388,
  "NextSuperblockHeight": 33825,
  "NextSuperblockBudget": 2660579,
  "c852da1a620ad630b70c8ec1ccdee366_ADDRESS": "BT4PgVhnWKfonixcNGCbngA5vXEpqWCAWZ",
  "c852da1a620ad630b70c8ec1ccdee366_RAC": 35.38,
  "c852da1a620ad630b70c8ec1ccdee366_TEAM": 15044,
  "c852da1a620ad630b70c8ec1ccdee366_TaskWeight": 100,
  "c852da1a620ad630b70c8ec1ccdee366_UTXOWeight": 25,
  "Total_RAC": 35.38,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 2660579,
  "Total Budget (One Week)": 2660579,
  "Superblock Count (One Week)": 1,
  "Superblock Hit Count (One Week)": 1,
  "Superblock List": "33620",
  "Last Superblock Height": 33620,
  "Last Superblock Budget": 2660579,
  "Last Superblock Payment": 0,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}


Yes, that is the tamper rule.  If the researcher stops researching new tasks for more than 24hours, we interpret that as ' no tasks to check ' (similar to SQL tampering), and the researcher receives 0 task weight.  So they have to keep researching to be in the next superblock.

However the 7 day magnitude on the screen would still linger for a while. 

[T-Mike]

Hmm, I need help with that as I cant get it to crash, need someone to mine with valgrind on.
Well on the pool though, they can technically mine without a CPID, but the hashes only count it the block gets stale, looks like I need an additional rule in the pool to kick them off the pool if they mine without a CPID.

Lots of fun.

OK, because I think people think they are still mining even though the hash rate is really low. But I think your saying that they might not actually be mining at all.

[Rob Andrews]

Oh, and a question about the amount of BBP per superblock: shouldn't it be about half of what it is? Or is it that high because the network difficulty is low now?

Superblockbudget / blocks = 2.660.579 / 205 = +-13.000 per block.

Yes, West emailed me of this this morning, and whats happening is we have a total gross emission error in the DC payment superblock calculation due to cascading superblocks (IE one per month plus one per day), causing the DC budget to be 20% too high (gross).  So to fix it we need to lower the DC emission rate by 30% net (that puts the entire block budget down below its allowable emission level). 

Im planning on merging that calc change in at a height of T+7 inside the exchange mandatory.

So in summary, due to cascading superblocks, there is a total emission error, and at T+7, the superblock emission for DC superblocks will be reduced by 30%, making the Biblepay block distribution:
20% for Monthly Budget Superblocks
50% for Distributed Computing Superblocks
27% for Sanctuary Payments
3% for POW mining

[jaapgvk]

I just analyzed the last few hundred blocks, and no it didnt improve.  Im still seeing 30 hour completion time for 205 blocks (about 20% slow still).

Ive triple and quadruple checked the rule - there is no way the rule is not being used, so let octuple check some things, and if need be, our exchange mandatory can reflect yet another change at a future height to make this right, Ill get to the bottom of this.

I strongly believe our rule kicked in and lowered our diff by 17%, and our block times with CPIDs happened to lag by 17% offseting the change, which is kind of hilarious but I believe it to be the case.

Im committed to fixing the emission system in 10 days - to decrease the DC budget by 20% and at the same time speed the blocks up by 20%.....  My, lots of fun.

Does the release of a new mandatory also mean that the pool unbanked function will be  fixed at that point? Because that would be awesome!

[Rob Andrews]

Does the release of a new mandatory also mean that the pool unbanked function will be  fixed at that point? Because that would be awesome!

Yes, absolutely, Im trying to team all this up together now and make a list of what it fixes:

- unbanked pool side
- unbanked sanc side and user side
- 7 min blocks
- lower DC budget
- Lukes new 10000 UTXO per magnitude

Etc...

The good news is since it has to be a mandatory, it shores up everything as a team.

[jaapgvk]

Yes, absolutely, Im trying to team all this up together now and make a list of what it fixes:

- unbanked pool side
- unbanked sanc side and user side
- 7 min blocks
- lower DC budget
- Lukes new 10000 UTXO per magnitude

Etc...

The good news is since it has to be a mandatory, it shores up everything as a team.

Absolutely awesome Rob!

[T-Mike]

Yes, absolutely, Im trying to team all this up together now and make a list of what it fixes:

- unbanked pool side
- unbanked sanc side and user side
- 7 min blocks
- lower DC budget
- Lukes new 10000 UTXO per magnitude

Etc...

The good news is since it has to be a mandatory, it shores up everything as a team.

That's great, I'll update when the Windows wallet is ready.

[Rob Andrews]

https://bitcointalk.org/index.php?topic=2388064.new#new

Please Vote:

[Ichthus220]

Does my wallet that is associated with my CPID have to be running to be eligible for rewards? I noticed that mine is down and I won't be home for several hours.

[T-Mike]

Does my wallet that is associated with my CPID have to be running to be eligible for rewards? I noticed that mine is down and I won't be home for several hours.

Yes, the wallet has to on at all times. If it can't send out podc updates your UTXOweight will go to zero.

[orbis]

Rob,
why I have more than 6 payment to yourself tx/day?
Last PODC update was 24h ago, but I have those 6 with UTXOamounth. Is it PODC confirmation?

[Rob Andrews]

Rob,
why I have more than 6 payment to yourself tx/day?
Last PODC update was 24h ago, but I have those 6 with UTXOamounth. Is it PODC confirmation?

You can actually just click on them and see if its "PODC notification", or check the XML in the vout to see if it says "PODCUpdate", but anyway it normally only sends a couple in 24 hours, but if you have multiple CPIDs, it sends one for each CPID.

[Rob Andrews]

Does my wallet that is associated with my CPID have to be running to be eligible for rewards? I noticed that mine is down and I won't be home for several hours.

Although I dont recommend it if you absolutely have to shut down you can exec podcupdate true and send a fresh one then hope that you are in the chain for 24 hours, and pick it up the next day.

There is an option in the qt wallet to minimize to Tray, and install as service.  This is nice if you do not want to see whats going on- now that we are pretty green Im sure you can run biblepay on a windows machine as a service and not even notice its running.

[T-Mike]

Rob, I hope this helps. The wallet crashes with any values over 1 it seems like.

https://transfer.sh/12zRuR/Debug.zip

Password: biblepay