Forwarded from Libre Blockchain
New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 2]
*Brief Breakdown*
In order to implement this solution properly, we needed to start with P2SH transactions.
This transaction also needs to be specially crafted.
Some of the rarely used op codes that we created for our redeem noscript include:
-CHECKLOCKTIMEVERIFY
-OP_SUB1
-OP_HASH160
-(if, then conditions)
Among others. The first two (checklocktimeverify + op_sub1) are ran on the submitted expiry time value (which is measured against the block height in this case, not the UNIX time).
If the expiry time is at least at the height of the chain at the time that it is submitted, then the expiry time is valid.
However, if this 2FA TOTP authentication is to work, then we need to ensure that an arbitrary time is not being selected either.
That's where the 'OP_IF', 'OP_ELSE' condition statements come in.
By lining up these conditions on the stack to generate a condition that declares that our submitted block height value must pass the CHECKLOCKTIMEVERY (with a 'true'), yet render a 'false' when its value is subtracted by '1' (with the 'OP_SUB1' operation), we can essentially validate that whatever number was submitted must be accurate to the block height at the time that the operations were performed.
*Brief Breakdown*
In order to implement this solution properly, we needed to start with P2SH transactions.
This transaction also needs to be specially crafted.
Some of the rarely used op codes that we created for our redeem noscript include:
-CHECKLOCKTIMEVERIFY
-OP_SUB1
-OP_HASH160
-(if, then conditions)
Among others. The first two (checklocktimeverify + op_sub1) are ran on the submitted expiry time value (which is measured against the block height in this case, not the UNIX time).
If the expiry time is at least at the height of the chain at the time that it is submitted, then the expiry time is valid.
However, if this 2FA TOTP authentication is to work, then we need to ensure that an arbitrary time is not being selected either.
That's where the 'OP_IF', 'OP_ELSE' condition statements come in.
By lining up these conditions on the stack to generate a condition that declares that our submitted block height value must pass the CHECKLOCKTIMEVERY (with a 'true'), yet render a 'false' when its value is subtracted by '1' (with the 'OP_SUB1' operation), we can essentially validate that whatever number was submitted must be accurate to the block height at the time that the operations were performed.
Forwarded from Libre Blockchain
New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 3]
Where it Gets Quirky
Using literal UNIX time would be the best case scenario - as this is what the TOTP uses (generally a 'nonce' factor for your TOTP secret code increases by '1' every time a 30 second period transpires).
However, since transactions are stateless as we mentioned before, there is no 'server' or central time tracker that has accounted for this 2FA setup that we have.
No matter though - there's a work around to this.
After Validating the Block Height
At this point in our transaction operations, we should have removed the op conditions + CHECKLOCKTIMEVERIFY from the stack, duplicated the submitted block time (after the conditions are met successfully), then remove the top submitted block time from our step.
At this point, we should be left with an input.
What Do We Do With the Block Height Value? And How to Handle the Input
In order to really make this work, we made this a multi-signature address (m-of-n). However, there will be multiple signatures involved and only two are needed.
One signature is obviously the signature (and accompanying public key) associated with the wallet.
However, another one is the 'input' (which will be our 2FA TOTP secret), which will hash out to one of the provided signatures.
Since cryptography is strong (this is what makes a "normal" transaction secure), we don't weaken our security by affixing pre-generated signatures to the transaction to select from (guessing these should be no easier than guessing someone's private / public key pairing).
From this point, we're going to run the 'op_hash160' operation on our input secret (which will be 32 bytes in length) [operation hashes the input twice with SHA256, then peforms a ripemd160 hash operation on the result of those two sha256 hashes).
Lucky Break
According to the IETF, the recommended length of the 2FA TOTP secret = 160-bits (link = https://tools.ietf.org/html/rfc6238) - thus that result can also be the 'secret' for our 2FA authenticated code (more on this later before you object).
Where it Gets Quirky
Using literal UNIX time would be the best case scenario - as this is what the TOTP uses (generally a 'nonce' factor for your TOTP secret code increases by '1' every time a 30 second period transpires).
However, since transactions are stateless as we mentioned before, there is no 'server' or central time tracker that has accounted for this 2FA setup that we have.
No matter though - there's a work around to this.
After Validating the Block Height
At this point in our transaction operations, we should have removed the op conditions + CHECKLOCKTIMEVERIFY from the stack, duplicated the submitted block time (after the conditions are met successfully), then remove the top submitted block time from our step.
At this point, we should be left with an input.
What Do We Do With the Block Height Value? And How to Handle the Input
In order to really make this work, we made this a multi-signature address (m-of-n). However, there will be multiple signatures involved and only two are needed.
One signature is obviously the signature (and accompanying public key) associated with the wallet.
However, another one is the 'input' (which will be our 2FA TOTP secret), which will hash out to one of the provided signatures.
Since cryptography is strong (this is what makes a "normal" transaction secure), we don't weaken our security by affixing pre-generated signatures to the transaction to select from (guessing these should be no easier than guessing someone's private / public key pairing).
From this point, we're going to run the 'op_hash160' operation on our input secret (which will be 32 bytes in length) [operation hashes the input twice with SHA256, then peforms a ripemd160 hash operation on the result of those two sha256 hashes).
Lucky Break
According to the IETF, the recommended length of the 2FA TOTP secret = 160-bits (link = https://tools.ietf.org/html/rfc6238) - thus that result can also be the 'secret' for our 2FA authenticated code (more on this later before you object).
Forwarded from Libre Blockchain
New Bitcoin Innovation: 2FA-enabled (TOTP Transactions) [part 4]
On the Backend
Blake2bs is hashed from a true secret (to give us our variable input). Hashed with RIPEMD160 and placed in as our secret.
From there, we generate our first 6-digit code.
It is that code that is then inputted back into our Blake2bs function (as the IV key) to generate our set of 20 signatures.
This is a bit complex to explain in a Telegram channel, but we were able to work it out to where this will validate on a blockchain, must be required in order to fulfill the condition to spend the transaction, is pegged to time in a pretty direct manner (by polling the block height in a fairly concrete manner), is attached to the ECDSA-generated priv+pubkey pair so that we don't impose a vendor restriction (in other words, you don't need a 'special wallet' or software that leverages capabilities that other general wallet software does not have).
On the Backend
Blake2bs is hashed from a true secret (to give us our variable input). Hashed with RIPEMD160 and placed in as our secret.
From there, we generate our first 6-digit code.
It is that code that is then inputted back into our Blake2bs function (as the IV key) to generate our set of 20 signatures.
This is a bit complex to explain in a Telegram channel, but we were able to work it out to where this will validate on a blockchain, must be required in order to fulfill the condition to spend the transaction, is pegged to time in a pretty direct manner (by polling the block height in a fairly concrete manner), is attached to the ECDSA-generated priv+pubkey pair so that we don't impose a vendor restriction (in other words, you don't need a 'special wallet' or software that leverages capabilities that other general wallet software does not have).
Forwarded from Libre Blockchain
Announcement #2: Renewal of 'Py-Bitcoin'
—-
This idea is (somewhat) attached to our already existing membership. However, those that aren't members will benefit as well because we'll have be publishing the renewed 'PyBitcoin' noscript out for the general public (under copyleft because Bitcoin & Python3.8 are open source - all we're doing is providing formulas, there's nothing we should be paid for as it pertains to that).
Updating the 'PyBitcoin Code Shouldn't Be Difficult
At least when it comes to the basic functions & operations of Bitcoin (i.e., key pair generation, RPC commands like polling the blockchain for UTXOs, crafting a transaction, etc.).
Truthfully, there are probably many people in this chat that know Python that could do the same within a few solid hours, max.
For Members
After the code is renewed, we'll be integrating it into our *JupyterNotebook*.
These notebooks possess the ability generate snippets of Python code, markdown, etc.
"But I Don't Know Python!"
We're not expecting you to (and would be pleasantly surprised if you did).
The benefit of JupyterNotebook is that its designed to share code (Python in our case) to others and all they need to do is just hit the 'Run' button.
Specifically, we felt it would be useful to have a few Bitcoin-related Python snippets pre-saved as notebook items for users that would like to play around w those functions.
However, the current code for Bitcoin Py is outdated at the time of writing.
In addition, we're going to reach back out to coinmetrics.io (we did a bit of research a while back for them) to see if we can ink out a renewed agreement to obtain their API as data sources for us to query against for :
A) Prices of various assets
B) On-chain data [they are the industry-leader when it comes to polling blockchain data and statistics; which can be really useful in assessing a lot of underlying factors that move things on the 'surface']
C) Various indices
And more...
—-
This idea is (somewhat) attached to our already existing membership. However, those that aren't members will benefit as well because we'll have be publishing the renewed 'PyBitcoin' noscript out for the general public (under copyleft because Bitcoin & Python3.8 are open source - all we're doing is providing formulas, there's nothing we should be paid for as it pertains to that).
Updating the 'PyBitcoin Code Shouldn't Be Difficult
At least when it comes to the basic functions & operations of Bitcoin (i.e., key pair generation, RPC commands like polling the blockchain for UTXOs, crafting a transaction, etc.).
Truthfully, there are probably many people in this chat that know Python that could do the same within a few solid hours, max.
For Members
After the code is renewed, we'll be integrating it into our *JupyterNotebook*.
These notebooks possess the ability generate snippets of Python code, markdown, etc.
"But I Don't Know Python!"
We're not expecting you to (and would be pleasantly surprised if you did).
The benefit of JupyterNotebook is that its designed to share code (Python in our case) to others and all they need to do is just hit the 'Run' button.
Specifically, we felt it would be useful to have a few Bitcoin-related Python snippets pre-saved as notebook items for users that would like to play around w those functions.
However, the current code for Bitcoin Py is outdated at the time of writing.
In addition, we're going to reach back out to coinmetrics.io (we did a bit of research a while back for them) to see if we can ink out a renewed agreement to obtain their API as data sources for us to query against for :
A) Prices of various assets
B) On-chain data [they are the industry-leader when it comes to polling blockchain data and statistics; which can be really useful in assessing a lot of underlying factors that move things on the 'surface']
C) Various indices
And more...
Announcements
1. Began a public “Phabricator” instance for the sake of maintaining a legitimate (suitably complex) means of documenting our progress as an organization
2. Revamped a # of projects that we were working on (with our first major improvements being facilitated through the “PrivateBin” fork that we are currently developing)
3. Made significant headway with a few of our blockchain initiatives - such as a publicly available “Bitcoin full node” that can be used to query the chain & even create a Bitcoin wallet that receives funds + is tracked independently (wallet creation is generated via secure, transparent + auditable client side encryption that deploys cryptography *correctly* within a W3C-designated “secure context” in order to ensure that we’ve done everything in our power to provide a meaningfully “safe” environment for Bitcoin users to move funds to and fro freely).
4. Reinstated our public newsletter (first edition of the new issue releases today)
5. Incorporated new analysis methods into our publicly disseminated reports on blockchain & other related entities
6. Rotated our GPG keys
7. Hardened our mail servers much further than where they were before. Part of that gardening process has involved finding a reasonably simple means of employing GPG encryption (of the highest, RFC-compliant strength available), whilst simultaneously providing a reasonably feasible & super simple means of generating such key pairs + storing them w/o being forced to be concerned about the learning curve of integrating an *entirely new concept* & new habits
1. Began a public “Phabricator” instance for the sake of maintaining a legitimate (suitably complex) means of documenting our progress as an organization
2. Revamped a # of projects that we were working on (with our first major improvements being facilitated through the “PrivateBin” fork that we are currently developing)
3. Made significant headway with a few of our blockchain initiatives - such as a publicly available “Bitcoin full node” that can be used to query the chain & even create a Bitcoin wallet that receives funds + is tracked independently (wallet creation is generated via secure, transparent + auditable client side encryption that deploys cryptography *correctly* within a W3C-designated “secure context” in order to ensure that we’ve done everything in our power to provide a meaningfully “safe” environment for Bitcoin users to move funds to and fro freely).
4. Reinstated our public newsletter (first edition of the new issue releases today)
5. Incorporated new analysis methods into our publicly disseminated reports on blockchain & other related entities
6. Rotated our GPG keys
7. Hardened our mail servers much further than where they were before. Part of that gardening process has involved finding a reasonably simple means of employing GPG encryption (of the highest, RFC-compliant strength available), whilst simultaneously providing a reasonably feasible & super simple means of generating such key pairs + storing them w/o being forced to be concerned about the learning curve of integrating an *entirely new concept* & new habits
Publish0x Stole Our Ideas: Their Site Looks Great
Had a lengthy discussion with the 'owner' of the project several months ago (probably dating back to 2018, now that I think about it).
At that time, they wanted me to start writing on the platform in order to help them gain adoption sooner.
I told them that I was intrigued by the offer - but only if they made a few select integrations on their site.
Essentially all of the ideas that I contributed to them is what they have in motion right now.
Check them out! https://www.publish0x.com
Had a lengthy discussion with the 'owner' of the project several months ago (probably dating back to 2018, now that I think about it).
At that time, they wanted me to start writing on the platform in order to help them gain adoption sooner.
I told them that I was intrigued by the offer - but only if they made a few select integrations on their site.
Essentially all of the ideas that I contributed to them is what they have in motion right now.
Check them out! https://www.publish0x.com
Publish0X
Publish0x - Earn Cryptocurrency for blogging
Earn Crypto for Publishing AND for Reading or Watching quality stuff! Publish0x is a Crypto agnostic platform where both authors and readers earn in Crypto.
All Messages Have Been Answered On All Platforms
1. Answered all pending messages here on Telegram
2. Answered all pending messages on Discord / Riot
3. Answered all pending messages on Twitter as well
So if you've sent out a message to Librehash in the recent past, and you're awaiting a response to your message - you should check your inbox at your earliest convenience, because all messages have officially been answered at the time of this post's sending.
1. Answered all pending messages here on Telegram
2. Answered all pending messages on Discord / Riot
3. Answered all pending messages on Twitter as well
So if you've sent out a message to Librehash in the recent past, and you're awaiting a response to your message - you should check your inbox at your earliest convenience, because all messages have officially been answered at the time of this post's sending.
Obtained a .ETH Name
We officially have reserved 'librehash.eth' ; feel free to get in contact and say 'Hey' :)
We officially have reserved 'librehash.eth' ; feel free to get in contact and say 'Hey' :)
Issue Created on the Roundcube GitHub (directed at Enigma Plugin / Enigmail)
You can find it here: https://github.com/roundcube/roundcubemail/issues/7473
Main Goal
Get this developer to tell us how to generate these keys (through the user interface in specific - solutions that are terminal-based do not apply here).
There's no reason why this should not be feasible in 2020 with a semi-modern ish browser.
You can find it here: https://github.com/roundcube/roundcubemail/issues/7473
Main Goal
Get this developer to tell us how to generate these keys (through the user interface in specific - solutions that are terminal-based do not apply here).
There's no reason why this should not be feasible in 2020 with a semi-modern ish browser.
GitHub
'Enigma' Plugin Provides No Way (or documentation) For Creating ecdsa / ed25519 keys · Issue #7473 · roundcube/roundcubemail
This is an Urgent Issue (Not Exaggerating) Perhaps I've missed it (doubtful), but I'm mystified as to how one would configure the Enigmail plugin so that it will provide more option...
Librehash ANN
Issue Created on the Roundcube GitHub (directed at Enigma Plugin / Enigmail) You can find it here: https://github.com/roundcube/roundcubemail/issues/7473 Main Goal Get this developer to tell us how to generate these keys (through the user interface in…
They already responded to this issue - closed the ticket, then redirected it here: https://github.com/roundcube/roundcubemail/issues/6853 (fair enough).
However, they are still being incredibly unhelpful.
Yes, I question the motives of this developer and any other entity in this world that finds the security of their users to be a optional consideration.
We Will Not Abandon This Idea
The Librehash Mail solution could be so much better if the code were modified to allow for this - because it would allow users (for the first time) to take complete control of their GPG key management in the easiest way possible (more than likely, easier than generating and managing a really cryptocurrency wallet)
However, they are still being incredibly unhelpful.
Yes, I question the motives of this developer and any other entity in this world that finds the security of their users to be a optional consideration.
We Will Not Abandon This Idea
The Librehash Mail solution could be so much better if the code were modified to allow for this - because it would allow users (for the first time) to take complete control of their GPG key management in the easiest way possible (more than likely, easier than generating and managing a really cryptocurrency wallet)
GitHub
Enigma: ED25519 Support · Issue #6853 · roundcube/roundcubemail
is it possible to implenemt the ED25519 key generation or import?
Upgraded Matrix Client On the Site
Version 1.19.0 (Synapse)
Changelog can be found here = https://github.com/matrix-org/synapse/releases/tag/v1.19.0
Version 1.19.0 (Synapse)
Changelog can be found here = https://github.com/matrix-org/synapse/releases/tag/v1.19.0
GitHub
Release v1.19.0 · matrix-org/synapse
Synapse 1.19.0 (2020-08-17)
No significant changes since 1.19.0rc1.
Removal warning
As outlined in the previous release, we are no longer publishing Docker images with the -py3 tag suffix. On top o...
No significant changes since 1.19.0rc1.
Removal warning
As outlined in the previous release, we are no longer publishing Docker images with the -py3 tag suffix. On top o...
New Platform Release
'Catchet Status App' ; not really a perk, but a necessary addition / reference point for members to check uptime & status of various apps
full write-up here = https://librehash.org/cachet-status-app-launched-deployed/
write-up also published on our forums too = https://forums.librehash.org/t/sticky-readme-for-status-app/83
'Catchet Status App' ; not really a perk, but a necessary addition / reference point for members to check uptime & status of various apps
full write-up here = https://librehash.org/cachet-status-app-launched-deployed/
write-up also published on our forums too = https://forums.librehash.org/t/sticky-readme-for-status-app/83
Librehash
Librehash Platform Update: 'Cachet' / Status App Launched & Deployed
This is a really basic site that I set up for members to reference on the fly to see the 'status' of any of our apps on the site at any given point in time. Why Would You Use This?App is acting funny / you're not able to access a
A Bunch of Ethereum-based DID Integrations
1. DID Protocol Sidetrees Over Tor = https://forums.librehash.com/t/update-tor-integration-onion-link-created-completed/66
2. Ethereum Sidetree Protocol: Technical Breakdown = https://forums.librehash.com/t/technical-breakdown-of-the-ethereum-sidetree-protocol/65
3. Ethereum Sidetree App Deployment: General Information = https://forums.librehash.com/t/ethereum-sidetree-app-deployment-general-information/64
1. DID Protocol Sidetrees Over Tor = https://forums.librehash.com/t/update-tor-integration-onion-link-created-completed/66
2. Ethereum Sidetree Protocol: Technical Breakdown = https://forums.librehash.com/t/technical-breakdown-of-the-ethereum-sidetree-protocol/65
3. Ethereum Sidetree App Deployment: General Information = https://forums.librehash.com/t/ethereum-sidetree-app-deployment-general-information/64
Librehash Forums
UPDATE: Tor Integration (.onion link created) Completed
Brief Details on This Update There wasn’t any particular demand for this, but I figured since I had the ability to do this (in a fairly secure manner), that I might as well. Below is a screenshot showing me accessing the Ethereum DID Sidetree Protocol (GUI)…
Petitioning the Maintainer of 'Gocryptfs' to Import Argon2id Hashing Alongside Scrypt (or as a drop-in replacement)
Follow along with the issue here: https://github.com/rfjakob/gocryptfs/issues/520
Why you should care
Because I wrote up a mean noscript for this that allows for the creation of super secure gpg keys, w a private key encryption passfile that's ephemerally generated in 'RAM' in a stateless manner using a generic password (of your choosing) as the 'input'
I am going to abstract this onto a GUI that users can navigate using Jupyter Lab for a teaching experience / demo, then I'll make it a shiny, clean app.
Modern commercial (+ open source) password managers, vaults, cloud storage, etc., is woefully lacking when it comes to security parameters, and I hate that. I want to use the best cryptographic schemes available and utilize the libraries, code, & published cryptographic schemes available to us to their fullest extent - why not?
Follow along with the issue here: https://github.com/rfjakob/gocryptfs/issues/520
Why you should care
Because I wrote up a mean noscript for this that allows for the creation of super secure gpg keys, w a private key encryption passfile that's ephemerally generated in 'RAM' in a stateless manner using a generic password (of your choosing) as the 'input'
I am going to abstract this onto a GUI that users can navigate using Jupyter Lab for a teaching experience / demo, then I'll make it a shiny, clean app.
Modern commercial (+ open source) password managers, vaults, cloud storage, etc., is woefully lacking when it comes to security parameters, and I hate that. I want to use the best cryptographic schemes available and utilize the libraries, code, & published cryptographic schemes available to us to their fullest extent - why not?
Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability
Full stop.
This didn't need to be covertly relayed to the maintainer of that project because there is more than enough public information re: the shortcomings of Scrypt and there have been others that have brought up the inclusion of Argon2 as either an alternatives or an outright replacement for Scrypt.
The issue can be found here: https://github.com/rfjakob/gocryptfs/issues/522
Full stop.
This didn't need to be covertly relayed to the maintainer of that project because there is more than enough public information re: the shortcomings of Scrypt and there have been others that have brought up the inclusion of Argon2 as either an alternatives or an outright replacement for Scrypt.
The issue can be found here: https://github.com/rfjakob/gocryptfs/issues/522
GitHub
Gocryptfs Use of Scrypt Introduces a Vulnerability That Renders the Entire Cryptographic Schme Effectively Compromised · Issue…
Preface: To any that are reading, this is a continuation of a former (now closed) issue that I pulled a few days ago, inquiring about the inclusion of Argon2 / outright replacement of Scrypt. For s...
Librehash ANN
Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability Full stop. This didn't need to be covertly relayed to the maintainer of that project because there is more than enough…
Subsequent Measures
1. Will open up another issue that briefly breaks down the benefits / properties of Argon2 as a KDF (specifically the many that Scrypt fails to provide). In addition, the fact that there are three instantiations of this KDF that, in itself, serves as an adjustable parameter means that not only are users receiving superior security (comparative to Scrypt), more informed users are given the opportunity to tweak the algorithm in a way that flexibly addresses their unique threat environment / perceived adversary
2. Currently collaborating with the maintainer of gocryptfs on this (hopefully; the step-by-step breakdown of how to swap out Scrypt was done when this was first brought up to the lead maintainer as everyone can see above)
Pull Request Will Be Made Before the End of the Week
In my opinion, this should be considered a time sensitive issue because the successful implementation of a cache timing attack on someone using Scrypt means that they have put themselves in a position to viably extract the original password...and since this password is what gets piped into 'gocryptfs' to mount containers, the solution itself (file system encryption overlay) is equally as vulnerable since the password serves as the encryption / decryption key.
1. Will open up another issue that briefly breaks down the benefits / properties of Argon2 as a KDF (specifically the many that Scrypt fails to provide). In addition, the fact that there are three instantiations of this KDF that, in itself, serves as an adjustable parameter means that not only are users receiving superior security (comparative to Scrypt), more informed users are given the opportunity to tweak the algorithm in a way that flexibly addresses their unique threat environment / perceived adversary
2. Currently collaborating with the maintainer of gocryptfs on this (hopefully; the step-by-step breakdown of how to swap out Scrypt was done when this was first brought up to the lead maintainer as everyone can see above)
Pull Request Will Be Made Before the End of the Week
In my opinion, this should be considered a time sensitive issue because the successful implementation of a cache timing attack on someone using Scrypt means that they have put themselves in a position to viably extract the original password...and since this password is what gets piped into 'gocryptfs' to mount containers, the solution itself (file system encryption overlay) is equally as vulnerable since the password serves as the encryption / decryption key.
Katacoda Deployment Coming Soon
For those not familiar, Katacoda is most well-known (for me at least), for their hosting & always available 'Ubuntu Playgrounds'.
A 'playground' is essentially an "environment" that's containerized, sandboxed and ephemeral.
To simplify that, Katacoda provides access to a terminal that's running an OS like Ubuntu. The purpose of doing this is to allow users to practice running different commands or even spin up a project you came across on GitHub that you don't want to clone onto your personal computer / expose a localhost port to the internet.
These playgrounds come with full-blown, regularly featured Ubuntu instances. Obviously not without resource constraints imposed since this is free, but they give you a very, very generous & workable leash on it.
I've personally never had my connection to one of Katacoda's terminal throttled, and I've pulled in a few dozen GBs before in a session (don't be a dick & abuse this, these folks are providing a free service that helps folks out - they don't deserve to be punished for that)
For those not familiar, Katacoda is most well-known (for me at least), for their hosting & always available 'Ubuntu Playgrounds'.
A 'playground' is essentially an "environment" that's containerized, sandboxed and ephemeral.
To simplify that, Katacoda provides access to a terminal that's running an OS like Ubuntu. The purpose of doing this is to allow users to practice running different commands or even spin up a project you came across on GitHub that you don't want to clone onto your personal computer / expose a localhost port to the internet.
These playgrounds come with full-blown, regularly featured Ubuntu instances. Obviously not without resource constraints imposed since this is free, but they give you a very, very generous & workable leash on it.
I've personally never had my connection to one of Katacoda's terminal throttled, and I've pulled in a few dozen GBs before in a session (don't be a dick & abuse this, these folks are providing a free service that helps folks out - they don't deserve to be punished for that)
Changes to the Website / Blog / Newsletter (librehash.org)
1. Added a new background to the top of the page
2. Added a 'search' feature
3. Reoriented a few tags
4. Combing through & editing a few pieces to amend spelling errors, formatting issues & other grammatical mistakes for clarity
5. Created a 'subscribers' page for any and all that are interested in getting these posts / updates straight to their inbox. No charge necessary. Nothing will ever be sent to said inbox except for a post update (won't even advertise the ephemeral membership package that we have going on currently)
1. Added a new background to the top of the page
2. Added a 'search' feature
3. Reoriented a few tags
4. Combing through & editing a few pieces to amend spelling errors, formatting issues & other grammatical mistakes for clarity
5. Created a 'subscribers' page for any and all that are interested in getting these posts / updates straight to their inbox. No charge necessary. Nothing will ever be sent to said inbox except for a post update (won't even advertise the ephemeral membership package that we have going on currently)