Right now we exchange the huge Spend PSBT to the Cosigning Server. Since it's not checking managers signatures anymore we have no reason to do so.

I reached the Noise message limit on regtest with 12 stakeholders 4 managers, a dozen of vaults and about 5 outputs. That's unreasonable to have this hard limit.

In https://github.com/re-vault/practical-revault/blob/master/messages.md#synchronisation-server ,

{
    "method": "sig",
    "params": {
        "pubkey": "Secp256k1 public key used to sign the transaction (hex)",
        "encrypted_signature": {
          "pubkey": "Curve25519 public key used to encrypt the signature",
          "signature": "base64-encoded encrypted Bitcoin ECDSA signature"
        },
        "id": "transaction txid"
    }
}

Should be

{
    "method": "sig",
    "params": {
        "pubkey": "Secp256k1 public key used to sign the transaction (hex)",
        "encrypted_signatures": {
          "Curve25519 public key used to encrypt the signature": "base64-encoded encrypted Bitcoin ECDSA signature"
        },
        "id": "transaction txid"
    }
}

If i'm not overlooking something

• What if a feebump input is more valuable than the bumped utxo
• What if dust: the necessary amount needed to bump this spend exceeds the unvault txo amount Chose 200k sat as dust limit for now for transactions pre-signed by the stakeholders.
• How should received dust be handled in the UI

As discussed with Jacob, it seems better in practice.

Nice brainfart (on my end, as usual): we shouldn't be using txids as unique identifiers!!

Problem:

• we want each watchtowers to have access to the spending transaction in order to give an ACK to the manager before broadcast

suggested solution:
Each stakeholder has a sync-server like a mail box, messages are send by each participants to each sync-server. The central sync-server no longer exists. The personal sync-server can have a "cosigning" feature in order to be a cosigning server.

example: sign round
each stakeholder sign the cancel tx and share it to other stakeholder through their sync-servers

example: manager ask for spending:

Hopefully we do not have to implement a big change to the interface, calls are the same only duplicated.

future:
I believe that with system we can integrate a lot more services as sync-server plugins for the stakeholder.
For example, if the manager want to have an other watchtower, this time hosted by revault corp: he only have to give special credentials and address of the sync-server.

the personal sync-server is still not trusted, each communication keys are handled by revaultd and watchtowers received emergency transactions/cancel transactions from revaultd

I can already imagine the really poor UX of having user to refill their utxo pools in order to be able to operate.

Can we come up with a mechanism to automatically refill as we use the architecture ?

An obvious one would be eg (did not think much about it) appending a [pre-defined value]sats output for each participant to the unvault transaction. It drains a small part of funds out of it, and the created outputs being unencumbered by a timelock they could directly be used to revault the attempt. This means we can account for them as well so this could avoid the dread of "please refill your WT's utxo pool" as long as feerate does not go crazy.

The only alternatives i can see to automated fee utxo pool refill are "batching ceremonies" and "refill ceremonies", which, well, we certainly want to prevent as much as possible.

ref https://github.com/re-vault/practical-revault/issues/16

PLZ IMPLEMENT SIRS

I need to keep track of things, or i forget. So i abuse Github's disk space.

darosior
23:26

Don't remember why we kept the cosigning servers for the stk-mans. Vaguely remember it was for simplicity but can't remember exactly why
darosior
23:35

Hmmm that really make no sense
kloaec
23:42

stk-mans means?
darosior
23:44

stakeholder-managers
kloaec
23:55

ah, because if you don't it means you assume all managers need to sign all the time

and that's not always the case (could be a 1-of-2 or something)
darosior
23:58

Thanks! We should have notes so we don't forget these rationales..

So it was for simplicity. In the future we could remove them when the threshold for the managers multisig is equal to the number of managers.

Which message encoding should we go with ?

This has been mentioned over and over by @kloaec. We should make a list of cases for which we want to achieve non-repudiation (eg emergency broadcast) and whether we already do (spoiler alert: we don't for the former example) and/or are able at all.

We still have not settled on this..

It'll greatly help debugging and we don't greed on bandwidth..

For example if the watchtowers are only enforcing the "you can only unvault once per day, otherwise anything it's fine" policy then the setup does not need cosigners.

This is possible with the today protocol --at least i believe it is-- to only sign part of the pre-signed transactions set.
We can use that for a "cold wallet" capability: don't sign the whole second-stage (no unvault, cancel and unvault emergency), just keep the funding multisig with the emergency transaction deterrent.

WORK IN PROGRESS.
Edit number 2

This document discusses the needs in term of signing devices to have reasonable security. Its audience is people interested to develop or modify hardware wallets compatible with Revault.
It covers risk mitigation for very advanced attacks, compromising all participants computers. These attacks are very unlikely in the first place but shouldn't be considered impossible given the incentive.

Revault is engineered to withstand advanced and well funded attacks. Some Revault wallets will secure hundreds of million USD worth of bitcoin. One core assumption is that Revault users will have the client (Revaultd and GUI) running on their work laptop, and it is assumed to be easily compromised.
This means all transactions, especially the critical Cancel and Emergency transactions, are potentially poisoned at time of generation (for example output with an external pubkey added to the multisig for example).
The signing isn't happening on this laptop, but on a separate signing device to protect the private keys better.

While a signing device could technically be any machine capable of signing bitcoin signatures (currently: ECDSA), key management is still important. We recommend (and assume going forward) our users to store their private keys on security modules such as Hardware Wallets with secure elements. This improves the physical attack resilience significantly. (again: Revault doesn't limit itself to online/remote threats).

--

Output Script Parsing

In 2020, hardware wallets typically display the amount and the destination address to be checked by the user. This is not sufficient to prevent an attack as the user cannot know what this address corresponds to, it is only a hash after all.
We need a few improvements to make Revault more secure.

• the hardware wallet should display the output script(s), not an address (whenever possible). This can be done in multiple ways:
• Raw Script
• Miniscript Policy (better)
• A more verbose and user friendly parsing (best)

We don't expect anyone to be able to understand what Script does, so this option isn't acceptable.
The minimal viable implementation would be a Miniscript Policy display, and this is still hard to check even for technical users.
The better implementation would display the transactions in a user friendly manner such as:

Transaction type: Unvault Tx
Spending path: Timelock of 10 blocks, and signatures of (here goes PubKey1) AND (here goes PubKey2).
Cancel path: All of (PubkeyA, PubkeyB, PubkeyC, PubkeyD).

This is quite easy to attack, as users may not have access to all the Stakeholders public keys to double check. I.E, the format can be respected but not the actual participants...

The solution is to be able to identify all the participants' PubKeys directly on the HW. The display would look as follow:

Transaction type: Unvault Tx
Spending path: Timelock of 10 blocks, and signatures of Alice AND Bob.
Cancel path: All Stakeholders.

Any transaction trying to add different participants or omit them would generate an error, not respecting the normal Unvault output. To support this, each hardware wallet needs to be able to store and derive the public keys of every participant.

While such a logic could be made on the MCU (general purpose chip, low security) of the hardware wallets, it would be preferable to have it in the tamper-proof Secure Element.
We understand the Secure Elements are very limited in performance and memory and this will not be an easy feat.

--

Inputs

With the Private Key extraction and Output attacks now covered, we need to discuss another risk specifically annoying in a pre-signed transaction architecture: poisoned Inputs.
In Bitcoin, inputs refer to previous transactions' "unspent outputs". A pre-signed transaction (not broadcast yet) is only valid as long as its inputs stay unspent. Revault mitigates the risk of two Spend transactions to spend from the same outputs with the addition of the Cosigning Servers.
The security pre-signed transactions (Cancel and Emergency tx) are still at risk because the Hardware Wallets do not have the "state" of Bitcoin, they are not full nodes. The Inputs provided in the PSBT might be inexistant, wrong or already spent.
As Revault does not use Secure Key Deletion, the funds are not at risk of permanent loss. The risk is a malware sending the correct Inputs for the Unvault, but not for the Cancel or Emergency transaction. A malicious transaction wouldn't be "revault-able" in this case.
Against theft, we do not need to know if the Inputs are valid UTXOs. We only need to make sure the signing device checks that the Unvault transaction uses inputs already pre-signed with Cancel and Emergency transactions. If the inputs are invalid, the Unvault is also invalid therefore no Spend can happen.
The issue remaining would be that the Emergency spending from the Vault directly may be invalid, creating a false sense of security in case an Emergency is broadcast (the funds would stay in the Vault instead of moving to the Emergency Vault).

The alternative would be to have a full node on, or trusted by, the hardware wallet. Again: we do not want to consider the day-to-day laptop to be trusted.

Conclusion:

• The signing device needs to keep track of the inputs of Cancel and Emergency transaction to make sure no Unvault is signed without its corresponding security transactions.
• An even better implementation would require the HW to be a full node or an external trusted state such as a the PSBTs to be signed by the watchtowers or something equivalent.

--

Revault uses quite a few features of Bitcoin that may or may not be supported by existing hardware wallets.
To be "Revault compatible", HW needs to support:

• sighash flags
• OP_CSV time locks
• conditional outputs
• PSBT
• large transactions. A "Revault-compatible" hardware wallet should specify what maximum size of PSBT it can process.

As previously stated, Miniscript Policy and Output Descriptors parsing is also considered a must.

--

To Be Continued...
( transaction types, "bypass")

When we are really designing the txid of the transaction, use that. Opt for id when designing the outpoint that can be seen as a "vault id"

I'll remove the FIXME in messages.md to move it here for a broader reflexion about this case. There are input from @JSwambo in https://github.com/re-vault/practical-revault/pull/1.

Long story short: the number of different vaults a watchtower can track is limited by its available funds, otherwise it could not be able to handle the worst case scenario (revault all unvault transactions of all vaults).

Note that it is also inherently limited by feerate increase (as we can't bet on future feerate)... Is it the fractional reserve of tomorrow ?

We can either:

• Accept it, and wait for full noise channels across the sync server in Revault 2.0
  • Therefore the txid obfuscation is meaningless and should be removed
• Fixed it
  • But is the known leak the only one ?

Also:

• Move the pdf there as well
• This is where we'd eventually add additional attack trees

We don't currently support having eg an optional fund manager.
We should, however we shall not reuse keys across the policy.

We currently have

and(
  thresh(len(managers), managers),
  or(
    1@thresh(len(non_managers), non_managers),
    10@and(thresh(len(cosigners), cosigners), older(X))
  )
)

@JSwambo proposes that we use different keys for the timelocked path so that we can support that without reusing keys. Something like:

or(
  1@and(thresh(len(managers), managers),  thresh(len(non_managers), non_managers)),
  10@and(thresh(len(managers_second_keys), managers_second_keys), thresh(len(cosigners), cosigners), older(X)))
)

What would be the implications of supporting that ?

All 3 servers (cosigner, wt, sync) are ran behind an onion service.

We could assume the tor encryption and the auth as in "knowing the actual onion". If we don't want that then we need noiseKX or even noiseKK communication channels between each authorized-to-connect-here entity and the server.

Do we need it ?
What would be the consequences on the ceremony / setup ?

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

Would be nice if the revaultd of a stakholder retrieves spend transaction from coordinator when it watch vaults unvaulting.
The stakeholder would have then more information of spending attempts.
Same for a manager who did not received the spend transaction during the sign round and has the notification that vaults are unvaulting.

After #43, i think it'd create a virtuous circle and avoid too much pollution of the utxo set.

The sync server could be configured with WTs policy, and could return a hint when the managers are pushing a transaction. It would of course be untrusted, but it's just a hint and could increase UX in an "everything is fine" scenario while not decreasing security in a rogue scenario (if it's just a boolean that is returned).

A bunch of stuff that "seems cool" but is not considered to be part of the actual implementation for now, or may still even be half-baked.

I spec'ed that the spend_opinion requires a signature from the watchtower.... But did not specify the actual public key used by the recipient to verify it !

That's YA key exchange that needs to be done.

If the Coordinator does not have it they must return something, and starting using JSONRPC errors for this seems overkill.

Just realised that we could just not share the Emergency address -which we currently consider "internally public"- at all with the managers. This would allow to simplify the protocol further by removing the workarounded encryption of the emergency signatures, as we exchange raw signatures (in order to use them an attacker -best fit would be a manager- would need to know the Emergency transaction structure). I think it is an equivalent protection in our case as:

• As soon as the emergency address is publicly known, the wallet is decomissioned (you cannot perform a DOS if a DOS is already being performed :p)
• The encryption keys are hot and, aside of the usual brittle OS ACL used for the key file, the Emergency Address could be treated almost as privately

Am i ovelooking something ? @JSwambo

We could reuse the unvault's ones but this requires the HSM to sign the transaction... Maybe that's too much overhead for a low-value fee wallet ?

TL;DR: we currently assume authorized spenders (or more precisely, their wallet) are not going to submit a wrong tx to the cosigning servers, are we ok with that?

The cosigning server, as currently specified in messages.md will refuse to sign an input spending a specific unvault transaction twice.

However, if the watchtowers refuse the spending attempt the "authorized spenders" are stuck with the already-signed spend transaction for the entire life of this vault.

This is not that bad, since the spend transaction is (hopefully!) valid and can be used anyway. However this restrains usability in case of mistake on their end.

Not as much as the unvault transaction, but still signed in advance, the spend transaction is making hard to estimate a viable feerate.

We need to attach a new CPFP output to the spend tx, as we do with the unvault transaction.

H/T Magnus

https://github.com/re-vault/practical-revault/blob/master/messages.md#sign

Not sure it's going to be needed actually.

Because of @kloaec i'm once again re-considering the flow, should we really block on a NACK by the watchtower at the second step (fully signed spend tx) ? In this case what we are going to do with it ? Try in half an hour ? Sure. Would it be the most likely scenario ? In other ones should it better be revaulted ?

To be detailed.

Either we force them to run bitcoind in the background all day long, or we (ab)use the mandatory (and trusted) watchtower to query fee estimation data.

It makes sense as it's how we are using them in the daemon right now, and this way you can't be in a state where part of the revocation signatures were ACKed but not all

Not crucial security-wise as it's not a revocation tx (to which we attach fee-bumping inputs so it's fine), but if the rolling feerate of nodes' mempools get above that (as it is at the time i'm writing this) then the unvault transaction won't be relayed (feefilter protocol message).

TL;DR: unvault tx fees should not be static (or at least not that low but it does not count as a solution)

WORK-IN-PROGRESS - DO NOT USE (yet)

THERE IS NOT SUCH THING AS PERFECT SECURITY.
thIs iS NoT SEcuRitY ADviCe

Table of content:

1. Rationale
2. Revault
   2.1. Vocabulary
   2.2. The Revault deployment
   2.3. Secrets
3. Key generation and verification
   3.1. Shopping list
   3.2. Pre-ceremony work
   3.3. The Ceremony
   3.4. Sharing the secrets and pub keys
   3.5. Testing
4. Post-ceremony

Rationale

Revault is about going further than simple key management security. The protocol adds logic and rights management for delegating, spending and securing funds.
That said, key management is still important in Revault.
Revault states that everybody-but-one-participant can be corrupt, the system still works. Still, we want to help clients/users to set up the protocol correctly, with best security practice. We try to keep a trail for forensic should a critical failure happen, helping the client understand what went wrong.
The Ceremony, as the rest of the Revault architecture, is designed to defend against very motivated and capable attackers.

Revault

Vocabulary

• stakeholder: participant necessary to make funds "spendable" but not needed during day-to-day spending
• manager: participant making day-to-day transactions. May or may not also be a Stakeholder.
• participant: either a stakeholder or a manager (or a stakeholder-manager).
• emergency wallet: a wallet external to the Revault deployment, used as a deterrent against some physical threats.
• watchtower: automated server enforcing the policy of a stakeholder.
• hardware wallet: offline and secure signing device, with a firmware compatible with the Revault protocol.

The Revault deployment

• (at least) 1 watchtower per stakeholder
• 1 revaultd+GUI client per participant (stakeholders+managers) / running either on their day to day computer or a dedicated machine
• 1 hardware wallet per participant (stakeholders+managers)
• 1 cosigning server per stakeholder
• 1 coordinator server per deployment
  extra watchtowers may (should) be deployed and/or contracted to third parties.

Secrets

• 1 seed per hardware wallet (= per participant)
• ? private keys (typically 1 per stakeholder, can have more/different/external participants) for the Emergency address
• 1 extra seed per manager (fee-bumping wallet)
• 1 seed per watchtower (>= per stakeholder)
• 1 static bitcoin private key per cosigning server (=per stakeholder)
• 1 authentication key per participant
• 1 authentication key per watchtower
• 1 authentication key per cosigning server
• 1 authentication key for the coordinator server
• the Emergency Witness Script (shared by the stakeholders)

Key generation and verification

shopping list

• each participant to procure 1 hardware wallet, directly from manufacturer, if possible not in their own name/address, if possible in person, cash. Participants should not all procure their hardware wallet from the same manufacturer. other signing devices such as offline computers may be used but are not recommended for usability (in a secure manner)
• each stakeholder to procure 2 brand new laptops (or other general purpose computing device) of different brands, from 2 different shops, if possible in person, in cash, and not at the store closest to their place of residence or work. Any laptop should work AS LONG AS it has an SD or MicroSD card reader. Preferably no Apple computer.
• each participant to procure (number of participants + 4) MicroSD cards (speed and capacity do not matter) + 1 MicroSD-to-SD adapter
• each participant to procure 1 faster MicroSD card, class U3 and or V30 (or faster). Capacity does not matter.
• each participant to procure a "Revault Kit" or its content separately:
  • printed instructions (this can be tampered with - compare&verify with digital doc!)
  • at least 5 unmarked 6-sided dice (or casino grade dice, or equivalent). More dice=better in case they are not proven balanced.
  • a backup medium. The Revault kit includes both
    • Metal backups (at least 2 for the main secret + 2 for emergency key. The more the better.) + numbered stamps (durability and readability)
    • Paper backups for seed words (recovery convenience), archival grade and preferably water resistant
    • a transparent pen with archival grade ink
  • 10+ unique tamper-evident envelopes per participant (or better tamper-evident seals)
  • "privacy booths", such as cardboard screen to prevent other participants to watch what is being rolled/written
  • screwdrivers (for opening the laptops)
  • thick tape to mask cameras
  • a minimalist room with a basic table and basic chairs, where you can make sure there is no camera nor microphone. Thick curtains or no windows.

Pre-ceremony work for all participants (may be assisted by Revault team)

• unseal the faster MicroSD card
• download a Linux operating system with live environment
• verify the signatures/hashes of the downloaded ISO
• "burn" the ISO to MicroSD
• unseal one of the MicroSD card
• download the Revault Installer
• verify the signatures/hashes
• copy the Revault Installer to the MicroSD
• check both SD cards again on a trusted laptop (the Revault team can assist)
• label the SD cards:
  • Revaultd+GUI
  • Watchtower
  • Cosigning Server
  • Coordinator Server (only 1 needed per company, who verifies? Is it critical?)
  • CEREMONY stick
• copy each software to their respective SD card
• put the SD cards in read-only mode (from the physical LOCK tab) if available. (or do we make full size mandatory?)
• install the Revaultd+GUI on their existing work computer (if not using a dedicated laptop for Revault)
  • ⚠️ if full archive node, need to have a ton of free space >>500GB for long-term usage
  • user will face the Ceremony screen, nothing to do at this stage. Sync in background until done.

The Ceremony 🍾

• participants get naked and check cavities of each other participants for microphones or other devices (alright, optional i guess)
• participants leave their phones at home, or at least outside of The Ceremony Room ™️
• Unseal the laptop boxes
  • DO NOT BOOT.
  • use the screwdriver to open the laptops
  • remove the wifi card if possible, if not at least disconnect the antennas.
• Boot (pre-installed OS or sd card?)
• check signatures of all sd cards again? Are we not creating a security risk here? Need to discuss this more.
• Use CEREMONY sd card. Verify this one for sure.
• Open the README text file, follow instructions
• Open the Revault Kit, or equivalent. Follow instructions, compare with README during each step

Private Keys

• (if required, label the dice)
• open the EFF Diceware list from the SD card, on both latops
• roll 100 dice (20 rolls of 5 dice or equivalent), while stamping/writing on the backups.
• on the EFF Diceware list, for each 5 dice scroll to find the corresponding word. (Scroll, do not type anything).
  • copy the word, paste it on the key generation software (need name and format for this.). Do this on both laptops.
  • write down the word on a backup paper sheet
  • once all words have been written down, and copy-pasted, do one last check they match.
• click "generate" on the software on both computers
  • check that the results are identical on both computers
  • write down the resulting mnemonics (optional, recommended) on paper

Sharing the secrets and public keys

2 options here: either type them on virtual keyboards or use SD cards. Different UX and security. (THIS NEEDS TO BE STUDIED IN DEPTH. SD and .txt security is important to check here)
The "typing on virtual keyboards" is self explanatory, follow each device instructions.
The SD option is as follow:

• for each step, write the data on the corresponding SD card, then lock it, then verify it on the second laptop, then if it matches use it on the right device.
• Public Stakeholder SD
  • Wallet xPub, Cosigner address, Emergency address, Noise pubkeys (which?), name/identifier
• Secret Hardware Wallet SD
  • Wallet private key/mnemonic
• Secret Watchtower SD
  • Wallet private key/mnemonic
  • Noise Private
• Secret Cosigner SD
  • Wallet private key/mnemonic
  • Noise Private
• Secret Manager SD
  • Wallet private key/mnemonic
  • Fee wallet private key/mnemonic
  • Noise Private
• Secret Revaultd SD
  • Noise Private

I thought to go with one repo per entity:

• Wallet
• Watchtower
• Cosig server
• Sync server

The communication channel code will probably be part of another repo (not here).