introduction: replace out-dated revault.pdf with introduction.md #113

JSwambo · 2022-01-14T19:23:40Z

In addition to many language clarifications and minor updates, major differences with revault.pdf are given below.

Removed:

The 'Keys' section was removed in favour of a more detailed spec coming with #107
The 'Transactions' section was removed as it duplicates transactions.md
'Acknowledgements' section removed. Should it be somewhere else in the repo?

'Further Discussion' removed as this information is mostly out-dated or duplicated.

New content:

Updated transaction diagram using descriptors abstraction.
Discussed options for revault deployments and the infrastructure requriements.

Still to do:

The 'fee bumping' section was mostly removed as we are approaching it differently. New approach needs description and rationale.
'Threat model' needs updating to better reflect our current understanding.
Update background colour for diagram to white

kloaec

Few things :) I guess there are many more assumptions like underlying libs being OK, Bitcoin behaving, network connectivity, etc.

introduction.md

kloaec · 2022-01-17T12:42:23Z

introduction.md

+
+The Emergency TX is the first to be signed. It would spend a deposit and pay to the `emergency output descriptor` which is a bitcoin script that is harder to unlock than `deposit output descriptor`. Keeping the `emergency output descriptor` private among stakeholders strengthens the emergency deterrent feature as attackers don't know how they would compromise the emergency vault.
+
+Then, stakeholders exchange signatures for the Cancel and Unvault Emergency TXs:


Is there any reason why this is a separate step?

It's how the practical protocol currently is specified. But it's going to change and in any case this document shouldn't be influenced by the details of the protocol.

So, yeah, it should be merged together.

in any case this document shouldn't be influenced by the details of the protocol.

I find this confusing. What is "the protocol" for you? (I think you mean messages?)

In my opinion the intro should be consistent with the rest of practical-revault, so if messages are passed in a certain order (as in messages.md) that should be the same in the intro. Happy to merge these given the upcoming change tho

I think the intro should be a conceptual overview of Revault. What i meant there is that we "shouldn't bother" the reader of the intro with low-level communication details.

If there is a fundamental reason why we are doing things a certain way (for instance, separating the communication of the revocation sigs and the unvault sig) it should be noted. But in this case it was a protocol hack to not require a new message for "hey WT do you have enough of these feebumping utxos for a new vault?". So it shouldn't make the intro more complicated, which could confuse the reader (what just happened with Kevin).

kloaec · 2022-01-17T13:20:23Z

introduction.md

+
+#### Bitcoin
+
+- assume users can propagate revocation transactions to miners.


if we did, we wouldn't have the fee discussions all the time :)

kloaec · 2022-01-17T13:20:44Z

introduction.md

+
+- assume users can propagate revocation transactions to miners.
+- assume miners will mine the transaction paying the most feerate, regardless of any other (meta)data.
+- assume a significant hashrate to prevent reorgs of depth higher than the unvault time-lock length.


Altho it's more complex than that. We don't want "natural reorgs" to be long, but they still statistically can happen. And then there is the game theory as in: are the miners going to mine the next block instead of rewriting the chain?
It's not only a simple hashrate discussion.

kloaec · 2022-01-17T13:25:05Z

introduction.md

+#### Infrastructure
+
+- assume a proper ceremony (FIXME: link) as the root of trust for cryptographic protocols used.
+- assume a secure signing device allowing users to check the validity of the data being signed.


meh, more like enforcing descriptors, securing keys, and being tamper proof/evident.

kloaec · 2022-01-17T13:26:12Z

introduction.md

+
+- assume a proper ceremony (FIXME: link) as the root of trust for cryptographic protocols used.
+- assume a secure signing device allowing users to check the validity of the data being signed.
+- assume at least one honest cosigning server AND at least one honest online watchtower per stakeholder.


Not really, 1 honest WT and 1 honest cosig in total is enough.
Also, does not apply to unvault policies, in which no cosig is necessary.

kloaec · 2022-01-17T13:26:55Z

introduction.md

+- assume a secure signing device allowing users to check the validity of the data being signed.
+- assume at least one honest cosigning server AND at least one honest online watchtower per stakeholder.
+- assume the N stakeholders’ keys to not all be compromised.
+- assume sufficient fees for Revault TXs such that operations aren't stalled. 


is this an assumption or part of the protocol?

darosior

Great! Thanks for tackling this, i think it'll make it much simpler to introduce technical people to Revault.

introduction.md

darosior · 2022-01-17T13:48:28Z

introduction.md

+
+The Unvault TXs have an additional output that allows dynamically allocating fees through child-pays-for-parent (CPFP). 
+
+The Cancel, Emergency and Unvault Emergency TXs aren't compatible with CPFP-carve out (FIXME: Why?), nor with ANYONECANPAY|ALL signatures (because this enables pinning attacks). The safest solution is to prepare multiple variants of the same transactions with a broad distribution of feerates, from typical to extreme and with many in-between. 


FIXME: Why?

As discussed since the beginning (Almost 2y ago now), and especially as detailed in the work you and i authored, the CPFP carve-out is specific to 2-parties contract. See this stackexchange answer in the context of Lightning which applies to any transaction that has more than 2-reasily spendable outputs.

nor with ANYONECANPAY|ALL signatures (because this enables pinning attacks).

Since the current state of the repo is to use fee-bumping, i think you should just say we do supplement fees by pre-signing with ANYONECANPAY|ALL. I'll modify that in my PR removing all the fee-bumping stuff from this repo

You can even just put a note that it's not detailed as it's going to be removed soon due to pinning concerns.

introduction.md

darosior · 2022-01-17T20:28:27Z

'Further Discussion' removed as this information is mostly out-dated or duplicated.

You did well 👍. But that's not a TODO :) Editing your post to make it an actual TODO list and removing this line from this list. I think the first element is also mostly address by one of my review comments.

Besides, you should remove revault.pdf in your commit.

JSwambo · 2022-01-23T17:24:19Z

Thanks for all the feedback! Updated with a fixup commit so you can check the diff. Will squash after final edits.

darosior

Mostly nits, the fixup commit looks mostly good to me

introduction.md

darosior · 2022-01-24T14:05:55Z

introduction.md


 With these in place, stakeholders are able to delegate bitcoin to fund managers and manually broadcast Cancel, Emergency and Unvault-Emergency TXs. Fund managers will also be able to manually broadcast Cancel TXs to recover from mistakes. 

 Next, users who want additional features will require additional infrastructure components. Each stakeholder may control one or more watchtowers and/ or a co-signing server.

- **Watchtower**: An always-online server that monitors the bitcoin network and chain, as well as polls the coordinator for Spend TXs to perform its responsibilities (automated unvault policy enforcement, automated spend policy enforcement, emergency deterrent). 
+- **Watchtower**: An always-online server that monitors the Bitcoin network and chain, and depending on its responsibilities (which could include; automated unvault policy enforcement, automated spend policy enforcement, emergency deterrent) it will respond to relevant events.


The use of ; in the english language i've always found interesting

ah I actually used it wrong. It should be :

introduction.md

darosior

ACK f6b793b

Awesome, very excited to finally have a better introduction. Just a couple final nits:

Can you move the image to a img/ subfolder?
Can you link to this document in the README somehow? Like "For a high-level description of Revault, see the introduction"

Removed: The 'Keys' section was removed in favour of a more detailed spec coming with revault#107 The 'Transactions' section was removed as it duplicates transactions.md 'Acknowledgements' section removed. Should it be somewhere else in the repo? New content: Updated transaction diagram using descriptors abstraction. Discussed options for revault deployments and the infrastructure requriements. Renamed "Threat model" section to "Risk" and updated. The 'fee bumping' section was mostly removed as we are approaching it differently. 'Further Discussion' removed as this information is mostly out-dated or duplicated.

darosior · 2022-02-01T19:17:00Z

Applied my two comments myself. Let's move forward.

ACK 6b35b37

kloaec suggested changes Jan 17, 2022

View reviewed changes

darosior reviewed Jan 17, 2022

View reviewed changes

darosior reviewed Jan 24, 2022

View reviewed changes

JSwambo force-pushed the intro branch from f673cdf to f6b793b Compare January 25, 2022 12:43

darosior reviewed Jan 26, 2022

View reviewed changes

darosior changed the title ~~(WIP) introduction: replace out-dated revault.pdf with introduction.md~~ introduction: replace out-dated revault.pdf with introduction.md Jan 26, 2022

darosior force-pushed the intro branch 2 times, most recently from 95a7061 to 6b35b37 Compare February 1, 2022 19:16

darosior merged commit aeb8dd0 into revault:master Feb 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

introduction: replace out-dated revault.pdf with introduction.md #113

introduction: replace out-dated revault.pdf with introduction.md #113

JSwambo commented Jan 14, 2022 •

edited by darosior

Loading

kloaec left a comment

kloaec Jan 17, 2022

darosior Jan 17, 2022

JSwambo Jan 18, 2022

darosior Jan 18, 2022

kloaec Jan 17, 2022

kloaec Jan 17, 2022

kloaec Jan 17, 2022

kloaec Jan 17, 2022

kloaec Jan 17, 2022

kloaec Jan 17, 2022

darosior left a comment

darosior Jan 17, 2022

darosior Jan 17, 2022

darosior commented Jan 17, 2022 •

edited

Loading

JSwambo commented Jan 23, 2022

darosior left a comment

darosior Jan 24, 2022

darosior Jan 24, 2022

JSwambo Jan 25, 2022

darosior left a comment

darosior commented Feb 1, 2022


		The Emergency TX is the first to be signed. It would spend a deposit and pay to the `emergency output descriptor` which is a bitcoin script that is harder to unlock than `deposit output descriptor`. Keeping the `emergency output descriptor` private among stakeholders strengthens the emergency deterrent feature as attackers don't know how they would compromise the emergency vault.

		Then, stakeholders exchange signatures for the Cancel and Unvault Emergency TXs:


		#### Bitcoin

		- assume users can propagate revocation transactions to miners.


		The Unvault TXs have an additional output that allows dynamically allocating fees through child-pays-for-parent (CPFP).

		The Cancel, Emergency and Unvault Emergency TXs aren't compatible with CPFP-carve out (FIXME: Why?), nor with ANYONECANPAY\|ALL signatures (because this enables pinning attacks). The safest solution is to prepare multiple variants of the same transactions with a broad distribution of feerates, from typical to extreme and with many in-between.

introduction: replace out-dated revault.pdf with introduction.md #113

introduction: replace out-dated revault.pdf with introduction.md #113

Conversation

JSwambo commented Jan 14, 2022 • edited by darosior Loading

kloaec left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darosior left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darosior commented Jan 17, 2022 • edited Loading

JSwambo commented Jan 23, 2022

darosior left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darosior left a comment

Choose a reason for hiding this comment

darosior commented Feb 1, 2022

JSwambo commented Jan 14, 2022 •

edited by darosior

Loading

darosior commented Jan 17, 2022 •

edited

Loading