"People" in general are bad for the environment.  The more people who mine, the more electricity that has to be produced, and yes mining does take a lot of energy to mine, anyone can base it off the total power of XXX and YYY, but the only TRUE way to see how much it takes it for everyone to STOP mining completely and observe the change.  This will never happen so there is no real way to test it.

Many have mentioned for bitcoin to goto proof of stake as well.  I am not a crypto fanatic, wish I was and wish I hadn't lost accounts that I "tested" with back in the day, but oh well.  Obviously crypto is everywhere and when I wanted to get back in it, found out that "normal" individuals with "advanced" hardware really can't do it successfully.  I ran my three graphics cards recently 2070super for about a week and my electric bill was over $70 more and definitely didn't make that up...

Anyway back to a suggestion. 

I have been reading things here and there (definitely nowhere near a "noob" status yet, still a baby).  I see coins that went proof of stake/etc... so I have a suggestion..maybe someone with knowledge can tear it up so I could learn some more.

The point of decentralization is to have as many "nodes" as possible running to keep it decentralized. If everyone stopped hosting nodes, the whole system would crash (from my understanding)... so with that...why not make bitcoin mining all about decentralization/running nodes/verification.  Ehereum setting it at 32 is crazy for people, to mee it should be incentivized to run a full node...

1) lower the Proof of Work to a simple calculation that allows a basic CPU to do the work (no more advanced fpga/graphics cards/etc)...(lowering the electricity draw/electronic waste SIGNIFICANTLY)
2) not sure how, but I'm sure a list of all nodes is somehow on the network, but iterate through the node addresses and use something like 60% of them to send the "WORK" to.  The Node on top of the list gets the "coins" for the original work, the rest validated that it was correct, the next 60% is iterated down one by one with that 60% so that everyone does the work/validation/has a chance to get the coins the longer the node stays active.

Example

Transaction 1

List of Nodes
Node1
Node2
Node3
Node........1,000,000


So it starts at Node1 and grabs the next 600,000 nodes (60% of the current 1,000,000).  Node1 Does the simple PoW, Node2-600,000 does the same work, and validates that Node1 is correct/adds to network, node1 gets coins!!!! YAY thanks Node1 for helping keep Bitcoin Decentralized....

Transaction 2
Node2 through Node 600,001 get sent the work, Node 2 does the simple calculation, Node3-600,0001 validates its correct/adds to network/node 2 gets the coins!!!!.... and it just repeats....

The key is that they must be running a full node.  The node list will be based off an IP address so its not like running 10,000 nodes on a single IP will benefit anyone. 

______
Something else to think about is the "private key lottery".... if bitcoin can keep a blockchain on transactions, why can't it keep a blockchain of "password hashes" that are part of the validation process in order to complete the transaction process.....

public key address: bcrypt/scrypt/etc or some long hashing function that incorporates the private key/users made up password

This way, as technology evolves, its not just how fast can you go through the range 2^1-2^255, its can you provide the additional potential of the unknown.

____

anyway... food for thought

awesome program, thank you for your hard work...  Signed up just to post these suggestions...

I know in its current form, its just a start from one point and 1by1 increment....

1) like many the -stride function (aka increment up by 100,000 instead of 1)
2) ability to check for the REVERSE of the hash
3) -random function with some options
      a) ability to also create a "mask" that will increment each position a certain number (for instance 000000001100111000111000110045980813040) would increment each position by the number in that position forwards
          and backwards
      b) again to do the reverse with the above options
      c) if possible restrict the number of duplicates in a row...example... -max-duplicates 3 means in the key no more than 3 of the same letters/numbers in a row... (not sure if this can be controlled with "random" but thought I would ask)

4) ability to input your own hex keys as a file input/stdin
5) on the command line display have the ability to see the status/pause/etc.. kinda like hashcat

Thank you again for your hard work.