LBRYCommunity/spec
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity

Merge branch 'signing'

Browse source 
* signing:
  clarify claim signing. fixes #16
This commit is contained in:
Alex Grintsvayg 2019-12-09 15:37:09 -05:00
commit d0a6fd3cac
No known key found for this signature in database
GPG key ID: AEB3F089F86A22B5
1 changed files with 17 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
index.md
View file

@ -64,7 +64,7 @@ This document assumes that the reader is familiar with distributed hash tables (
## Blockchain ## Blockchain
The LBRY blockchain is a public, proof-of-work blockchain. The design is based on the [Bitcoin](https://bitcoin.org/bitcoin.pdf) blockchain, with substantial modifications. This document does not cover or specify any aspects of LBRY that are identical to Bitcoin and instead focuses on the differences, primarily the claim operations and claimtrie. The LBRY blockchain is a public proof-of-work blockchain. The design is based on [Bitcoin](https://bitcoin.org/bitcoin.pdf), with substantial modifications. This document does not cover or specify any aspects of LBRY that are identical to Bitcoin and instead focuses on the differences, primarily the claim operations and claimtrie.
Our blockchain serves three key purposes: Our blockchain serves three key purposes:
@ -628,15 +628,15 @@ The purpose of channels is to allow content to be clustered under a single pseud
#### Signing #### Signing
A claim is considered part of a channel when its metadata is signed by the channel's private key. Here's the structure of a signed metadata value: A claim is considered part of a channel when the metadata in it's value is signed by the channel's private key. Here's the structure of a signed value:
field | size | description field | size | description
:--- | :--- | :--- :--- | :--- | :---
Version | 1 byte | Format version. See [Format Versions](#format-versions). Version | 1 byte | Format version. See [Format Versions](#format-versions).
Channel ID | 20 bytes | Claim ID of the channel claim that contains the matching public key. _Skip this field if there is no signature._ Channel Claim ID | 20 bytes | Claim ID of the channel claim that contains the matching public key. _Skip this field if there is no signature._
Signature | 64 bytes | The signature. _Skip this field if there is no signature._ Signature | 64 bytes | The signature. _Skip this field if there is no signature._
Payload | variable | The protobuf-encoded metadata. Metadata | variable | The protobuf-encoded metadata.
##### Format Versions ##### Format Versions
@ -651,9 +651,13 @@ format | description
##### Signing Process ##### Signing Process
1. Encode the metadata using protobuf. 1. Encode the metadata using protobuf.
2. Hash the encoded claim using SHA-256. 1. Create the payload to be signed by concatenating the following:
3. Sign the hash using the private key associated with the channel. - The outpoint hash the first transaction input of this claim's transaction. This is in the payload to prevent replay attacks.
4. Append all the values (the version, the claim ID of the corresponding channel claim, the signature, and the protobuf-encoded metadata). - The claim ID of the channel. See <a href="#stake-identifier-generation">this</a> for more on outpoints and claim IDs.
- The encoded metadata
1. Hash the payload using SHA-256.
1. Sign the payload hash using the private key associated with the channel.
1. Concatenate the version, the channel claim ID, the payload signature, and the protobuf-encoded metadata. This is the claim value.
##### Signature Validation ##### Signature Validation
@ -661,7 +665,8 @@ format | description
1. Check the version field. If it indicates that there is no signature, then no validation is necessary. 1. Check the version field. If it indicates that there is no signature, then no validation is necessary.
1. Split out the channel ID and signature from the rest of the data. 1. Split out the channel ID and signature from the rest of the data.
1. Look up the channel claim to ensure it exists and contains a public key. 1. Look up the channel claim to ensure it exists and contains a public key.
1. Use the public key to verify the signature. 1. Create the payload hash as described <a href="#signing-process">above</a>.
1. Use the public key to verify that the payload hash signature is valid.
### Validation {#metadata-validation} ### Validation {#metadata-validation}