You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 17, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
+19-17Lines changed: 19 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -170,13 +170,13 @@ Members of the contract can interact with the vm using signed statements, called
170
170
}
171
171
```
172
172
173
-
Members can use the vm to settle on a spending path, or lock, unlock, and dispute paths. Each statement that updates the vm is recorded into a hash-chain. The chain validates the full running history of the vm, from activation to settlement.
173
+
Members can use the vm to settle on a spending path, or lock, unlock, and dispute paths. Each statement that updates the vm is recorded into a hash-chain. This chain validates the full history of the vm, from activation to settlement.
174
174
175
175
Once the contract vm has settled on a spending path, the agent will complete the relevant pre-signed transaction, and broadcast it, closing the contract.
176
176
177
-
The proposal, covenants, and vm combine to create a proof of validity. This proof covers how the contract should execute at any moment. There is zero ambiguity left to the `agent`.
177
+
The proposal, covenants, and vm combine to create a proof of validity. This proof covers how the contract should execute at any moment, with zero ambiguity left to the `agent`.
178
178
179
-
Each contract settlement on mainnet will include a valid proof in order to keep our reputation intact.
179
+
Each contract settlement on mainnet will include a valid proof to maintain our reputation.
180
180
181
181
### Protocol Flow
182
182
@@ -219,33 +219,31 @@ Each contract settlement on mainnet will include a valid proof in order to keep
219
219
220
220
A brief description of the security model:
221
221
222
-
* Each member joins the proposal using an anonymous credential. The involvement of a credential can be independently verified without revealing the owner.
222
+
* Each member joins the proposal using an anonymous credential. The involvement of a credential can be independently verified without revealing the owner to the agent.
223
223
224
224
* Members decide the terms of the proposal, and all spending paths. The contract agent does not get involved until the proposal terms have already been finalized.
225
225
226
-
* Each member can optionally sign the proposal terms, if they wish to publicize their endorsement. This does not reveal their credential in the proposal.
226
+
* Each member can optionally sign the proposal terms, if they wish to publicize their involvement. This does not reveal their credential in the proposal.
227
227
228
228
* Funders ultimately decide on what transactions to sign and deliver to the agent. If there's a disagreement, funders can back out of a deposit.
229
229
230
230
* The contract agent cannot link depositors to members, nor members to credentials.
231
231
232
-
* The contract agent can only settle on transactions provided by funders.
232
+
* The contract agent can only settle via transactions provided by funders.
233
233
234
-
* All parites independently verify the progression of the contract, and the final settlement. If the platform settles without a valid proof, their reputation is burned.
234
+
* All parites independently verify the progression of the contract and final settlement. If an agent settles the contract without publicizing a valid proof, their reputation is burned.
235
235
236
236
Some challenges with the current model:
237
237
238
-
* The platform has a limited opportunity to censor members of a contract by ignoring their witness statements. In the short term, we plan to mitigate this using signed delivery receipts. In the long-term, we will support alternative platforms for delivery (such as nostr).
238
+
* The agent has limited opportunity to censor members of a contract by ignoring their witness statements. In the short term, we plan to mitigate this using signed delivery receipts. In the long-term, we will support alternative platforms for publishing (such as nostr).
239
239
240
-
* Even with the covenant restrictions, the burning of reputation may not be considered strong enough incentive. We are exploring additional options, such as staking collateral.
240
+
* Even with the covenant restrictions, the burning of reputation may not be considered strong enough incentive. We are exploring additional options, such as the agent staking collateral.
241
241
242
242
In terms of security, speed, and simplicity, we believe this is the best non-custodial solution for providing programmable escrow contracts on Bitcoin.
243
243
244
244
## How to Use
245
245
246
-
This readme will be an mixture of documentation and links to code examples. The full documentation is still a work in progress.
247
-
248
-
Below is a step-by-step guide through the protocol. This guide also includes a live demo that you can run yourself. To view the demo, simply clone this repository, then run the following commands:
246
+
Below is a step-by-step guide through the protocol. This guide follows a live demo that you can run yourself. To run the demo, simply clone this repository, then run the following commands:
249
247
250
248
```sh
251
249
npm install # Install all package dependencies.
@@ -258,7 +256,6 @@ Read more info about the demo [here](demo/README.md).
Provides a full suite of cryptographic primities and other useful tools. Wraps the noble-curve and noble-hash libraries (and cross-checks them with other implementations). Also provides an extended protocol for BIP32 key-derivation that supports strings and urls.
527
+
Provides a suite of cryptography primitives and tools. Wraps the noble-curve and noble-hash libraries (and cross-checks them with other implementations).
0 commit comments