I assumed a Babylon Trustless Bitcoin Vaults (TBV) still had 1 key behind all its Taproot scripts.
Maybe the depositor held it. Maybe the Vault Provider did. Or maybe several participants could use it together if they all agreed.
then I checked the Taproot internal key.
It is a NUMS public key with no known matching private key. That makes the key path unusable.
A Taproot output normally gives BTC two ways to move. One way follows a committed script and must satisfy its conditions. The other uses the private key matching the internal key. That lets the spender avoid revealing those scripts.
TBV gives up that second route on purpose.
No participant can step around the transaction graph with a key-path spend. The BTC can only leave through paths prepared before the vault output was created.
At first, I read this as a simple anti-backdoor choice. I thought it only removed a hidden escape hatch.
Then I noticed what that choice takes away.
The depositor, Vault Provider and other participants may later agree on a new destination. Their agreement still can't create a new transaction path.
If the path wasn't prepared before the BTC moved, it isn't available now.
The internal key blocks one kind of bypass. It doesn't prove the transaction graph was designed well. It can't add a rescue path later either.
No one can improvise a malicious spend through the key path. No one can improvise a helpful one there either.
That changed how i think about custody in TBV.
The protocol isn't choosing the safest person to hold final authority. It is making that authority unusable through the key path.
The real decision happens earlier. The allowed spending paths must be chosen before the BTC enters the vault.
The question isn't only who controls the Bitcoin. It is also what the vault was built to allow before the Bitcoin moved.
Does making the key path unusable make the vault safer, since no one can bypass its prepared paths? Or does it make the vault more rigid, since no one can add a new path after the BTC moves?
No final key, or no second chance?
@BabylonLabs_io $BANK $BABY #baby ✨
Maybe the depositor held it. Maybe the Vault Provider did. Or maybe several participants could use it together if they all agreed.
then I checked the Taproot internal key.
It is a NUMS public key with no known matching private key. That makes the key path unusable.
A Taproot output normally gives BTC two ways to move. One way follows a committed script and must satisfy its conditions. The other uses the private key matching the internal key. That lets the spender avoid revealing those scripts.
TBV gives up that second route on purpose.
No participant can step around the transaction graph with a key-path spend. The BTC can only leave through paths prepared before the vault output was created.
At first, I read this as a simple anti-backdoor choice. I thought it only removed a hidden escape hatch.
Then I noticed what that choice takes away.
The depositor, Vault Provider and other participants may later agree on a new destination. Their agreement still can't create a new transaction path.
If the path wasn't prepared before the BTC moved, it isn't available now.
The internal key blocks one kind of bypass. It doesn't prove the transaction graph was designed well. It can't add a rescue path later either.
No one can improvise a malicious spend through the key path. No one can improvise a helpful one there either.
That changed how i think about custody in TBV.
The protocol isn't choosing the safest person to hold final authority. It is making that authority unusable through the key path.
The real decision happens earlier. The allowed spending paths must be chosen before the BTC enters the vault.
The question isn't only who controls the Bitcoin. It is also what the vault was built to allow before the Bitcoin moved.
Does making the key path unusable make the vault safer, since no one can bypass its prepared paths? Or does it make the vault more rigid, since no one can add a new path after the BTC moves?
No final key, or no second chance?
@BabylonLabs_io $BANK $BABY #baby ✨