Yes, I know you was suggesting that, see this posts last paragraph, and I said it sounded a good idea, I just thought there may have been a reason he couldn’t or didn’t want to implement that solution.
Felix (Foxy Pool) had to increase the transaction fee’s for payouts to ensure they arrived in a reasonable time frame.
The randomness over the past few months seems to be less random. Max has a 3.125% fee, right? 3/9 (33%) going to Max the past two months for me. I’m doubting what is going on now tbh. I have been winning less consistently since the ongoing dust storm started also. Maybe it’s all a coincidence.
This problem has been discussed many times before. It’s just bad luck, and there is no easy fix for it…
It’s the price of having it decentralized.
Thanks for answering! What will happen later with CHIP 22? I’m tired of bad luck so I’ll leave it to the next person who replies after me…
CHIP 22 will not change anything regarding the fee.
Thanks to our proposal, CHIP 22 will issue warnings when a harvester unfairly claims a higher percentage of block rewards than advertised. This is easy if the decision to claim a reward is based on a deterministic random source and the decision algorithm is made public. Initially, we suggested classifying such cheating as critical errors, but you opposed this for multiple reasons.
Very valid reasons, no doubt.
but will it have remote compute
I think only you wants it. I want 300% compression support
I really don’t follow. Based on my understanding CHIP 22 will log an ERROR if the fee is taken wrongly. There should be no cheating possible. At the same time users need to check the claimed fee percentage of course.
Is it possible to send every farmer reward to a wallet, then when it lands in that wallet deduct the fees and send the change back?
Obviously this would rely on the sending address being identified back to the original farmer, and software running to process what lands in said wallet.
PS I’m fine with the current system but if the above was possible it may be a better option especially for smaller farmers.
It’s possible but too complicated and relies on a central server (ie. not decentralized).
It’s basically the same as running a pool.
@madMAx43v3r
We proposed to stop harvesters from claiming a reward block above the initially advertised threshold. You opposed this and now the farmer will pass this block to the node anyway. Consequently, users would need to routinely check logs to find out if the harvester is cheating. However my previous comment address a different issue. There is a simple approach to verify fairness of a reward claim and no blind trust is required from the users. You can even copy this algorithm from the CHIP and make a minor release update to the current Gigahorse version. This should stop doubts and speculations on a possible bias.
What function would that server need to perform? Will it be needed to match that 0.25 to a particular farmer, or this information can be passed to the server without the need for decentralization?
Does the farmer knows which height the proof was submitted for, and can this height be inferred from the won block notification?
By the way, it looks like Chia may be looking into a hard fork that would potentially make compressions not feasible.
I would have to implement a full blown pool backend, where the farmer submits proof that he farmed a block and the farmer reward will be sent to the pool.
The pool backend will then perform the payouts while keeping the fee.
In any case it’s way too complicated, and centralized.
That’s the pool implementation, so we are not talking about it.
My question was a bit different, whether in the current implementation your existing farmer can collect enough information during the submission process to match it to the information provided with either the block info for that submission or the 0.25 coin generated (without going the pool route).
Isn’t 2/3 of the netspace already compressed? How does it work?
You can infer from the block if the fee would be taken or not. However if all the farmer rewards with GH are sent to a backend, the original farmer address would be lost. Which is why you would need a separate channel to the backend to submit extra signatures together with your payout address.
All i need is this and I’m good…
Yuck!
