Add a `1 CSV` to the vault script

[darosior]

Hack hack hack, but in practice it can be valuable. It allows at least a race to happen if the N stakeholders are compromised.

[JSwambo]

If I'm not mistaken, the intention is to enforce that a transaction spending the vault utxo signals for RBF. That way if a theft transaction is signed with n-of-n compromised stakeholder keys, the emergency transaction can replace the theft transaction through RBF. The emergency transaction must also signal for RBF. Thus we have a race with the attacker.

Why does putting 1 CSV in the vault script enforce RBF for the spending transaction?

[darosior]

If I'm not mistaken, the intention is to enforce that a transaction spending the vault utxo signals for RBF.

Right.

That way if a theft transaction is signed with n-of-n compromised stakeholder keys, the emergency transaction can replace the theft transaction through RBF.

Yeah, as pointed out during our discussion yesterday i think that the value here is in the actual race: it could happen thus all funds could be burnt in fees instead of going to the theft.

The emergency transaction must also signal for RBF. Thus we have a race with the attacker.

Yep, we presign it with a sequence at 0xff_ff_ff_fd.

Why does putting 1 CSV in the vault script enforce RBF for the spending transaction?

The CSV op code restricts the sequence of the spending transaction input, such as nSequenceInTheInput >= nSequenceInScript, but not only ! It also forces the input's nSequence to unset its most significant bit. Hence, it forces RBF (any 32 bits number with the most significant bit unset is < 0xff_ff_ff_fd).

[darosior]

Some relevant bitcoind lines, fwiw:

1) The codepath when a CSV op is encountered: https://github.com/bitcoin/bitcoin/blob/1769828684f16b53e5fbf65173f508b9ea1b4b9c/src/script/interpreter.cpp#L519-L551

2) The nSequence check: https://github.com/bitcoin/bitcoin/blob/1769828684f16b53e5fbf65173f508b9ea1b4b9c/src/script/interpreter.cpp#L1456-L1501

[JSwambo]

Nice hack! what are the trade-offs here besides increased script size?

The protocol is supposed to resist up to N-1 compromised stakeholders before a theft is possible. This adds a deterrent for the case of N compromised stakeholders which allows the funds to be burnt.

I suppose there are some potential difficulties related to the n-of-n revault-bypass feature. For example, if (in-house) watchtowers are given the ability to burn funds when broadcasting the emergency tx, that's a serious risk. What entities should be enabled with this functionality, and in what circumstances?

[darosior]

what are the trade-offs here besides increased script size?

Cannot spot any yet, but i need some time for the idea to mature in my mind.

For example, if (in-house) watchtowers are given the ability to burn funds when broadcasting the emergency tx, that's a serious risk.

That's actually part of the design. In-house WTs need to be able to broadcast an emergency (dead man button deterrent).

What entities should be enabled with this functionality, and in what circumstances?

Haha welcome to The Revault ThinkTank. Adding @kloaec here as well, since we had this discussion multiple times but the answer is still "I don't know".

[kloaec]

ACK this. While Revault offers N-1 corruption, it doesn't mean our efforts should stop there. The In-Person/Physical attack deterrent is definitely a major benefit of Revault and this 1 CSV helps.

Regarding the risk of WT burning funds, DOSing the company, etc: yes, major risk of the Revault architecture. It also seems, to be effective, the HOT WALLET of EACH watchtower must be equal or superior to ALL UTXOs, which is absolutely impossible/impractical ( fee is > funds being moved). The "snow ball" policy of emergencies (1 pushed = all pushed) makes this extremely hard to defend against in practice.

[darosior]

It also seems, to be effective, the HOT WALLET of EACH watchtower must be equal or superior to ALL UTXOs

I'd say instead that the hot wallet of each watchtower must satisfy:

total_balance >= n * ( max(cancel_tx_size, emer_tx_size) + fee-bumping_tx_size) * current_top_feerate

With n the number of deposit utxos and current_top_feerate being dynamic. That's less than what you postulate but still a huge stab into practicality, though.

It's however tracked in https://github.com/re-vault/practical-revault/issues/28.

[darosior]

Ok so i think it's dumb actually. If i were the attacker i'd just pay an insane fee, no WT could do anything. And that's out of scope of our security model, so it starts getting hard to justify.