diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 09a3cd179..1231e710a 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -624,7 +624,7 @@ \(\mathsf{issued\_assets(AssetBase).final}\) to \(1\) - in the global state immediately after the block in which this transaction occurs. + in the global state.
  • (Replay Protection) If issue bundle is present, the fees MUST be greater than zero.
    • @@ -646,11 +646,6 @@
  • We limit the size of the \(\mathsf{asset\_desc}\) string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.
    • -
  • We require a check whether the - \(\mathsf{finalize}\) - flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the - \(\mathsf{issued\_assets}\) - map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.
  • We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.

    • Concrete Applications

    diff --git a/rendered/zip-0230.html b/rendered/zip-0230.html index 3b2eeec36..1ef67e07e 100644 --- a/rendered/zip-0230.html +++ b/rendered/zip-0230.html @@ -585,7 +585,15 @@ 43 recipient byte[43] - The raw encoding of an Orchard Raw Payment Address, as per protocol §5.6.4.2 ‘Orchard Raw Payment Addresses’. + The encoding of a recipient's diversified payment address, as + \(\mathsf{LEBS2OSP}_{88}(\mathsf{d})\| +\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}} +(\mathsf{pk}_\mathsf{d}))\!\) + , where + \(\mathsf{d}\) + is the diversifier and + \(\mathsf{pk_d}\) + is the diversified transmission key. Non Normative Note: This is the same as the encoding of an Orchard Raw Payment Address, as defined in the protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’. 8 diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 9dac2581d..4a981f2c8 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -362,7 +362,7 @@ If all of the above checks pass, do the following: - Add :math:`\mathsf{cm}` to the Merkle tree of note commitments. - Increase the value of :math:`\mathsf{issued\_assets(AssetBase).balance}` by the value of the note, :math:`\mathsf{v}`. -- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state immediately after the block in which this transaction occurs. +- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state. - (Replay Protection) If issue bundle is present, the fees MUST be greater than zero. @@ -382,7 +382,6 @@ The following is a list of rationale for different decisions made in the proposa - information to be committed by the issuer, though not enforceable by the protocol. - We limit the size of the :math:`\mathsf{asset\_desc}` string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format. -- We require a check whether the :math:`\mathsf{finalize}` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the :math:`\mathsf{issued\_assets}` map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve. - We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack. Concrete Applications diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index 77eac1422..2bed2e300 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -342,8 +342,14 @@ An issuance note, ``IssueNote`` contains the following fields: +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ | Bytes | Name | Data Type | Description | +=============================+==========================+======================================+====================================================================+ -|``43`` |``recipient`` |``byte[43]`` |The raw encoding of an Orchard Raw Payment Address, as | -| | | |per protocol §5.6.4.2 ‘Orchard Raw Payment Addresses’. | +|``43`` |``recipient`` |``byte[43]`` |The encoding of a recipient's diversified payment address, as | +| | | |:math:`\mathsf{LEBS2OSP}_{88}(\mathsf{d})\| | +| | | |\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}} | +| | | |(\mathsf{pk}_\mathsf{d}))\!`, where :math:`\mathsf{d}` is the | +| | | |diversifier and :math:`\mathsf{pk_d}` is the diversified | +| | | |transmission key. **Non Normative Note**: This is the same as the | +| | | |encoding of an Orchard Raw Payment Address, as defined in the | +| | | |protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’. | +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+ |``8`` |``value`` |``uint64`` |The amount being issued in this note. | +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+