Nothing like a major vulnerability to get people trying new things:
Like many, I’ve barely slept since the Coldcard incident. My mind has been racing on how to stop something like this from ever happening again. I believe I’ve come up with a novel wallet design that solves for all three points of the self-custody trilemma.
Although, I'm not sure a state of sleep deprivation is the ideal for developing vault-like constructions. As far as vaults go, it either needs a soft fork, relies on presigned transactions, or isn't a vault.
(This isn't quite true: there was ReVault, but it's mostly true.)
Under the hood, yes: the annual ceremony splits the vault into chunks and pre-signs a carefully structured set of transactions. But none of that ever needs to reach the user. This is purely an engineering problem, and a very solvable one. The same way nobody needs to understand how to perform Diffie–Hellman key exchange to use HTTPS, no one needs to understand how to manage a presigned transaction chain to approve a vault policy with Anzen.
And with so many time lock constructions, you have to roll your coins or presign new transactions.
Also he seems to have built a prototype which you can check out:
Once a year, ideally on the same calendar date, you re-approve the vault policy on your hardware wallet. This automates a signing ceremony between your phone and hardware wallet that rolls the vault forward (resetting the timeouts) and pre-authorizes an entire year of spending.
I don't know if this is a good idea. My gut says presigned transactions are not the way, but it's come up a few times this past week #1538230 so I thought I'd share it.
I have a working prototype running on mainnet with real funds, with all vault functionality and recovery paths fully implemented. It’s definitely not production ready, it’s very early, but it is (just about) usable if you want to test with small amounts of money.
There is also an extensive end-to-end test suite that runs on regtest if you want to see the full functionality without risking funds, and an interactive CLI that fully emulates a phone, a hardware wallet, and all operations between them.
Here’s my mainnet vault, you’re warmly invited to try and rug it:
bc1pvaultn3953ns47dw6rpm6ahfpz449vcnns5rpnr5v2d0u55fekxq39v257
The details in the design doc are interesting to read.
I am not super technical so don't fully understand, but it seems like this kind of approach makes UTXOs less static and more active on-chain. The UTXOs need to be rebroadcast on an annual basis etc.
What would happen if because of something like Anzen we saw UTXOs being created and spent much more frequently on-chain? What is the impact on miners / fee market etc? Plenty has been said about the "unfair advantage" old UTXOs have to be secured by the network without paying any ongoing fees.
I am not sold on the "hot wallet" analogy that the author talks about, maybe I am misunderstanding but I think the use case for most of us is deep cold storage, so monthly spend allowances and involving phones etc are not so necessary or wanted?
But this article has got me thinking more about taproot, I wonder if there is more possibilities?
@Scoresby what is it about the presigned transactions that gives you bad vibes? I am keen to understand specifically.
Presigned transactions seem bad to me because it might be quite easy to screw up. The wallet from which you are spending needs to be very careful not to move any utxos that are part of the presigned transactions. Probably the easiest way to do this is to delete the keys and only keep the presigned transactions, but that is scary as hell and not something I'd ever do. But if you are keeping the keys around, well, you have all the same threats that a normal cold storage wallet has and I don't see why you'd bother with presigned transactions.
Also, you create the presigned transactions at a certain time when the world looks a certain way, but so much can change. Imagine if fee rates are dramatically different -- now you have the added complexity of fee-bumping the transaction. Or imagine that Bitcoin forks in some way. The presigned transaction is not nimble.
Of course, this protocol proposes an annual "re-authorization" of the transactions, which limits some of these risks. Still: I'd rather just use my keys.
Thanks. Seperate to this project, in the context of my post about using Presigned TXNs I guess I see them as another tool in the cold storage toolbox that is not as powerful as the pure seed but gives something, anything - in the case that the seed / signing device are lost.
The seed is ownership: always a bearer instrument, whereas a presigned txns are never ownership, just a trigger for sending to a predetermined location.
Regarding fee rates I could imagine a script for wallets etc to generate 1, 10, 100sats/vbyte transactions and prepare them for signing, while also notifying the user if the conditions have changed (UTXOs have moved etc, unlikely in a cold storage scenario).
Thanks for the input though, good to see how others view it.
It doesn't seem like a terrible idea to me. It's a bit vague on the details - although much of that might be implied to someone that knows more about vaults.
Worst case is losing both devices. Can I still spend in the second worst case where I lose one device and all presigned transactions? Like, is losing the presigned transactions at any point catastrophic or just inconvenient?
I don't fully understand the proposal, but there is some good info in the design doc. Seems like most of it is done in the proposed wallet app, with taproot providing the signing permission structure on-chain.