pull down to refresh

there's a narrative that this or that covenant opcode facilitates storage via vaults. and we already need this for whale vaults like coinbase, mstr, future bitcoin strategic reserve at fort knox if they ever get that going.
I say YAGNI to covenants for scaling reasons. In other threads on hacker news (often dialog with u/justin_shocknet) we argued the YAGNI case for covenants in scaling.
I also leaned YAGNI for covenants in vaults, but I hadn't really fleshed that out. I think reacting to coldcard's work here might be a good place to begin to do so.
I also think I saw in twitter (or somewhere) that coldcard themselves lean the other way (they like vault covenants) so I'd like to hear the other side from them if so.
Anyway here, coldcard here is pitching what can be achieved for security just using dedicated hardware and mainnet bitcoin.
most importanatly
"velocity and magnitude limits whitelisted destination addresses"
enforced at the hardware level of the signing device, iiuc.
covenants get us clawback for a limited time basically, enforced at the protocol level, iiuc.
So the debate is, do we really need clawback for a limited time, if we are already enforcing velocity and magnitude in the hardware, via a multisig setup?
Expiring clawbacks give you a security policy that doesn't rely on rate limits. IE, you can send the whole amount safely, is the idea. However, the receiver doesn't have the safety that you really sent it until the clawback expires. You could partially replicate the expiring clawback by rate limiting real withdrawals to coincide with the same time period. In both cases, in the case of a successful attack, the attacker can spend funds at the end of the time period. With the expiring clawback, the attacker either gets all the funds or none of the funds at the end of the expire period.
With the rate limit, the attacker gets funds up to the point that the attack is noticed and blocked. With the clawback, all funds can be rescued, but the "all or nothing" nature of it might lead to less vigillance, resulting in missing the clawback period. EG, the attacker also compromised the machine watchtowers or human sentries that are suppose to notice an attack happening. With rate limits, maybe there would be more vigilance to stop an attack in progress before all funds are drained.
The rate limits are also better for (legitimate) receivers, because they can plan on over what time period funds will be received, rather than having to wait a clawback time before any can be spent.
It's a bit tomato/tomahto for me.
Thoughts?
I'm not the right person to ask really. I tend to not think about soft forks and op codes much (I find the social dynamics around them more interesting than the technicals). I also don't spend much time thinking about improving the store of value properties of bitcoin because it seems like that's what most bitcoiners think about.
In general though, your thinking is good imo. Multisig setups like this make it clear what vaults would give that we can't achieve by other means.
reply