This commit is contained in:
Alex Grintsvayg 2018-11-08 15:54:31 -05:00
parent 67c9aada3d
commit a5cf630072
2 changed files with 57 additions and 78 deletions

View file

@ -125,6 +125,7 @@
* [Design Notes](#design-notes) * [Design Notes](#design-notes)
* [Transactions](#transactions) * [Transactions](#transactions)
* [Operations and Opcodes](#operations-and-opcodes) * [Operations and Opcodes](#operations-and-opcodes)
* [Claim Identifier Generation](#claim-identifier-generation)
* [OP_CLAIM_NAME](#op-claim-name) * [OP_CLAIM_NAME](#op-claim-name)
* [OP_UPDATE_CLAIM](#op-update-claim) * [OP_UPDATE_CLAIM](#op-update-claim)
* [OP_SUPPORT_CLAIM](#op-support-claim) * [OP_SUPPORT_CLAIM](#op-support-claim)
@ -266,7 +267,7 @@
<dl> <dl>
<dt>claim_id</dt> <dt>claim_id</dt>
<dd>A 20-byte hash unique among all claims. See <a href="#fixme">Claim Identifier Generation</a>.</dd> <dd>A 20-byte hash unique among all claims. See <a href="#claim-identifier-generation">Claim Identifier Generation</a>.</dd>
<dt>name</dt> <dt>name</dt>
<dd>A normalized UTF-8 string of up to 255 bytes used to address the claim. See <a href="#urls">URLs</a> and <a href="#normalization">Normalization</a>.</dd> <dd>A normalized UTF-8 string of up to 255 bytes used to address the claim. See <a href="#urls">URLs</a> and <a href="#normalization">Normalization</a>.</dd>
<dt>amount</dt> <dt>amount</dt>
@ -285,24 +286,15 @@
&quot;name&quot;: &quot;lbry&quot;, &quot;name&quot;: &quot;lbry&quot;,
&quot;amount&quot;: 1.0, &quot;amount&quot;: 1.0,
&quot;value&quot;: { &quot;value&quot;: {
&quot;claimType&quot;: &quot;streamType&quot;,
&quot;stream&quot;: { &quot;stream&quot;: {
&quot;metadata&quot;: { &quot;title&quot;: &quot;What is LBRY?&quot;,
&quot;author&quot;: &quot;Samuel Bryan&quot;, &quot;author&quot;: &quot;Samuel Bryan&quot;,
&quot;description&quot;: &quot;What is LBRY? An introduction with Alex Tabarrok&quot;, &quot;description&quot;: &quot;What is LBRY? An introduction with Alex Tabarrok&quot;,
&quot;language&quot;: &quot;en&quot;, &quot;language&quot;: &quot;en&quot;,
&quot;license&quot;: &quot;LBRY inc&quot;, &quot;license&quot;: &quot;LBRY inc&quot;,
&quot;licenseUrl&quot;: &quot;&quot;,
&quot;nsfw&quot;: false,
&quot;preview&quot;: &quot;&quot;,
&quot;thumbnail&quot;: &quot;https://s3.amazonaws.com/files.lbry.io/logo.png&quot;, &quot;thumbnail&quot;: &quot;https://s3.amazonaws.com/files.lbry.io/logo.png&quot;,
&quot;title&quot;: &quot;What is LBRY?&quot;, &quot;mediaType&quot;: &quot;video/mp4&quot;,
}, &quot;stream_hash&quot;: &quot;232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752&quot;,
&quot;source&quot;: {
&quot;contentType&quot;: &quot;video/mp4&quot;,
&quot;source&quot;: &quot;232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752&quot;,
&quot;sourceType&quot;: &quot;lbry_sd_hash&quot;,
},
}, },
} }
} }
@ -803,9 +795,13 @@ OP_UPDATE_CLAIM &lt;name&gt; &lt;claimId&gt; &lt;value&gt; OP_2DROP OP_2DROP &lt
OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&gt; OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&gt;
</code></pre> </code></pre>
<p>The <code>&lt;name&gt;</code> parameter is the [[name]] that the claim will be associated with. <code>&lt;value&gt;</code> is the protobuf-encoded claim metadata and optional channel signature (see <a href="#metadata">Metadata</a> for info about this value). <code>&lt;claimId&gt;</code> is the claim ID of a previous claim that is being updated or supported.</p> <p>The <code>&lt;name&gt;</code> parameter is the [[name]] that the claim will be associated with. <code>&lt;value&gt;</code> is the protobuf-encoded claim metadata and optional channel signature (see <a href="#metadata">Metadata</a> for info about this value). The <code>&lt;claimId&gt;</code> is the claim ID of a previous claim that is being updated or supported.</p>
<p>Each opcode will push a zero on to the execution stack. Those zeros, as well as any additional parameters after the opcodes, are all dropped by <code>OP_2DROP</code> and <code>OP_DROP</code>. <code>&lt;outputScript&gt;</code> can be any valid script, so a script using these opcodes is also a pay-to-pubkey script. This means that claimtrie scripts can be spent just like regular Bitcoin output scripts.</p> <p>Each opcode will push a zero on to the execution stack. Those zeros, as well as any additional parameters after the opcodes, are all dropped by <code>OP_2DROP</code> and <code>OP_DROP</code>. <code>&lt;outputScript&gt;</code> can be any valid script, so a script using these opcodes is also a pay-to-pubkey script. This means that claim scripts can be spent just like regular Bitcoin output scripts.</p>
<h5 id="claim-identifier-generation">Claim Identifier Generation</h5>
<p>Like any standard Bitcoin output script, a claim script will be associated with a transaction hash and output index. This combination of transaction hash and index is called an <em>outpoint</em>. Each claim script has a unique outpoint. The outpoint is hashed using SHA-256 and RIPEMD-160 to generate the claim ID for a claim. For the example above, let&rsquo;s say claim script is included in transaction <code>7560111513bea7ec38e2ce58a58c1880726b1515497515fd3f470d827669ed43</code> at the output index <code>1</code>. Then the claim ID would be <code>529357c3422c6046d3fec76be2358004ba22e323</code>. An implementation of this is available <a href="https://github.com/lbryio/lbry.go/blob/master/lbrycrd/blockchain.go">here</a>.</p>
<h5 id="op-claim-name">OP_CLAIM_NAME</h5> <h5 id="op-claim-name">OP_CLAIM_NAME</h5>
@ -814,8 +810,6 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
<pre><code>OP_CLAIM_NAME Fruit Apple OP_2DROP OP_DROP OP_DUP OP_HASH160 &lt;address&gt; OP_EQUALVERIFY OP_CHECKSIG <pre><code>OP_CLAIM_NAME Fruit Apple OP_2DROP OP_DROP OP_DUP OP_HASH160 &lt;address&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre> </code></pre>
<p>Like any standard Bitcoin output script, it will be associated with a transaction hash and output index. The transaction hash and output index are concatenated and hashed using Hash160 to create the claim ID for this claim. For the example above, let&rsquo;s say the above transaction hash is <code>7560111513bea7ec38e2ce58a58c1880726b1515497515fd3f470d827669ed43</code> and the output index is <code>1</code>. Then the claimID would be <code>529357c3422c6046d3fec76be2358004ba22e323</code>. An implementation of this is available <a href="https://github.com/lbryio/lbry.go/blob/master/lbrycrd/blockchain.go">here</a></p>
<h5 id="op-update-claim">OP_UPDATE_CLAIM</h5> <h5 id="op-update-claim">OP_UPDATE_CLAIM</h5>
<p><code>OP_UPDATE_CLAIM</code> updates a claim by replacing its metadata. An update transaction has an added requirement that it must spend the output for the existing claim that it wishes to update. Otherwise, it will be considered invalid and will not make it into the claimtrie. Thus it must have the following redeem script:</p> <p><code>OP_UPDATE_CLAIM</code> updates a claim by replacing its metadata. An update transaction has an added requirement that it must spend the output for the existing claim that it wishes to update. Otherwise, it will be considered invalid and will not make it into the claimtrie. Thus it must have the following redeem script:</p>
@ -871,7 +865,7 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
<h4 id="block-hash-algorithm">Block Hash Algorithm</h4> <h4 id="block-hash-algorithm">Block Hash Algorithm</h4>
<p>LBRY uses a combination of SHA256, SHA512, and RIPEMD160. The exact hashing algorithm can be seen <a href="https://github.com/lbryio/lbrycrd/blob/master/src/hash.cpp#L18">here</a>.</p> <p>LBRY uses a combination of SHA-256, SHA-512, and RIPEMD-160. The exact hashing algorithm can be seen <a href="https://github.com/lbryio/lbrycrd/blob/master/src/hash.cpp#L18">here</a>.</p>
<h4 id="block-rewards">Block Rewards</h4> <h4 id="block-rewards">Block Rewards</h4>
@ -902,10 +896,6 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
<p>Heres some example metadata:</p> <p>Heres some example metadata:</p>
<pre><code>{ <pre><code>{
&quot;claim_id&quot;: &quot;6e56325c5351ceda2dd0795a30e864492910ccbf&quot;,
&quot;name&quot;: &quot;lbry&quot;,
&quot;amount&quot;: 1.0,
&quot;value&quot;: {
&quot;stream&quot;: { &quot;stream&quot;: {
&quot;title&quot;: &quot;What is LBRY?&quot;, &quot;title&quot;: &quot;What is LBRY?&quot;,
&quot;author&quot;: &quot;Samuel Bryan&quot;, &quot;author&quot;: &quot;Samuel Bryan&quot;,
@ -914,8 +904,7 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
&quot;license&quot;: &quot;LBRY inc&quot;, &quot;license&quot;: &quot;LBRY inc&quot;,
&quot;thumbnail&quot;: &quot;https://s3.amazonaws.com/files.lbry.io/logo.png&quot;, &quot;thumbnail&quot;: &quot;https://s3.amazonaws.com/files.lbry.io/logo.png&quot;,
&quot;mediaType&quot;: &quot;video/mp4&quot;, &quot;mediaType&quot;: &quot;video/mp4&quot;,
&quot;streamHash&quot;: &quot;232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752&quot;, &quot;streamHash&quot;: &quot;232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752&quot;
}
} }
} }
</code></pre> </code></pre>
@ -1033,7 +1022,7 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
<tr> <tr>
<td align="left"><code>00000001</code></td> <td align="left"><code>00000001</code></td>
<td align="left">Signature using ECDSA SECP256k1 key and SHA256 hash.</td> <td align="left">Signature using ECDSA SECP256k1 key and SHA-256 hash.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
@ -1042,7 +1031,7 @@ OP_SUPPORT_CLAIM &lt;name&gt; &lt;claimId&gt; OP_2DROP OP_DROP &lt;outputScript&
<ol> <ol>
<li>Encode the metadata using protobuf.</li> <li>Encode the metadata using protobuf.</li>
<li>Hash the encoded claim using SHA256.</li> <li>Hash the encoded claim using SHA-256.</li>
<li>Sign the hash using the private key associated with the channel.</li> <li>Sign the hash using the private key associated with the channel.</li>
<li>Append all the values (the version, the claim ID of the corresponding channel claim, the signature, and the protobuf-encoded metadata).</li> <li>Append all the values (the version, the claim ID of the corresponding channel claim, the signature, and the protobuf-encoded metadata).</li>
</ol> </ol>

View file

@ -60,6 +60,7 @@
* [Design Notes](#design-notes) * [Design Notes](#design-notes)
* [Transactions](#transactions) * [Transactions](#transactions)
* [Operations and Opcodes](#operations-and-opcodes) * [Operations and Opcodes](#operations-and-opcodes)
* [Claim Identifier Generation](#claim-identifier-generation)
* [OP_CLAIM_NAME](#op-claim-name) * [OP_CLAIM_NAME](#op-claim-name)
* [OP_UPDATE_CLAIM](#op-update-claim) * [OP_UPDATE_CLAIM](#op-update-claim)
* [OP_SUPPORT_CLAIM](#op-support-claim) * [OP_SUPPORT_CLAIM](#op-support-claim)
@ -199,7 +200,7 @@ Claims have four properties:
<dl> <dl>
<dt>claim_id</dt> <dt>claim_id</dt>
<dd>A 20-byte hash unique among all claims. See <a href="#fixme">Claim Identifier Generation</a>.</dd> <dd>A 20-byte hash unique among all claims. See <a href="#claim-identifier-generation">Claim Identifier Generation</a>.</dd>
<dt>name</dt> <dt>name</dt>
<dd>A normalized UTF-8 string of up to 255 bytes used to address the claim. See <a href="#urls">URLs</a> and <a href="#normalization">Normalization</a>.</dd> <dd>A normalized UTF-8 string of up to 255 bytes used to address the claim. See <a href="#urls">URLs</a> and <a href="#normalization">Normalization</a>.</dd>
<dt>amount</dt> <dt>amount</dt>
@ -218,24 +219,15 @@ Here is an example stream claim:
"name": "lbry", "name": "lbry",
"amount": 1.0, "amount": 1.0,
"value": { "value": {
"claimType": "streamType",
"stream": { "stream": {
"metadata": { "title": "What is LBRY?",
"author": "Samuel Bryan", "author": "Samuel Bryan",
"description": "What is LBRY? An introduction with Alex Tabarrok", "description": "What is LBRY? An introduction with Alex Tabarrok",
"language": "en", "language": "en",
"license": "LBRY inc", "license": "LBRY inc",
"licenseUrl": "",
"nsfw": false,
"preview": "",
"thumbnail": "https://s3.amazonaws.com/files.lbry.io/logo.png", "thumbnail": "https://s3.amazonaws.com/files.lbry.io/logo.png",
"title": "What is LBRY?", "mediaType": "video/mp4",
}, "stream_hash": "232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752",
"source": {
"contentType": "video/mp4",
"source": "232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752",
"sourceType": "lbry_sd_hash",
},
}, },
} }
} }
@ -601,9 +593,14 @@ OP_UPDATE_CLAIM <name> <claimId> <value> OP_2DROP OP_2DROP <outputScript>
OP_SUPPORT_CLAIM <name> <claimId> OP_2DROP OP_DROP <outputScript> OP_SUPPORT_CLAIM <name> <claimId> OP_2DROP OP_DROP <outputScript>
``` ```
The `<name>` parameter is the [[name]] that the claim will be associated with. `<value>` is the protobuf-encoded claim metadata and optional channel signature (see [Metadata](#metadata) for info about this value). `<claimId>` is the claim ID of a previous claim that is being updated or supported. The `<name>` parameter is the [[name]] that the claim will be associated with. `<value>` is the protobuf-encoded claim metadata and optional channel signature (see [Metadata](#metadata) for info about this value). The `<claimId>` is the claim ID of a previous claim that is being updated or supported.
Each opcode will push a zero on to the execution stack. Those zeros, as well as any additional parameters after the opcodes, are all dropped by `OP_2DROP` and `OP_DROP`. `<outputScript>` can be any valid script, so a script using these opcodes is also a pay-to-pubkey script. This means that claim scripts can be spent just like regular Bitcoin output scripts.
##### Claim Identifier Generation
Like any standard Bitcoin output script, a claim script will be associated with a transaction hash and output index. This combination of transaction hash and index is called an _outpoint_. Each claim script has a unique outpoint. The outpoint is hashed using SHA-256 and RIPEMD-160 to generate the claim ID for a claim. For the example above, let's say claim script is included in transaction `7560111513bea7ec38e2ce58a58c1880726b1515497515fd3f470d827669ed43` at the output index `1`. Then the claim ID would be `529357c3422c6046d3fec76be2358004ba22e323`. An implementation of this is available [here](https://github.com/lbryio/lbry.go/blob/master/lbrycrd/blockchain.go).
Each opcode will push a zero on to the execution stack. Those zeros, as well as any additional parameters after the opcodes, are all dropped by `OP_2DROP` and `OP_DROP`. `<outputScript>` can be any valid script, so a script using these opcodes is also a pay-to-pubkey script. This means that claimtrie scripts can be spent just like regular Bitcoin output scripts.
##### OP\_CLAIM\_NAME ##### OP\_CLAIM\_NAME
@ -613,8 +610,6 @@ New claims are created using `OP_CLAIM_NAME`. For example, a claim transaction s
OP_CLAIM_NAME Fruit Apple OP_2DROP OP_DROP OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG OP_CLAIM_NAME Fruit Apple OP_2DROP OP_DROP OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG
``` ```
Like any standard Bitcoin output script, it will be associated with a transaction hash and output index. The transaction hash and output index are concatenated and hashed using Hash160 to create the claim ID for this claim. For the example above, let's say the above transaction hash is `7560111513bea7ec38e2ce58a58c1880726b1515497515fd3f470d827669ed43` and the output index is `1`. Then the claimID would be `529357c3422c6046d3fec76be2358004ba22e323`. An implementation of this is available [here](https://github.com/lbryio/lbry.go/blob/master/lbrycrd/blockchain.go)
##### OP\_UPDATE\_CLAIM ##### OP\_UPDATE\_CLAIM
@ -677,7 +672,7 @@ The proof-of-work target is adjusted every block to better adapt to sudden chang
#### Block Hash Algorithm #### Block Hash Algorithm
LBRY uses a combination of SHA256, SHA512, and RIPEMD160. The exact hashing algorithm can be seen [here](https://github.com/lbryio/lbrycrd/blob/master/src/hash.cpp#L18). LBRY uses a combination of SHA-256, SHA-512, and RIPEMD-160. The exact hashing algorithm can be seen [here](https://github.com/lbryio/lbrycrd/blob/master/src/hash.cpp#L18).
#### Block Rewards #### Block Rewards
@ -708,10 +703,6 @@ Heres some example metadata:
``` ```
{ {
"claim_id": "6e56325c5351ceda2dd0795a30e864492910ccbf",
"name": "lbry",
"amount": 1.0,
"value": {
"stream": { "stream": {
"title": "What is LBRY?", "title": "What is LBRY?",
"author": "Samuel Bryan", "author": "Samuel Bryan",
@ -720,8 +711,7 @@ Heres some example metadata:
"license": "LBRY inc", "license": "LBRY inc",
"thumbnail": "https://s3.amazonaws.com/files.lbry.io/logo.png", "thumbnail": "https://s3.amazonaws.com/files.lbry.io/logo.png",
"mediaType": "video/mp4", "mediaType": "video/mp4",
"streamHash": "232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752", "streamHash": "232068af6d51325c4821ac897d13d7837265812164021ec832cb7f18b9caf6c77c23016b31bac9747e7d5d9be7f4b752"
}
} }
} }
``` ```
@ -799,12 +789,12 @@ The following formats are supported:
format | description format | description
:--- | :--- :--- | :---
`00000000` | No signature. `00000000` | No signature.
`00000001` | Signature using ECDSA SECP256k1 key and SHA256 hash. `00000001` | Signature using ECDSA SECP256k1 key and SHA-256 hash.
##### Signing Process ##### Signing Process
1. Encode the metadata using protobuf. 1. Encode the metadata using protobuf.
1. Hash the encoded claim using SHA256. 1. Hash the encoded claim using SHA-256.
1. Sign the hash using the private key associated with the channel. 1. Sign the hash using the private key associated with the channel.
1. Append all the values (the version, the claim ID of the corresponding channel claim, the signature, and the protobuf-encoded metadata). 1. Append all the values (the version, the claim ID of the corresponding channel claim, the signature, and the protobuf-encoded metadata).