Merge pull request #74 from rencryptofish/main

Create html website for paper with dates, sidebar, mobile friendly

Author: moneyball

.github/workflows/deploy-pages.yml

@@ -0,0 +1,50 @@
+name: Deploy to GitHub Pages
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches: ["main"]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Build job
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      
+      - name: Setup Pages
+        uses: actions/configure-pages@v4
+      
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          # Upload entire repository
+          path: '.'
+  
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.nojekyll

@@ -65,7 +65,7 @@ Understanding the technical aspects of consensus is important because any change
 
 Soft forks and hard forks are two types of protocol changes in blockchain networks like bitcoin. Soft forks are backwards-compatible upgrades where old nodes still see new blocks as valid, though they may miss out on new features. They only tighten or add rules to the existing protocol and can be activated with consensus from the network. Furthermore, for soft forks, only the nodes that want to use the newly proposed rules have to upgrade. Soft forks are generally preferred in bitcoin due to being a more pragmatic coordination solution as the window of time for Economic Nodes to upgrade can be quite lengthy. Examples include segwit and P2SH. However, they can create two classes of nodes, upgraded and non-upgraded nodes. The median time for a bitcoin node to upgrade has historically been ~40 weeks, but that has been trending even longer in recent years.
 
-![bitcoin_core_upgrade_time](/img/bitcoin_core_upgrade_time.png) [^1]
+![bitcoin_core_upgrade_time](img/bitcoin_core_upgrade_time.png) [^1]
 
 Hard forks, on the other hand, are non-backwards-compatible upgrades requiring all nodes to upgrade within an activation window of time with code that activates at the same block height to maintain consensus. They can change or relax existing rules, allowing for more extensive protocol modifications. Hard forks need near-universal consensus to avoid permanent chain splits and are more difficult to coordinate. Hard forks do not necessarily create a separate chain if all existing nodes on the network use the hard fork or if Miners do not continue mining the previous rule set. For example, the addition of OP_NOP in 2010 was done with a hard fork on bitcoin. While they can fix fundamental issues or add significant new features, they carry a higher risk of community divisions and network splits. Notable examples include the Bitcoin Cash hard fork in 2017, where a proposal to increase the block size limit led to disagreements within the Bitcoin community, resulting in a contentious hard fork and the creation of a new coin. This illustrates the risks of chain splits and network fragmentation inherent in hard forks.