Covenant tools softfork

[ajtowns]

@harding

The presigned versions are a lot harder to implement correctly than with OP_CTV + OP_VAULT, they can’t receive payments without interaction with the payer, […] However, it seems to me that if there were high demand for the general ability to have hot spends announced onchain with a cancellation window, a significant number of people would be using presigned vaults—but I’m not aware of that happening.

Ease of (correct) use is a big deal though – otherwise you could say “Linux is a lot harder to use than Windows NT, however if there were high demand for an OS that didn’t [suck], a significant number of people would be using Linux–but everyone’s running Windows NT” and conclude Linux is worthless.

@harding

why is it that so few developers are working on the 2x-5x improvement that presigned vaults provides and few users seem excited about presigned vaults?

I don’t think pre-signed vaults really get the right security properties? As described in 2019:

One of the biggest problems with the vault scheme […] is an attacker that silently steals the hot wallet private key and waits for the vault’s owner to make a delayed-spend transaction to initiate a withdrawal from the vault. If the user was unaware of the theft of the key, then the attacker could steal the funds after the delay period.

I think you could simulate everything about OP_VAULT if you have access to an HSM that you trust – then you just have a “vault key” that only the HSM has the privkey for, and have the HSM enforce the rules that OP_VAULT would when signing for that key. However if you have an HSM that you trust already, I think you don’t really have a need for the “withdraw everything to an offline wallet in the case of attempted theft” behaviour that OP_VAULT is all about providing.

I think the answer to the same question but for CTV/OP_VAULT vaults (vs presigned ones) is that many people estimate the chance of a successful consensus change to Bitcoin – especially one advocated for by Bitcoin businesses – at something like 0.01%, so a 5x improvement reduces down to something like 1.0004x when you calculate the expected value. And of course, new consensus features are immediately part of the commons, so you’re not getting an obvious competitive advantage by having them available.

Personally, I’d say: improve the demo, make it easier to try yourself, and to understand what’s going on (eg, run an optech workshop about it) – if there’s interest in that (people go to the workshop, people are interested in podcasts/videos about the demo, people run the demo themselves), then that starts becoming a good reason to think about activation/etc. IMHO, etc.

@harding

It also seems to me personally that John Law’s tunable penalties protocol provides the primary advantage of LN-Symmetry (proper assignment of penalties when >2 parties are involved) without requiring any consensus change.

I think n-party channels are a bit futuristic, really – we still have enough problems getting 2-party channels to work, and there’s currently enough room on-chain for spam floods so the efficiency gains aren’t yet necessary. For me, for now, the main benefits of eltoo/ln-symmetry/tunable penalties is rather that:

1. if your node has a problem, you’re no longer necessarily risking 100% of your channel balance if you try to close the channel; and
2. you only need to keep a constant amount of state in order to close the channel and claim all your funds, rather than having to remember an ever increasing amount of data potentially forever.

Without APO (or equivalent), though, you don’t quite achieve the first of those in a sufficiently hostile scenario even with Law’s tunable penalties (ref).