zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 317: fill in values for `p2pkh_standard_{input,output}_size`. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-10-12 15:00:15 +01:00
parent 6f97fd5b6c
commit 4a308cb87e
2 changed files with 62 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
zip-0317.html
View File

@ -165,10 +165,10 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/631">https://githu
<span class="math">\(grace\_actions = 2\)</span>
;</li>
<li>
<span class="math">\(p2pkh\_standard\_input\_size = TODO\)</span>
<span class="math">\(p2pkh\_standard\_input\_size = 150\)</span>
bytes;</li>
<li>
<span class="math">\(p2pkh\_standard\_output\_size = TODO\)</span>
<span class="math">\(p2pkh\_standard\_output\_size = 34\)</span>
bytes.</li>
</ul>
<p>It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee, in order to reduce information leakage, unless overridden by the user.</p>
@ -210,6 +210,35 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/631">https://githu
<span class="math">\(grace\_actions = min\_actions = 2\)</span>
. This also ensures that a denial-of-service adversary does not gain a significant per-logical-action cost advantage by using transactions with a smaller or larger number of logical actions.</p>
</section>
<section id="transparent-contribution"><h5><span class="section-heading">Transparent Contribution</span><span class="section-anchor"> <a rel="bookmark" href="#transparent-contribution"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>The specified formula calculates the contribution of transparent inputs and outputs based on their total size relative to a typical input or output. Another considered approach was to calculate this contribution simply as
<span class="math">\(\mathsf{max}(transparent\_inputs, transparent\_outputs)\)</span>
. However, this would allow a denial-of-service adversary to create transactions with transparent components containing arbitrarily large scripts.</p>
<p>The chosen values for
<span class="math">\(p2pkh\_standard\_input\_size\)</span>
and
<span class="math">\(p2pkh\_standard\_output\_size\)</span>
are based on the maximum encoded length for simple P2PKH inputs and outputs, as follows:</p>
<ul>
<li>
<span class="math">\(p2pkh\_standard\_input\_size\)</span>
<ul>
<li>outpoint: 36 bytes</li>
<li>stack script: 72 bytes</li>
<li>redeem script: 34 bytes</li>
<li>sequence: 4 bytes</li>
</ul>
</li>
<li>
<span class="math">\(p2pkh\_standard\_output\_size\)</span>
<ul>
<li>value: 8 bytes</li>
<li>script: 26 bytes</li>
</ul>
</li>
</ul>
<p>Simple P2SH inputs and outputs are not typically larger than this.</p>
</section>
<section id="marginal-fee"><h5><span class="section-heading">Marginal Fee</span><span class="section-anchor"> <a rel="bookmark" href="#marginal-fee"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>This returns the conventional fee for a minimal transaction (as described above) to the original conventional fee of 10000 zatoshis specified in <a id="footnote-reference-4" class="footnote_reference" href="#zip-0313">5</a>, and imposes a non-trivial cost for potential denial-of-service attacks.</p>
</section>

33
zip-0317.rst
View File

@ -132,8 +132,8 @@ The parameters are set to the following values:
* :math:`marginal\_fee = 5000`;
* :math:`grace\_actions = 2`;
* :math:`p2pkh\_standard\_input\_size = TODO` bytes;
* :math:`p2pkh\_standard\_output\_size = TODO` bytes.
* :math:`p2pkh\_standard\_input\_size = 150` bytes;
* :math:`p2pkh\_standard\_output\_size = 34` bytes.
It is not a consensus requirement that fees follow this formula; however,
wallets SHOULD create transactions that pay this fee, in order to reduce
@ -198,6 +198,35 @@ ensures that a denial-of-service adversary does not gain a
significant per-logical-action cost advantage by using transactions
with a smaller or larger number of logical actions.
Transparent Contribution
~~~~~~~~~~~~~~~~~~~~~~~~
The specified formula calculates the contribution of transparent inputs
and outputs based on their total size relative to a typical input or
output. Another considered approach was to calculate this contribution
simply as :math:`\mathsf{max}(transparent\_inputs, transparent\_outputs)`.
However, this would allow a denial-of-service adversary to create
transactions with transparent components containing arbitrarily large
scripts.
The chosen values for :math:`p2pkh\_standard\_input\_size` and
:math:`p2pkh\_standard\_output\_size` are based on the maximum encoded
length for simple P2PKH inputs and outputs, as follows:
* :math:`p2pkh\_standard\_input\_size`
* outpoint: 36 bytes
* stack script: 72 bytes
* redeem script: 34 bytes
* sequence: 4 bytes
* :math:`p2pkh\_standard\_output\_size`
* value: 8 bytes
* script: 26 bytes
Simple P2SH inputs and outputs are not typically larger than this.
Marginal Fee
~~~~~~~~~~~~