<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 2 Jan 2025, 02:55 Jacob Bachmeyer via cfarm-users, <<a href="mailto:cfarm-users@lists.tetaneutral.net">cfarm-users@lists.tetaneutral.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/1/25 19:23, Paul Eggert wrote:<br>
> On 2025-01-01 16:32, Jacob Bachmeyer via cfarm-users wrote:<br>
>> Perhaps a combination of nice(1) and ulimit(1) would be suitable?<br>
><br>
> Not for mining, no. It would still consume resources that are better <br>
> used for cfarm's intended purposes.<br>
<br>
The intention is to limit "miner" testing to idle time, or as close to <br>
that as we can get.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No, it should be zero time, not just idle time. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, note that I am suggesting allowing /testing/ "miner" software, not <br>
/using/ it.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I suggest banning it entirely. The cfarm has no obligation to provide resources to miners, even for testing.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For testing, it should be possible to set up an environment with a known <br>
state, instead of using a "live" blockchain, so there is no need to <br>
actually store the blockchain structure, which I agree would be an <br>
intolerable waste of disk space.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Just because something is possible doesn't make it useful. Why are you trying to find a way to support something that doesn't need to be supported?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In fact, for regression tests, you would /need/ that past tip of the <br>
blockchain and transaction buffer state in order to make the test <br>
repeatable.  You could also artificially lower the block difficulty to <br>
run the test faster.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Or ban it.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For performance tests, ulimit(1) can be used to limit each run to a <br>
fixed amount of CPU time, with optimization measured in progress made <br>
before SIGXCPU is received.<br>
<br>
>> I would suggest ... making very clear that "mining" for profit is not <br>
>> permitted<br>
><br>
> That wouldn't suffice, as it's too easy for me to say that I'm not <br>
> doing something for profit, when I get to define "profit". (See what <br>
> many US "nonprofits" do.)<br>
<br>
Simple definition:  if the results of "miner" "testing" are submitted to <br>
a blockchain network (directly or indirectly through a pool), excepting <br>
Bitcoin "testnet" or analogous systems where the tokens are agreed to be <br>
worthless, it is considered to be for profit.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Simpler definition: no cryptocurrency, nft, blockchain or bitcoin.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In other words, claiming a block reward is "profit" and forbidden on the <br>
cfarm.  Your access to the cfarm is gratis, you are not allowed to use <br>
it to directly acquire "money" in the form of cryptocurrency tokens.<br>
<br>
An accidental submission can be remedied by burning any tokens <br>
received.  (For Bitcoin, "send them to Satoshi", although that cannot <br>
happen because you were testing on "testnet" where the tokens are <br>
worthless, right?)<br>
<br>
Another option could be to use a provably invalid address for "miner" <br>
testing, so any rewards received will go nowhere, which amounts to <br>
burning the tokens.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Maybe for would be reasonable rules for a server farm available for testing cryptocurrency tech. But the cfarm is not such a resource, so doesn't need to come up with any such rules. It seems like a waste of time trying to craft such rules, just say "find somewhere else to do this".</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There should be viable solutions here, solutions that also scale to less <br>
controversial uses such as CI or automated snapshot builds, which could <br>
then be run with priorities below interactive users but above "miner" tests.<br>
<br>
<br>
-- Jacob<br>
<br>
_______________________________________________<br>
cfarm-users mailing list<br>
<a href="mailto:cfarm-users@lists.tetaneutral.net" target="_blank" rel="noreferrer">cfarm-users@lists.tetaneutral.net</a><br>
<a href="https://lists.tetaneutral.net/listinfo/cfarm-users" rel="noreferrer noreferrer" target="_blank">https://lists.tetaneutral.net/listinfo/cfarm-users</a><br>
</blockquote></div></div></div>