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

Great!

Ok, it's redeployed, please try now.

For some reason the download links are again showing only a few kb in size.  Good news though is that 1.4.4.2 has been working flawless for me on several machines, switching between ABN and Funded seamlessly and no crashes so far.

I've been getting a lot of complaints about the cloak feature in the pool, so I think we need to remove it.
(Some users think the highest rewarded users are non-funded ABNs).

I think its better to error on the side of transparency in the pool than give the impression we are hiding something.

First I will uncloak the users, then we will remove the checkbox in the user account settings.

Nice, this should help others mine as well then.

I imagine the logic for this can get rather complex (when it comes to mixing/matching coins) but hopefully not too bad.

BiblePay
1.4.4.3-Leisure Upgrade

- Enhance ABN/GSC tx creator to sort by coin-age first, then create the
tx (IE use lowest coin age possible).

After updating the pool code, some other things needed updated over the last few hours; finally I believe these are resolved.

Now please check the non funded vs funded, and they should be correct now.

Also: Pool leaderboard seems to be missing a 0/digit somewhere. Just noticed it, not sure if you are working on it currently.

I made an edit to the post before yours as well, but I can see the difference already.

So long as they continue to game funded-mining now, they could only raise their deducted hashrate on the sliding scale, eventually providing up to 99% of their hashrate to non-funded users based on funded blocks solved(if it can go that high,) correct?

OK, now the ABN-provider miners are receiving the hashpower docked from the funded miners.

Let's see how this plays out.

Yes sir, that is exactly it.

Exceptional! I hope that it can be done, because I see that miner growing with hashrate (up to 4.1 million now...) and his subsidy reward is over half of what's allotted.

Even though he's docked for hashrate for not having coins in his wallet, he's still outmining everybody that is holding coins.

Edit: With this idea, it keeps the pool completely competitive even if somebody were determined to attempt to use a botnet.

Even with a botnet(people will always try), the additional deducted hashing would still assist the chain and non-funded miners and boost them to a competitive level so that they couldn't game the network no matter the amount of hash they poured in. It might give them second thought to even doing such in the first place, as it would use 100% of their mining power on their end, but distributing most of it to the loyal non-funded miners based on how many funded blocks solved.

In this case, it would almost push the idea that buying BBP to fund their mining would be a better choice than deciding to game funded mining.

I think I see and agree with what you are saying.  You are sort of saying that its irrelevant how much HPS the 'non-funded' miners are mining with, that their HPS should really be Boosted by the amount docked from the funded, because in reality, the non-funded miners are supporting the ABNs for 65% of the pool, yet they are not even 10% of the hashpower (IE its not a fair distribution of hashpower compared to the bonus they receive for their tiny contribution in HPS).

So another words, we need a better algorithm to provide a bonus for the ones providing the ABNs.


Something like : HPS docked from the funded miners gets ADDED to the HPS of the non-funded ....

Let me look into the technical feasibility of this.

So I took a look at this in great detail.

First of all, I just want to say this particular issue is related entirely to our coin selection algo on the input side of the ABN (the chooser that chooses coin age to spend in the GSC or in the ABN).

The enhancement we added yesterday was related to creation of bankroll denominations for 'change' (IE creating more small outputs when we create GSC transmissions).  So for example, on the output side, if the wallet needs to break a 1 million BBP coin, as of yesterday, it will break this up automatically into 10 outputs of 100K each, so that each will age, and give the user more individual future inputs.

But lets hone in on this particular issue from Shorty:  The inputs chosen for an ABN.  The issue is BiblePay - the way it is today - can choose any coin in the wallet, because the default sort order is not based on coin-age.

So the crux of this boils down to this:  We should sort the entire wallet by coin*age ascending first when creating GSCs or ABNs.   That would give the GSC/ABN creator the ability to use up the smallest coin age coins first, and never skip by and spend a big coin (or a coin with high coin age).

I'll prioritize this change next, and we will make the wallet sort by coin age when choosing coins for ABN or for GSC.

In my thinking, I'm not sure if it'll take emissions away from the big hashpower coming from funded abn -- as non-funded miners that recieve the "bonus" would simply keep them relevant in their own mining. This gives a person with a single CPU and a wallet full of coins the ability to remain relevant if several big miners suddenly came and threw all their hashrate at once on funded miners, which would game the emission rewards from those non-funded either way.

So, if three big miners came online with a total of 6 million hashrate each on funded pool miners, they would most certainly game the network in its current state, choking out small miners of rewards unless the sliding scale ratio of a "fee" were to pass the % of hashrate deducted from their mining and distributed it evenly amongst those non-funded.

Altogther, with 3 miners like that they would be providing about 9 million hashpower (with 9+ million deducted) against smaller miners with 1-500k hashpower(non-funded, without the distribution)

First let me say this:  The pool currently charges zero fees for normal mining (we charge 0 for everything), and additionally, zero fees for the ABN (the abn amount docked from each miner is just passed on to the rest of the pool).  (Just to clarify) - I realize you arent insinuating the pool is getting any of the abn fee , just throwing that out there for others.

So I think what you are saying is because the Funded ABNs are now the minority, since they have a smaller HPS in total than the pool, they should actually receive even a greater reward because the non-funded miners are getting a greater share of pool total emissions?

Understandable. But even for that 65% penalty, if hashrate is in the millions (6 million + to be precise) wouldn't that 65% cascade down to miners WITH abn?

I am only seeing maybe a 10-12k increase in hashrate per my one miner according to the pool, (comparing to RPC because of my own abn funding.) I understand it should cascade to all miners using their own abn -- but it doesn't feel like it is calculating fully for other miners. How does it split rewards from funded abn to nonfunded, I guess is what I'm trying to ask.


Edit for better example:

Big miner is using funded abn to mine across a ton of rigs, produces 6 million hashpower in total but he's solving far more blocks than miners with their own ABN, so his fees get pushed up to 67%. Technically speaking, I believe the pool deducts 67% of his total hashpower and is suppose to divide it evenly to those with ABN mining -- so they can remain competitive against big networks / hash that aren't buying BBP to fund their own wallets.

So, if there were 10 miners with their own ABN, and this joe comes and kicks all his miners online producing 6 million hashpower, it should take 67% of that 6 million (3.5 million?) and distribute it evenly to the 10 miners using their own ABN, which would up their hashrate by 350k each (on the pool, giving them part of the distribution correctly), ontop of what their rigs are producing. (since they're getting it from the funded miner)

Is that how it works?

Let me analyze this in great detail.

Yeah, I see the non funded guys are solving 65% of the blocks, and diff did rise above 7000 recently.

I think we should let it play out for 30 days and in the mean time we can discuss it.

I'm open to hearing any opinions.  On one hand it just means that non funded miners are willing to take a penalty to keep mining, and it sort of points to our funded miners not having as many mining machines (which makes sense as they are different people - probably investors vs. miners).

The question is, are we really seeing "bot-net" activity; I would think not really, as those are the miners that just want to mine (as compared to a nefarious group that wants to copy biblepay out to 300 machines in a school, etc).  These miners do have to create pool accounts and show up in the leaderboard. 

So we have to think of are we creating a fair environment for everyone and are the newbies happy also.

shorty reported in Discord:


Shorty's ABN funding tx in block 132094
http://explorer.biblepay.org:3001/api/getrawtransaction?txid=964dc8190d4645085dce08f55594b9293d465b08728c0754ec4264e58b720036&decrypt=1

Contains many VINs, many of them are 150k bankroll denominations he prepared some time ago:
Example of one:

Looking at 3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0
http://explorer.biblepay.org:3001/api/getrawtransaction?txid=3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0&decrypt=1

So he asks if this is correct behavior (sweeping way more coins for ABN than the ones necessary).

EDIT: I saw those coins had low age so it might be correct that all of them were used for the ABN tx, but still the coins in all have far more weight than necessary.

Kinda worried that botnets are gaming the system, even with funded ABN.

They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.

and 65+ machines

Ok,  to revisit the govobj data--
 When you erased the chain data, did you also delete all of your .dat files btw?  Its worth at least doing this at least once to rule it out (IE manually delete the .dat files like mnc* and gov* and mnp* and then start with -erasechain=1).  Then move to step 2.

2)  If you have another silent crash after deleting the .dat files, and trying 4d version:
At that point you will need to go into our testnet thread and run the Testnet version for windows against prod.  It has a stack trace feature and it should tell us why windows10 is crashing for you.  (If it doesnt work, we will have to work through the process of getting the stacktrace set up on windows 10 for you).

3) This brings up another issue:  Does your wallet have a CPK?  If not, can you please create one with 'exec cpk nickname'?  That could be the silent crash.

4) Regarding switching back from funded abn to non- Ill test that on my dev node; I remember specifically testing that and it was working, will get back.
4b) On the non-switch, please ensure your workerid=non_funded (IE=0), and workeridfunded=funded (IE = 1) in the pool?  Two distinct workerids?
4c) When it continues to mine in funded mode, does the poolinfo3 show the workerid name you expect?