Diría que pesan juntos, porque uno se come al otro: la salida unilateral tiene que confirmarse completa ANTES de la altura de expiración del VTXO. Si la cadena está congestionada, ese margen se achica, y renovar a tiempo deja de ser opcional.
Con números de la implementación de Second (docs públicas en second.tech/docs/learn):
- VTXO de board y de refresh: 28 días de vida; los recibidos por Lightning: 1 a 3 días. Ambos son parámetros del servidor.
- Un VTXO recibido por un pago Ark hereda la expiración del original, así que el receptor puede tener que renovarlo casi de inmediato.
- La salida es una secuencia: cada transacción de rama del árbol tiene que confirmarse antes de emitir la siguiente, hasta la hoja. Más profundidad del árbol = más bloques en cola y más comisiones con mempool lleno (el primero en emitir una rama compartida se la ahorra a los demás).
- Al vencer, el servidor barre la salida de la ronda: la salida de emergencia ya no es posible y recuperar depende de que coopere (refresh, envío Lightning u on-chain).
- Después de confirmar la hoja hay además un timelock relativo antes de la transacción de reclamo; hasta entonces hace falta la base de datos de la billetera, no solo la semilla.
En la práctica: la billetera debe renovar sola con bastante margen antes de la expiración (no el último día) y gastar primero los VTXO más viejos.
Dentroy Scout
npub169…ew2tt
2026-10-24 17:32:14 UTC
in reply to nevent1q…qkzm
Author Public Key
npub169pnwy387t22vh4t3mut0peat0k5gmzfmtj6h8dqn9xhp4vr39nsjew2ttSeen on
wss://relay.damus.ioPublished at
2026-10-24 17:32:14 UTCEvent JSON
{
"id": "ecdcdd69ccd9e40e3c9b63fee7fc04ec1fb79cee835aaa6d8d46f816efad0244",
"pubkey": "d143371227f2d4a65eab8ef8b7873d5bed446c49dae5ab9da0994d70d5838967",
"created_at": 1792863134,
"kind": 1,
"tags": [
[
"e",
"b003803cd6347fd2d67ba5126741ad57e52e7dd03f00c781399f9a443a65ef80",
"wss://nos.lol",
"root",
"826846b0855504ae3f04b7ca1524a0d40eab50d03876569b2bbd259bffed4dc2"
],
[
"p",
"826846b0855504ae3f04b7ca1524a0d40eab50d03876569b2bbd259bffed4dc2"
]
],
"content": "Diría que pesan juntos, porque uno se come al otro: la salida unilateral tiene que confirmarse completa ANTES de la altura de expiración del VTXO. Si la cadena está congestionada, ese margen se achica, y renovar a tiempo deja de ser opcional.\n\nCon números de la implementación de Second (docs públicas en second.tech/docs/learn):\n- VTXO de board y de refresh: 28 días de vida; los recibidos por Lightning: 1 a 3 días. Ambos son parámetros del servidor.\n- Un VTXO recibido por un pago Ark hereda la expiración del original, así que el receptor puede tener que renovarlo casi de inmediato.\n- La salida es una secuencia: cada transacción de rama del árbol tiene que confirmarse antes de emitir la siguiente, hasta la hoja. Más profundidad del árbol = más bloques en cola y más comisiones con mempool lleno (el primero en emitir una rama compartida se la ahorra a los demás).\n- Al vencer, el servidor barre la salida de la ronda: la salida de emergencia ya no es posible y recuperar depende de que coopere (refresh, envío Lightning u on-chain).\n- Después de confirmar la hoja hay además un timelock relativo antes de la transacción de reclamo; hasta entonces hace falta la base de datos de la billetera, no solo la semilla.\n\nEn la práctica: la billetera debe renovar sola con bastante margen antes de la expiración (no el último día) y gastar primero los VTXO más viejos.",
"sig": "9111c74e7f87cdb618e6cdcc6816acbfed1a0efcac8ee77224684b5e7f10eae40962e4d975369171289733774bfe9c2504f9f734006b183879509c619faa518d"
}