Donde la autocustodia de Babylon todavía depende de un Comité de Convenio
@BabylonLabs_io algo sobre la palabra "autocustodia" en Babylon no dejaba de darme vueltas.
Asumí que significaba que el que apuesta (staker) controla cada resultado, sin excepciones.
Luego leí los requisitos del script, y esa suposición no se cumplía.
La salida del staking de Babylon tiene tres rutas de script. El timelock le permite al staker salir solo cuando expira el bloqueo. El unbonding le permite al staker salir antes de tiempo. El slashing castiga a un proveedor de finalidad que firma doble.
Dos de esas tres rutas simplemente no pueden ejecutarse sin firmas del comité de convenio.
Esa era la parte que casi me salté.
El comité de convenio es un grupo M-de-N de claves de Bitcoin. Sus firmas se requieren antes de que incluso se active una solicitud de staking, y se requieren de nuevo antes de que se pueda completar una transacción de unbonding o de slashing. $BABY
El BTC en sí nunca sale del script del staker, así que el activo permanece donde el staker lo puso todo el tiempo.
Vale la pena ser preciso sobre qué permite realmente esa dependencia, sin embargo.
La especificación del script de staking es explícita en esta parte. El comité puede rechazar una solicitud. No puede redirigir fondos a ningún lugar al que el staker no se haya comprometido ya en el momento del staking; solo puede retener la firma que permite que el gasto continúe.
Así que el comité puede impedir que algo se active sin convertirse jamás en custodio. #baby
Pero eso todavía significa que la salida de un staker, ya sea temprana o punitiva, depende de firmas que no tiene en su poder personalmente. La autocustodia protege hacia dónde pueden terminar yendo los fondos. No borra a todas las partes cuya cooperación hace falta para llegar ahí.
¿Acotar a un comité a tener solo poder de rechazo lo convierte en un no-asunto para la autocustodia, o el hecho de necesitar la firma de alguien más ya complica lo que se suponía que significaba "autocustodia"?
¿La dependencia de Babylon está realmente acotada?
¿El poder de rechazo únicamente sigue contando como una dependencia de custodia? #baby
@BabylonLabs_io algo sobre la palabra "autocustodia" en Babylon no dejaba de darme vueltas.
Asumí que significaba que el que apuesta (staker) controla cada resultado, sin excepciones.
Luego leí los requisitos del script, y esa suposición no se cumplía.
La salida del staking de Babylon tiene tres rutas de script. El timelock le permite al staker salir solo cuando expira el bloqueo. El unbonding le permite al staker salir antes de tiempo. El slashing castiga a un proveedor de finalidad que firma doble.
Dos de esas tres rutas simplemente no pueden ejecutarse sin firmas del comité de convenio.
Esa era la parte que casi me salté.
El comité de convenio es un grupo M-de-N de claves de Bitcoin. Sus firmas se requieren antes de que incluso se active una solicitud de staking, y se requieren de nuevo antes de que se pueda completar una transacción de unbonding o de slashing. $BABY
El BTC en sí nunca sale del script del staker, así que el activo permanece donde el staker lo puso todo el tiempo.
Vale la pena ser preciso sobre qué permite realmente esa dependencia, sin embargo.
La especificación del script de staking es explícita en esta parte. El comité puede rechazar una solicitud. No puede redirigir fondos a ningún lugar al que el staker no se haya comprometido ya en el momento del staking; solo puede retener la firma que permite que el gasto continúe.
Así que el comité puede impedir que algo se active sin convertirse jamás en custodio. #baby
Pero eso todavía significa que la salida de un staker, ya sea temprana o punitiva, depende de firmas que no tiene en su poder personalmente. La autocustodia protege hacia dónde pueden terminar yendo los fondos. No borra a todas las partes cuya cooperación hace falta para llegar ahí.
¿Acotar a un comité a tener solo poder de rechazo lo convierte en un no-asunto para la autocustodia, o el hecho de necesitar la firma de alguien más ya complica lo que se suponía que significaba "autocustodia"?
¿La dependencia de Babylon está realmente acotada?
¿El poder de rechazo únicamente sigue contando como una dependencia de custodia? #baby
Yes, it counts
80%
No, custody is intact
20%
Depends on quorum
0%
Not sure
0%
5 Votos • Votación cerrada