[Bitcoin-segwit2x] segwit2x alpha release code drop
jeff at bloq.com
Fri Jun 16 06:52:42 UTC 2017
An update on the alpha release, and some discussion on block weight.
- tl;dr The code for the alpha release is on github
- "segwit2x" is the official release branch, at
- If it ain't in the branch, it ain't in the release
- PR #11, 2M HF, just left Work-In-Progress state, and will be pushed
- PR #21, BIP91 updates (JamesH), will be pushed
- Tag release in git
- gitian builds
- Test, test, test
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:
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.
If we assume a successful SegWit activation, there are some block
weight/SegWit-related issues and challenges to consider:
1) The wallet users who must reason fees face a complex market:
1a) Non-upgraded users are bidding for base block space.
1b) SegWit users are bidding for base + witness space.
These two are mixing in the same market *and* an opt-it transition implies
users switch unpredictably from 1a to 1b.
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.
2) Witness discount/scaling factor
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.
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.
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.
3) "Will the discount be applied to the non-witness data for legacy
transactions, as well as SegWit transactions (per Luke's suggestion)?"
That seems like a reasonable suggestion from an incentive alignment
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
CEO and Co Founder
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bitcoin-segwit2x