<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <span dir="ltr">&lt;<a href="mailto:jl2012@xbt.hk" target="_blank">jl2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>In a sum tree, however, since the nSigOp is implied, any redefinition requires either a hardfork or a new sum tree (and the original sum tree becomes a placebo for old nodes. So every softfork of this type creates a new tree)</div></div></blockquote><div><br></div><div>That&#39;s a good point.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The only way to fix this is to explicitly commit to the weight and nSigOp, and the committed value must be equal to or larger than the real value. Only in this way we could redefine it with softfork. However, that means each tx will have an overhead of 16 bytes (if two int64 are used)</div></div></blockquote><div><br></div><div style="word-wrap:break-word">The weight and sigop count could be transmitted as variable length integers.  That would be around 2 bytes for the sigops and 3 bytes for the weight, per transaction.<br><br></div><div style="word-wrap:break-word">It would mean that the block format would have to include the raw transaction, &quot;extra&quot;/tree information and witness data for each transaction.<br><br></div>On an unrelated note, the two costs could be combined into a unified cost.  For example, a sigop could have equal cost to 250 bytes.  This would make it easier for miners to decide what to charge.<br><br></div><div class="gmail_quote">On the other hand, CPU cost and storage/network costs are not completely interchangeable.<br><br>Is there anything that would need to be summed fees, raw tx size, weight and sigops that the greater or equal rule wouldn&#39;t cover?<br></div><div class="gmail_quote"><div style="word-wrap:break-word"><br></div>On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<div style="word-wrap:break-word"><div><blockquote type="cite"><div><div class="h5"><br class="m_6699621031753262314Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <span dir="ltr">&lt;<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_6699621031753262314gmail-">On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:<br>
&gt; Any new merkle algorithm should use a sum tree for partial validation and<br>
&gt; fraud proofs.<br>
<br>
</span>PR welcome.<br></blockquote><div><br></div><div>Fair enough.  It is pretty basic.<br><br><a href="https://github.com/luke-jr/bips/pull/2" target="_blank">https://github.com/luke-jr/<wbr>bips/pull/2</a><br><br></div><div>It sums up sigops, block size, block cost (that is &quot;weight&quot; right?) and fees.<br></div></div></div></div></div></div><span class="">
______________________________<wbr>_________________<br>bitcoin-dev mailing list<br><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br></span></div></blockquote></div><br></div></div><br></div></div>