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 - T-Mike

Pages: 1 ... 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25
256
Biblepay
1.0.9.2-Mandatory Upgrade for TestNet


- Add Spork for Team Biblepay Requirement for PODC
- Enforce Team requirement in PODC Contract
- Add PODC Difficulty Measurement for getmininginfo, and add exec podcdifficulty RPC command
- Extend instantsend signing timeout to allow higher transmission amounts
- Increase PrivateSend Mixing Denominations by 1000
- Add team value and warning to exec getboincinfo

** Windows is Compiling **

Rob, updating one node now.

257
ok. I must check the settings and find it... But maybe it doesnt matter anymore, because all my VPS are ending today :)
So I will be without any "external help"...
My only 24/7 device will be my old Nexus 4 ;) and maybe this will be interresting for you Rob.
It is old phone, comparable to nowaday mid range.

I test it for 2 days now. There were some problems on beginning and I've found that I need to use only 2 of 4 cores to run it properly.
After two days: Total credit   1015 ; Average credit   89.93
https://boinc.bakerlab.org/rosetta/results.php?hostid=3352819

Did you have to do anything to get your phone to run 24/7? I have mine plugged in but it will only work for a few hours then it will suspend it self. I have to manually start it again afterwards.

258
All 10 nodes on 1.0.9.1 now.

259
Awesome, lets see if your new getboincinfo looks good now, ie rac numbers came down to be accurate?  I just thought of something, we need a tool to see an in - wallet leaderboard report, like exec leaderboard, so we can see "cpid, magnitde" ranked from top to bottom, that will reveal any strange anomolies also...

Rob, the information looks great now.

"Command": "getboincinfo",
  "CPID": "f80ab050ab53459ec937879a046d603e",
  "Address": "yjKEf6GvMkuiXLXibCCtj9wt4ZEBwQ5i84",
  "CPIDS": "e94c1704c75f731f8bfde303f08408ee;71f1f1f46deb2f25961c7d9af06f2b31;95a79cd5829e8315b0b946709930df18;cc37d0ef74a621379974484f43d3b1c5;f80ab050ab53459ec937879a046d603e;",
  "CPID-Age (hours)": 421848,
  "NextSuperblockHeight": 9999,
  "e94c1704c75f731f8bfde303f08408ee_RAC": 438.68,
  "71f1f1f46deb2f25961c7d9af06f2b31_RAC": 180.95,
  "95a79cd5829e8315b0b946709930df18_RAC": 151.15,
  "cc37d0ef74a621379974484f43d3b1c5_RAC": 185.96,
  "f80ab050ab53459ec937879a046d603e_RAC": 151.9,
  "Total_RAC": 1108.64,
  "Total Payments (One Day)": 71927,
  "Total Payments (One Week)": 1482797,
  "Total Budget (One Day)": 1365210,
  "Total Budget (One Week)": 48156570,
  "Superblock Count (One Week)": 66,
  "Superblock Hit Count (One Week)": 36,
  "Superblock List": "9702,9108,8613,8217,8118,8019,7821,7425,7326,7128,7029,6831,6732,6633,6534,6435,6336,6138,5940,5841,5742,5643,5247,5148,5049,4950,4851,4752,4653,4554,4455,4356,4257,4158,3762,3465",
  "Last Superblock Budget": 1386000,
  "Last Superblock Height": 9900,
  "Last Superblock Payment": -1,
  "Magnitude": 30.79116722806462

260

I did think of a simple "pie" thing, and its good, dont get me wrong but there was one other consideration other than large numbers.
There is a chance that when biblepay grows, we might make biblepay consider more than one projects RAC, for example 30% from Alzheimers research and 70% from cancer. 

Magnitude is a term I am coining for "consolidated project effectiveness as a researcher" so its slightly different than a pure percent when you consider the possibility of blending two projects together.

I deliberately kept the system simple in that it only works with Rosetta, but PODC is generic in the back end enough to potentially go with more than one blended project in the future.

If that ever happens your magnitude is the single number as a researcher across all biblepay projects.

I see, sounds good Rob. If all goes well I'll clone up 9 more nodes tomorrow.

261
Ill modify the wiki.  I mentioned Magnitude somewhere in this thread a little better with a different equation.

Im sticking with 1000 cap-limit for the magnitude for now, as I want it to be a granular float from 0-1000 meaning your position in team Biblepay.  Its certainly equivalent to a percent of the superblock, but Magnitude is meant to be the total "weight" you have in our leaderboard and I have the gut feeling people who compete like large numbers.

This will come into play when we have 5000-10000 researchers (we will), and the granularity will be very small between some.

EDIT: Heres where the confusion came from - you said the wiki said "it says mangitude = RAC * 1000", but the wiki says "the Individual Researchers Share of RAC * 1000".  The individual researchers share of RAC * 1000 is the magnitude.  The wiki is correct, your quote was missing the word "share".

Yes, I did think you might have wanted the number to be bigger. Yeah, I mentioned I missed the word "share".

262
You can verify your RAC against the Rosetta UI, or against the many Boinc credit providers or against the row in Boinc Manager.

No, we never said Magnitude is RAC * 1000.

We said Magnitude = RAC/TotalProjectRAC * 1000.

I can put the TotalProjectRAC in getboincinfo.

TotalProjectRAC would be great. In the wiki it says "(Magnitude is computed by assessing the Individual Researchers Share of RAC * 1000)" I missed the words "share of" in that sentence. Did you consider using "Pie%" by doing x100 instead of x1000? I personally would like percentage better, it makes more sense to me.

263
Try going to Settings | Options | Display and changing default language to another language first.

The .01 bbp to you is just a remnant of POL, that is going away soon.
The 581 reward is a heat-mining reward.
The 5800 reward is a sanctuary reward.
Anything over 6000 bbp is a PODC reward.
Tx list looks good.

Is there a way to check the RAC of the Biblepay network so I can see if my magnitude is correct? Also, on the wiki, it says mangitude = RAC * 1000, that doesn't seem to be the case anymore right?

264
That is the protection, the fee increases higher and higher according to the block size.  To my knowledge all the berkeleydb coins do the same thing, but I dont know how Ethereum works in this respect.

Oh, I meant the clown situation. But I guess that clown would have to be rich or just want to waste coins if he wants to do that to every block and make everyone's fees really high.

265
32767 is the biggest transaction vout size that can fit in a block, and after the block gets above 1 Meg in bytes, fees start to get around 100bbp per transaction after 2 meg its more like 1000bbp per tx.  Warnings start appearing on the UI for every tx sent warning you would you like to add this fee to your Tx, or decline and wait?   Its not really based on time, its based on size.  Its always possible some clown electronically pumps in 5,000 tx in one minute right when a new block hits.

I see, thanks. So do any of the crypto currencies out there have a way of protecting against that?

266
But lets clarify one thing quickly first, its 1 HPS because we are sleeping, it rises up to more like 100 HPS when the CPID is actually available in an open spot (to mine the next block). 

As far as Tx per day, we would be able to process 32,767 per block * 202 per day, max.  But you would see very high fees after the 7000'th transaction because the size of the block would be very large.  Otoh, our fees are so small, compared to bitcoin, a 1000 bbp fee is still only .20 cent compared to bitcoin $17 fee.

Really you dont need much mining power as long as we are not getting attacked.  DGW kicks in when people throw a lot of hash our way.
In some POS coins like blackcoin, diff can stay at 5.0 for a whole day if hardly anyone is staking, and security is not suffering (as long as they have a wide distribution of holders).

Rob, how did you arrive at those numbers in the calculation? So is the fee based on processing time? Like what makes a big block more expensive. Sorry for the NOOB questions.

267
Looks like we matched, great!

But we will need more hashers out here with CPIDs to speed up these blocks....

Edit: It looks like Im the only one mining.  The mining feature is working, Im mining at 1 HPS!  This is cool, 99.9% available for Rosetta....

Yeah, I started the mining, 0.84hps. How much mining power do we need to keep the network operating with 500k transactions per day? I mean, for bitcoin, if there was only 10 people mining, could it process 500k transactions per day?

268
Do we have the latest windows version compiled already? I cannot compile it myself even in linux as all my boxes don't have QT installed at the moment so no gui available for me.
Thank you.

With the newest version QT is not required anymore. You just need to compile and run the daemon.

269
Not sure if it matters though, its on by default, and makes the miner run at 100 HPS or so.  If they turn it off, they can use genproclimit to mine as fast as they want if thats what they insist on.

Uhh, we definitely need to test headless's ability to download the file.  Could you run headless, and do a 'exec dcc' and see if it updates the /SAN files to current timestamp?

Then do an exec testvote also and lets see if we both vote on the same file.

"Command": "testvote",
  "fileage": 303,
  "filehash": "00000000000000000000000000000000747be9068b0b5ae2ae03be8dd0900019",

270
Cool, I think its working now, Im not seeing anything unusual in the logs. 

I forgot to mention the newest version does have the 100ms sleep feature in the miner, so technically BBP should be using 1% cpu power when mining unless you set 'fullspeed=true'.  This is defaulted to true in prod, of course.

Im the only miner mining right now in testned (ca89*).

So the blocks are taking 15 mins each...

Did you need me to turn on the mining? I think it would be helpful if the sleep feature was a variable from 0-100 so people can adjust it according to their needs.

What else do we need to test right now?

Pages: 1 ... 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25