Bible Pay

Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
I see, I think the checkbox solution would be better then. I'll keep researching.

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.

52
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.
53
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.)

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.

54
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.)
55
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.
56
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.

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.

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

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

Oh ok thats good to know.  Just wanted to know we werent dealing with a one core VPS where the root issue could have been even the base biblepay wallet would be consuming more than 10% LOL, good to know.
Well in the case of my dev machine, I went into boincs GUI preferences and limited CPU use to no more than 50%, and I also have it shutting boinc off when "computer is in use" as this machine has 40 things going on.

So, yes, I will definitely be looking at this thread priority and tailorization today.

59
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.
60
We dont need a pool, because the boinc infrastructure is already pooling the RAC for us. 

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.


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.
Pages: 1 2 3 4 5 [6] 7 8 9 10