Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 69. (Read 243376 times)

Oh ok, I see what you mean, thats a good idea.  You basically mean we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC.  MIP and I were discussing unbanked last night (maybe leaving a zero stake requirement for mobiles who are unbanked with < 100 RAC, and giving them a way to associate the CPID on the biblepay-mobile wallet).

Yeah, we could actually create a method that would allow association for unbanked with 0 bbp.  Im not sure if this will be ready in testnet first release; but the first baby step is:

- Allow zero staking requirements for cpids with < 100 RAC - so we find these unbanked cpids, as long as they are in team BBP or GRC, they pass and get included
- MIP looks at making the associate message on the mobile
- I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks).

I've already got the external purse working; Ill look into implementing these things as I think this helps bring the barriers down.

As far as the nomp, I tweaked a few things just now and it appears to be working; Ive reset the servers shares found counters - if we can get below 10% rejects, I believe its fixed.
You cant get much below 5% as there are a lot of chatty unexpected breaks in the protocol. 
Besides, a rejected share is not necessarily meaning the hashes were wasted; a lot of these mean the stratum job was changed on the server side before the miner submitted the solution for work that was 15 secs old; IE sometimes, the server finds a new merkleroot  - changes the job for its 50 clients - while at the same time the client is sending a solution for work that is 20 secs old - so those are not actually hurting the team as far as finding a block.
But I agree, efficiency rejections should be fixed.  So if we get below 10% again Ill share the params.

If you're going to make PoDC the main GSC contract, I would consider not starting the exponential stake until after you go past a certain RAC like 5k RAC. So, from 1 RAC to 5,000 RAC no stake is required. Why do this? If you create zero barrier to entry, you will get more BBP members. That's also where zero (0) fee registration comes in. You should be able to participate in PoDC 2.0 with 0 BBP in your wallet.

Otherwise, you will need to do airdrop or faucet like last time to get people to BBP. That created a lot of support work and we're just repeating the same scenarios from PoDC 1.0 all over again. Let's learn from the previous pain points.


I've seen it happen on nomp.biblepay.org before. You can see the console error when you run with the -P (protocol) parameter.

I see it on my test pool too but takes some time (10 minutes?) before it shows up. The rejected shares are primarily duplicate, but this out of range shows up less frequently.

Sun-

I see our rejects have crept up to 20% or so, let me take a look at the core problem.

MIP notified me this version is ready.

Btw, you can type 'exec join' to see 'v1.1' to know you have upgraded.

Please dont uncomment that; thats only for bitcoin-lightning.  Or coins who have difficulty that changes during the same block.

Lets look at our screens and see what the reasoning is for dupes first - I had it down to less than 10% then something appears to have changed recently, sliding back up to 20%?

Do you have swap space on this machine btw?
And when you install bbp, do you let it sync from zero?

It seems like your nodes do have multiple recurring consecutive issues - but I usually see 90 days of uptime per run.
When I have problems I see it is confined down to the same few problem nodes though - somethign to do with region.

Something is going on with your nodes being able to gather votes from the network.
Is your firewall set up in a way to block our gobjects propagation somehow?

Please check exec health and make sure it matches the exec health in the pool.biblepay.org | reports | Sanc health report?

I see the same 10 nodes appear over and over ; could be a Country issue - where nodes aren't reaching out to propagate the votes; but first we need to ensure your votes are falling behind and creating a discrepency with the network?

That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic).  Please check the server and ensure the timezone is correct and the time is correct?

Is it only happening on your mining against your own server, or ....

It wouldn't make sense to design 0 bbp requirement when 100% of our use cases require bbp now.  Cameroon requires bbp to pay the bill, podc requires a daily stake, and POG requires a tithe, etc.

Dash has already expirimented with 0 cost transactions and its not being embraced because it can be an attack vector.  We already do support 0 fee transactions - that store data in two ways - but they are 'use at your own risk'.  Basically, they have a 99% chance of being delivered, but a miner could theoretically modify the client and filter those.  Although we do have a more decentralized network than bitcoin and dash, so it probably wouldnt happen (I say this from the perspective that we have distinct CPUs mining, not asics).

Regarding data storage we already have two types of storage:  We use op_return in our non financial tx's and we can store a lot of data, but you pay by the byte.  We also store data in our proprietary transaction format at the end of each vout.  This is where prayers are stored. 

So there is no lack in creation or transmission of PODC messages in biblepay.  However we do charge the transaction fee for the message to avoid the attack vector.

I wanted to see if there is a way to send data when the block is generated with no BBP involved (0 tx fee and no BBP sent to anyone). Was hoping new participants with 0 BBP in wallet could register with GSC.

in the nomp pool, I see shares rejected with this error message:


what does this mean and why does it happen?

While we are currently in block 154642, for the second day in a row I got my sancs stall behind at block 154590. Now I see, one of them even crashed

I moved those sancs from several $5 Vultr VPS to a bigger hardware a couple of days ago and host all in the same machine with different ports same IP, and they are all now behaving the same, they stall during the night, I restart in the morning, they work for about 15h, then stall again.

Yesterday running reassesschains worked for me, but today is inneffective.

Rob I will send you the log of the crashing MN by email, you will probably find some interesting information there.

OP_RETURN allows you to store a limited amount of bytes.
Also in Biblepay we have an extra "message" string field to add information into a transaction.

Rob, can OP_RETURN be used as a way to store GSC data (e.g. exec join) for PoDC, PoG, Healing? I don't understand OP_RETURN either, but thought you might know more.

https://en.bitcoin.it/wiki/OP_RETURN
https://dash-docs.github.io/en/glossary/null-data-transaction
https://github.com/bitcoin/bitcoin/pull/2738

Rob, how do we set up stratum send work restart request more often?

I was looking at pool.js - with vardiff. The comments made me hopeful that perhaps if the difficulty is adjusted often, this would be a way to workaround the duplicate share issue I've been facing in the pool I've been setting up?


Update:

Oh well.. so much for that idea to uncomment it.

Capulo,

I released this just now for windows:
https://github.com/biblepay/biblepay-evolution/commit/a63bab6a14717dbaf4bcb8e634ae9c3a58d522a7

Hopefully this will solve your problem.

MIP is building the Linux version, but I'm not sure yet of the eta.

To use the command please type:
exec join pog nickname true



Good luck.

I'm sooo surprised that unjoin join did not work.  Well at least we know your CPK is in.
I'm also surprised you don't receive an error or anything after the confirmation that it will tithe.

Let me add an RPC option for you to force a 'join' and Ill report back in a bit.

only this is in log  after trying to tithe
2019-10-30 21:39:52
Tithing 2000.000000 BBP into the Orphan Foundation for POG, because expected ROI is 2394.548592 percent.Misbehaving: 107.172.188.132:40000 peer=20 (0 -> 1)
2019-10-30 21:40:08 Misbehaving: 107.172.188.132:40000 peer=20 (1 -> 2)

and when i try unjoin and then join i get error; already in chain...
i still think i'm not joined, how to force join cmd?

I installed my pool as root, to ensure the paths would work for biblepay evos block store location, etc. 
Of course we should be careful to block all firewall ports except 80 and the stratum ports etc.
And to restrict the RPC port to the pool only with rpcallowip.

I wonder why does your sanc go down so much?  
Looking at mine, still no problems.  

If your sanc goes down more than once a month, we should be drilling into the logs and finding if we have a problem.

You can safely ignore the peerMagic error, that is only needed for the 'c' version of blockUpdates - and we dont have that anyway and it wont hurt anything.