Chemaclass - tutorial

Inside the .claude Folder

2026-04-17T00:00:00+00:00

Every project I work on has a .claude/ folder at the root. Committed to git, like the rest of the code.

That folder turns Claude Code from a generic assistant into a project-aware teammate. Everyone who clones the repo inherits the same setup.

Agentic coding is only as good as the context you give the agent. The .claude/ folder is where that context lives.

The .claude folder, at a glance #

.claude/
├── CLAUDE.md # project onboarding
├── settings.json # permissions, hooks, env
├── skills/ # reusable procedures (slash commands)
├── rules/ # glob-targeted conventions
├── hooks/ # shell scripts run on events
└── agents/ # specialized roles

Six layers, one folder. Context, safety, procedures, guardrails, automation, specialists.

The foundation #

CLAUDE.md: where everything starts #

Claude Code reads CLAUDE.md on every boot. The onboarding doc.

In Phel, mine covers the compiler pipeline (Lexer → Parser → Analyzer → Emitter), module structure, conventions, and key commands.

A global ~/.claude/CLAUDE.md applies to all your projects. The project file says how this codebase works. The global file says how I work.

Every byte ships in every prompt. Keep it short. Past one screen, move detail into rules/ or skills/.

A good CLAUDE.md is a good onboarding doc. The better it is, the less you repeat yourself.

settings.json: safety before leverage #

Before giving the agent more power, lock down what it must never do.

.claude/settings.json holds three things: permissions (allow/deny), hooks (event commands), and env (variables). A gitignored settings.local.json keeps personal overrides separate.

{
 "permissions": {
 "allow": [
 "Bash(composer:*)",
 "Bash(./bin/phel:*)",
 "Bash(git:*)",
 "Bash(gh:*)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(sudo:*)"
 ]
 }
}

Allow unlocks flow. Deny draws the line agents cannot cross, even when asked politely.

Permissions are the floor. Everything else builds on top of a safe baseline.

Procedures and guardrails #

Skills: procedures you can run #

Next pain after onboarding: repetition. Skills solve that.

A skill is a markdown file in .claude/skills/, a procedure you call with a slash:

/gh-issue <number>: issue to branch, TDD plan, PR.
/commit: fix, analysis, tests, conventional commit.
/refactor-check: SOLID, naming, architecture smells.
/release [version]: changelog, PHAR, tag, release.

Raw prompt: “fix issue #42”. Agent improvises. Different every time.
Rule: “use conventional commits”. Shapes output, not procedure.
Skill: “/gh-issue 42”. The procedure is the instruction.

Skills turn tribal knowledge into runnable steps anyone can execute.

Skills capture what to do. Rules capture what not to do.

Rules: the guardrails #

CLAUDE.md is read every session. Rules only when they match. Files in .claude/rules/ target code areas with glob patterns: the agent loads only what applies, keeping context lean.

Rule files in Phel:

compiler.md: strict 4-phase pipeline, no bypassing.
php.md: PER 3.0, final classes, readonly, Gacela.
phel.md: kebab-case, defn- private, :doc/:example required.
integration-tests.md: --PHEL-- / --PHP-- fixture sections.

Compiler rules don’t fire when editing Phel source. Phel rules don’t fire when editing PHP infrastructure.

Rules are not suggestions. They travel with the code: a convention change and its rule ship in the same commit. No drift, no outdated wiki.

Automation and delegation #

Hooks: automation at the edges #

Rules tell the agent what to do. Hooks make sure it happens even if the agent forgets.

Shell commands triggered by Claude Code events (PreToolUse, PostToolUse, Stop), wired through settings.json. In Phel, PreToolUse blocks edits to critical files (build/release.sh, .github/*, composer.lock). PostToolUse auto-formats PHP via php-cs-fixer.

{
 "hooks": {
 "PreToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/protect-files.sh" }]
 }],
 "PostToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/format-php.sh" }]
 }]
 }
}

Rules are what the agent should know. Hooks are what the system enforces anyway.

Agents: specialized roles #

Everything so far shapes one agent. Agents add specialists the main agent can delegate to, each with its own tools, permissions, and model. Most advanced piece. Recommend it last.

A few from Phel:

Explorer (Sonnet, read-only): files, structure mapping.
Clean Code Reviewer: SOLID and naming on diffs.
TDD Coach: red-green-refactor enforcement.
Domain Architect: module boundaries, compiler pipeline.
Debugger: compiler errors across all phases.

Each agent runs in its own context window: the main session stays clean while the specialist digs deep. The win is not only cost, it is focus. An agent with only read and grep cannot rewrite your codebase by mistake.

Right model for the right job. Fast and cheap for exploration. Deep and careful for architecture.

Start small, grow with friction #

Do not build all of this on day one.

The order, driven by real friction:

Start with CLAUDE.md.
Lock down settings.json permissions.
First time you repeat yourself, write a skill.
First time the agent breaks a convention, add a rule.
First time something bad almost gets committed, add a hook.
First time a generalist is wrong for the job, define a specialist.

Each step fixes a problem you actually had. Not one you imagined.

The setup grows from real friction, not from upfront design.

Commit the folder. Share it. When someone joins, their session inherits everything.

Treat .claude/ like infrastructure. Version it. Review it. Evolve it with the codebase.

How Bitcoin Works

2025-12-22T00:00:00+00:00

This post explains how Bitcoin works under the hood. If you’re looking for why Bitcoin matters, start with Bitcoin Fundamentals.

For the technically curious.

The Blockchain #

The Double-Spend Problem #

Digital money has a fundamental problem: how do you prevent someone from copying their coins and spending them twice? Traditional systems solve this with a central authority (banks, PayPal) that tracks who owns what. Bitcoin’s breakthrough was solving this without any central party.

The solution: a shared ledger that everyone can verify but no one controls.

How It Works #

Bitcoin uses a blockchain: a chain of blocks where each block contains transactions and links to the previous block through cryptographic hashes.

A hash function takes any input and produces a fixed-size fingerprint. Change one bit of input, and the output changes completely. This makes tampering obvious. Bitcoin uses SHA-256, which produces a 256-bit output.

Each block contains:

A list of transactions
A hash of the previous block header
A proof-of-work solution (more below)

Before transactions get into a block, they wait in the mempool. Miners pick transactions from this pool, prioritizing those with higher fees. Watch this in real-time at mempool.space.

Every node keeps a complete copy of the blockchain. No single server to hack, no central database to corrupt. To change history, you’d need to rewrite blocks on the majority of nodes worldwide.

A block has two parts: the header (80 bytes) and the body (transactions).

The header contains:

Version: Protocol version
Previous block hash: Links to the chain
Merkle root: Hash of all transactions in the block
Timestamp: When the block was created
Difficulty target: How hard the puzzle was
Nonce: The solution miners found

Merkle trees organize transactions efficiently. Each transaction is hashed, then pairs of hashes are combined and hashed again, building up to a single root hash. This allows proving a transaction exists in a block without downloading all transactions. Useful for lightweight wallets.

Block weight is measured in virtual bytes (vB). The limit is 4 million weight units, roughly 1-1.5 MB of data per block.

Transactions & Cryptography #

The UTXO Model #

Bitcoin doesn’t use accounts with balances. Instead, it tracks Unspent Transaction Outputs (UTXOs). Think of them as digital coins of varying sizes.

When you receive bitcoin, you get a UTXO. When you spend, you consume entire UTXOs as inputs and create new ones as outputs. If you have a 1 BTC UTXO and want to send 0.3 BTC, you spend the whole UTXO and create two outputs: 0.3 BTC to the recipient and ~0.7 BTC back to yourself (minus fees).

Your “balance” is the sum of all UTXOs you can spend.

Public-Key Cryptography #

Bitcoin transactions use public-key cryptography:

Private key: A secret 256-bit number. This proves ownership.
Public key: Derived mathematically from the private key. Shared publicly.

When you send bitcoin, you sign the transaction with your private key. This signature proves you own the UTXOs being spent without revealing the private key. Anyone can verify the signature using your public key.

Programmable Money #

Bitcoin isn’t just digital cash. It has its own programming language called Script. Every transaction includes a small program that defines the conditions for spending.

Most transactions use simple scripts: “whoever can prove they own this public key can spend these coins.” But Script enables much more: multi-signature wallets requiring multiple keys, time-locked transactions that can’t be spent until a certain date, and complex conditions combining multiple requirements.

This makes Bitcoin programmable money. For a deeper dive into Script and address types, see Programmable Money.

Bitcoin uses ECDSA (Elliptic Curve Digital Signature Algorithm) with the secp256k1 curve. This curve was chosen for efficiency and because it wasn’t designed by any government agency (unlike NIST curves), reducing backdoor concerns.

A private key is a random 256-bit integer. The public key is derived by multiplying this number by a generator point on the curve. Easy to compute forward, practically impossible to reverse.

Transaction signing involves:

Hashing the transaction data
Creating a signature using the private key
Including the signature and public key in the transaction

SIGHASH flags control what parts of a transaction the signature covers:

SIGHASH_ALL: Signs all inputs and outputs (most common)
SIGHASH_NONE: Signs inputs only
SIGHASH_SINGLE: Signs one specific output
These can be combined with ANYONECANPAY for advanced use cases

Mining & Consensus #

How does a decentralized network agree on which transactions are valid? Through proof-of-work mining.

The Puzzle #

Miners race to find a number (the nonce) that, when combined with the block header and hashed, produces a result below a target value. It’s like rolling dice until you get a number under 100, except with 2^256 possible outcomes.

The work is:

Hard to find: Requires trillions of guesses
Easy to verify: One hash check proves the solution

This asymmetry is key. Anyone can verify a block instantly, but creating one requires real computational work.

Why It Matters #

Mining serves three purposes:

Secures the network: Rewriting history means redoing all hash work
Issues new coins: Following a predictable schedule (halving every 210,000 blocks)
Processes transactions: Including them in the permanent record

Every 2016 blocks (~2 weeks), the network adjusts difficulty to maintain ~10 minute block times. More hashpower joins? Puzzles get harder. Hashpower leaves? Puzzles get easier.

Explore mining pools and hashrate at mempool.space/mining.

Difficulty calculation: The target is a 256-bit number. A valid block hash must be below this target. Lower target = harder puzzle. The network adjusts every 2016 blocks based on how long those blocks actually took vs. the expected 20,160 minutes.

Hashrate and security: Bitcoin’s security comes from the cost to rewrite history. With ~500 EH/s (exahashes per second) of hashrate, attacking the network would require controlling majority hashpower. That means billions in hardware and electricity, plus the attack would crash the asset’s value.

Economic incentives: Miners spend real resources (electricity, hardware). They only profit if they play by the rules. A miner who creates invalid blocks wastes their work because nodes reject invalid blocks. This aligns individual profit motive with network security.

51% attacks: If an attacker controlled majority hashrate, they could theoretically double-spend by mining an alternative chain. But the economics make this irrational for large values: the attack destroys the value of what you’re stealing.

Addresses & Wallets #

Bitcoin addresses are derived from public keys. Different formats have evolved:

P2PKH: Legacy addresses starting with “1”
P2SH: Script addresses starting with “3”
P2WPKH: Native SegWit addresses starting with “bc1q”
P2TR: Taproot addresses starting with “bc1p”

For technical details on each type, see Programmable Money.

Wallets #

A wallet manages your keys and constructs transactions. It doesn’t hold your coins. Coins exist on the blockchain. The wallet holds keys that prove you can spend them.

Hot wallets connect to the internet. Convenient for daily use, more vulnerable. Examples: phone apps, browser extensions.

Cold wallets stay offline. More secure for savings. Examples: hardware wallets (Ledger, Trezor), paper wallets.

HD Wallets and Seed Phrases #

Modern wallets are Hierarchical Deterministic (HD). One master seed generates unlimited keys in a tree structure. Back up the seed once, recover everything.

BIP-39 defines the 12 or 24-word seed phrase most wallets use. These words encode entropy that derives all your keys. Lose the phrase, lose access. Anyone with the phrase controls the funds.

Never store seed phrases digitally. Write them down. Store securely offline.

How big is the BIP-39 keyspace, really? I built seed-hunter, an open-source educational Go CLI that tries to brute-force a 12-word seed against the real Bitcoin network. It logs every attempt and shows live progress with ETAs spanning 10²⁹ to 10³⁹ years. A burglar checking one trillion seed phrases per second since the Big Bang would have completed 0.000_000_008% of the search by now. The point isn’t to break Bitcoin, it’s to make the math viscerally obvious: thermodynamics, not just computation, forbids the attack.

The Network #

Bitcoin is a peer-to-peer network. No central servers. Nodes connect to each other, share transactions and blocks, and enforce rules independently.

Node Types #

Full nodes download and validate every block and transaction. They enforce all consensus rules and don’t trust anyone. Running a full node means you verify everything yourself.

SPV (light) clients only download block headers. They trust that miners validated the transactions. Less security, but works on phones and low-power devices.

Mining nodes are full nodes that also compete to create new blocks.

How Transactions Propagate #

When you broadcast a transaction:

Your wallet sends it to connected nodes
Each node validates and forwards to its peers
Within seconds, the transaction reaches most of the network
Miners include it in their candidate blocks

Blocks propagate similarly. When a miner finds a valid block, it spreads across the network in seconds.

Peer discovery: Nodes find each other through DNS seeds (hardcoded addresses that return active node IPs) and by sharing peer addresses with connected nodes.

Gossip protocol: Information spreads through “inv” (inventory) messages. A node announces it has something new, peers request it if interested. This prevents bandwidth waste from duplicate data.

Compact blocks (BIP-152) speed up block propagation. Since nodes already have most transactions in their mempool, blocks can be transmitted as just the header plus short transaction IDs.

Security & Confirmations #

Why Confirmations Matter #

When a transaction is included in a block, it has 1 confirmation. Each subsequent block adds another confirmation.

More confirmations = harder to reverse. To undo a confirmed transaction, an attacker would need to mine an alternative chain faster than the honest network. Each block makes this exponentially harder.

General guidelines:

0 confirmations: Transaction broadcast but not yet in a block. Can be double-spent.
1 confirmation: In a block. Reversal requires significant hashpower.
6 confirmations: Standard for large amounts. Reversal practically impossible.

Satoshi’s whitepaper includes the probability calculation. With an attacker controlling fraction q of hashpower:

If q < 0.5: Probability of catching up decreases exponentially with each confirmation
At 6 confirmations with q = 0.1 (10% hashpower): Success probability < 0.1%

The “6 confirmations” rule assumes a well-funded attacker with substantial but minority hashpower. For smaller transactions, fewer confirmations are often acceptable.

Finality in Bitcoin is probabilistic, not absolute. But after enough confirmations, the probability of reversal approaches zero for any realistic attacker.

Incentive Alignment #

Bitcoin isn’t just a clever technology. It’s a system where every participant’s self-interest reinforces the network.

Miners invest in hardware and electricity. They only profit by producing valid blocks. Cheating wastes their investment because nodes reject invalid blocks instantly.
Nodes enforce the rules to protect their own holdings. A node operator who accepts invalid transactions devalues their own bitcoin. Self-interest makes them honest validators.
Users pay fees to get transactions processed. Higher fees mean faster confirmation. This creates demand for block space and funds network security.
Developers contribute to software they themselves use. Bugs hurt their own holdings. Improvements benefit everyone, including them.
Holders benefit from network security and adoption. The more secure and useful Bitcoin becomes, the more valuable their holdings. They’re incentivized to support the ecosystem.

No central coordinator. No trust required. Everyone acts in their own interest, and the system benefits everyone.

“Don’t trust, verify.” Anyone can run a node and verify every transaction, every block, every rule. You don’t need to trust banks, governments, or even other Bitcoin users. The math proves itself.

Scaling: The Lightning Network #

Bitcoin’s base layer processes about 7 transactions per second. That’s by design: keeping things decentralized requires blocks small enough for anyone to verify. But this limits how many transactions it can handle.

The Lightning Network solves this with a second layer built on top of Bitcoin. It enables:

Instant payments: No waiting for block confirmations
Near-zero fees: Fractions of a cent
High capacity: Millions of transactions per second

Lightning works by opening “payment channels” between parties. Transactions within a channel happen off-chain, instantly. Only the opening and closing of channels require on-chain transactions. You can visualize the network topology and statistics at mempool.space/lightning.

Bitcoin’s base layer provides security and final settlement. Lightning provides speed and scale. Different tools for different jobs.

If you want to run your own Lightning node and take full control of your payments, I wrote a guide on how to Run your LN node on a Raspberry Pi.

Payment channels use 2-of-2 multisig addresses. Both parties must sign to move funds. This creates a shared account that neither can steal from.

HTLCs (Hash Time-Locked Contracts) enable multi-hop payments. The mechanism:

Alice wants to pay Carol through Bob
Carol generates a secret and gives Alice the hash
Alice creates an HTLC: “Bob gets paid if he reveals the secret within 24 hours”
Bob creates a similar HTLC with Carol
Carol reveals the secret to Bob, claiming payment
Bob uses the same secret to claim from Alice

If anyone fails to cooperate, the timelock expires and funds return. The secret travels backward, payments travel forward.

Watchtowers monitor the blockchain for cheating attempts. If your counterparty tries to broadcast an old channel state, the watchtower can penalize them, even while you’re offline.

The Bigger Picture #

What makes Bitcoin remarkable isn’t any single component. It’s how they fit together into a self-reinforcing system.

Cryptography proves ownership without trusted authorities. Proof-of-work makes history expensive to rewrite. Economic incentives turn individual greed into collective security. Decentralization removes single points of failure. And the fixed supply creates digital scarcity for the first time in history.

Every piece supports every other piece. Remove one, and the system weakens. Together, they create something that has never existed before: money that can’t be inflated, transactions that can’t be censored, and property that can’t be confiscated.

No banks. No governments. No trusted third parties. Just math, code, and a global network of nodes all enforcing the same rules.

Whether that matters to you depends on where you live and how much you trust your institutions. But the option exists now. And no one can take it away.

Bitcoin’s technical depth goes far beyond what fits in one post. Here are topics worth exploring if you want to go deeper:

SegWit (Segregated Witness) was Bitcoin’s 2017 upgrade that moved signature data outside the main transaction structure. This fixed transaction malleability (a bug that prevented Lightning), introduced block weight for more efficient space usage, and did it all while staying backwards-compatible with old nodes.

Taproot & Schnorr landed in 2021, upgrading Bitcoin’s cryptography. Schnorr signatures are smaller and enable aggregation (multiple signatures become one). Taproot makes complex spending conditions look identical to simple payments on-chain, improving both privacy and efficiency.

Soft forks vs hard forks: How does Bitcoin upgrade without a central authority? Soft forks add new rules that old nodes still accept. Hard forks change rules in ways old nodes reject. Understanding this distinction explains why Bitcoin evolves slowly and why contentious changes are rare.

Fee mechanics: The fee market is more nuanced than “pay more, confirm faster.” Replace-By-Fee (RBF) lets you bump a stuck transaction’s fee. Child-Pays-For-Parent (CPFP) lets recipients accelerate incoming payments by spending them with high fees.

Timelocks: Bitcoin can lock funds until conditions are met. CLTV (CheckLockTimeVerify) locks until a specific block height or timestamp. CSV (CheckSequenceVerify) locks for a relative time after confirmation. These primitives enable Lightning channels, inheritance schemes, and atomic swaps.

Coinbase transactions: The only way new bitcoin enters circulation. Every block begins with a special transaction that pays the miner the block reward plus all fees. These newly minted coins can’t be spent for 100 blocks, a rule that protects against chain reorganizations.

The deeper you go, the more you find.

Run Your LN Node on a Raspberry Pi

2025-02-17T00:00:00+00:00

In this guide, I’ll show you how to set up a fully custodial Lightning Network (LN) node using Alby Hub on a Raspberry Pi, giving you complete control over your node. Alby Hub offers a DIY free version for a self-custodial Lightning wallet, ensuring full ownership of your funds while being 100% open-source.

It supports both Lightning and Nostr addresses, enabling seamless connectivity across ecosystems, and integrates effortlessly with dozens of Bitcoin applications. With built-in Lightning Service Provider (LSP) services and the Alby Go mobile app, managing your node on the go has never been easier.

Important: This is NOT a Bitcoin miner or a full node. It’s simply a Raspberry Pi running on an SD card power-efficient and low-cost.

⚠️ Disclaimer ⚠️

I assume you understand Bitcoin’s fundamental concepts.
I assume you know how the Lightning Network (LN) works.

Anyway, I’ve included a brief recap of the Lightning Network basics below.

What is the Lightning Network? #

The LN is a second-layer solution built on top of Bitcoin to enable fast, cheap, and scalable transactions.

Why? Bitcoin’s base layer is secure but slow and expensive for small payments due to block size limits and fees.
How? LN uses off-chain payment channels that allow users to transact instantly without waiting for blockchain confirmations.

Key Concepts #

Payment Channels: Users open a channel by making an on-chain transaction, then send unlimited instant payments within that channel.
Routing: You don’t need a direct channel with everyone, payments can be routed through multiple connected nodes.
Low Fees: Only opening/closing channels require on-chain fees; most transactions cost fractions of a cent.

Goal #

LN makes Bitcoin usable for everyday transactions, like buying coffee, without waiting 10+ minutes for confirmations.

In short: Lightning Network = Instant + Cheap Bitcoin payments, secured by Bitcoin’s blockchain.

Setting up Alby Hub #

Alby Hub is a free, open-source (ideally private) Lightning Network node.

Requirements #

Before we begin, you are going to need the following things:

A windows or mac or linux computer
Raspberry Pi 4 or 5 (For Zero 2W see this tutorial!)
- In this tutorial, I am using a raspi-4b (~60€)
The charger for your raspi (~10€)
SD memory card (32/64gb) (~10€)
Adapter SD card to USB (to flash the OS into the raspi) (~10€)

Installation Steps #

1. Flash a Linux kernel into the SD card #

Suggestion: You can use RPI imager on your computer. Use it to flash the recommended raspi OS for you

On the Storage you will see your SD card after inserting it into your laptop.

Once you click “Next”, you will see different settings. Click to Edit Settings

On Settings > General: set your hostname, the username and password for your admin user. Make sure you enable your WIFI, otherwise you will have to plug it to the router with an RJ-45.

For this tutorial, I am using testhub as hostname, you can use albyhub or whatever you prefer.

On Settings > Services: make sure the access via SSH is enabled. We are going to need it to install Alby Hub.

Click “Save” and click “Yes” to start the installation.

You will see a confirmation. Click “Yes”. It will take ~10 mins…

Now we got the SD with a fresh linux kernel ready to use!

2. Insert the SD into the raspi #

Extract the SD from the laptop and insert it in the raspi first.

Once the SD is inserted, then plug in the power cable. It will turn on automatically as soon as you plug it in.

3. Alby Hub installation #

It will take ~5mins since you turned it on to be able to access to it. How can you make sure it’s alive? Open the terminal and ping the hostname you defined while flashing the SD on Settings > General, remember it ended up with .local:

ping testhub.local

It’s normal if you don’t get any answer at the beginning… until you do get this.

Now you can install Alby Hub in your raspi using the SSH connection that you enabled earlier:

# Source code: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

You will be asked to type the word “yes”; type it.

Then, you will be asked to enter your password. Enter the password you chose in Settings > General for the username.

4. Alby Hub Setup #

Wait another 2-3 mins and visit your host: http://testhub.local/

Your Alby hub is now running. Let’s connect it to your GetAlby account!

Creating a GetAlby Account #

🔗 getalby.com

Connecting GetAlby with Alby Hub #

I created an account named testhub.

Left: the GetAlby account. Right: the node in the raspi.

Click “Connect Now”.

Click “Request Authorization Code”.

You get the auth code (left) that you need to insert it into your setup (right).

Create a Password for your Alby Hub installed in your raspi. It can be different from the password that you set up for your root user in the rapi itself.

Now it’s time to Link your Alby Account

Unless you specify otherwise, set the default “Budget renewal: Monthly 1M sats”.

Opening Lightning Channels #

I recommend following the Initial Steps to set up your Alby Hub.

Let’s open the first channel.

You need to pay ~$20 in sats to open a 1M sats incoming liquidity channel.

After the payment, then you will see the channel open. It might take a couple of mins until the funding transaction is mined in the next block.

Receiving Sats #

You can receive sats using your LN Address.

Left: Public page linked to your node. Right: Private page from your Alby Hub.

Optional: You can add ln funds to your wallet using GetAlby’s third-party services: getalby.com/topup - mind the KYC…

Using Your Sats #

After that, you will be able to use it via the Alby Extension or the AlbyGo.

Your node is the ultimate source of truth. Connecting these apps to it will allow you to use your sats seamlessly across different platforms.

Disclaimer: the testhub LN address was created only for testing and tutorial purposes. My real address is chemaclass ;)

Maintenance and Troubleshooting #

Updating Your Node #

Similar to the installation process, there’s a script available to update your node. You can find it in the source repository: GitHub - Alby Hub Update Script

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

Handling Power Outages #

If the power goes out, the Raspberry Pi will turn off. Once power is restored, it will automatically restart, but Alby Hub will prompt you to enter the password you set earlier.

Related links