Jennifer Zynn

Comprobé si la billetera del tesoro podía realmente recuperar la participación en Babylon.

Pudo firmar los UTXOs que financian el depósito.

Luego ejecuté la verificación de propiedad contra el StakerPk comprometido dentro de la salida de staking.

“Clave no encontrada.”

Se suponía que la billetera del tesoro controlaba esa clave. El sistema de recuperación todavía no podía producirla cuando se le solicitaba.

Nada en el flujo del depósito revelaría eso.

La transacción de financiación firma. La participación confirma. La delegación se activa.

La ruptura solo aparece cuando el BTC necesita moverse de nuevo.

Tanto la ruta normal de retiro como el desenganche anticipado todavía dependen de la clave del staker. La aprobación de covenant no la reemplaza.

Así que el BTC nunca se comprobó como recuperable cuando entró en Babylon. Solo se comprobó que podía financiarse.

“Clave no encontrada” parece inofensivo hasta que se adjunta a la única clave que puede traer el BTC de vuelta.

#BABY $BABY @BabylonLabs_io
$HOME
$TUT

Mi simulación de recuperación pasó la verificación de clave y aun así no produjo votos de finalización.

Una firma de finalización de Babylon necesita más que la clave EOTS. Debe incluir la prueba de Merkle que muestra que su aleatoriedad pública fue comprometida para esa altura exacta. Esas pruebas, junto con la última altura votada del proveedor, viven dentro de finality-provider.db.

Restaurar el keyring en una máquina limpia no es una restauración que funcione. El daemon puede reconocer a mi proveedor, llegar a eotsd y reunir suficiente gas mientras cada envío de voto falla porque falta la prueba de aleatoriedad. El proveedor parece recuperado en el keyring y permanece en silencio en la siguiente altura de Babylon.

La reparación es específica. Tengo que detener fpd y ejecutar recover-rand-proof desde una altura de inicio seleccionada. Si omito esa altura, la herramienta reconstruye las pruebas desde el primer compromiso de aleatoriedad, convirtiendo todo el historial operativo del proveedor en trabajo de recuperación.

Probaría una copia de seguridad enviando un voto de finalización real, no comprobando si el proceso se inicia. Restaurar la identidad sin restaurar la evidencia de firmado es solo la mitad de una recuperación.

La máquina puede recordar quién es y, aun así, olvidar cómo probar su próximo voto.

#baby $BABY @BabylonLabs_io
$DOGE
$TAKE

Capturé el fallo cuando el firmante devolvió la pre-captura de Babylon como completamente firmada.

Babylon todavía mostraba la delegación como PENDIENTE.

Ese era el problema.

La selección de monedas había extraído un UTXO legado en una captación de múltiples entradas. Como esa entrada necesitaba su firma dentro de scriptSig, mi firmante completó la transacción antes de que Babylon terminara la verificación del pacto.

El hex de la transacción ya no era solo un paquete de registro. Un nodo de Bitcoin podía aceptarla y retransmitirla.

Descarté la transacción firmada, reconstruí la selección de monedas usando únicamente entradas SegWit, y comencé el flujo de registro de nuevo.

Ninguna firma inválida. Ninguna transacción de Bitcoin rechazada.

Solo BTC volviéndose minable mientras Babylon aún trataba la delegación como no finalizada.

#BABY $BABY @BabylonLabs_io

Tenía al BABY sentado en una aceptación de delegación mientras otra posición se deslizaba hacia la liquidación a $0.01188.

Pensé que “aceptada” significaba que había comenzado el período de espera. Así que conté hacia adelante desde el clic y planeé el movimiento del colateral en torno a eso.

Aún no había empezado.

La solicitud todavía tenía que pasar el epoch y llegar a un checkpoint de Bitcoin antes de que incluso comenzaran las 300 confirmaciones. Para cuando me di cuenta, el BABY seguía bloqueado y la posición tenía menos margen del que yo había planeado.

El detalle de la pantalla que importaba no era la solicitud aceptada. Era que el conteo de confirmaciones de Bitcoin todavía no había comenzado.

Necesitaba ese BABY como colateral antes de $0.01188.

En cambio, quedó atascado en una cola de salida mientras el riesgo de liquidación seguía acercándose.

#BABY $BABY @BabylonLabs_io

Encontré una apuesta de BTC que puedo confirmar en Bitcoin y aun así llegar inutilizable en Babylon.
La trampa es el momento de los parámetros. Babylon versiona las reglas de staking de BTC por btc_activation_height. En el flujo de pre-staking, tengo que construir contra el conjunto de parámetros que ve el propio cliente ligero de Bitcoin de Babylon cuando me registro, y no lo que parezca vigente cuando Bitcoin más tarde mine la transacción. Esa versión seleccionada fija las claves del covenant y el quórum, además de las condiciones de desenganche que Babylon verificará.
Si fallas esa búsqueda, la transacción puede hacer exactamente lo que firmé que hiciera. Bitcoin acepta la salida. El minero recibe el pago. Se acumulan las confirmaciones. Entonces Babylon no puede verificar el paquete de staking porque el script se construyó para el conjunto de reglas incorrecto.
Para un desarrollador de carteras, eso crea un éxito falso brutal. El BTC del usuario ya salió del saldo gastable y está dentro de una salida de staking con tiempo limitado, pero la posición no tiene poder de voto y no gana nada. Un reintento normal no puede reparar un script que ya quedó comprometido en Bitcoin.
Yo pondría la versión del parámetro y la altura de activación en la pantalla de firma, y luego bloquearía la difusión cuando la vista de mi cliente ligero de Babylon esté desactualizada. Ocultar esa búsqueda tras una confirmación verde es como una integración convierte Bitcoin válido en capital de staking varado.
#baby $BABY @BabylonLabs_io

Encontré que un proveedor de finalización de Babylon puede pasar su verificación de salud mientras que cada solicitud de firma que importa ya está muerta.
La zona ciega está entre fpd y eotsd. Babylon deja pasar Ping sin HMAC, así que un monitor puede seguir mostrando al administrador de EOTS como alcanzable. Pero SignEOTS, SignSchnorrSig y CreateRandomnessPairList requieren la clave compartida. Una discrepancia entre fpd.conf y eotsd.conf, incluso un espacio en blanco suelto, deja la llamada inofensiva en verde y las llamadas de producción rechazadas.
Eso significa que puedo tener dos demonios ejecutándose, un nodo Babylon Genesis sincronizado, conectividad RPC abierta y sin salida de finalización utilizable. El proveedor no falla de forma ruidosa al iniciarse. Falla cuando fpd le pide a eotsd la firma o la aleatoriedad necesaria para la altura siguiente.
No alertaría solo con Ping. Probaría una ruta de firma autenticada y haría seguimiento de la última solicitud EOTS exitosa. De lo contrario, el panel solo prueba que la puerta existe, no que la clave siga abriéndola.
Para un operador de Babylon, una conectividad en verde puede ocultar un proveedor que ya dejó de votar.
#baby $BABY @BabylonLabs_io

Puede enviar una delegación BABY, confirmar la transacción en tiempo real y no tener participación en la transacción.

Para delegar, desdelegar y redelegar los mensajes dentro de x/epoching, usa las colas de Babylon. El acuerdo se registra aquí, pero el poder del validador solo se actualizará cuando termine el epoch de 360 bloques, aproximadamente una hora después. Este muro de BABY I que presuntamente planté sigue siendo flexible, hasta ese límite.

Eso genera un problema horrible de billetera. Cuando muevo mis tokens después de ver “success”, la delegación en cola llegará al procesamiento del epoch sin el saldo que estaba esperando y fallará. No era una mentira lo que dijo la cadena. La interfaz creó la etapa incorrecta como si estuviera completada.

La utilidad del estado no se verifica. Está esperando el fin del epoch, en cuyo momento se bloqueará y empezará a generar rendimientos. Una billetera debería mostrar la cola, el tiempo de epoch que queda y el resultado final de la participación que se ejecutó correctamente, para que si firmo una participación válida y la cancelo por accidente con una transferencia posterior, pueda ver la participación en la cola.

Simplemente no puedo escapar de esa hora de tiempo que me falta. En Babylon, el éxito de la transacción y el éxito de la participación son dos eventos. Cualquier interfaz que los reduzca a una sola marca verde causará que el movimiento normal del token sea una delegación fallida.

#baby $BABY @BabylonLabs_io

$COTI actualización:

Esta subida parecería ser una subida a corto plazo. En mi opinión, eventualmente va a crear otro cierre a la baja, antes de que el mercado comience el próximo gran impulso alcista.

Mi zona de venta preferida sigue siendo $0.01900–$0.02170. Desde ahí, buscaré una ruptura hacia la zona de acumulación de $0.0050-$0.0055.

Cuando se alcance ese nivel, cerraré mis posiciones cortas y empezaré a abrir posiciones largas en lugar de esta recuperación alcista, que creo que será la gran subida.

Registra la bóveda. Verifica el bloqueo de Bitcoin. Haz seguimiento del estado del colateral. Construye la ruta de redención. Luego repite el mismo trabajo específico de Bitcoin antes de que el producto financiero en sí haya hecho algo útil.

Babylon ha eliminado ese cuello de botella.

Su testnet Trustless BTCVault ofrece a los desarrolladores una superficie de trabajo funcional para el colateral nativo en BTC, mientras que el contrato del gestor TBV maneja el registro de la bóveda, la verificación y la redención segura detrás de una única interfaz estándar.

Por fin, la lógica del producto puede permanecer al frente.

Un desarrollador puede definir qué debería suceder con el colateral y, luego, delegar la ejecución intensiva en Bitcoin a través del contrato del gestor. Una aplicación existente también puede conectarse mediante un proxy en lugar de tener que reconstruirse alrededor de un sistema de colateral completamente nuevo.

Eso es un desbloqueo práctico.

Lo difícil de un producto de préstamos o de colateral debería ser sus reglas de riesgo y el resultado para el usuario. No debería obligar a que cada equipo enseñe por separado cómo reconocer el mismo estado externo de Bitcoin.

Babylon ha creado una primera versión más pequeña. El flujo funcional inicial ahora puede centrarse en la acción financiera, no en un motor de redención de Bitcoin construido a mano.

@BabylonLabs_io $BABY #baby

Eso significa que los parámetros más nuevos de staking de Babylon pueden ser los incorrectos para verificar un stake.

Un verificador no puede obtener la configuración de hoy y aplicarla a cada transacción de staking de BTC creada alguna vez. Babylon versiona sus reglas de staking por la altura de activación de Bitcoin. El snapshot correcto depende de cuándo y cómo el stake entró al sistema.

Para el registro posterior al staking, el verificador usa los parámetros activos en el bloque de Bitcoin donde se incluyó la transacción. Para el staking previo, la transacción queda fijada a los parámetros que vio el cliente ligero de Bitcoin de Babylon cuando ocurrió el registro, incluso si Bitcoin la incluye después de una actualización posterior.

Esa diferencia protege un compromiso anterior para que no sea reescrito por reglas más nuevas.

También cambia la evidencia que un verificador necesita. Solo la transacción no es suficiente. la ruta de registro y la altura que seleccionó su versión de parámetros deben viajar con ella.

Ignora ese contexto y un stake histórico válido puede parecer malformado frente al conjunto de convenios, límites o reglas de temporización de hoy. Los bytes no han cambiado. El verificador ha abierto el libro de reglas equivocado.

La mayoría de las verificaciones de configuración preguntan si un objeto coincide con el sistema actual. Babylon pregunta si el stake coincidía con el sistema en el momento en que se fijaron sus condiciones.

Aquí, la verificación no consiste en hacer coincidir el estado más reciente. Se trata de reconstruir el conjunto exacto de reglas al que el BTC se comprometió.

@BabylonLabs_io $BABY #baby
$DGB
$DIA

Abre el producto.

Determina las personas que pueden mover el BTC.

Determina qué causó que la empresa fuera liquidada.

Determina si existe alguna posibilidad de utilizar la misma garantía.

Calcula si cada una de las posiciones se refiere a un Bitcoin conocido.

Repite para cada diseño.

Érase una vez que lo tomé como un costo general de mi investigación por hecho. Como se publica por Babylon Publishing bajo SCRIPT, es más difícil de defender.

La cuadrícula de riesgos, que Babylon usó internamente al diseñar las Trustless Bitcoin Vaults, se llama SCRIPT. El acrónimo unlock no es para el investigador. El acrónimo unlock no es para el investigador. Es que las preguntas caóticas tienen destinos específicos a los que viajan.

¿El propietario permanecerá bajo control hasta que ocurra un evento determinado?

¿Se puede rehypotecar el BTC, sin el permiso expreso del prestatario?

¿Una posición de una sola aplicación puede rastrearse hasta la posición original en la garantía de Bitcoin?

Pero esas comprobaciones revelan brechas que se ocultan con palabras como “nativo” y “sin custodia”.

La debida diligencia a nivel de protocolo permanece inafectada por SCRIPT.

Evita que cada revisión comience en una nueva página. También tiene el efecto de proporcionar una prueba pública basada en su propio diseño de la bóveda babilónica, que puede aplicarse a todas las cosas alrededor de la bóveda babilónica.

Esa es la tasa que me preocupa.

Un primer paso repetible con investigación sobre garantías en Bitcoin. Desde la decodificación de etiquetas hasta encontrar el punto exacto en el que se rompe el control, el aislamiento o la atribución.

@BabylonLabs_io $BABY #baby
$DIA

$EUL

🎁Gracias, @Binance Square Official 🎁

Ciertos paquetes son más que solo mercancía.
Para recordarles a las personas que se está viendo el trabajo.
Son como si se les estuviera apreciando.

Gracias por pensar en mí y gracias por el apoyo.

El trader que delegó BABY no puede considerar el clic de "desapostar" como si realmente estuvieran accediendo a ese inventario como trader en el mercado. Sin embargo, la otra suposición también es falsa. Esto no es un período de "enfriamiento" de 21 días que tienen muchas redes PoS.

Babylon primero coloca la desdelegación en la cola hasta el final del epoch actual. Este epoch está vinculado a Bitcoin y la liberación del token espera 300 confirmaciones de Bitcoin, lo cual es aproximadamente 50 horas con un ritmo normal. Dependiendo de las condiciones de la red, puede tardar más.

Así que, no estaría añadiendo otra categoría ni a "liquid balance" ni a "capital" de bloqueo largo. Funciona más como una acción basada en el calendario de Bitcoin.

Esa es la diferencia en la forma en que un trader hará planes para sí. El reloj es útil y comienza con el límite del epoch y solo terminará cuando el BABY vuelva a ser transferible. No seguir esta secuencia puede hacer que un trader quede posicionado para hacer una operación en un momento en el que los fondos aún no estén listos.

La apuesta se mantiene en Babylon Genesis, pero Bitcoin decide cuándo puede usarse la salida. Eso significa que el reloj de confirmación no está escondido en la letra pequeña, sino justo al lado del precio de entrada.

@BabylonLabs_io $BABY #baby

Abre el borrador. Escribe “staking de BTC autocustodiado”. Bórralo. Escríbelo de nuevo. Durante un tiempo, ese fue el bucle del creador alrededor de Babylon, porque el concepto hizo la mayor parte del trabajo y la consecuencia se mantuvo fuera de pantalla. La Fase 2 llevó la historia más allá de esa primera frase. Babylon Genesis salió en vivo; luego, el staking de BTC sin permisos se abrió a través del panel tanto para las posiciones de la Fase 1 como para nuevas apuestas. Ahora el BTC podía pasar de una posición de Bitcoin bloqueada a una seguridad en funcionamiento para Genesis, con recompensas base de staking adjuntas.
El trabajo del creador cambió con ello.
Ahora empezaría después del bloqueo. El punto de la autocustodia sigue siendo importante, pero ya no es todo el post. La secuencia más fuerte es visible: el BTC permanece en Bitcoin, la apuesta entra en un papel de seguridad y el resultado del titular cambia porque ese rol se está llevando a cabo. Eso le da al creador una consecuencia que mantener desde el inicio hasta el final, en lugar de otra explicación de cómo podría funcionar el staking.
El hito no solo abrió el acceso. Les dio a los creadores de Babylon una historia con movimiento, y el marco más fuerte ahora comienza donde solían detenerse las publicaciones antiguas.
@BabylonLabs_io $BABY #baby