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] 2 3 4 5 6 7 8 ... 11
1
So I think it is possible to welcome and love the unbanked and cells and tablets, if you log in to the pool, and look at the rosetta leaderboard machine view, I see that I can determine Which CPIDs are 100% tablets or phones by querying the Processor field per CPID (IE If the processor contains "RM" and all processors are ARM then this is an unbanked CPID).  . .   So that is good, EXCEPT, one processor on the list: Rastiks.

Rastiks I see your machine right above your other ARM has 1.9GB ram and a BLANK for the processor.  What machine is that?

So far that is my assumption, we can mark CPIDs who are associated in biblepay as "ARM" only if they only have ARM devices, and those CPIDs do not need to stake UTXOs and do not need to have TaskWeight audited  they just receive 1*RAC = Magnitude, automatically.  Which makes it nice and easy for them - they basically need a PC with a controller wallet Once to set it up, then they dont need to leave their controller wallet on either.

Yes, I think you can white list the ARM devices. In the future we can add one more check to fail any ARM processors having more then a certain amount of RAC. Actually, maybe we can just have an average ARM RAC counter and if anyone exceeds that by 20% it fails. That way as technology improves the threshold is automatically raised.

2
As far as efficient: Unfortunately no, as I can pretty much tell you roughly whats going to happen.. LOL, because I watched this train wreck in slow motion before LOL.  Basically when we go live, we'll have about 100 CPIDs kick in the first week, then 400 by the end of the month, then about 2000 or so within 6 months.  When we hit 2000, that means the Sanc has to iterate through a lot of data once per morning.  So it really needs a checkbox to see if the researcher is "implying" that they are tablet only.  This way it only has to check the machines if it has to.  I dont want the sanc to have to do one hour of work each morning and freeze up, if it can do 10 minutes of work.  The other thing is remember, some researchers will have 75 machines attached to a cpid. So it has to loop through a lot of devices to come to a binary 1:0 conclusion.

As far as allocating funds for tablets, I dont really want to - as it will be a fallacy to try to believe that arm or a certain processor type is worth "more" per cobbleston than the rest of the system (IE they will get arbitraged to a certain value) that value is usually power related.  I think what happens is the compensation ends up being $20 per month for the amount of energy required to run a PC for 30 days, and that equates to say 1000 RAC in rosetta (at a constant state).  If the phone can do 100 RAC, then thats $2 per month for the phone, no matter what we do.  So yes the phone has to be crunching constantly to buy one loaf of bread once per month, its a sad state of affairs but you know thats pretty good for something you didnt have to do hard labor for.  Otoh, there will come a time - God willing - where our forward value may be Massively higher than we are worth - where someone will pay 20* the current rate for one BBP.  If that day comes, the phone will temporarily make $40 per month and can buy food for the whole family.  It depends on if we can higher 7 devs, and go through the stratis phase as well, if we can pull that off this can be a reality for a long, long time.

I see, I think the checkbox solution would be better then. I'll keep researching.

3
Yeah, no one realizes this but the feature to allow mass payments in biblepay for 32767 researchers in one airdrop per day is actually a *major* feature.  No one has that.  So Id rather leverage it than lose it.

But yes I hear you, but lets remember the UTXO feature itself, the staking requirement raises PODC up to at least the integrity level of POS coins, and I think that could be major when people start to figure it out.

I understand from the convenience perspective, it would be nice to make this a sleek black box and leave the controller off.  But lets also not forget the controller will also provide a base level of security for POBH block checking (POW heat mining) so thats a major benefit for us as a stable backbone globally.  If we were to be considered a true payment system, it would pay off for us in a healthy way, because we could tell our potential partners we have a backbone of 10,000 PCs always on - as full nodes for block processing.

But yes, I really want the unbanked and the small tiny 3rd world phone to be able to use biblepay!  So that will also be a priority today, I will check into that today along with the threading.

As far as abuse of the system, Im pretty sure what we will have to do is add a checkbox to the association page and mark the CPID as "phone/tablet" only.  And then the sanc will check that CPIDs machines before it pays the RAC, and if they lied about it they get 0 reward.  If they really only have devices that match the processor type (ARM or whatever) and none are PCs, the RAC is induced into the superblock.  It adds yet one more complexity to biblepay, but I think its a good complexity.

Would it be more transparent if the Sanc just looks the CPID up to see if it's an arm processor?

By the way, I started on the research assignment and right now I'm trying to figure out how much you can make with your phone per day. I think we might have to have a certain percentage of the block reward to be allocated to cellphones for it to be profitably for them. (So they have enough to buy bread.)

4
Oh, thx! I didn't understand the 'CPU time' option. It indeed does what I was looking for. I'm also going to look for the RAM limiting option.

Limiting the RAM required estimation. Each task on average is probably 500MB, so if you usually have 4 tasks running and it's taking up 100% of your cpu and you want it to be 50%, then just set the RAM usage to 1GB or so. The setting is in percentage so you'll have to calculate that from the amount of RAM you have.

5
Well, it's an AMD Phenom II machine. 4 cores and 4 threads. What I've done for now, is allocate 3 cores to BOINC and 1 core to the wallet (which is mining with 1 thread now (+-250hps), with low priority).
Now both can run at the same time.

It's interesting to read that your Rosetta tasks take up 50% of your cpu power. With my PC (if I don't allocate cores), it just goes up to 100%, and I don't know how to lower that (is there a way to configure the amount of tasks that you do?).

I fired up Rosetta on a second PC (also AMD 4-core, 4-thread), and there Rosetta also takes up 100% of the CPU power.

You can lower the number of tasks by limiting the amount of RAM used in the settings. Or you can just reduce the CPU time setting.

6
We dont need a pool, because the boinc infrastructure is already pooling the RAC for us. 

Id rather simplify the infrastructure than make it more complicated.

Regarding the Gridcoin pool that T-mike mentioned, they have a pool because they dont have enough blocks per day to pay the researchers.  We dont need a pool, because we airdrop the payment once per day.

Regarding mobile devices, we may be able to add a feature to not require PODC updates on tablets and smartphones - but thats still in the wish list - I have not looked at that yet.

Jaap, regarding one thread using too much power, I already made it sleep 200ms between iterations, it could be that you are running this on a low power machine, I suppose I can put in more granular control over this to see if this can be improved.  Right now on my windows dev machine, Im running rosetta 6 tasks : taking 50% of the cpu, the plain vanilla biblepay on 1 thread is taking 13% of the cpu, and its hashing at 270hps in testnet.  So of course we have to consider the fact that we *do* want it hashing on 1 thread so we have a baseline level of average security.  But nevertheless, Ill add a setting to see if we can control the sleep better, and, have it actually attempt to sleep more often - there is also something that I need to look at for the miner process as far as CPU priority - it might be set to high and not normal, meaning that on certain machines its not listening to your wishes, ill check into all that today.

I think what will end up with the regular pool, is I have no intention on taking it down - I still want to make it a place for "Biblepay Central", for Reports, for Orphan related letter writing and functions, but the heat-mining pool might be removed.  If we keep compatibility with the heat mining side, which I believe we have done so far, I may let it run and see what kind of interest we have and what the numbers look like, but most likely with everyone running on one thread, it wont be necessary to have a pool for heat mining and I may end up shutting that feature down.

At that point we would be fully Rosetta decentralized, with no pools.

I mainly mentioned the pool because it allows you to perform DC without having to stake, in our case it allows you to not need a controller wallet on 24/7. But if you can exclude the UXTO validation for phones and tablets that would work too.

7
Hi.
I was fighting with this too :)
I have ordered "weak" linux based VPS for 24/7 wallet but I wanted to run boinc there too.
So, my solution is: run biblepay with setgenerate true 1. Of course it consumes more than 90% of CPU :) so rosetta won't work. But than I install "cpulimit" (apt-get install cpulimit). It is very useful for this. Than you can usse it with command like this: "cpulimit -b -l 15 -m -p 1607" what means allow PID nr 1607 to spend max 15% of CPU. After this my BBP process consumes 15-20% of CPU and rosetta eats rest to 100 ;)

And shared wallet was of my thought too. What about creating some Rosetta/BBP pool? Rob will it be possible to change pool to handle this?

In testnet we use what's call hot sanctuaries where the controller wallet is on the same machine as the Sanctuary. Once in production, you should really have you wallet on your home computer, never run your wallet on the VPS!

@Rob: I think we will need something like the gridcoin pool for mobile devices or have it in the code if it sees an arm processor to drop the UXTO validation. But then I would check to see if more than 10 arm processors are coming from the same IP to stop people from abusing the lowered requirements.

8
Yeah, I'm using the latest wallet and BOINC on my windows pc now. But I can't mine and use BOINC at the same time, because the wallet will use too much of the cpu-cycles and BOINC stops processing.

I don't know how to tweak the settings so that I can use both.

That also brings me to an other question about poor people all over the world using their phone to mine BBP (which I think will be a great application for Biblepay). How would one go about this? Would one person have a wallet running somewhere 24/7, and other people (with phones and tablets) would be running BOINC, and the person with the wallet would divide the collected BBP? Just thinking out loud.

Because I always liked the idea of 'one-click-mining', especially in combination with mobile phones and tablets, because even though - for example - a lot of people in Afrika are poor, a lt of them have a phone (although I don't know how many have smartphones).

Are you using Windows or Linux? In Advanced View->Options->Usage Limits of BOINC Manager you can set the usage for BOINC. I think Rob can fix the wallet to mine less but it's ok for for now. You can also use Oribs's method to limit the cpu usage on linux.

You can also try this for windows: http://mion.faireal.net/BES/

I wouldn't worry about it too much though, Rob will most likely fix it in the next update.

9
For example, if your first machine is running 10 tasks, and lets say WU 98651 was started at unix time 15345321, then your controller wallet will ask what time did that task start, once it receives 15345321 it will send that into the chain as a PODC update (along with a list of every other task it is working and timestamps to save size).  (It queries the timestamps from the Rosetta task themselves, not from the XML file). Then the Sanctuary will compare the XML sent_time, to that timestamp to ensure they agree.  This way if someone on the Rosetta side were to mass validate tasks or alter timestamps, or insert random records in the table to try to get someone paid, those would fail because we would have already sent our timestamps into our chain before the alteration.

Oh...I understand now. That's a great idea!

10
Here is an example of how the sanctuary verifies work units from the xml file:
https://boinc.bakerlab.org/rosetta/result_status.php?ids=976055122,975055123,975055124,975055125,975055126,975055127,975055128,975055129,975055129,975055129

The task info is sent from the controller wallet into the block chain as a PODC Transaction.

For RAC, we actually get that out of the daily rosetta userbase file (its 389 megs per day).  If you go to your Sanctuary SAN directory you can see the "ser" file there.

Rob, sorry, I'm still having difficulty understanding. I see the xml file, can you show exactly what your comparing? (I know it's the timestamp but which one to which one?)

11
The UTXO weight is very similar to POS, where the wallet tries to spend 5% of your balance back to you in a coinstake, and that amount is used for the UTXOweight.  You can raise it with polpercentage=60 for example.

The task integrity is assessed by the sanctuary iterating through all your reported tasks, and comparing the timestamp information for each task with Rosettas XML report for its (live in real time) timestamp info.  With the goal of being to detect any WU tampering.  We do not dock you for an invalid task solved out of your TaskWeight, but in that case you dont get paid any RAC at all for that task, we actually only dock you if your purported timestamps disagree with Rosettas timestamps on a given WU, or if your WU is not reported to the Sanc and you solve it and ask for credit.  This is designed to allow us to assess if you are indeed working on the task(s) you say you are working on and they match.  The RAC reward comes separately after the task(s) are completed, validated and assigned credit, Then the final magnitude calc is : Integrity * RAC * UTXOWeight = Magnitude.

The XML report is the one you obtain the RAC from correct? Where does the task information come from?

12
Rob, when does it change??
  "04fba56d89a5eb38b1b82f8a6240132c_TaskWeight": 0,
  "04fba56d89a5eb38b1b82f8a6240132c_UTXOWeight": 0,
On starting new task, or on the end?
And second T-mike's question... how it is Task Integrity calculated?

oh.. EDIT :) when i will be "mine" only on rosetta without online master wallet I will be DR level 3?

No, the levels are for disaster recovery, like when Rosetta goes down or if there is a problem with the validation modules.

13
So assuming this system is reliable and for 30 days we see 100% taskweight and utxo weight for the average researcher, do you like the feature, IE will this raise the integrity of PODC up to the accepted levels and be a killer feature?

I think it is much improved, great job.

For the task weight, is it calculated from invalid tasks like the one's we can see on the Rosetta website? And the uxto is purely on the amount of BBP available in the wallet correct?

14
3 sanctuaries up.

Before block 5346:
Code: [Select]
"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 9574526.06132864,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 5339,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 0.2604936799427617,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

Code: [Select]
"Command": "getboincinfo",
  "CPID": "e94c1704c75f731f8bfde303f08408ee",
  "Address": "yjKEf6GvMkuiXLXibCCtj9wt4ZEBwQ5i84",
  "CPIDS": "f80ab050ab53459ec937879a046d603e;71f1f1f46deb2f25961c7d9af06f2b31;cc37d0ef74a621379974484f43d3b1c5;95a79cd5829e8315b0b946709930df18;e94c1704c75f731f8bfde303f08408ee;",
  "CPID-Age (hours)": 422035,
  "NextSuperblockHeight": 5346,
  "NextSuperblockBudget": 1380386,
  "f80ab050ab53459ec937879a046d603e_RAC": 430.07,
  "f80ab050ab53459ec937879a046d603e_TEAM": 15044,
  "f80ab050ab53459ec937879a046d603e_TaskWeight": 100,
  "f80ab050ab53459ec937879a046d603e_UTXOWeight": 100,
  "71f1f1f46deb2f25961c7d9af06f2b31_RAC": 441.45,
  "71f1f1f46deb2f25961c7d9af06f2b31_TEAM": 15044,
  "71f1f1f46deb2f25961c7d9af06f2b31_TaskWeight": 100,
  "71f1f1f46deb2f25961c7d9af06f2b31_UTXOWeight": 100,
  "cc37d0ef74a621379974484f43d3b1c5_RAC": 446.56,
  "cc37d0ef74a621379974484f43d3b1c5_TEAM": 15044,
  "cc37d0ef74a621379974484f43d3b1c5_TaskWeight": 100,
  "cc37d0ef74a621379974484f43d3b1c5_UTXOWeight": 100,
  "95a79cd5829e8315b0b946709930df18_RAC": 407.91,
  "95a79cd5829e8315b0b946709930df18_TEAM": 15044,
  "95a79cd5829e8315b0b946709930df18_TaskWeight": 100,
  "95a79cd5829e8315b0b946709930df18_UTXOWeight": 100,
  "e94c1704c75f731f8bfde303f08408ee_RAC": 557.48,
  "e94c1704c75f731f8bfde303f08408ee_TEAM": 15044,
  "e94c1704c75f731f8bfde303f08408ee_TaskWeight": 100,
  "e94c1704c75f731f8bfde303f08408ee_UTXOWeight": 100,
  "Total_RAC": 2283.47,
  "Total Payments (One Day)": 223900,
  "Total Payments (One Week)": 2028581,
  "Total Budget (One Day)": 4141158,
  "Total Budget (One Week)": 48313510,
  "Superblock Count (One Week)": 49,
  "Superblock Hit Count (One Week)": 35,
  "Superblock List": "5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 5247,
  "Last Superblock Budget": 1380386,
  "Last Superblock Payment": 0,
  "Magnitude": 41.98786219423925

After Block 5346:
Code: [Select]
"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 9601523.09132864,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 5350,
  "timeoffset": 0,
  "connections": 9,
  "proxy": "",
  "difficulty": 0.1106453170532401,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

Code: [Select]
"Command": "getboincinfo",
  "CPID": "e94c1704c75f731f8bfde303f08408ee",
  "Address": "yjKEf6GvMkuiXLXibCCtj9wt4ZEBwQ5i84",
  "CPIDS": "f80ab050ab53459ec937879a046d603e;71f1f1f46deb2f25961c7d9af06f2b31;cc37d0ef74a621379974484f43d3b1c5;9
5a79cd5829e8315b0b946709930df18;e94c1704c75f731f8bfde303f08408ee;",
  "CPID-Age (hours)": 422036,
  "NextSuperblockHeight": 5445,
  "NextSuperblockBudget": 1380386,
  "f80ab050ab53459ec937879a046d603e_RAC": 430.07,
  "f80ab050ab53459ec937879a046d603e_TEAM": 15044,
  "f80ab050ab53459ec937879a046d603e_TaskWeight": 100,
  "f80ab050ab53459ec937879a046d603e_UTXOWeight": 100,
  "71f1f1f46deb2f25961c7d9af06f2b31_RAC": 441.45,
  "71f1f1f46deb2f25961c7d9af06f2b31_TEAM": 15044,
  "71f1f1f46deb2f25961c7d9af06f2b31_TaskWeight": 100,
  "71f1f1f46deb2f25961c7d9af06f2b31_UTXOWeight": 100,
  "cc37d0ef74a621379974484f43d3b1c5_RAC": 446.56,
  "cc37d0ef74a621379974484f43d3b1c5_TEAM": 15044,
  "cc37d0ef74a621379974484f43d3b1c5_TaskWeight": 100,
  "cc37d0ef74a621379974484f43d3b1c5_UTXOWeight": 100,
  "95a79cd5829e8315b0b946709930df18_RAC": 407.91,
  "95a79cd5829e8315b0b946709930df18_TEAM": 15044,
  "95a79cd5829e8315b0b946709930df18_TaskWeight": 100,
  "95a79cd5829e8315b0b946709930df18_UTXOWeight": 100,
  "e94c1704c75f731f8bfde303f08408ee_RAC": 557.48,
  "e94c1704c75f731f8bfde303f08408ee_TEAM": 15044,
  "e94c1704c75f731f8bfde303f08408ee_TaskWeight": 100,
  "e94c1704c75f731f8bfde303f08408ee_UTXOWeight": 100,
  "Total_RAC": 2283.47,
  "Total Payments (One Day)": 223900,
  "Total Payments (One Week)": 2028581,
  "Total Budget (One Day)": 5521544,
  "Total Budget (One Week)": 49693896,
  "Superblock Count (One Week)": 50,
  "Superblock Hit Count (One Week)": 36,
  "Superblock List": "5346,5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,
2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 5346,
  "Last Superblock Budget": 1380386,
  "Last Superblock Payment": 0,
  "Magnitude": 40.82153268884372

15
Good point.  Yeah, its very, very close.  Im testing it on my LAN now.  Im not sure if it will be ready tonight though...

No problem.

By the way, I don't think it's very loving to say "get lost". I understand your frustration though.

Pages: [1] 2 3 4 5 6 7 8 ... 11