On 1/1/25 19:23, Paul Eggert wrote:
On 2025-01-01 16:32, Jacob Bachmeyer via cfarm-users wrote:
Perhaps a combination of nice(1) and ulimit(1) would be suitable?
Not for mining, no. It would still consume resources that are better
used for cfarm's intended purposes.
The intention is to limit "miner" testing to idle time, or as close to
that as we can get.
Also, note that I am suggesting allowing /testing/ "miner" software, not
/using/ it.
For testing, it should be possible to set up an environment with a known
state, instead of using a "live" blockchain, so there is no need to
actually store the blockchain structure, which I agree would be an
intolerable waste of disk space.
In fact, for regression tests, you would /need/ that past tip of the
blockchain and transaction buffer state in order to make the test
repeatable. You could also artificially lower the block difficulty to
run the test faster.
For performance tests, ulimit(1) can be used to limit each run to a
fixed amount of CPU time, with optimization measured in progress made
before SIGXCPU is received.
I would suggest ... making very clear that "mining" for profit is not
permitted
That wouldn't suffice, as it's too easy for me to say that I'm not
doing something for profit, when I get to define "profit". (See what
many US "nonprofits" do.)
Simple definition: if the results of "miner" "testing" are submitted to
a blockchain network (directly or indirectly through a pool), excepting
Bitcoin "testnet" or analogous systems where the tokens are agreed to be
worthless, it is considered to be for profit.
In other words, claiming a block reward is "profit" and forbidden on the
cfarm. Your access to the cfarm is gratis, you are not allowed to use
it to directly acquire "money" in the form of cryptocurrency tokens.
An accidental submission can be remedied by burning any tokens
received. (For Bitcoin, "send them to Satoshi", although that cannot
happen because you were testing on "testnet" where the tokens are
worthless, right?)
Another option could be to use a provably invalid address for "miner"
testing, so any rewards received will go nowhere, which amounts to
burning the tokens.
There should be viable solutions here, solutions that also scale to less
controversial uses such as CI or automated snapshot builds, which could
then be run with priorities below interactive users but above "miner" tests.
-- Jacob
_______________________________________________
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users
