Volví hoy a las especificaciones de arquitectura técnica para @BabylonLabs_io para ver cómo las salidas de un vault realmente se ejecutan en Bitcoin L1 sin covenants nativos.
Vale la pena entender la mecánica aquí. Bitcoin no tiene covenants nativos (OP_COVENANT) todavía. Entonces, ¿cómo un Vault de Bitcoin sin confianza impone timelocks y slashing sin una VM de contrato inteligente?
Depende de árboles de transacciones Taproot pre-firmadas construidas en el momento exacto en que bloqueas tu BTC.
Mi suposición inicial era que, una vez que expira el timelock o se activa una condición de slashing, la transacción simplemente aterriza de forma fluida en Bitcoin L1.
No automáticamente.
Como esas transacciones están pre-firmadas con antelación, sus comisiones de minero (sat/vB) se estructuran en función de los entornos de fees en el momento en que se crea el vault.
Si la mempool de Bitcoin L1 sufre un pico masivo de congestión durante una caída del mercado—pasando de 15 sat/vB a 250+ sat/vB—una transacción pre-firmada de desbando o slashing puede quedarse atascada en la mempool a menos que se invoquen mecanismos de aumento de comisiones como CPFP (Child-Pays-For-Parent) o RBF.
La criptografía detrás de las rutas de gasto EOTS y de los scripts de Taproot es completamente sin confianza y hermética.
Pero la ejecución en Bitcoin L1 siempre depende de la economía de fees de la mempool.
Si las comisiones de L1 se disparan durante un evento de liquidación del mercado, ¿importa la garantía criptográfica si la transacción queda encolada detrás de miles de ordinals y transferencias?
Esa es la sutileza entre la validez criptográfica y la prioridad en la mempool.
Al evaluar la arquitectura de $BABY vault, ¿qué consideras el mayor cuello de botella durante una alta congestión de L1? #baby $BABY
Vale la pena entender la mecánica aquí. Bitcoin no tiene covenants nativos (OP_COVENANT) todavía. Entonces, ¿cómo un Vault de Bitcoin sin confianza impone timelocks y slashing sin una VM de contrato inteligente?
Depende de árboles de transacciones Taproot pre-firmadas construidas en el momento exacto en que bloqueas tu BTC.
Mi suposición inicial era que, una vez que expira el timelock o se activa una condición de slashing, la transacción simplemente aterriza de forma fluida en Bitcoin L1.
No automáticamente.
Como esas transacciones están pre-firmadas con antelación, sus comisiones de minero (sat/vB) se estructuran en función de los entornos de fees en el momento en que se crea el vault.
Si la mempool de Bitcoin L1 sufre un pico masivo de congestión durante una caída del mercado—pasando de 15 sat/vB a 250+ sat/vB—una transacción pre-firmada de desbando o slashing puede quedarse atascada en la mempool a menos que se invoquen mecanismos de aumento de comisiones como CPFP (Child-Pays-For-Parent) o RBF.
La criptografía detrás de las rutas de gasto EOTS y de los scripts de Taproot es completamente sin confianza y hermética.
Pero la ejecución en Bitcoin L1 siempre depende de la economía de fees de la mempool.
Si las comisiones de L1 se disparan durante un evento de liquidación del mercado, ¿importa la garantía criptográfica si la transacción queda encolada detrás de miles de ordinals y transferencias?
Esa es la sutileza entre la validez criptográfica y la prioridad en la mempool.
Al evaluar la arquitectura de $BABY vault, ¿qué consideras el mayor cuello de botella durante una alta congestión de L1? #baby $BABY
