Core/grin
0
0
Fork 0
mirror of https://github.com/mimblewimble/grin.git synced 2025-02-01 17:01:09 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Minor header formatting fix

Browse source
This commit is contained in:
Ignotus Peverell 2018-02-26 19:15:39 +00:00 committed by GitHub
parent 341a3c9f4d
commit 4f95fcef47
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
doc/contracts.md
View file

@ -10,18 +10,18 @@ Pryds Pedersen, Gregory Maxwell, Andrew Poelstra, John Tromp, Claus Peter
Schnorr. We apologize in advance for all those we couldn't name and recognize Schnorr. We apologize in advance for all those we couldn't name and recognize
that most computer science discoveries are incremental. that most computer science discoveries are incremental.
h1. Built-Ins # Built-Ins
This section is meant as a reminder of some crucial features of the Grin chain. This section is meant as a reminder of some crucial features of the Grin chain.
We assume some prior reading as to how these are constructed and used. We assume some prior reading as to how these are constructed and used.
h2. Pedersen Commitments ## Pedersen Commitments
All outputs include a Pedersen commitment of the form `r*G + v*H` with `r` All outputs include a Pedersen commitment of the form `r*G + v*H` with `r`
the blinding factor, `v` the value, and G and H two distinct generator points the blinding factor, `v` the value, and G and H two distinct generator points
on the same curve group. on the same curve group.
h2. Aggregate Signatures (a.k.a. Schnorr, MuSig) ## Aggregate Signatures (a.k.a. Schnorr, MuSig)
We suppose we have the Blake2 hash function and the same G curve as above. In We suppose we have the Blake2 hash function and the same G curve as above. In
its simplest form, an aggregate signature is built from: its simplest form, an aggregate signature is built from:
@ -52,7 +52,7 @@ public key `r*G`, and allows to verify non-inflation for all Grin transactions
Because these signatues are built simply from a scalar and a public key, they Because these signatues are built simply from a scalar and a public key, they
can be used to construct a variety of contracts using "simple" arithmetic. can be used to construct a variety of contracts using "simple" arithmetic.
h2. Timelocked Transactions ## Timelocked Transactions
A transaction can be time-locked with a few simple modifications: A transaction can be time-locked with a few simple modifications:
@ -62,9 +62,9 @@ becomes spendable appended to the fee (so `M = fee | h`)
* a block with a kernel that includes a lock height lower than the current * a block with a kernel that includes a lock height lower than the current
block height is rejected block height is rejected
h1. Derived Contracts # Derived Contracts
h2. Trustless Transactions ## Trustless Transactions
An aggregate (Schnorr) signature involving a single party is relatively simple An aggregate (Schnorr) signature involving a single party is relatively simple
but does not demonstrate the full flexibility of the contstruction. We show but does not demonstrate the full flexibility of the contstruction. We show
@ -107,7 +107,7 @@ can compute `e = SHA256(M | sum(ki*G) | sum(ri*G))` and their own signature
`si`. Finally, a finalizing party can then gather all the partial signatures `si`. Finally, a finalizing party can then gather all the partial signatures
`si`, validate them and produce `s = (sum(si), sum(ki*G))`. `si`, validate them and produce `s = (sum(si), sum(ki*G))`.
h2. Multiparty Outputs (multisig) ## Multiparty Outputs (multisig)
We describe here a way to build a transaction with an output that can only be We describe here a way to build a transaction with an output that can only be
spent when multiple parties approve it. This construction is very similar to spent when multiple parties approve it. This construction is very similar to
@ -133,7 +133,7 @@ need to know `ra + rb` to produce a kernel signature. To produce that spending
kernel, Alice and Bob need to collaborate. This, again, is done using a kernel, Alice and Bob need to collaborate. This, again, is done using a
protocol very close to Trustless Transactions. protocol very close to Trustless Transactions.
h2. Multiparty Timelocks ## Multiparty Timelocks
This contract is a building block from multiple other contracts. Here, Alice This contract is a building block from multiple other contracts. Here, Alice
agrees to lock some funds to start a financial interaction with Bob and prove agrees to lock some funds to start a financial interaction with Bob and prove
@ -153,7 +153,7 @@ lock expires.
This contract can be trivially used for unidirectional payment channels. This contract can be trivially used for unidirectional payment channels.
h2. Atomic Swap ## Atomic Swap
Alice has grins and Bob has bitcoins. They would like to swap. We assume that Alice has grins and Bob has bitcoins. They would like to swap. We assume that
Bob built an output on the Bitcoin blockchain that can be spent either by Alice Bob built an output on the Bitcoin blockchain that can be spent either by Alice
@ -178,4 +178,6 @@ signature is `(sr + ss, kr*G + ks*G)`.
6. As soon as Bob broadcasts the final transaction to get his new grins, Alice 6. As soon as Bob broadcasts the final transaction to get his new grins, Alice
can compute `sr' - sr` to get `x`. can compute `sr' - sr` to get `x`.
h2. Hashed Timelocks (Lightning Network) ## Hashed Timelocks (Lightning Network)
TODO relative lock times