<div dir="ltr">All,<div><br></div><div>An update on the alpha release, and some discussion on block weight.</div><div><br></div><div>Alpha release</div><div>------------------</div><div>- tl;dr The code for the alpha release is on github</div><div><br></div><div>- "segwit2x" is the official release branch, at <a href="https://github.com/btc1/bitcoin">https://github.com/btc1/bitcoin</a></div><div>- If it ain't in the branch, it ain't in the release</div><div>- PR #11, 2M HF, just left Work-In-Progress state, and will be pushed</div><div>- PR #21, BIP91 updates (JamesH), will be pushed</div><div>- Tag release in git</div><div>- gitian builds</div><div>- Test, test, test</div><div><div><br></div><div><br></div><div>Block weight</div><div>------------------</div><div><br></div><div>Block weight was the last detail to be finalized for the alpha release. It predictably garnered several comments on github and elsewhere. For background, here is a description: <a href="https://www.reddit.com/r/btc/comments/5vxuti/what_is_block_weight_in_segwit/de6waug/">https://www.reddit.com/r/btc/comments/5vxuti/what_is_block_weight_in_segwit/de6waug/</a></div><div><br></div><div>As a first pass, the block weight solution taken in the segwit2x code pushed (above) is the obvious approach one expects from a project with "2x" in the name.</div><div><br></div><div>If we assume a successful SegWit activation, there are some block weight/SegWit-related issues and challenges to consider:</div><div><br></div><div>1) The wallet users who must reason fees face a complex market:</div><div><br></div><div>1a) Non-upgraded users are bidding for base block space.</div><div>1b) SegWit users are bidding for base + witness space.</div><div><br></div><div>These two are mixing in the same market <i>and</i> an opt-it transition implies users switch unpredictably from 1a to 1b.</div><div><br></div><div>Rough analogy: Imagine a market where automobiles are sold by weight (kg). This market now embarks on an opt-in transition to selling automobiles based on engine size (cc's), a metric that automobile experts agree better measures automobile ability. Result: Some bidders in the market buy cars based on weight, others based on cc's. How does one bid efficiently in an always-in-transition market? SegWit is not just a technology upgrade, it is a market upgrade.</div><div><br></div><div><br></div><div>2) Witness discount/scaling factor</div><div><br></div><div>It is fair to say that this remains an issue of note. A few WG members have independently described the witness discount as an arbitrary economic incentive encoded directly into the software.</div><div><br></div><div>As a thought exercise, removing the scaling factor still retains extra witness space and therefore retains a natural incentive to stash data there, while removing a weighting that may or may not be the best ratio.</div><div><br></div><div>Block weight plays into this - if you're not scaling, you don't need an abstract "weight" unit, just a total size. For wallets (#1, above), size is probably more simple to reason and calculate than weight. Block size is a well studied attribute, versus block weight.</div><div><br></div><br>3) "Will the discount be applied to the non-witness data for legacy transactions, as well as SegWit transactions (per Luke's suggestion)?"</div><div><br></div><div>That seems like a reasonable suggestion from an incentive alignment perspective.<br><br><div><br></div><div><br></div><div>All that said - what was delivered in the code should be, per charter, maximally compatible w/ SegWit. These notes on block weight are provided as an adjunct to what was committed, possibly noting some pain points or better-paths.</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Jeff Garzik</div><div dir="ltr">CEO and Co Founder<div>Bloq, Inc.</div><div><br></div></div></div></div></div>
</div></div>