• Lo que trae 0.21 y te importa como nodo
• La migración: lo crítico
• 1. Diagnóstico previo
• 2. Parar LND y volcar la BD
• 3. Descargar, verificar e instalar
• 4. Arrancar y vigilar la migración
• 5. Validar
• 6. Limpieza

LND 0.21.0-beta trae un cambio que toca de lleno a quien corre el backend con SQL nativo (PostgreSQL o SQLite): migra el almacén de pagos de formato KV a SQL, y es de un solo sentido. Lo demás del salto es rutina, pero esa migración obliga a hacer backup antes de tocar nada, porque LND no baja de versión una vez migrado el esquema.

Esta guía asume una instalación tipo MiniBolt: usuario admin/lnd, datos en /data/lnd, PostgreSQL como backend. Si usas bbolt o SQLite, te marco dónde cambia.

§Lo que trae 0.21 y te importa como nodo

• Migración del payment store de KV a SQL. Solo corre si tienes db.use-native-sql=true con backend postgres o sqlite. Es automática en el primer arranque y de un solo sentido. Se puede desactivar con db.skip-native-sql-migration=true. (Con bbolt esto no aplica.)
• MinCLTVDelta sube de 18 a 24. Solo te afecta si emites invoices con cltv_delta custom entre 18 y 23; el valor por defecto (80) no cambia.
• Los cierres de canal ahora piden entre 3 y 6 confirmaciones (protección de reorg), en vez de darse por finales al detectar el gasto. Escala con la capacidad del canal.
• getinfo añade el campo wallet_synced: estado de sync del wallet, independiente de synced_to_chain.
• getdebuginfo / lncli getdebuginfo ya NO devuelven el log por defecto: hay que pasar --include_log.
• Nueva tabla chain_params en backends SQL nativo: persiste la red activa y, si arrancas con una red distinta a la guardada, LND se niega a arrancar (evita corromper la BD mezclando mainnet/testnet).
• Compilado con go1.26.3. Trae además forwarding de onion messages con rate limiting, canales taproot simples de producción y RBF coop-close para taproot, entre otras.

§La migración: lo crítico

Si tu lnd.conf tiene db.use-native-sql=true (config estándar de MiniBolt con PostgreSQL), la migración de pagos se ejecuta sola la primera vez que arranque 0.21. Tres cosas que no se te pueden olvidar:

1. Es irreversible. LND no soporta downgrade una vez migrado el esquema.
2. El backup es tu única vuelta atrás. Para PostgreSQL, un pg_dump; para SQLite, copia de los .db; y siempre, el channel.backup (SCB).
3. Si prefieres separar riesgos, puedes subir el binario con db.skip-native-sql-migration=true y disparar la migración en otra ventana, con backup fresco.

§1. Diagnóstico previo

Comprueba que el nodo está sano y mira con qué backend corres.

lnd --version
lncli getinfo
lncli pendingchannels

En getinfo, synced_to_chain y synced_to_graph deben estar en true. No actualices desincronizado. En pendingchannels miras si tienes cierres en curso: reiniciar en mitad de un force-close es seguro (el estado de resolución persiste y se reanuda al arrancar), pero ten en cuenta que 0.21 cambia las confirmaciones de cierre y que la migración añade downtime.

Mira tu backend:

grep -nA6 -F '[db]' /data/lnd/lnd.conf
grep -niE 'native-sql|db.backend' /data/lnd/lnd.conf

Si ves db.use-native-sql=true, la migración de pagos correrá. Si solo ves db.backend=postgres sin native-sql, o usas bbolt, no corre.

Para PostgreSQL, hazte una idea del tamaño (y de la salud de la réplica si tienes una):

sudo -u postgres psql -d lndb -c "SELECT pg_size_pretty(pg_database_size('lndb'));"
sudo -u postgres psql -c "SELECT client_addr, state, sync_state, replay_lag FROM pg_stat_replication;"
df -h /data

§2. Parar LND y volcar la BD

sudo systemctl stop lnd

PostgreSQL — dump lógico con LND ya parado:

sudo mkdir -p /data/pgbackup && sudo chown postgres:postgres /data/pgbackup
sudo -u postgres pg_dump -Fc -d lndb -f /data/pgbackup/lndb-pre0.21-$(date +%F).dump
ls -lh /data/pgbackup/

-Fc es formato comprimido restaurable con pg_restore. Guárdalo, idealmente con copia fuera de la máquina.

SQLite: en lugar del dump, copia channel.sqlite y wallet.sqlite con LND parado. bbolt: copia los .db.

§3. Descargar, verificar e instalar

cd /tmp
VERSION=0.21.0
wget https://github.com/lightningnetwork/lnd/releases/download/v$VERSION-beta/lnd-linux-amd64-v$VERSION-beta.tar.gz
wget https://github.com/lightningnetwork/lnd/releases/download/v$VERSION-beta/manifest-v$VERSION-beta.txt.ots
wget https://github.com/lightningnetwork/lnd/releases/download/v$VERSION-beta/manifest-v$VERSION-beta.txt
wget https://github.com/lightningnetwork/lnd/releases/download/v$VERSION-beta/manifest-roasbeef-v$VERSION-beta.sig.ots
wget https://github.com/lightningnetwork/lnd/releases/download/v$VERSION-beta/manifest-roasbeef-v$VERSION-beta.sig

En arm64 (Raspberry Pi y similares), cambia amd64 por arm64 en el nombre del .tar.gz.

Checksum:

sha256sum --check manifest-v$VERSION-beta.txt --ignore-missing

Debe salir lnd-linux-amd64-v0.21.0-beta.tar.gz: OK.

Firma: importa la clave de roasbeef y verifica el manifest.

curl https://raw.githubusercontent.com/lightningnetwork/lnd/master/scripts/keys/roasbeef.asc | gpg --import
gpg --verify manifest-roasbeef-v$VERSION-beta.sig manifest-v$VERSION-beta.txt

Busca Good signature from "Olaoluwa Osuntokun". El aviso de “key not certified” es normal si no le has dado trust a la clave.

Opcional, si tienes el cliente ots, verifica el timestamp:

ots verify manifest-roasbeef-v$VERSION-beta.sig.ots -f manifest-roasbeef-v$VERSION-beta.sig

Descomprime e instala (reemplaza al binario anterior):

tar -xzvf lnd-linux-amd64-v$VERSION-beta.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-amd64-v$VERSION-beta/lnd lnd-linux-amd64-v$VERSION-beta/lncli
lnd --version

Debe decir lnd version 0.21.0-beta commit=v0.21.0-beta.

§4. Arrancar y vigilar la migración

sudo systemctl start lnd

Como systemctl start se queda bloqueado durante la migración, ábrete una segunda sesión SSH y sigue los logs ahí:

journalctl -fu lnd

Verás, en orden: Opening the main database, this might take a few minutes..., líneas SQLD migrando el esquema, una migración de pagos KV→SQL con su Total: N (igual que las de invoices/graph en su día), y al final Database(s) now open. Después, desbloqueo del wallet y arranque normal. No la interrumpas.

Para confirmar que avanza (PostgreSQL), en esa segunda ventana:

sudo -u postgres psql -c "SELECT pid, state, wait_event, now()-query_start AS dur, left(query,60) FROM pg_stat_activity WHERE datname='lndb' AND state='active';"

Conexión active con la query cambiando = está migrando. Si tienes réplica, vigila replay_lag: la migración genera un buen pico de WAL.

§5. Validar

lncli getinfo | grep -E 'version|synced'
lncli pendingchannels
lncli listchannels | grep -c '"channel_point"'
lncli listpayments --max_payments 1

Versión 0.21.0-beta, synced_to_chain / synced_to_graph / wallet_synced en true, tus canales contados, y listpayments devolviéndote pagos = el store SQL responde. En PostgreSQL, confirma que las tablas de pagos están pobladas y la réplica al día:

sudo -u postgres psql -d lndb -c "SELECT relname, n_live_tup FROM pg_stat_user_tables WHERE relname LIKE '%payment%' ORDER BY relname;"
sudo -u postgres psql -c "SELECT client_addr, state, sync_state, replay_lag FROM pg_stat_replication;"

§6. Limpieza

cd /tmp && sudo rm -r lnd-linux-amd64-v0.21.0-beta lnd-linux-amd64-v0.21.0-beta.tar.gz manifest-roasbeef-v0.21.0-beta.sig manifest-roasbeef-v0.21.0-beta.sig.ots manifest-v0.21.0-beta.txt manifest-v0.21.0-beta.txt.ots