Why Bitcoin Needs to Go to Zero: A Comprehensive Look at its Negative Impact

 I wanted to play with ChatGPT and have it create a blog post.  Here is my its first creation with some input/guidance from myself.

Bitcoin has been touted as a revolutionary technology that can transform the way we store and transfer value. However, there are numerous reasons why it needs to go to zero. While the underlying technology behind Bitcoin, known as blockchain, is genuinely innovative and potentially transformative, the issue with Bitcoin is that it is a bad use case for this technology. In this blog post, we will examine the various reasons why Bitcoin needs to go to zero and why blockchain technology should be used in more responsible and sustainable ways.

1. Environmental Damage

The process of mining Bitcoin is incredibly energy-intensive, consuming vast amounts of electricity and contributing to climate change. This high energy consumption is a significant problem, with studies showing that Bitcoin's energy usage is equivalent to that of a small country. The environmental damage caused by Bitcoin mining is already apparent and is set to become more severe unless we take action. Bitcoin mining in China alone could produce enough greenhouse gas emissions to raise the country's temperature by 2 degrees Celsius by 2033.

2. Facilitation of Illegal Activities

Bitcoin is often associated with illegal activities such as money laundering, drug trafficking, and terrorism financing. Its anonymity and lack of regulation make it an attractive option for criminals looking to evade detection and launder money. The prevalence of illegal activities associated with Bitcoin means that it poses a significant threat to global security.

3. High Volatility

Bitcoin's high volatility makes it a risky investment option, with prices fluctuating wildly over short periods. This volatility not only makes it difficult to predict the value of Bitcoin but also increases the risk of financial losses. Bitcoin's volatility can lead to financial instability, making it a significant threat to the global economy.

4. Lack of Regulation

Bitcoin operates outside of traditional financial systems, making it difficult to regulate effectively. This lack of regulation has led to numerous frauds and scams in the Bitcoin market, resulting in significant financial losses for individuals. Bitcoin's lack of regulation also makes it challenging to prevent illegal activities associated with it.

5. Harming Societal Well-being

Bitcoin's high energy consumption, illegal activities, financial instability, and lack of regulation are all factors that can harm societal well-being. The damage caused by Bitcoin extends beyond financial losses and environmental degradation, creating a world where criminal activities are facilitated, and financial instability is rampant.

It is important to note that the underlying technology behind Bitcoin, blockchain, is a genuinely innovative and potentially transformative technology. Blockchain has the potential to revolutionize a range of industries, from finance to healthcare, by providing a secure, transparent, and decentralized way to store and transfer data.

However, the issue with Bitcoin is that it is a bad use case for this technology. While the idea of a decentralized currency that operates outside of traditional financial systems is certainly compelling, the reality is that Bitcoin has become a vehicle for speculation and illegal activities, rather than a useful currency or payment system. This has resulted in the negative consequences mentioned earlier, such as environmental damage, financial instability, and harm to societal well-being.

In conclusion, while blockchain technology has tremendous potential, Bitcoin is a bad implementation of it. It is time for us to recognize the shortcomings of Bitcoin and focus our efforts on finding more responsible and sustainable applications of blockchain technology. By doing so, we can ensure that the benefits of blockchain are realized while mitigating the negative consequences associated with Bitcoin. It is time for Bitcoin to go to zero, and for us to move on to more viable and sustainable uses of blockchain technology.

Virtual Transparent Firewall not working

I have been successfully using a pfSense community edition firewall to protect my home test lab.  My local ISP delivers me a subnet of addresses directly so I need to leverage a transparent firewall or "bridge" to protect the lab.  After rebuilding a few pieces of the lab I restored my pfSense configuration to a new host/VM and found that no traffic was passing.  I did a packet capture and did not see any communication traffic.  I thought that *something* must be blocking the traffic before it gets to the pfSense transparent firewall VM.  A lightbulb went off in my head back to my VMware architecture days about the 3 security settings you can set on a virtual network switch, promiscuous mode being the easiest to remember.  I played with turning these on/off 1 by 1 and found I needed both Promiscuous mode and Forged transmits security turned off (Setting to Accept) for this pfSense transparent firewall VM to operate correctly.  Obviously turning these features off does open your ESX Host up to accepting more (possibly malicious) packets, but the ESX host is simply passing the packets along to the VM(s) attached to that Network on the host.  You can limit your exposure by only having a single VM on that host's "raw internet" network and a  single (same) VM attached to the inside "filtered internet" network.   Assuming you trust pfSense to do its job, turning off these features should work for most home use cases.

yum update failing on Google Cloud VM

 I use google cloud's smallest VM for hosting my own DNS servers.  I use the f1-micro instances that are very limited in memory and cpu, but cheap!

During a regular yum update I received the following error and my instance (VM) failed to reboot.

During the Cleanup part of yum update the google-cloud-sdk gave me this error:

/var/tmp/rpm-tpm.rdz2f9: line 4: 11963 Killed gcloud components post-process --force-recomplile warning: %postrun(google-cloud-sdk-360.0.0-1.x86_64) scriptlet failed, exit status 137 Non-fatal POSTUN scriptlet failure in rpm package google-cloud-sdk-360.0.0-1.x86_64

I read on this post - https://stackoverflow.com/questions/40163733/upgrading-google-cloud-sdk-fails-on-configure that this person had the same issue to due using the smallest GCP instance size, but they chose to stop some processes to free up memory before they did an update.

My resolution was to first build a new VM with a previous snapshot of the VM before it was messed up by the update.

Just for good measure I did some yum cleanup with yum-utils before anything else, then update the single google-cloud-sdk, before updating the rest without error.

sudo yum install yum-utils

sudo package-cleanup --dupes --noplugins

sudo yum clean all

sudo yum clean dbcache (probably redundant)

sudo yum update google-cloud-sdk (this took a long time)

sudo yum update (update all the other pieces)

After this everything was happy!

How to setup DNS forwarding for specific domains (i.e. home.lab)

I recently purchased a USG-3P (Unified Secure Gateway) Ubiquiti Unify Home router.

With its DHCP, everything points to this device as the DNS server for the house.  I like this because I don't want to depend on my home lab being up for DNS (Internet) to be working for basic name resolution.  However, I want my xyz.home.lab domains to resolve.  I did a bunch of googling and found I needed to modify the config.gateway.json file, but I couldn't find it on the appliance.  I then found this article, so I just needed to SSH into my USG and run a command such as ---  

set service dns forwarding options server=/lab.dns/172.16.1.10

This seemed great, but the command gave me “invalid command”, which it turns out you need to go into configure mode first on the USG,  just type ‘configure’ and hit enter and then run the command above.  After that you type commit, then save. 

This almost makes my home work, but my primary mac machine is always VPN’d into work, and all DNS requests are sent there, so my home.lab still doesn’t work from this machine.

On my mac I needed to mkdir /etc/resolver, then in the /etc/resolver directory, then create a file named home.lab

Adding the following lines ----

nameserver 172.16.1.10

nameserver 172.16.1.11

After I saved that, I can now resolve my home.lab dns from everywhere, and I get the bonus of being able to still work just fine if the lab (DNS) is down.

Team Rules

 I dug this up from many years ago, just as good today as it was then!

Team Rules - by Brian Smith

1. It's all about the customers! We must provide a reliable and cost effective solution!
2. If there are customers on it, then it is in production and will be treated as production until the customers are off and it is NOT in production.
3. You can't say that's not my job, you may direct someone to the appropriate person or group if you can’t help them.
4. All Negative customer experiences must be escalated, no matter who you believe is responsible
5. If a project deadline is in jeopardy, you must escalate immediately.
6. There is no excuse use official methods (i.e. Open an Incident in the official ticketing tool)
7. When you are on call, you must be available to work on an issue.
8. Document before you execute and open a change for all changes (use official tools)
9. Do your best to not directly delete anything, take offline for 3-7 days when possible

SRE BUZZWORD BINGO

 ok, it's not bingo, but it is a crossword

https://crosswordlabs.com/view/sre-buzzword 

Enjoy!

What does SRE commonly do, the five principals of SRE

 Here are some slides I've presented at a number of places people have asked me to post.

Lastly i'd like to add that "Self Correcting Systems" are vital to the success of SRE.  Of course we all hear about auto-remediation or self-healing technologies.  While those are self evident I personally recommend you think about your people and processes.  Think about the motivations, rewards and expected human behaviors.  If you focus on a target of reducing false monitoring alarms, someone MIGHT decide to just disable the alarms instead of fixing them.  If you focus on auto-healing too much, you may miss the fact that most things that can/should be fixed by auto-healing is a design flaw/problem.  Unfortunately we tend to ask how many fires we put out, not how many fires we prevented because "fires put out" is easier to count.  We have to educate our stakeholders and leadership to learn that an ounce of prevention is worth a pound of cure!