search

revault / practical-revault

Version 0 specifications for a Revault deployment
Creative Commons Attribution 4.0 International
33 stars 9 forks source link

Transactions format #7

Closed darosior closed 4 years ago

darosior commented 4 years ago

This is a starter but is I think somewhat comprehensive.

Writing all this in Markdown is error-prone so there must be typos here!

JSwambo commented 4 years ago

Reviewed all transactions. To the best of my knowledge without actually testing the scripts it all seems correct.

Unvault tx:

FIXME: do we really need a multisig here ? Interaction consequences are cumbersome..

Who should be able to bump the fee through CPFP? If it's multi-sig, it is cumbersome to do a distributed signing round to bump the fee, but it means that there is agreement about the value being bumped and mitigates a malicious party attempting transaction pinning. One could alternatively not require the whole set of M parties, but a subset, if the interaction cost is too significant. Hard to say what the user experience would be like at this stage. Perhaps the user just sees "spend from the vault" and a sequence of Unvault Tx, fee-bump tx, and Spend Tx are all processed behind the scenes.

darosior commented 4 years ago

Who should be able to bump the fee through CPFP?

The authorized spenders. I think of the spending flow as:

The initiator (its wallet, no burden on them i presume) would generate its signature for the spend_tx and the fee-bump transaction for the unvault_tx (which spends the second output of the unvault_tx (multi-sig), and an output of their wallet (single sig)).

They would then hand this whole stack of PSBTs to the followers, they would each generate both signatures and hand it back to the initiator.

We could use a single sig but that's quite hacky: shared private key because the initiator can change, weird race conditions etc.. I think that not having to share a private key and handle all this sync mechanism in the wallet is worth the 71 * (M - 1) weight units and the longer PSBT strings.

I opened #6 after thinking about that :-).

mitigates a malicious party attempting transaction pinning

Pinning the unvault is OK, it's actually not a good idea for an attacker.

One could alternatively not require the whole set of M parties, but a subset, if the interaction cost is too significant. Hard to say what the user experience would be like at this stage.

Ouch gives me headaches :sweat_smile:

Perhaps the user just sees "spend from the vault" and a sequence of Unvault Tx, fee-bump tx, and Spend Tx are all processed behind the scenes.

That's precisely what I'm thinking about.