<div dir="ltr"><div>Yes, you only need a few bits in the version number, probably less than 8. <br></div><div><br></div><div>If you encourage the overt method of using AsicBoost I would argue that you no longer need to dis-encourage the couvert method anymore as in Greg&#39;s proposal. Nobody would use the couvert method anyway because the overt method is so much simpler. So maybe the proposals can be completely disentangled?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;ve gotten feedback from Adam Back that you actually don&#39;t need all 32 bits in the header for overt ASICBoost, so I&#39;m modifying my proposal. Of the 32-bit version field, bits 16 to 23 are reserved for miners, the witness commitment stays as defined in BIP-141 except that it&#39;s now required. BIP9 then is modified so that bits 16 to 23 are now no longer usable.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <span dir="ltr">&lt;<a href="mailto:jaejoon@gmail.com" target="_blank">jaejoon@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><h3 name="d843" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><span style="font-weight:normal"><font size="2">Hey everyone, </font></span></h3><h3 name="d843" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><span style="font-weight:normal"><font size="2">This is an idea that I had about Segwit and Gregory&#39;s proposal from yesterday that I wanted to run by everyone on this list. I&#39;m not at all sure what this would mean for non-upgraded nodes on the network and would like feedback on that. This is not a formal BIP as it&#39;s a modification to a previously submitted one, but I&#39;m happy to formalize it if it would help.</font></span></h3><div><span style="font-weight:normal"><font size="2">------------------------------<wbr>----------</font></span></div><h3 name="d843" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><span style="font-weight:normal"><font size="2">Motivation</font></span></h3><h3 name="d843" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><span style="font-weight:normal"><font size="2">One of the interesting aspects of Gregory Maxwell’s proposal is that it only precludes the <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">covert</span> version of ASICBoost. He specifically left the <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">overt</span> version alone.<br></font></span></h3><p name="416c" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p"><span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">Overt</span> ASICBoost requires grinding on the version bits of the Block header instead of the Merkle Root. This is likely more efficient than the Merkle Root grinding (aka <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">covert</span> ASICBoost) and requires way less resources (much less RAM, SHA256 calculations, no tx shuffling, etc).</p><p name="26c8" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a slight modification, this should, in theory, make ASICBoost a lot more useful to miners and appeal to their financial interests. </p><h3 name="49b1" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><font size="2" style="font-weight:normal">The Modification</font></h3><p name="d82f" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">Currently, the version bits (currently 4 bytes, or 32 bits) in the header are used for BIP9 signaling. We change the version bits to a nonce-space so the miners can use it for <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">overt</span> ASICBoost. The 32-bits are now moved over to the Coinbase transaction as part of the witness commitment. The witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used as the version bits in the block header previously. The witness commitment becomes required as per Gregory Maxwell’s proposal.</p><h3 name="bf2c" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--h3"><font size="2" style="font-weight:normal">Reasoning</font></h3><p name="7083" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">First, this brings ASICBoost out into the open. <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">Covert</span> ASICBoost becomes much more costly and <span class="m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-em">overt</span> ASICBoost is now encouraged.</p><p name="e25f" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">Second, we can make this change relatively quickly. Most of the Segwit testing stays valid and this change can be deployed relatively quickly.</p><p name="b417" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">Note on SPV clients</p><p name="b417" class="m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">Currently Segwit stores the witness commitment in the Coinbase tx, so lightweight clients will need to get the Coinbase tx + Merkle proof to validate segwit transactions anyway. Putting block version information in the Coinbase tx will not impose an extra burden on upgraded light clients.<br></p></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>