DEV Community: Susan Githaiga

Using the Lightning Anchor Fee Bumping Service: A Frontend Walkthrough

Susan Githaiga — Tue, 31 Mar 2026 06:40:09 +0000

Welcome to Part 6 of my Lightning Anchor Fee Outputs Series

In the previous articles, we built the entire backend for a Lightning powered CPFP fee bumping service. From Bitcoin RPC integration, to LND invoice creation, to broadcasting the child transaction.

In this final part, I will walk you through the frontend and show you exactly how to use the service end to end.

What the Service Does

When a Bitcoin transaction gets stuck in the mempool due to low fees, you can use Child-Pays-For-Parent (CPFP) to accelerate/unstuck it. Our service uses the anchor output as the input for a child transaction that pays a higher fee. You pay for this service via a Lightning invoice, and the service broadcasts the fee-bumping transaction on your behalf.

Prerequisites

Before using the frontend, make sure the following are running:

Docker containers: bitcoin-regtest, lnd-alice, postgres-db, redis-cache
Backend server on port 3000 (npm run dev in /backend)
Frontend on port 5173 (npm run dev in /frontend)

# Start all Docker services
cd backend
docker compose up -d

# Terminal 1: Start backend
cd backend && npm run dev

# Terminal 2: Start frontend
cd frontend && npm run dev

Step 1: The Status Dashboard

When you open the app at http://localhost:5173 and click on Get Started, the first thing you'll notice on the right side is the Status Dashboard.

After the backend syncs to the regtest blockchain, the dashboard shows:

Block Height: The current regtest block height, confirming Bitcoin Core is synced
Network: regtest for local development
Mempool Monitor: Shows Inactive until a transaction is submitted

If Block Height shows a number (861 in our case), your backend is successfully connected to the regtest blockchain network.
If it shows an error, check that your backend is running.

Step 2: Creating a Test Transaction

Before using the fee bumper, you need a stuck transaction to work with. In regtest, we create one manually:

First, get the service wallet address:

SERVICE_ADDR=$(curl -s http://localhost:3000/api/v1/bitcoin/wallet-address | jq -r '.data.address')
echo "Service wallet address: $SERVICE_ADDR"

Then send 330 sats to it and capture the TXID:

TXID=$(docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -rpcwallet=testwallet sendtoaddress $SERVICE_ADDR 0.00000330)
echo "TXID: $TXID"

Expected output

Copy the TXID(Transaction Id) as you'll need it in the next step. My TXID in this case is 59224b8385c5dd882f0a1f48b11e05fbe0e9fdab414344f8fd5f725b6571661a

Step 3: Estimating the Fee

Paste your TXID into the Transaction ID field. Set the Anchor Output Index (usually 0) and choose a Target Fee Rate.

Three fee rate presets are available:

Preset	Rate	Use case
Low	1 sat/vB	Non-urgent, patient
Medium	10 sat/vB	Standard confirmation
High	50 sat/vB	Urgent, next block

Click Estimate Cost. The Fee Estimation panel below will populate with:

Child Fee Needed: The fee the child transaction must pay
Total Fee Needed: Child fee plus the service fee
Parent Fee Rate: What the stuck transaction is currently paying
Feasibility indicator: confirms the anchor output can cover the bump

Feasible vs Non-Feasible Transactions

The 330-sat anchor feasible badge tells you whether the service can actually bump your transaction.

Feasible (green badge) means the anchor output in your transaction is a valid 330-satoshi output that the service can spend as the CPFP child input. The child transaction can pay enough to bring the combined package fee rate up to your target. You can proceed to generate an invoice and broadcast.

Not feasible (red badge) means one of the following is true:

The output at the specified index is not a 330-satoshi anchor output
The parent transaction's fee rate is already at or above your target. There is nothing to bump
The TXID does not exist in the mempool or the local blockchain

If you see a non-feasible result, double-check that you are using the correct Anchor Output Index, try 0, 1, or 2 depending on which output in the transaction is the anchor. Also confirm the transaction is genuinely stuck by checking its current fee rate against your target..

Sample non-feasible output

Step 4: Generating the Lightning Invoice

Once the estimate looks good, scroll down and click Generate Invoice. The backend calls LND via gRPC to create a Lightning invoice for the exact fee amount.

The Lightning Invoice panel appears with:

A QR code you can scan with any Lightning wallet
The amount in satoshis
The payment hash for tracking
A Copy Invoice button to copy the raw lnbc... invoice string

In production, your user scans this QR code with their Lightning wallet and pays. In regtest, you can pay it programmatically:

# Pay the invoice from a second LND node (if you have one set up)
docker compose exec lnd lncli --network=regtest payinvoice <INVOICE_STRING>

Expected output:

The error self-payments not allowed means you're trying to pay an invoice from the same LND node that created it. You can't pay yourself on Lightning.

Coming Up Next

In the next article, we step out of regtest and into the real Bitcoin network, mainnet.

To continue from here on mainnet, we'll need to:

Spin up a Lightning node connected to the live Bitcoin network
Migrate the project configuration from regtest to mainnet

By doing this, we'll be able to handle real invoices paid by real wallets

Part 7: Going Live and Migrating to Mainnet →
(Link will be updated when the article is published)

What We Built Across This Series

Over six parts, we've gone from understanding what anchor outputs are to building and using a fully functional fee bumping service:

Parts 1–2: What anchor outputs are and why they exist in Lightning commitment transactions
Part 3: Setting up the backend, Bitcoin RPC integration, and Docker environment
Part 4: Integrating LND for Lightning invoice creation and payment verification
Part 5: Building the CPFP transaction constructor and broadcast endpoint
Part 6 (this article): Walking through the React frontend and completing the end-to-end flow

The full source code is on GitHub. If you found this series useful, feel free to connect on LinkedIn or follow along on Dev.to.

Building an Anchor Output Fee Bumping Service — Part 5: CPFP Transactions and Broadcasting

Susan Githaiga — Thu, 12 Mar 2026 10:33:48 +0000

Introduction

In Part 4, we got Lightning payments working. The service can now generate invoices, track payment status, and verify that users have paid before taking action. That's the business logic sorted.

But we stopped right before the interesting part: actually building and broadcasting the CPFP transaction that does the fee bumping.

That's what Part 5 covers. By the end of this article, you'll have a service that can construct a valid Child-Pays-For-Parent transaction using bitcoinjs-lib, understand why the signing fails (and what that teaches us about Lightning), and see the complete flow from stuck transaction to broadcast-ready CPFP.

We're still on regtest, still safe, still learning.

📂 Source code: lightning-anchor-fee-outputs

Where We Left Off

Part 4 ended with three working Lightning endpoints:

Create invoice ✓
Check payment status ✓
Decode invoice ✓

We verified the payment flow works, even though we can't actually pay invoices on single-node regtest. The verification logic is solid.

What we haven't done yet is build the actual CPFP transaction. That's the piece that makes this more than just an invoice generator.

Building the CPFP Transaction

File: src/services/feebump/cpfp.ts

This is where theory meets practice. We're going to take a parent transaction with an anchor output and construct a child transaction that spends it, paying enough fee to bump both transactions.

Why Use PSBT?

Before jumping into code, let's talk about PSBTs (Partially Signed Bitcoin Transactions). You might wonder why we need this abstraction when we could just build a transaction directly.

The reason is simple: most Bitcoin transactions these days involve multiple parties or require careful coordination. PSBTs are Bitcoin's standard format for "I've built this transaction, but it's not ready to broadcast yet."

For our CPFP service:

Build the transaction structure
Add the anchor output as an input
Calculate the change output
Sign it (this is where things get interesting)
Extract the final transaction

The Complete createCPFPTransaction Method

The method follows nine distinct steps. Let's walk through each one.

Step 1: Fetch the Parent Transaction

const parentTx = await bitcoinService.getTransaction(request.parentTxid);
if (!parentTx) {
  return { success: false, error: 'Parent transaction not found' };
}

We start by fetching the full parent transaction from Bitcoin Core. We need this to access the anchor output's details.

Step 2: Verify the Anchor Output

const anchorOutput = parentTx.vout[request.anchorVout];
if (!anchorOutput) {
  return { success: false, error: `Anchor output ${request.anchorVout} not found` };
}

const anchorValue = Math.round(anchorOutput.value * 100000000);
if (anchorValue !== 330) {
  return {
    success: false,
    error: `Output is ${anchorValue} sats, not 330 (not an anchor output)`,
  };
}

This catches mistakes early. If someone passes the wrong output index, or if they're trying to spend something that isn't an anchor, we bail out before doing any work.

Bitcoin Core returns values in BTC (e.g., 0.00000330), so we multiply by 100,000,000 to convert to satoshis.

Step 3: Calculate Parent Transaction Fees

const parentSize = parentTx.vsize || parentTx.size;
const parentFee = await this.calculateActualFee(request.parentTxid);
const parentFeeRate = parentFee > 0
  ? Math.ceil((parentFee / parentSize) * 100) / 100
  : 0;

We need to know what the parent is already paying. The calculateActualFee() helper fetches all the parent's inputs, sums them up, subtracts the outputs, and returns the difference. That's the fee.

Note: Calculating the actual fee requires fetching each input's previous transaction to determine input values. This is why we have a separate helper method for it.

Step 4: Calculate Required Child Fees

Remember the package fee rate concept from Part 2? Miners care about the combined fee rate of parent and child transactions.

// 1 input + 1 output ≈ 110 vbytes
const childSize = 110; 
const totalSize = parentSize + childSize;
const totalFeeNeeded = Math.ceil(totalSize * request.targetFeeRate);
const childFeeNeeded = totalFeeNeeded - parentFee;

The child transaction size estimate (110 vbytes) assumes one input (the anchor) and one output (change back to our wallet). In reality, it might be slightly different, but this is conservative.

Here's the math:

Parent is 200 vbytes paying 200 sats (1 sat/vbyte)
We want 10 sat/vbyte for the package
Total package: (200 + 110) × 10 = 3,100 sats needed
Child must pay: 3,100 - 200 = 2,900 sats

Step 5: Check the 330-Sat Limitation

if (childFeeNeeded > anchorValue) {
  return {
    success: false,
    error: `Child fee needed (${childFeeNeeded} sats) exceeds anchor value (${anchorValue} sats). Need additional inputs.`,
  };
}

This is the constraint we kept running into during testing. At 1 sat/vbyte, the anchor usually covers it. At 10 sat/vbyte or higher, you need additional wallet inputs.

We also check an optional maxFee parameter to prevent accidentally burning too much in fees.

Step 6: Build the PSBT

Now we construct the actual transaction:

const psbt = new bitcoin.Psbt({ network: this.network });

// Add anchor as input
psbt.addInput({
  hash: request.parentTxid,
  index: request.anchorVout,
  witnessUtxo: {
    script: Buffer.from(anchorOutput.scriptPubKey.hex, 'hex'),
    value: BigInt(anchorValue),
  },
});

The witnessUtxo field is important. For SegWit inputs (which anchor outputs are), we only need the output being spent, not the entire previous transaction. This makes PSBTs more efficient.

Why BigInt? Bitcoin.js-lib v6+ uses BigInt for satoshi amounts to avoid floating-point precision issues.

Step 7: Add Change Output

const changeAmount = anchorValue - childFeeNeeded;

if (changeAmount > 0) {
  const changeAddress = bitcoin.payments.p2wpkh({
    pubkey: this.walletKeyPair.publicKey,
    network: this.network,
  }).address!;

  psbt.addOutput({
    address: changeAddress,
    value: BigInt(changeAmount),
  });
}

If there's any satoshis left after paying the fee (there usually is at low fee rates), we send it back to our wallet as change. If the fee consumes the entire 330 sats, we skip adding an output.

The wallet address is generated from our keypair using Pay-to-Witness-Public-Key-Hash (P2WPKH), which is standard SegWit.

Step 8: The Signing Challenge

Here's where things get educational:

try {
  psbt.signInput(0, this.walletKeyPair);
  psbt.validateSignaturesOfInput(0, () => true);
  psbt.finalizeAllInputs();
} catch (signError: any) {
  return {
    success: false,
    error: `Transaction signing failed: ${signError.message}. This is expected - the anchor output belongs to the Lightning channel, not our test wallet.`,
  };
}

We generate a random keypair in the constructor:

this.walletKeyPair = ECPair.makeRandom({ network: this.network });

This signing will always fail. And that's actually useful for learning.

Why does it fail?

The anchor output doesn't belong to this random key. It belongs to the Lightning channel participants. In a real Lightning channel, only the channel partners have the private keys needed to spend anchor outputs.

What does this teach us?

In production, this service would need to:

Request the signature from the user's LND node via lncli signrawtransaction
Have the user provide a pre-signed CPFP transaction template
Use a collaborative signing setup where the service has partial authority

For learning purposes, the transaction structure is perfect. The fee calculations are correct. The inputs and outputs are valid. Only the signature is invalid because we don't have the real keys.

This is exactly how it works in real Lightning: the service can build the transaction, but only the channel participants can sign it.

Step 9: Extract the Transaction

const childTx = psbt.extractTransaction();
const childTxHex = childTx.toHex();
const childTxid = childTx.getId();

return {
  success: true,
  childTxid,
  childTxHex,
  feePaid: childFeeNeeded,
};

If signing succeeded (which it won't in our test setup), we'd extract the raw transaction as a hex string. This is what gets broadcast to the Bitcoin network.

The transaction ID is deterministic—it's the hash of the transaction data.

The Helper Method: calculateActualFee

This method deserves special attention because it's not obvious:

async calculateActualFee(txid: string): Promise<number> {
  const tx = await bitcoinService.getTransaction(txid);

  let inputValue = 0;
  let outputValue = 0;

  // Sum all outputs (easy - they're in the transaction)
  for (const vout of tx.vout) {
    outputValue += vout.value * 100000000;
  }

  // Sum all inputs (harder - need to fetch previous transactions)
  for (const vin of tx.vin) {
    if (vin.txid) {
      const prevTx = await bitcoinService.getTransaction(vin.txid);
      const prevOut = prevTx.vout[vin.vout];
      inputValue += prevOut.value * 100000000;
    }
  }

  return Math.round(inputValue - outputValue);
}

Bitcoin transactions don't store input amounts directly. To find out how much an input is worth, you have to:

Look at which previous transaction it's spending
Fetch that previous transaction
Look at the specific output being spent
That output's value is your input value

This is why calculating actual fees requires multiple RPC calls.

Testing the CPFP Builder

Let's create a test transaction and try to build a CPFP for it. First, we'll need to load the wallet we created on this series testwallet by running:

# Load testwallet
docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  loadwallet "testwallet"

# Expected output:
{
  "name": "testwallet"
}

#Verify wallet is loaded
docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  listwallets

# Expected output:
[
  "testwallet"
]

Create a test transaction with an anchor-like output:

ADDR=$(docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -rpcwallet=testwallet getnewaddress)

TXID=$(docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -rpcwallet=testwallet sendtoaddress $ADDR 0.00000330)

echo "Test TXID: $TXID"

# Expected output:
Test TXID: 20bdc7dd508d7fe8fc2569c..........

Try to create CPFP with a low fee rate (feasible):

curl -X POST http://localhost:3000/api/v1/feebump/create \
  -H "Content-Type: application/json" \
  -d "{
    \"txid\": \"$TXID\",
    \"anchorVout\": 0,
    \"targetFeeRate\": 1
  }" | jq

Expected result:

{
  "success": false,
  "error": "Transaction signing failed: ... This is expected - the anchor output belongs to the Lightning channel, not our test wallet."
}

That error message is honest about what's happening. The transaction was built correctly:

✓ Anchor output verified
✓ Fees calculated properly
✓ Transaction structure valid
✓ PSBT constructed
✗ Signing failed (expected—we don't have the keys)

Try with a high fee rate (unfeasible):

curl -X POST http://localhost:3000/api/v1/feebump/create \
  -H "Content-Type: application/json" \
  -d "{
    \"txid\": \"$TXID\",
    \"anchorVout\": 0,
    \"targetFeeRate\": 50
  }" | jq

Expected result:

{
  "success": false,
  "error": "Child fee needed (14020 sats) exceeds anchor value (330 sats). Need additional inputs."
}

This confirms the math from Part 2. At 50 sat/vbyte, you'd need roughly 13,000 sats in fees. The anchor only has 330. The service catches this in Step 5 before even attempting to build the transaction.

Payment-Gated Broadcasting

File: src/api/v1/broadcast.ts

The broadcast endpoint ties everything together. It's the final piece that turns this from a dev tool into a viable service.

The Three-Step Flow

Step 1: Verify Payment

const paymentStatus = await lightningPaymentService.checkPaymentStatus(paymentHash);

if (!paymentStatus.settled) {
  return res.status(402).json({
    success: false,
    error: 'Payment not received',
    paymentRequired: true,
    paymentHash,
  });
}

HTTP 402 literally means "Payment Required." It's rarely used, but this is exactly what it's for.

Step 2: Create CPFP

const cpfpResult = await cpfpService.createCPFPTransaction({
  parentTxid: txid,
  anchorVout: parseInt(anchorVout),
  targetFeeRate: parseFloat(targetFeeRate),
});

If payment was confirmed but the CPFP fails to build (maybe the fee is too high, or the anchor is already spent), we return an error but note that payment was received. This matters for customer support.

Step 3: Broadcast

const broadcastResult = await bitcoinService.sendRawTransaction(cpfpResult.childTxHex);

res.json({
  success: true,
  message: 'CPFP transaction broadcast successfully',
  data: {
    parentTxid: txid,
    childTxid: cpfpResult.childTxid,
    feePaid: cpfpResult.feePaid,
    paymentHash,
  },
});

If we get here, everything worked. The transaction is in the mempool. Both parent and child will confirm together.

Testing the Broadcast Endpoint

Step 1: Create test transaction

ADDR=$(docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -rpcwallet=testwallet getnewaddress)

TXID=$(docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -rpcwallet=testwallet sendtoaddress $ADDR 0.00000330)

echo "Test Transaction ID: $TXID"

Expected output:

Test Transaction ID: 25cebabb25670aa0ab2bc25190dec91....

Step 2: Create a real Lightning invoice (but don't pay it)

INVOICE_RESPONSE=$(curl -s -X POST http://localhost:3000/api/v1/lightning/create-invoice \
  -H "Content-Type: application/json" \
  -d '{"amountSats": 250, "memo": "CPFP test"}')

echo $INVOICE_RESPONSE | jq

**Expected response**

![Create a real Lightning invoice](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jy8xvegfimxoizn3hr2k.png)

# Extract payment hash
PAYMENT_HASH=$(echo $INVOICE_RESPONSE | jq -r '.data.paymentHash')
echo "Payment Hash: $PAYMENT_HASH"

Expected response:

Payment Hash: 5d04662cb0b736f7574d85c1371039..............

Step 3: Verify invoice is unpaid

curl -s http://localhost:3000/api/v1/lightning/payment/$PAYMENT_HASH | jq

Expected response:

{
  "success": true,
  "data": {
    "paymentHash": "5d04662cb0b736f7574d85c1371039..............",
    "paid": false
  }
}

Step 4: Try to broadcast without payment

curl -X POST http://localhost:3000/api/v1/feebump/broadcast \
  -H "Content-Type: application/json" \
  -d "{
    \"txid\": \"$TXID\",
    \"anchorVout\": 0,
    \"targetFeeRate\": 1,
    \"paymentHash\": \"$PAYMENT_HASH\"
  }" | jq

Expected response:

{
  "success": false,
  "error": "Payment not received",
  "paymentRequired": true,
  "paymentHash": "5d04662cb0b736f7574d85c1371039.............."
}

Perfect! The service correctly blocks unpaid requests with HTTP 402 (Payment Required).

Enhanced Bitcoin Service

File: src/services/bitcoin/node.ts

The Bitcoin service needed one crucial method: sendRawTransaction().

async sendRawTransaction(hexString: string): Promise<string> {
  logger.info('Broadcasting transaction', {
    size: hexString.length / 2,
  });

  try {
    const txid = await this.call<string>('sendrawtransaction', [hexString]);
    logger.info('Transaction broadcast successful', { txid });
    return txid;
  } catch (error: any) {
    logger.error('Transaction broadcast failed', {
      error: error.message,
    });
    throw new Error(`Broadcast failed: ${error.message}`);
  }
}

This wraps Bitcoin Core's RPC call, adds logging, and handles errors. Simple but essential.

We also added testMempoolAccept() for validating transactions without broadcasting them:

async testMempoolAccept(hexString: string) {
  return await this.call('testmempoolaccept', [[hexString]]);
}

This is great for debugging. You can check if a transaction would be accepted before actually sending it to the network.

What We've Built

Let's step back and look at the complete system:

The Flow

User's Lightning channel force-closes
Commitment transaction gets stuck in mempool (low fee)
User requests fee bump estimate
Service calculates cost: "2,500 sats to bump to 10 sat/vbyte"
Service generates Lightning invoice for 2,500 sats
User pays invoice from their Lightning wallet
Service verifies payment received
Service builds CPFP transaction
Service broadcasts CPFP
Both transactions confirm together

What Works

✅ Real-time mempool monitoring
✅ Accurate fee calculation
✅ Lightning invoice generation
✅ Payment verification
✅ CPFP transaction building
✅ Payment-gated broadcasting
✅ Complete error handling

What Doesn't Work (Yet)

⚠️ Transaction signing (needs Lightning keys)
⚠️ Actual payment testing (need multiple nodes)

Key Takeaways

1. The 330-Sat Limit is Real

We confirmed through testing what the math told us: 330 sats can bump fees to roughly 1-2 sat/vbyte. For higher rates, you need more inputs. This isn't a bug; it's a fundamental constraint.

2. Payment Verification Matters

Without the payment check in the broadcast endpoint, anyone could use the service for free. That one HTTP 402 check is what makes this sustainable.

3. PSBTs are the Standard

Every modern Bitcoin tool uses Partially Signed Bitcoin Transactions. Learning this pattern once helps with Lightning wallets, hardware wallets, multi-sig setups, and more.

4. Signing is the Hard Part

Building the transaction is straightforward. Getting the right signature is the challenge. This is true for Lightning, multi-sig, hardware wallets, and pretty much every interesting Bitcoin use case.

5. Error Handling Takes Time

Look at the codebase. Half of it is error handling, validation, and logging. That's not overhead; it's what makes the service maintainable.

What's Next: Part 6

In the final article of this series, we'll tackle:

Database Integration

Save all CPFP transactions
Track payment history
Build an audit trail

Frontend Dashboard

React UI for the complete flow
QR codes for Lightning invoices
Real-time status updates

Try It Yourself

Clone the repo: lightning-anchor-fee-outputs

Follow the README setup, then experiment:

Try different fee rates
Watch the 330-sat limit in action
Test the payment verification
Break things and learn from the errors

Building this taught me more than reading specs ever could. The best way to understand how Lightning fee bumping works is to implement it yourself.

Conclusion

We started Part 1 understanding the problem: Lightning transactions can get stuck.

We're ending Part 5 with a working solution: a payment-gated service that can bump those transactions using CPFP.

The core logic is done. Part 6 will add the polish: persistence, monitoring, and a UI.

Previous Articles in This Series

Additional Resources

Questions? Found a bug? Have improvements? Drop them in the comments.**

See you in Part 6

Building an Anchor Output Fee Bumping Service — Part 4: Lightning Payment Integration

Susan Githaiga — Tue, 10 Mar 2026 10:18:24 +0000

In Part 3, we built a service that could watch the Bitcoin mempool, spot anchor outputs, and estimate whether a fee bump was feasible. It was a solid foundation, but it stopped short of actually doing anything. No transaction was built. No fee was bumped. And crucially, no one was paying for the service.

Part 4 fixes all of that.

By the end of this article, the service will generate Lightning invoices, verify payments, construct real CPFP transactions using bitcoinjs-lib, and only broadcast those transactions once payment is confirmed. In other words: a working, payment-gated fee bumping service.

We are using Bitcoin regtest, so there's no risk to real funds. The setup is similar to how transactions would work on the mainnet network.

📂 All source code for this project is available here: Anchor Outputs fee-bumping service

File paths referenced throughout this article correspond directly to this repository.

Recap: Where Part 3 Left Us

Before diving in, here's a quick summary of what was already working:

Bitcoin Core RPC integration: the service could connect to a regtest node, query the mempool, and fetch transaction details
Anchor output detection: any 330-satoshi output in the mempool was flagged as a potential anchor
Fee estimation: given a target fee rate, the service calculated whether the 330-sat anchor alone was enough, or whether additional wallet inputs would be needed
Basic REST API: endpoints to start/stop monitoring and request fee estimates

What was missing was everything that comes after the estimate: building the child transaction, collecting payment, and broadcasting. That's what we're adding now.

What We're Adding in Part 4

Here's what's new:

Lightning invoice generation: charge users for the fee bump service
Payment verification: confirm the invoice is settled before taking action
CPFP transaction builder: construct the actual child transaction using bitcoinjs-lib
Payment-gated broadcast: only broadcast the CPFP after payment is confirmed

The end result is a complete payment flow: a user's stuck transaction gets bumped, and they pay for it instantly over Lightning.

The New Payment Flow

Before walking through the code, it helps to see how all these pieces connect. Here is the complete flow a user goes through:

The key design decision here is that nothing irreversible happens until payment is confirmed. The service checks the payment hash before building or broadcasting anything. This is what makes it viable as a service rather than just a dev tool.

Starting the Implementation

Step 1: Installing New Dependencies

The CPFP transaction builder needs a few new packages for constructing and signing Bitcoin transactions.

Run the following in your project root:

npm install bitcoinjs-lib tiny-secp256k1 ecpair

What each package does:

Package	Purpose
`bitcoinjs-lib`	Builds and encodes Bitcoin transactions
`tiny-secp256k1`	Low-level elliptic curve cryptography (required by bitcoinjs-lib v6+)
`ecpair`	Key pair management for signing transactions

Before Testing: Ensuring LND is Synced

Before testing invoice creation, you need to ensure both Bitcoin Core and LND are properly synced. This is a common issue when working with regtest that can cause invoice creation to hang indefinitely.

Step 1: Load Bitcoin Wallet

After restarting Docker containers, Bitcoin Core's wallet needs to be loaded:

# Load the wallet
docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  loadwallet "testwallet"

Expected response:

{
  "name": "testwallet"
}

Step 2: Generate Blocks to Complete Sync

Bitcoin Core may still be in Initial Block Download (IBD) mode, which prevents LND from syncing. Generate additional blocks to complete the sync:

# Generate 100 blocks
docker compose exec bitcoin bitcoin-cli -regtest \
  -rpcuser=bitcoinrpc -rpcpassword=changeme \
  -generate 100

Step 3: Verify LND Sync Status

Wait approximately 10 seconds after generating blocks, then check if LND has synced to the chain:

# Check LND sync status
docker compose exec lnd lncli --network=regtest getinfo | \
  jq '{synced_to_chain, block_height}'

Sample response:

The critical field is "synced_to_chain": true. If this shows false, LND is still waiting for Bitcoin Core to sync, and invoice creation will hang.

If sync is still false:

Wait another 10-20 seconds
Generate more blocks:

docker compose exec bitcoin bitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=changeme -generate 50

Check LND logs:

docker compose logs lnd --tail=20

Once synced_to_chain is true, you're ready to test invoice creation.

Step 2: The Lightning Payment Service

File: src/services/lightning/payment.ts

This service handles all communication with LND's REST API. It's intentionally kept separate from the existing lnd.ts, which only handles node info; one file for node status, one for payment operations.

The service does three things:

Invoice creation: given an amount in sats, a memo, and an expiry time, it calls LND's /v1/invoices endpoint and returns a payment_request string the user can pay from any Lightning wallet.

Payment status checks: given a payment hash, it queries LND to see whether that invoice has been settled. One important detail here: LND's REST API expects the payment hash encoded as base64, but Bitcoin tools generally work in hex. The service handles that conversion internally.

Payment polling: rather than setting up a webhook infrastructure, the service simply checks payment status every 2 seconds until it's confirmed or a timeout is reached. This is simpler for regtest and works reliably, though a production system would benefit from webhooks for efficiency.

A note on authentication: LND uses macaroons , similar to API tokens, to authorize requests. The service reads the macaroon file from disk on startup and attaches it to every request as a header. In regtest, LND also uses a self-signed TLS certificate, so the HTTPS agent is configured to allow that. This should be handled properly with real certificates in production.

Step 3: Exposing Lightning Endpoints

File: src/api/v1/lightning-payment.ts

With the service built, three REST endpoints expose its functionality:

Method	Endpoint	What it does
`POST`	`/api/v1/lightning/create-invoice`	Generates a Lightning invoice for a given amount
`GET`	`/api/v1/lightning/payment/:hash`	Checks whether a specific invoice has been paid
`POST`	`/api/v1/lightning/decode-invoice`	Returns the decoded details of a payment request string

These are registered in src/index.ts under the /api/v1/lightning path.

Testing Invoice Creation

Create an invoice:

curl -X POST http://localhost:3000/api/v1/lightning/create-invoice \
  -H "Content-Type: application/json" \
  -d '{"amountSats": 2500, "memo": "Test"}' | jq

A successful response includes a payment_request (invoice) field starting with lnbcrt (the regtest prefix) and a paymentHash which you'll use to check status later:

Testing Payment Status Check

Check payment status:

# Replace with your actual payment hash
curl http://localhost:3000/api/v1/lightning/payment/702085df5684eab92460a1dbd9da797015d3fffcc179290f22c12b32facebbea | jq

Before payment, this returns "paid": false:

Testing Limitation on Regtest

On regtest with a single LND node and no open channels, you cannot actually pay invoices. In production, users would pay from their Lightning wallets, but for testing purposes, we can verify the broadcast logic works correctly.

The payment verification logic works. The service correctly checks payment status before broadcasting.

To fully test the payment flow in a real environment, you would need:

A second Lightning node (or use a testnet/mainnet Lightning wallet)
An open channel between the nodes
Sufficient balance to pay the invoice

For the purposes of this tutorial, we've verified that:

Invoice creation works ✓
Payment status checking works ✓
Broadcast is gated by payment verification ✓

Next: Part 5 continues with the CPFP transaction builder and the payment-gated broadcast endpoint.

Previous Articles in This Series

Question for those who've deployed Lightning services: How do you manage reserve funds for fee bumping? Do you keep a fixed amount or calculate it dynamically based on channel count? Trying to figure out the best approach for Part 4.

Susan Githaiga — Fri, 27 Feb 2026 14:58:05 +0000

Susan Githaiga

Feb 27

Building an Anchor Output Fee Bumping Service - Part 3: Setup & Implementation

#api #backend #bitcoin #tutorial

Comments

6 min read

Building an Anchor Output Fee Bumping Service - Part 3: Setup & Implementation

Susan Githaiga — Fri, 27 Feb 2026 04:49:12 +0000

Part 3 of my anchor outputs learning series - getting the service running and seeing it in action

Quick Recap

Part 1: The problem - commitment transactions with outdated fees get stuck

Part 2: The solution - anchor outputs let you boost fees later using CPFP

Part 3 (this one): Actually building a service that does this

What We're Building

A service that:

Monitors the Bitcoin mempool for commitment transactions
Detects anchor outputs (330 sat outputs)
Calculates CPFP fee requirements
Provides a REST API to estimate and request fee bumps

Important: We're using Bitcoin regtest network for this.

GitHub Repository: lightning-anchor-fee-outputs

System Requirements

Before you start:

Node.js 18 or higher
Docker Desktop (for Bitcoin Core and LND)

Operating Systems: Works on macOS, Linux, and Windows (with WSL2)

Setup Instructions

Step 1: Clone and Install

git clone https://github.com/SusanGithaigaN/lightning-anchor-fee-outputs.git
cd lightning-anchor-fee-service
npm install

Step 2: Start Docker Services

docker compose up -d

This starts:

Bitcoin Core (regtest network)
LND (Lightning node)
PostgreSQL
Redis

Step 3: Setup Bitcoin Regtest

i) Create Bitcoin wallet

docker compose exec bitcoin bitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=changeme createwallet "mywallet"

ii) Mine 101 blocks

docker compose exec bitcoin bitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=changeme -generate 101

If you already created the LND wallet before (you'll get this error), just verify it's working:

docker compose exec lnd lncli --network=regtest getinfo

Step 4: Setup LND Wallet

docker compose exec lnd lncli --network=regtest create

Follow the prompts:

Enter a password
Select n to create a new seed
Write down the 24 words (optional for regtest)
Press Enter for cipher passphrase

Step 5: Start the Service

npm run dev

You should see:

Server running on port 3000
Connected to Bitcoin Core

Testing the Service

Test 1: Health Check

curl http://localhost:3000/health

Expected: {"status":"ok"}

Test 2: Bitcoin Connection

curl http://localhost:3000/api/v1/bitcoin/info

You should see: Chain info showing regtest network with 101 blocks.

Test 3: LND Connection

curl http://localhost:3000/api/v1/lightning/info

You should see: Node info with anchor outputs feature enabled (check for "anchors-zero-fee-htlc-tx").

Test 4: Start Monitoring

curl -X POST http://localhost:3000/api/v1/monitor/start \
  -H "Content-Type: application/json" \
  -d '{"intervalMs": 3000}'

Expected: {"success":true,"message":"Monitoring started","intervalMs":3000}

Test 5: Create Test Transaction

# Get a new address
ADDR=$(docker compose exec bitcoin bitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=changeme getnewaddress)

# Send 330 sats (creates anchor-like output)
TXID=$(docker compose exec bitcoin bitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=changeme sendtoaddress $ADDR 0.00000330)

echo "Transaction ID: $TXID"

Test 6: Check Monitor Status

Wait 5 seconds, then:

curl http://localhost:3000/api/v1/monitor/status

You should see: Your transaction being tracked with detected anchor output.

Example response:

{"success":true,"data":{"isMonitoring":true,"trackedCount":1,"transactions":[{"txid":"b3f593509ba7efa9eabeedd159bcc158980917f4804f6a1be8163708c5542c5b","hex":"02000000000101c1de4dab5c406faad339b4e7ed3998a2c9286ee8d7e08eecc4cdd56cb1f98d980000000000fdffffff0243f8029500000000160014ba6345572da5d28ea9830dfc0476826c4bb10c8b4a010000000000001600142935034b935612bc85089f89fca385ba9a78791e0247304402205abef31db372537d0f3ab2f4b5240dbdc6dd7367fe64384e1e58669f4a1a686e022049e7e8d418d18b8328070dad0251b6aefc6b0023b6ed914f34797a40111a9df5012103bb47542f3fe2dd313e221de0620dd733f0766e00d52eb90e222c06aa090aec9e30010000","fee":0,"size":141,"feeRate":0,"anchorOutputs":[{"vout":1,"value":330,"scriptPubKey":"00142935034b935612bc85089f89fca385ba9a78791e"}]}]}}

Test 7: Estimate Fee Bump

curl -X POST http://localhost:3000/api/v1/feebump/estimate \
  -H "Content-Type: application/json" \
  -d "{\"txid\": \"$TXID\", \"targetFeeRate\": 10}"

You should see: Fee calculations showing that 10 sats/vbyte is NOT feasible with just the 330 sat anchor alone. This proves the limitation.

Expected result: "feasible": false

This means you'd need to add ~2,180 sats from your own wallet to bump to 10 sats/vbyte.

Example result

susan@susan-githaiga:~/development/projects/lightning-anchor-fee-outputs$ curl -X POST http://localhost:3000/api/v1/feebump/estimate \uts$ curl -X POST http://localhost:3000/api/v1/feebump/estimate \
  -H "Content-Type: application/json" \
  -d "{\"txid\": \"$TXID\", \"targetFeeRate\": 10}"
{"success":true,"data":{"txid":"b3f593509ba7efa9eabeedd159bcc158980917f4804f6a1be8163708c5542c5b","parentSize":141,"parentFee":0,"parentFeeRate":0,"childSize":110,"totalSize":251,"targetFeeRate":10,"totalFeeNeeded":2510,"childFeeNeeded":2510,"anchorValue":330,"feasible":false}}

Test with a lower fee rate (should be feasible):

curl -X POST http://localhost:3000/api/v1/feebump/estimate \
  -H "Content-Type: application/json" \
  -d "{\"txid\": \"$TXID\", \"targetFeeRate\": 1}"

Result

susan@susan-githaiga:~/development/projects/lightning-anchor-fee-outputs$ # Test with 1 sat/vbyte (should be feasible)ts$ # Test with 1 sat/vbyte (should be feasible)
curl -X POST http://localhost:3000/api/v1/feebump/estimate \
  -H "Content-Type: application/json" \
  -d "{\"txid\": \"$TXID\", \"targetFeeRate\": 1}"
{"success":true,"data":{"txid":"b3f593509ba7efa9eabeedd159bcc158980917f4804f6a1be8163708c5542c5b","parentSize":141,"parentFee":0,"parentFeeRate":0,"childSize":110,"totalSize":251,"targetFeeRate":1,"totalFeeNeeded":251,"childFeeNeeded":251,"anchorValue":330,"feasible":true}}

This should show "feasible": true because 251 vbytes × 1 sat/vbyte = only 251 sats needed

Understanding the Results

When you check the monitor status, look for:

✅ trackedCount: 1 - Service detected your transaction

✅ value: 330 - Confirmed it's an anchor output

✅ anchorOutputs array - Shows which outputs are anchors

When you estimate fees:

✅ feasible: true - Can bump with just the anchor

❌ feasible: false - Need additional inputs from wallet

Key insight: 330 sats can only bump to about 10-20 sats/vbyte maximum.

Troubleshooting

Port conflicts?

sudo systemctl stop redis-server postgresql
docker compose restart

Services not starting?

docker compose logs bitcoin
docker compose logs lnd

Monitor not detecting transactions?

Make sure the transaction is in mempool (not confirmed yet). Don't mine blocks immediately after sending!

What We Built

Here's what the service does:

1. Bitcoin Integration

Connects to Bitcoin Core via RPC
Monitors mempool every 3-10 seconds
Fetches transaction details

2. Anchor Detection

Scans all transaction outputs
Identifies 330 satoshi outputs
Tracks them as potential anchors

3. Fee Estimation

Calculates parent transaction size
Estimates child transaction size (~110 vbytes)
Computes package fee rate
Determines if anchor alone is sufficient

4. REST API

Start/stop monitoring
Check status and tracked transactions
Estimate fee bump requirements
Bitcoin and Lightning info endpoints

Key Learnings

1. The 330 Sat Limitation is Real

Anchor outputs can only bump fees to ~10-20 sats/vbyte. For higher rates, you need additional UTXOs from your wallet.

Example:

Target: 50 sats/vbyte
Parent + Child: 330 vbytes
Total fee needed: 16,500 sats
Anchor provides: 330 sats
Need to add: 16,170 sats from wallet

2. Regtest Makes Testing Easy

Free Bitcoin (just mine blocks)
Instant blocks (no waiting)
No risk of losing real money
Perfect for learning and development

3. Monitoring is the Easy Part

Detecting 330 sat outputs in the mempool is straightforward. The hard part comes next: signing and broadcasting CPFP transactions.

4. Production Needs Reserve Funds

Real implementations maintain a pool of UTXOs specifically for fee bumping. You can't rely on the anchor alone.

5. Docker Simplifies Setup

Bitcoin Core and LND in Docker means:

No system pollution
Easy cleanup
Consistent environment
Works everywhere

What's Next

Current Status: ✅ Monitoring and estimation work

Still Missing: ❌ Actual transaction signing and broadcasting

Part 4 will cover:

Wallet integration for additional inputs
Building and signing CPFP transactions
Broadcasting to Bitcoin mainnet network
Testing with real Lightning channels
Accepting Lightning payments for the service

Future improvements:

Automatic fee bumping (no manual trigger)
Multiple channel support
Reserve fund management
Web dashboard
Mainnet deployment

Resources

Next: Part 4 adds Lightning payment integration, including invoice generation and payment verification

If you have any questions or suggestions, drop them in the comments

The 330 sat number seemed random to me at first, but the dust limit explanation made it click. What other Lightning Network concepts have you found confusing at first but made sense once you dug deeper?

Susan Githaiga — Mon, 23 Feb 2026 04:17:16 +0000

Susan Githaiga

Feb 20

Understanding Lightning Network Anchor Outputs - Part 2: The Technical Deep Dive

#bitcoin #lightning #tutorial #web3

Comments

9 min read

Understanding Lightning Network Anchor Outputs - Part 2: The Technical Deep Dive

Susan Githaiga — Fri, 20 Feb 2026 04:43:53 +0000

Welcome back, and thank you for being here to learn with me.This is Part 2 of my ongoing series where I dive deeper into Lightning Network anchor outputs and share what I'm figuring out as I go

Welcome Back

In Part 1, we covered the basic problem: pre-signed Lightning commitment transactions can have outdated fees by the time you need to broadcast them. Anchor outputs solve this by letting you boost fees later using CPFP (Child Pays For Parent).

Today, we're going deeper. We're answering the "why" and "how" questions that make anchor outputs actually work.

What we're covering in Part 2:

How CPFP really works (the mechanics)
Why 330 sats? (The magic number explained)
The one-block delay (CSV) and why it's crucial
What happens to your other outputs
Real-world examples with actual numbers

Let's dive in.

CPFP Mechanics: How Does This Actually Work?

In Part 1, we learned that CPFP means "Child Pays For Parent." But let's understand the mechanics of HOW this works at the Bitcoin protocol level.

How Bitcoin Miners Think

Bitcoin miners want to maximize their profits. They look at transactions in the mempool and try to fill each block with the transactions that pay the highest fees.

Here's the key insight: Miners don't just look at individual transactions. They look at transaction packages (parent + child combinations) and calculate the total fee rate for the whole package.

The Math Behind It

Let's use real numbers:

Parent Transaction (Your Commitment TX):

Size: 200 vbytes
Fee: 200 sats (1 sat/vbyte)
Fee rate: 1 sat/vbyte ❌ Too low!

This transaction alone won't get confirmed during high-fee periods. Miners will ignore it.

Now you create a Child Transaction:

Size: 150 vbytes
Spends: Your 330-sat anchor output
Fee you add: 120,000 sats
Total fee: 120,330 sats

Combined Package:

Total size: 200 + 150 = 350 vbytes
Total fees: 200 + 120,330 = 120,530 sats
Package fee rate: 120,530 ÷ 350 = 344 sats/vbyte ✅

Now miners are interested! A 344 sat/vbyte fee rate is competitive even during high congestion.

The critical rule: The child transaction cannot be confirmed until the parent is confirmed (because the child spends an output from the parent). So miners MUST include both or neither.

This creates the economic incentive: to get the child's juicy fee, miners must also confirm the parent.

Why 330 Satoshis? The Magic Number Explained

You might be wondering: "Why exactly 330 sats? Why not 100 sats? Or 500 sats?"

Great question! There are actually three reasons for this specific number:

Reason 1: Bitcoin's Dust Limit

Bitcoin has something called a "dust limit" to prevent spam. Outputs that are too small are considered "dust" and many nodes won't relay transactions that create them.

The dust limit for standard outputs is around 546 satoshis.

But anchor outputs use a special script type that has a lower dust limit of 330 satoshis. This makes them the smallest spendable outputs possible without being classified as dust.

Why this matters: You want anchor outputs to be as small as possible so they don't waste channel capacity, but big enough to be spendable.

Reason 2: Standardization Across Lightning

All Lightning implementations (LND, Core Lightning, Eclair, LDK) agreed on 330 sats as the standard in the BOLT (Basis of Lightning Technology) specifications.

This means:

Everyone uses the same amount
Channels work consistently across different implementations
No confusion or compatibility issues

Reason 3: Enough Value to Spend

Even though 330 sats is small (currently worth less than $0.50 USD), it's enough to:

Be recognized as a valid output by the Bitcoin network
Cover the cost of creating a small child transaction
Not be dismissed as too trivial to process

The bottom line: 330 sats is the Goldilocks number—not too big (wastes channel funds), not too small (can't be spent), just right.

The One-Block Delay (CSV): Why Can't I Spend My Other Outputs Immediately?

Here's something interesting: When you broadcast a commitment transaction, you can spend your anchor output immediately, but you cannot spend your main balance output for at least one block (about 10 minutes).

This is called a CSV lock (CheckSequenceVerify).

What Is CSV?

CSV stands for CheckSequenceVerify. It's a Bitcoin script command that says: "This output cannot be spent until X blocks have been mined after this transaction is confirmed."

In anchor output commitment transactions, all outputs except the anchors have a 1 block CSV lock (written as 1 CSV in the script).

Why Does This Delay Exist?

This one-block delay prevents something called transaction pinning, which is a type of attack where your channel partner could try to interfere with your fee bumping.

Here's how the attack would work WITHOUT the CSV lock:

You broadcast your commitment transaction with low fees
Your evil partner immediately spends their balance output with a LOW fee
This creates a competing transaction in the mempool
When you try to CPFP using your anchor, Bitcoin's rules prevent you because there's already a conflicting spend

With the CSV lock:

You broadcast your commitment transaction
Your partner's balance output is locked for one block
You can spend your anchor output immediately to boost fees
Your commitment transaction confirms in the next block
Only AFTER confirmation can your partner spend their output (but it's too late to interfere)

The CSV lock gives you a clean window to boost fees without interference.

What Happens to Your Other Outputs?

Let's map out ALL the outputs in a typical anchor output commitment transaction:

Output 1: Your Balance

Amount: Your portion of the channel (e.g., 1,000,000 sats)
Lock: 1 block CSV delay
Why: This is your actual money from the channel

Output 2: Partner's Balance

Amount: Their portion of the channel (e.g., 500,000 sats)
Lock: 1 block CSV delay
Why: This is their money from the channel

Output 3: Your Anchor

Amount: 330 sats
Lock: None! Can spend immediately
Why: So YOU can fee-bump right away

Output 4: Partner's Anchor

Amount: 330 sats
Lock: None! Can spend immediately
Why: So THEY can fee-bump right away

Optional Output 5: HTLCs (If Any)

Amount: Varies (pending payments in the channel)
Lock: Time-locked based on payment conditions
Why: These are in-flight payments that need to be resolved

Key takeaway: Only the anchor outputs can be spent immediately. Everything else waits one block. This is by design for security.

Real-World Example: The Numbers in Action

Let's walk through a complete real-world scenario with actual numbers to see how this all works together.

The Setup

You have a Lightning channel:

Your balance: 5,000,000 sats (0.05 BTC)
Partner balance: 3,000,000 sats (0.03 BTC)
Your anchor: 330 sats
Partner anchor: 330 sats

Total channel capacity: 8,000,660 sats

The Crisis

Your partner goes offline. You need to force-close the channel to get your funds back.

You check Bitcoin mempool fees:

Current rate: 250 sats/vbyte (high congestion!)
Your commitment transaction size: 220 vbytes
Needed fee: 220 × 250 = 55,000 sats

Problem: Your pre-signed commitment only has a 440 sat fee (2 sats/vbyte). This won't confirm for days or weeks.

The Solution: CPFP

Step 1: Broadcast commitment transaction

Fee paid: 440 sats (pathetically low)
Status: Sitting in mempool, unconfirmed

Step 2: Create child transaction
You create a new transaction that:

Spends: Your 330-sat anchor output
Adds inputs: 60,000 sats from your regular Bitcoin wallet
Creates output: Sends to your wallet
Transaction size: 180 vbytes
Fee: 54,560 sats + 330 sats (anchor) = 54,890 sats total

Step 3: Calculate package fee rate

Parent size: 220 vbytes
Child size: 180 vbytes
Total size: 400 vbytes
Parent fee: 440 sats
Child fee: 54,890 sats
Total fee: 55,330 sats
Package rate: 55,330 ÷ 400 = 138 sats/vbyte

Wait, that's still lower than the 250 sats/vbyte market rate! Let me recalculate...

Step 2 (corrected): Create child transaction with proper fees
You need the package to average 250 sats/vbyte:

Total needed: 400 vbytes × 250 = 100,000 sats
Parent already paid: 440 sats
Child must pay: 100,000 - 440 = 99,560 sats

So you create the child transaction with a 99,560 sat fee.

Step 3 (corrected): Final package

Total size: 400 vbytes
Total fees: 440 + 99,560 = 100,000 sats
Package rate: 250 sats/vbyte ✅

Step 4: Confirmation
Miners see your attractive package and include it in the next block. Both transactions confirm together.

The cost:

You paid 100,000 sats total (~$130 USD at $65k BTC)
But you secured your 5,000,000 sats (0.05 BTC = ~$3,250 USD)
Worth it!

The Economics: Is This Expensive?

Let's talk about the elephant in the room: This can be expensive!

When Fees Are Normal (1-10 sats/vbyte)

Your commitment TX: 220 vbytes × 5 = 1,100 sats (~$1.43)
CPFP child: 180 vbytes × 5 = 900 sats (~$1.17)
Total cost: ~$2.60 ✅ Very affordable!

When Fees Are High (200+ sats/vbyte)

Your commitment TX: 220 vbytes × 200 = 44,000 sats (~$57)
CPFP child: 180 vbytes × 200 = 36,000 sats (~$47)
Total cost: ~$104 ⚠️ Ouch!

When Fees Are INSANE (500+ sats/vbyte)

Your commitment TX: 220 vbytes × 500 = 110,000 sats (~$143)
CPFP child: 180 vbytes × 500 = 90,000 sats (~$117)
Total cost: ~$260 💀 Very painful!

The reality: Force-closing channels during high-fee periods is expensive. This is why:

Lightning encourages cooperative closes (much cheaper)
You should maintain channels with reliable partners
Reserve funds for fee-bumping are essential

But here's the key: Without anchor outputs, you might not be able to close at all during high-fee periods. You'd be completely stuck. Anchor outputs give you the OPTION to pay more to get your funds back—which is better than having no option.

Common Questions

Q: Can I use the same anchor output multiple times?

A: No! Once you spend an anchor output in a child transaction, that's it. You can't spend it again. If your child transaction doesn't have enough fee and still doesn't confirm, you'd need to create ANOTHER child transaction that spends the FIRST child (a "grandchild") to bump fees further. This is called CPFP chaining.

Q: What if my partner also tries to fee-bump at the same time?

A: That's fine! You each have your own separate anchor output. You can both create child transactions independently. Whichever child transaction (yours or theirs) gets confirmed first will pull the parent through. This is actually good—it means either party can ensure confirmation.

Q: What if I don't have enough Bitcoin to fee-bump?

A: Then you're stuck. This is why maintaining a reserve fund is crucial. If you operate Lightning channels, you MUST keep separate on-chain Bitcoin available for fee-bumping emergencies. Think of it as insurance—you pay a little to protect a lot.

Q: Can I spend my balance output and my anchor in the same transaction?

A: No! Your balance output has a 1-block CSV lock. You must wait one block after the commitment transaction confirms before you can spend your balance. The anchor can be spent immediately, but the balance cannot.

Q: Why can't commitment transactions just use RBF (Replace-By-Fee) instead?

A: Great question! RBF (Replace-By-Fee) allows you to replace an unconfirmed transaction with a new version that pays higher fees. However, RBF doesn't work well for Lightning because:

Both parties would need to cooperate to create the replacement (but in a force-close, your partner is unresponsive)
RBF is vulnerable to transaction pinning attacks
CPFP with anchors is more secure because each party can act independently

What We've Learned in Part 2

Let's recap the key technical details we covered:

✅ CPFP mechanics: Miners calculate package fee rates (parent + child together), creating the economic incentive to confirm both

✅ 330 sats explained: The minimum spendable amount that's not classified as dust, standardized across all Lightning implementations

✅ CSV lock: The one-block delay on balance outputs prevents transaction pinning attacks and gives you a clean window to fee-bump

✅ Output structure: Anchors can be spent immediately, but all other outputs must wait one block after confirmation

✅ Real costs: Can range from $3 in normal times to $200+ during extreme congestion—but it beats being stuck with no option

✅ Economics: Force-closing is expensive, which incentivizes cooperative closes and choosing reliable channel partners

What's Coming in Part 3

Now that you understand the technical details, Part 3 will cover the practical side:

How to check if your Lightning node supports anchor outputs
Setting up anchor outputs in different implementations (LND, Core Lightning, Eclair)
How much Bitcoin to keep in reserve for fee-bumping
Tools and commands for monitoring and managing anchor outputs
What to do when a force-close happens

Building Understanding Together

We've gone from "what are anchor outputs?" (Part 1) to "how do they actually work?" (Part 2). The complexity is increasing, but we're building on the foundation step by step.

If anything in Part 2 was confusing, that's valuable feedback for me. It helps me understand what needs more explanation.

Next up: Part 3 will be hands-on and practical. We'll move from theory to "okay, how do I actually USE this stuff?"

Thanks for sticking with me through the technical details. See you in Part 3.

Quick Summary (For the Skimmers)

CPFP works because miners calculate package fee rates (parent + child together)
330 sats is the smallest spendable amount that's not dust, standardized in BOLT specs
CSV lock (1 block delay) on balance outputs prevents transaction pinning attacks
Only anchors can be spent immediately; all other outputs wait 1 block
Real costs vary from $3 to $200+ depending on network congestion
Part 3: Practical setup, implementation guides, and reserve fund management

If you have any questions or feedback? Drop them in the comments

Do you have stuck Bitcoin transactions? Learn how Lightning Network Anchor Outputs solve fee volatility using CPFP in Part 1 of our technical deep dive.

Susan Githaiga — Wed, 18 Feb 2026 03:24:16 +0000

Susan Githaiga

Feb 18

Lightning Network Anchor Outputs Explained: The Basics (Part 1)

#bitcoin #lightning #tutorial #web3

Comments

5 min read

Lightning Network Anchor Outputs Explained: The Basics (Part 1)

Susan Githaiga — Wed, 18 Feb 2026 03:02:36 +0000

This is Part 1 of an ongoing series where I'm learning about Lightning Network anchor outputs and sharing what I discover along the way.

A Note Before We Start

Hi! I'm learning about Lightning Network anchor outputs and documenting my journey. This is going to be a continuous series where I break down complex topics into digestible pieces.

Why a series? Because this stuff is complicated, and trying to explain everything at once would be overwhelming, both for me to write and for you to read. So, we're taking it step by step, together.

What to expect:

Part 1 (this article): The basic problem and what anchor outputs are
Part 2 (coming next): How they actually work in detail
Part 3+: Implementation, setup, management, and real-world usage

Let's build this understanding together, one piece at a time.

The Problem We're Solving

We use the Lightning Network for quick and low-cost Bitcoin payments. But there's a challenge: if a channel closes unexpectedly, changing network fees can cause transactions to get stuck and delay your funds.

Here's the scenario:

You open a Lightning channel today when Bitcoin network fees are low (let's say 5 sats/vbyte). You and your channel partner sign some special transactions called "commitment transactions" that say "if we need to close this channel, here's who gets what."

The problem? These transactions are signed TODAY, but you might not need to use them until WEEKS or MONTHS later.

What happens then?
Week 1: Channel opens, fees are 5 sats/vbyte
Week 4: You need to close the channel, but now fees are 500 sats/vbyte
**Result: **Your transaction with the old 5 sats/vbyte fee sits in the waiting room (mempool) forever because miners prioritize higher-paying transactions

You're stuck. Your funds are in limbo because you guessed wrong about future fees.

This is the exact problem anchor outputs solve.

What Are Lightning Network Anchor Outputs?

Picture this: You're vibing with your Lightning channel, everything's smooth, then BAM—network fees spike and your transaction gets stuck. You're basically Mort from Madagascar watching the fossa approach—complete panic mode.

Anchor outputs are the solution. Think of them like the assistance service you use at a mall when you forget where you parked your car:

The Mall Parking Analogy

WITHOUT Anchor Outputs:
You pay for parking when you enter (5 shillings, based on last month's rate). Three weeks later when you're ready to leave, parking now costs 50 shillings. The attendant won't let you out because you paid the old rate. You're stuck in the parking lot.

WITH Anchor Outputs:
You get a basic ticket when you enter (minimal fee). When you're ready to leave and see parking now costs 50 shillings, you can pay the CURRENT rate right then and there. The attendant is happy, you leave smoothly, everyone wins.

That's what anchor outputs do for Lightning channels.

Instead of guessing what fees will be weeks from now, you pay a tiny amount upfront and can boost the fee to whatever is needed when you actually close the channel.

What Exactly Are Anchor Outputs?

Anchor outputs are tiny Bitcoin outputs (around 330 satoshis) that get attached to your commitment transaction. They exist for ONE purpose: to let you boost your transaction fee later using CPFP.

Think of them as handles or hooks attached to your transaction that you can grab onto later to pull it through when you need to.

How This Works (Step by Step)

Step 1: Opening the Channel

When you create a Lightning channel with anchor outputs enabled, your commitment transaction includes:

Your balance output - Your portion of the channel funds
Partner's balance output - Their portion of the channel funds
Your anchor output - 330 sats that YOU can spend
Partner's anchor output - 330 sats that THEY can spend

Both of you get your own anchor. This means either person can boost fees independently.

Step 2: Channel Needs to Close

Something happens—maybe your partner goes offline, maybe there's a dispute—and you need to broadcast your commitment transaction to close the channel (a "force close").

Step 3: Check Current Fees

You look at the Bitcoin network. Fees are HIGH. Your pre-signed commitment transaction only has a minimal fee (maybe 1-2 sats/vbyte). At current rates, it won't confirm for days or weeks.

Step 4: CPFP to the Rescue

This is where the magic happens:

You create a NEW transaction (the "child")
This child transaction spends your 330-sat anchor output
You add a LARGE fee to this child transaction (from your regular Bitcoin wallet)
Miners see: "If I confirm the parent (your commitment tx), I get to also confirm the child and collect that big fee!"
Both transactions get confirmed together

You've successfully boosted your commitment transaction's fee AFTER broadcasting it.

Visual Breakdown

Here's what it looks like:

PARENT TRANSACTION (Your Commitment Transaction)
┌─────────────────────────────────────────────────┐
│ Your balance: 1,000,000 sats                    │
│ Partner's balance: 500,000 sats                 │
│ Your anchor: 330 sats ⚓ ← YOU GRAB THIS        │
│ Partner's anchor: 330 sats ⚓                    │
│                                                  │
│ Fee: 1 sat/vbyte (very low)                    │
└─────────────────────────────────────────────────┘
                    ↓
        (You create a child transaction)
                    ↓
CHILD TRANSACTION
┌─────────────────────────────────────────────────┐
│ Spends: Your 330-sat anchor output              │
│ Adds: 50,000 sats from your wallet             │
│ Total Fee: 50,330 sats (300+ sats/vbyte)       │
│                                                  │
│ Miners: "Great fee! We'll confirm BOTH!"        │
└─────────────────────────────────────────────────┘
                    ↓
            BOTH CONFIRMED! ✅

That's Part 1!

What we covered today:

The fee guessing problem with Lightning channels
What anchor outputs are (tiny 330-sat outputs for fee bumping)
The mall parking analogy
The four-step process of how anchor outputs work
A visual diagram of parent and child transactions

What's coming in Part 2:

Deep dive into CPFP mechanics
Why anchor outputs are 330 sats specifically
What happens to the other outputs in commitment transactions
The one-block delay (CSV) and why it matters
Real-world examples with actual numbers

Building This Series Together

I'm learning this stuff as I go, breaking it down into pieces that make sense to me, and sharing it with you. If something's unclear, that helps me learn where I need to explain better in future parts.

This is a continuous series. I'm not trying to teach everything at once. We're building understanding brick by brick.

Next up: Part 2 will go deeper into the technical details and answer questions like "why 330 sats?" and "what prevents my channel partner from messing with my fee bump?"

Thanks for learning with me. See you in Part 2!

Quick Summary (If You're Skimming)

Problem: Lightning channels use pre-signed transactions, but fees might change by the time you need to close
Solution: Anchor outputs let you boost fees AFTER broadcasting using CPFP
How: Tiny 330-sat outputs attached to commitment transactions that you can spend to create a high-fee child transaction
Analogy: Like paying for mall parking when you LEAVE instead of guessing the fee weeks earlier

In Part 2, we’re getting technical: we’ll break down the 'magic' 330-sat calculation, the mechanics of CPFP, and why a one-block delay is actually your best friend. See you in the deep dive

Connect MySQL Workbench to MySQL Server in WSL using Node

Susan Githaiga — Wed, 13 Nov 2024 06:14:30 +0000

Windows Subsystem for Linux(WSL) is a Microsoft Windows feature that lets you run a Linux environment directly on your Windows machine without needing a separate virtual machine or dual booting your PC.

WSL uses your window's system IP address as it's own. However, the default MySQL workbench config only accepts requests and connections from 127.0.0.1

If you want to connect your NodeJS app to MySQL workbench, then you need to use the ip address of your host machine(PC). To do this, follow these steps:

Open your WSL terminal.
Run the following command in your WSL terminal to retrieve your host machine's(PC's) IP address:

ip route show | grep -i default | awk '{ print $3}'

On your .env file, change the DB_HOST(the variable which stores your host IP Address) to your host machine's IP Address

Now, your NodeJS server is running and ready for use:

To learn more about how to access your PC's network applications through WSL, read the following article on Microsoft learn: Accessing network applications with WSL

Leetcode #2623. Memoize

Susan Githaiga — Tue, 01 Oct 2024 15:33:26 +0000

Given a function fn, return a memoized version of that function.

A memoized function is a function that will never be called twice with the same inputs. Instead it will return a cached value.

You can assume there are 3 possible input functions: sum, fib, and factorial.

sum accepts two integers a and b and returns a + b. Assume that if a value has already been cached for the arguments (b, a) where a != b, it cannot be used for the arguments (a, b). For example, if the arguments are (3, 2) and (2, 3), two separate calls should be made.
fib accepts a single integer n and returns 1 if n <= 1 or fib(n - 1) + fib(n - 2) otherwise.
factorial accepts a single integer n and returns 1 if n <= 1 or factorial(n - 1) * n otherwise.

Example 1:

Input:

fnName = "sum"
actions = ["call","call","getCallCount","call","getCallCount"]
values = [[2,2],[2,2],[],[1,2],[]]

Output: [4,4,1,3,2]
Explanation:

const sum = (a, b) => a + b;
const memoizedSum = memoize(sum);
memoizedSum(2, 2); // "call" - returns 4. sum() was called as (2, 2) was not seen before.
memoizedSum(2, 2); // "call" - returns 4. However sum() was not called because the same inputs were seen before.
// "getCallCount" - total call count: 1
memoizedSum(1, 2); // "call" - returns 3. sum() was called as (1, 2) was not seen before.
// "getCallCount" - total call count: 2

Example 2:

Input:

fnName = "factorial"
actions = ["call","call","call","getCallCount","call","getCallCount"]
values = [[2],[3],[2],[],[3],[]]

Output: [2,6,2,2,6,2]
Explanation:

const factorial = (n) => (n <= 1) ? 1 : (n * factorial(n - 1));
const memoFactorial = memoize(factorial);
memoFactorial(2); // "call" - returns 2.
memoFactorial(3); // "call" - returns 6.
memoFactorial(2); // "call" - returns 2. However factorial was not called because 2 was seen before.
// "getCallCount" - total call count: 2
memoFactorial(3); // "call" - returns 6. However factorial was not called because 3 was seen before.
// "getCallCount" - total call count: 2

Example 3:

Input:

fnName = "fib"
actions = ["call","getCallCount"]
values = [[5],[]]

Output: [8,1]
Explanation:

fib(5) = 8 // "call"
// "getCallCount" - total call count: 1

Constraints:

> 0 <= a, b <= 105
> 1 <= n <= 10
> 0 <= actions.length <= 105
> actions.length === values.length

actions[i] is one of "call" and "getCallCount"
fnName is one of "sum", "factorial" and "fib"

Solution

As you continue to develop and optimize your JavaScript applications, remember the power of memoization. By identifying the right functions to memoize and implementing the appropriate caching strategies, you can unlock significant performance gains and create a more seamless and responsive user experience for your customers.

I hope this article helps. If you like the article, please leave a like and feel free to leave any concerns on the comment section. That is all for today.

JavaScript memoization

Susan Githaiga — Tue, 01 Oct 2024 15:13:06 +0000

JavaScript is a powerful programming language that plays a significant role in developing interactive websites. However, when dealing with complex and data-intensive applications, JavaScript performance can become an issue. This is where memoization comes into play. By unleashing the power of caching, memoization is a technique that significantly boosts JavaScript performance, making your applications run faster and smoother.

In this article, we will dive deep into the world of memoization and explore how it can optimize your JavaScript code. We will uncover the benefits of caching and how it reduces unnecessary calculations, resulting in improved execution time. Whether you are a seasoned JavaScript developer or a beginner, understanding and implementing memoization can take your code to the next level.

What is memoization and how does it work?

Memoization is a powerful optimization technique in programming that involves caching the results of expensive function calls and returning the cached result when the same inputs occur again. This process helps to avoid redundant computations and significantly improves the performance of your JavaScript applications.

The core idea behind memoization is to store the results of function calls in a cache, typically an object or a Map, where the function's arguments are used as keys and the corresponding results are stored as values. When the function is called again with the same arguments, the cached result is retrieved instead of recomputing the entire operation.

This caching mechanism is particularly beneficial for functions that perform complex or time-consuming calculations, as it can dramatically reduce the overall execution time of your application. Memoization is especially useful for functions that are called repeatedly with the same inputs, as it allows you to avoid redundant computations and improve the overall responsiveness of your application.

How to implement memoization in JavaScript

Implementing memoization in JavaScript is relatively straightforward. The basic approach involves creating a cache, typically an object or a Map, to store the results of function calls. When the function is called, the implementation checks if the result is already cached, and if so, it returns the cached value. If the result is not cached, the function is executed, and the result is stored in the cache for future use.

One common way to implement memoization in JavaScript is to use a higher-order function, which takes a function as an argument and returns a new function that incorporates the memoization logic. Here's a simple example:

Conclusion and final thoughts

In this article, we have explored the power of memoization and how it can be used to boost the performance of your JavaScript applications. By caching the results of expensive function calls, memoization can dramatically reduce the time required to execute those functions, leading to faster and more responsive applications.

Embrace the power of memoization, and let it be a key part of your JavaScript optimization toolkit. With the right approach, you can supercharge your applications and take them to new heights of performance and efficiency.