BitVault: "Your fortress against physical attacks"
I've been hearing about this BitVault thing for a while, but it seems like they stepped up their advertising lately because all of a sudden bigger accounts on X (like Efrat Fenigson and Simply Bitcoin and PlanB Lugano) started posting about it.
I was always a little confused by the product, especially since they were touting it as a vault that didn't need any new op-codes. I don't know much, but I know that vaults in Bitcoin are really hard to make. BitVault says stuff on their website about a Convenience Service and 2hr - 15 day timelocks enforced by CSV -- which I found very confusing.
So then I see in the Bitcoin Optech Newsletter this write-up about a delving post that was talking about a "Secure Bitcoin Signing Layer" that uses a Convenience Service and 2hr - 15 day timelocks enforced by CSV...
Well, goody, goody: we finally get some real details. They have a github and a whitepaper and hooray.
Not hooray
The github is pretty much empty. It's just got a readme and this pdf that kinda looks like it was vibed. No code. Maybe it's all in the whitepaper...
The B-SSL whitepaper
I will freely admit that the timelock stuff in Bitcoin often makes my head spin. As soon as we start talking about relative timelocks, things get really wacky. Nonetheless, I gave it shot at figuring out what BitVault was proposing here.
As best I can tell, they propose that you lock your coins in a taproot output that has a number of possible spending paths -- the backup spending paths cannot be used for 1 - 3 years, while the primary spending path has a much shorter 2 hr - 15 day configurable timelock.
Here is how they describe the primary spending path ("used for ordinary operations"):
Path 1 -- Configurable User Path (2 h - 15 d CSV) Keys: (A or A1) + C Delay: Configurable 2 hours - 15 days (relative CSV) Gatekeeper: CS (optional)Used for ordinary operations. When the user initiates a spend, CS can enforce the chosen delay and emit a secret notification to monitoring wallets or guardians. If the CS is unavailable, the user still retains full control through fallback paths.
Frankly, this doesn't make any sense. CSV timelocks begin their "countdown" the moment the coins are sent to the address with the timelock. So BitVault's construction starts the timelock as soon as you send your coins into a vault...but doesn't let you lock them longer than 15 days.
What's the point of a vault that only works for at most 15 days?
I was so confused by this, I reached out to a number of different Bitcoiners who are much more technical than me. The response I got from them leads me to believe I am not misunderstanding BitVault's proposal.
BitVault's proposed design really does have you lock your coins for between 2 hours and 15 days. So either you have to avoid sending your coins into the vault until you are ready to enact the delay (which, in my mind, negates the point of a vault) or you have to "cycle" your coins.
This concept of "cycling" is something that all of the major timelock wallets (Nunchuk, Keeper, Liana, Bitcoin Safe) have to deal with: because CSV has a consensus limit of 388 days, wallets that use CSV to create timelocks require users to send the coins in the wallet to a new address in the wallet to "reset" the timelock).
However, nothing in the BitVault proposal or on their website marketing copy says anything about cycling coins or the transactions needed to do this or the trade-offs (if fees are high when you need to reset your timelock, you may end up paying quite a lot and if you don't do it, the timelock will expire, exposing a the locked spending path).
What actually is a vault anyway?
Here's another point that I'm confused about: a vault is not simply a timelock:
-
A timelock is a restriction placed on coins or a transaction that prevents them from being sent for a certain length of time or number of blocks.
-
A vault is a wallet construction that requires two separate transactions to spend coins, giving the owner a time window to be alerted that coins are moving from the vault and a way to stop them from leaving.
What BitVault is proposing isn't a vault.
What BitVault has to say about their design
This was so confusing to me I even responded to their post on delving, which was written by someone named ilghan, who is the CEO of BitVault.
After a little back-and-forth where he did not answer my question, despite claiming to have posted the idea seeking review, he said:
I invite you to focus on the end goal which is how to avoid two custodians to collude and then to assess the system in its entirety, if you analyze it part by part by not looking at the bigger picture then it could be difficult to make sense of it. If you want to join the Bitcoin Optech audio recap discussion by next Tue, maybe it could help.
"This work is shared for peer review and discussion before implementation"
Now, maybe this is just a harebrained scheme the folks at BitVault cooked up and we shouldn't knock 'em for putting themselves out there. Unfortunately, it looks to me like they are already accepting money for the product.
Unfortunately, BitVault's social media presence lately makes it seem like they are offering the product for sale.
This is a product that, as far as a can tell, uses CSV timelocks in a nonsensical way...almost like they don't understand how such timelocks work. Their product just has users give a key to a third-party signer who promises not to sign for a certain amount of time.
It's one thing to propose an idea, it's quite another to take customer's money for said product.
On their website, they offer that typical three-tier pricing scheme you see everywhere:
The middle tier sounds to me like this B-SSL scheme they've proposed. The fine print says
Your early access funds help us finalize security audits and open the beta to the public
So perhaps that's how they justify it.
65535 / 6 (blocks per h) / 24 (h per day) = 455"targeted days worth of blocks" (though that of course doesn't mean that it will actually take 455 days for that block height to be reached.)talkingwriting about it