[cfarm-users] Compile Farm acceptable usage---low priority batch jobs

[Jacob Bachmeyer]

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