<div dir="ltr"><h3 name="d843" class="gmail-graf gmail-graf--h3"><span style="font-weight:normal"><font size="2">Hey everyone, </font></span></h3><h3 name="d843" class="gmail-graf gmail-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">----------------------------------------</font></span></div><h3 name="d843" class="gmail-graf gmail-graf--h3"><span style="font-weight:normal"><font size="2">Motivation</font></span></h3><h3 name="d843" class="gmail-graf gmail-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="gmail-markup--em gmail-markup--p-em">covert</span> version of ASICBoost. He specifically left the <span class="gmail-markup--em gmail-markup--p-em">overt</span> version alone.<br></font></span></h3><p name="416c" class="gmail-graf gmail-graf--p"><span class="gmail-markup--em gmail-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="gmail-markup--em gmail-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="gmail-graf gmail-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="gmail-graf gmail-graf--h3"><font size="2" style="font-weight:normal">The Modification</font></h3><p name="d82f" class="gmail-graf gmail-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="gmail-markup--em gmail-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="gmail-graf gmail-graf--h3"><font size="2" style="font-weight:normal">Reasoning</font></h3><p name="7083" class="gmail-graf gmail-graf--p">First, this brings ASICBoost out into the open. <span class="gmail-markup--em gmail-markup--p-em">Covert</span> ASICBoost becomes much more costly and <span class="gmail-markup--em gmail-markup--p-em">overt</span> ASICBoost is now encouraged.</p><p name="e25f" class="gmail-graf gmail-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="gmail-graf gmail-graf--p">Note on SPV clients</p><p name="b417" class="gmail-graf gmail-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>