diff options
author | Christian Grothoff <grothoff@gnunet.org> | 2022-03-12 02:51:55 +0100 |
---|---|---|
committer | Christian Grothoff <grothoff@gnunet.org> | 2022-03-12 02:51:55 +0100 |
commit | 5599cf4bd7e271a7977e3c800e7aaa0fd1ada1e0 (patch) | |
tree | ede63d96813e89647741448d64dd0e3af3b2976b | |
parent | f073d64ab174389f84984ab91bf03a9f9b3e88c0 (diff) | |
download | lsd0004-5599cf4bd7e271a7977e3c800e7aaa0fd1ada1e0.tar.gz lsd0004-5599cf4bd7e271a7977e3c800e7aaa0fd1ada1e0.zip |
simplify block functions
-rw-r--r-- | draft-schanzen-r5n.xml | 14 |
1 files changed, 5 insertions, 9 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 6a58c91..412c460 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -1346,8 +1346,7 @@ bchar = *(ALPHA / DIGIT) | |||
1346 | <li> | 1346 | <li> |
1347 | Next, the <tt>ValidateBlockStoreRequest</tt> procedure for the <tt>BTYPE</tt> | 1347 | Next, the <tt>ValidateBlockStoreRequest</tt> procedure for the <tt>BTYPE</tt> |
1348 | as described in <xref target="block_functions"/> is used to | 1348 | as described in <xref target="block_functions"/> is used to |
1349 | validate the block payload. If a key could not be derived in the previous step, the | 1349 | validate the block payload. If the block payload |
1350 | key from the request is used for validation. If the block payload | ||
1351 | is invalid, the message <bcp14>MUST</bcp14> be discarded. | 1350 | is invalid, the message <bcp14>MUST</bcp14> be discarded. |
1352 | </li> | 1351 | </li> |
1353 | <li> | 1352 | <li> |
@@ -1725,11 +1724,8 @@ bchar = *(ALPHA / DIGIT) | |||
1725 | requested <tt>BTYPE</tt>. To do this, the peer attempts to compute the | 1724 | requested <tt>BTYPE</tt>. To do this, the peer attempts to compute the |
1726 | key using <tt>DeriveBlockKey</tt>. Note that the computed key | 1725 | key using <tt>DeriveBlockKey</tt>. Note that the computed key |
1727 | does not have to match the <tt>QUERY_HASH</tt>. Next, the peer | 1726 | does not have to match the <tt>QUERY_HASH</tt>. Next, the peer |
1728 | checks that the block is valid using <tt>ValidateBlockStoreRequest</tt> | 1727 | checks that the block is valid using <tt>ValidateBlockStoreRequest</tt>. |
1729 | using the derived key if it is available. If the derived key is | 1728 | If the result is <tt>BLOCK_INVALID</tt>, the message <bcp14>MUST</bcp14> be |
1730 | <tt>NONE</tt>, the query hash is passed to <tt>ValidateBlockStoreRequest</tt> | ||
1731 | instead of a key. If the | ||
1732 | result is <tt>BLOCK_INVALID</tt>, the message <bcp14>MUST</bcp14> be | ||
1733 | discarded. | 1729 | discarded. |
1734 | </li> | 1730 | </li> |
1735 | <li> | 1731 | <li> |
@@ -1848,11 +1844,11 @@ bchar = *(ALPHA / DIGIT) | |||
1848 | permit deriving the key from the block. A Key may be returned | 1844 | permit deriving the key from the block. A Key may be returned |
1849 | for a block that is ill-formed. | 1845 | for a block that is ill-formed. |
1850 | </dd> | 1846 | </dd> |
1851 | <dt>ValidateBlockStoreRequest(Block, Key) | 1847 | <dt>ValidateBlockStoreRequest(Block) |
1852 | -> BlockEvaluationResult</dt> | 1848 | -> BlockEvaluationResult</dt> |
1853 | <dd> | 1849 | <dd> |
1854 | <t> | 1850 | <t> |
1855 | is used to evaluate a block including its key and payload | 1851 | is used to evaluate a block payload |
1856 | as part of <tt>PutMessage</tt> and <tt>ResultMessage</tt> processing. | 1852 | as part of <tt>PutMessage</tt> and <tt>ResultMessage</tt> processing. |
1857 | Possible values for the <tt>BlockEvaluationResult</tt> are: | 1853 | Possible values for the <tt>BlockEvaluationResult</tt> are: |
1858 | </t> | 1854 | </t> |