From: Cameron Otsuka Date: Tue, 24 Dec 2024 01:03:56 +0000 (-0800) Subject: add callouts and styling X-Git-Tag: v1.0.0~69 X-Git-Url: https://git.otsuka.systems/?a=commitdiff_plain;h=25bbee73f76b96eb18a68ec87766bbb7bdfd5665;p=cotsuka.github.io add callouts and styling --- diff --git a/_includes/css/style.css b/_includes/css/style.css index 816a6d8..cb3c3d4 100644 --- a/_includes/css/style.css +++ b/_includes/css/style.css @@ -93,6 +93,32 @@ footer > address > menu > li { display: inline; padding-right: 1rem; } +.callout { + margin-bottom: 1rem; + padding-left: 0.5rem; + border-left: 0.2rem solid; +} +.callout-info { + border-left: 0.2rem solid #086ddd; +} +.callout-info > .callout-label { + color: #086ddd; + font-weight: bold; +} +.callout-warn { + border-left: 0.2rem solid #ec7500; +} +.callout-warn > .callout-label { + color: #ec7500; + font-weight: bold; +} +.callout-error { + border-left: 0.2rem solid #e93147; +} +.callout-error > .callout-label { + color: #e93147; + font-weight: bold; +} .collectiontag { font-variant: small-caps; } \ No newline at end of file diff --git a/content/articles/minimum-utxo-value/index.md b/content/articles/minimum-utxo-value/index.md index 2ba6d46..7a180fe 100644 --- a/content/articles/minimum-utxo-value/index.md +++ b/content/articles/minimum-utxo-value/index.md @@ -1,7 +1,7 @@ --- title: Minimum UTXO Value date: 2023-08-04 -modified: 2024-01-26 +modified: 2024-12-23 description: A look at what Bitcoin dust is, historical fee rates, how fees are calculated, and a decision on a minimum UTXO value to stay above the dust threshold. tags: - bitcoin @@ -13,9 +13,9 @@ While there is a [technical definition](https://bitcoin.stackexchange.com/a/4108 Because fee rates are the primary variable determining the dust threshold, whether a UTXO is considered dust can change over time. I took a look at historical fee rates, how fees are calculated, and included qualitative projections of future block space demand to determine a UTXO value that will stay above the dust threshold for myself. -> **TL;DR;** -> -> Taproot UTXO, 65k sats +{% callout "info" %} +**TL;DR:** Taproot UTXO, 65k sats +{% endcallout %} ### Historical Fee Rates The highest fee periods in Bitcoin history have been 2018, 2021, and 2023: @@ -45,9 +45,9 @@ I've selected 4 blocks to deep dive, based on their proximity to mempool peaks i The first visible difference based on the box and whisker plot is the noticeable decrease in fee rate variance, likely attributable to better fee estimations. Second, is the 86% decline in median fee rate with an average 194 sats/vB between blocks 504000 and 680000 vs. 27 sats/vB in block 782400. -> **Note** -> -> I'm taking a naïve view of transactions, so transactions pushed through using CPFP aren't coalesced into a single transaction with a blended, "effective" fee rate. In theory, this should reduce fee rate spread, but will be relatively centered around the median. +{% callout "info" %} +I'm taking a naïve view of transactions, so transactions pushed through using CPFP aren't coalesced into a single transaction with a blended, "effective" fee rate. In theory, this should reduce fee rate spread, but will be relatively centered around the median. +{% endcallout %} I don't expect to see major differences in fee rates by script type, but since I have the data available here's what that looks like (it's as expected): @@ -97,9 +97,9 @@ The table below shows the amount of vBytes required by a transaction consisting So in ideal dust spending conditions, you would hold a P2TR UTXO and spend it to a P2WPKH output. An input requires more vBytes than an output, so the ideal will change if you are spending few inputs to many outputs. -> **Note** -> -> Surprisingly, despite P2SH and P2PKH inputs being the most expensive (in terms of total fees), the fee data above doesn't bear that out. Without doing further digging, I assume it's due to multi-sig being more common with other script types. +{% callout "info" %} +Surprisingly, despite P2SH and P2PKH inputs being the most expensive (in terms of total fees), the fee data above doesn't bear that out. Without doing further digging, I assume it's due to multi-sig being more common with other script types. +{% endcallout %} ### Choosing a Minimum UTXO Value Putting everything together, here are my assumptions for choosing my minimum UTXO value: diff --git a/content/articles/removing-a-drive-from-a-btrfs-array.md b/content/articles/removing-a-drive-from-a-btrfs-array.md index 2058e62..228c737 100644 --- a/content/articles/removing-a-drive-from-a-btrfs-array.md +++ b/content/articles/removing-a-drive-from-a-btrfs-array.md @@ -1,7 +1,7 @@ --- title: 'Removing a Drive from a Btrfs Array' date: 2023-07-05 -modified: 2024-01-26 +modified: 2024-12-23 description: If a drive is failing in an array, Btrfs could block attempts at removing the drive due to corrupted files. A quick write-up of how to get it removed. tags: - linux @@ -11,9 +11,9 @@ I recently ran into a situation where I knew one of the hard drives in my Btrfs At this point, I was okay with losing any corrupted/unrecoverable files. You should already be past the point of restoring from backup, attempting other recovery methods, etc. I just wanted to get the dying drive removed from the array since I knew I didn't have critical data on the array. -> **Warning** -> -> Make sure you've exhausted all other resources before continuing. Check the [ArchWiki](https://wiki.archlinux.org/title/Btrfs), [Btrfs mailing list](https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list.html), etc. This will lead to data loss! +{% callout "warn" %} +Make sure you've exhausted all other resources before continuing. Check the [ArchWiki](https://wiki.archlinux.org/title/Btrfs), [Btrfs mailing list](https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list.html), etc. This will lead to data loss! +{% endcallout %} ### Scrub the Array Start a scrub to identify files blocking the device from getting deleted: diff --git a/eleventy.config.js b/eleventy.config.js index 974246c..2512a5d 100644 --- a/eleventy.config.js +++ b/eleventy.config.js @@ -4,6 +4,7 @@ const { feedPlugin } = require("@11ty/eleventy-plugin-rss"); const eleventyImagePlugin = require("@11ty/eleventy-img"); const eleventySyntaxHighlightPlugin = require("@11ty/eleventy-plugin-syntaxhighlight"); const globalMetadata = require("./_data/metadata.json"); +const markdownIt = require("markdown-it")(); const path = require("path"); function relativeToInputPath(inputPath, relativeFilePath) { @@ -59,6 +60,38 @@ module.exports = function (eleventyConfig) { // Return the smallest number argument return Math.min.apply(null, numbers); }); + eleventyConfig.addPairedShortcode( + "callout", + function (content, level = "", format = "md", customLabel = "") { + if (format === "md") { + content = markdownIt.renderInline(content); + } else if (format === "md-block") { + content = markdownIt.render(content); + } else if (format === "html") { + content = content + } + if (customLabel) { + label = customLabel; + } else if (level === "info") { + label = "🛈 Info" + } else if (level === "warn") { + label = "⚠ Warning"; + } else if (level === "error") { + label = "! Error" + } + let labelHtml = label + ? `
${customLabel || label}
` + : ""; + let contentHtml = + (content || "").trim().length > 0 + ? `
${content}
` + : ""; + + return `
${labelHtml}${contentHtml}
`; + } + ); eleventyConfig.addPassthroughCopy({ "./static/": "/" }); eleventyConfig.addPlugin(feedPlugin, { type: "atom",