When Things Go South: Stress-Testing a Bitcoin Vault at Noderunners
What happens to a Bitcoin vault when one of its keys is compromised?
And what if a key becomes unavailable instead?
At Noderunners Conference in Arnhem, we turned those questions into an interactive experiment thanks to our lead developer Riccardo.
During When Things Go South: The B-SSL Vault Challenge, BitVault Lead Developer Riccardo Biffi walked participants through a series of failure scenarios using the B-SSL simulator.
Instead of simply explaining how the security architecture works when everything behaves as expected, the workshop started from the opposite direction: something has gone wrong. What can happen next?

From architecture to failure scenarios
B-SSL uses multisig and timelocks to make time an explicit part of the security model.
That means the consequences of losing or compromising a key cannot always be understood by looking only at which keys are available at a particular instant.
When a spending path becomes available can matter just as much as which keys control it.
During the workshop, participants used the B-SSL web simulator to explore this directly.
Different keys could be marked as compromised or unavailable. The simulation could then be moved forward in time to see how the state of the vault changed.
The result was a much more useful question than simply asking whether a vault was “safe” or “broken”:
Who can move the bitcoin, through which path, and when?

A compromised key does not always mean immediate loss
One of the scenarios explored what happens if the key associated with the Convenience Service is compromised.
A conventional way of thinking about key compromise might suggest that the bitcoin should be considered lost as soon as an attacker gains enough signing capability.
Timelocks introduce another dimension.
Depending on the state of the vault and the available spending paths, the legitimate owner may still have a window in which to react and move the funds before the attacker can use the compromised path.
The simulator made that window visible.

Participants could advance the scenario through time and see how the possible outcomes changed.
The workshop also examined more severe combinations of failures, including scenarios where the service and another key were compromised.
The point was not that every compromise can be recovered from. It was to understand precisely how the security properties change as different assumptions fail.
Security is a state, not a binary label
This leads to one of the most important ideas behind the workshop.
A vault experiencing a failure can be in very different states.
It might be temporarily unavailable.
It might remain recoverable through another spending path.
Or the conditions might expose the funds to theft.
Those situations should not be treated as equivalent.
Timelocks make the distinction even more important because the state can change as time passes.
The workshop therefore turned Bitcoin security from a static architecture diagram into something participants could experiment with.
Change the compromised keys. Change which keys are unavailable. Move time forward. Observe what becomes possible.

Making the model explorable
The audience at Noderunners was highly technical, and the session generated an active discussion around the different failure cases and how B-SSL behaves under them.
One of the strongest points of interest was the simulator itself and the possibility of continuing to experiment with these scenarios independently after the workshop.

That is exactly the kind of discussion we wanted the B-SSL Vault Challenge to create.
Security models become easier to understand when you can deliberately break their assumptions and inspect what happens next.
Because in real self-custody, the important question is not only:
“Are my keys secure?”
It is also:
“If something goes wrong, what options do I still have — and how much time do I have to act?”
That is one of the problems BitVault is designed to explore through multisig, timelocks and explicit recovery paths.
Learn more about BitVault at bitvault.sv.

