[Bitcoin-segwit2x] segwit2x alpha release code drop

[Jameson Lopp]

On Thu, Jun 15, 2017 at 11:52 PM, Jeff Garzik via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> All,
>
> An update on the alpha release, and some discussion on block weight.
>
> Alpha release
> ------------------
> - tl;dr The code for the alpha release is on github
>
> - "segwit2x" is the official release branch, at https://github.com/btc1/
> bitcoin
> - 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
> ------------------
>
> 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: https://www.reddit.com/r/btc/comments/
> 5vxuti/what_is_block_weight_in_segwit/de6waug/
>
> 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.
>
> I see what you're saying here, though it seems to me that it's more like:
1a) Non-upgraded users are bidding for more block weight.
1b) SegWit users are bidding for less block weight.

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.
>

I'm not convinced this analogy fits given that the market completely
transitions to all users bidding based upon weight. Users who are driving
old, heavy cars will now be incentivized to upgrade to more modern cars
manufactured with lightweight materials.


>
> 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.
>
>
> The witness discount is not arbitrary. The economics of spending inputs
versus creating outputs is terribly imbalanced and the discount is applied
in order to bring it more in balance. It can cost 5X-10X as much (data size
& thus fees) to add an input (↓ UTXO set size) vs an output (↑ UTXO set
size) to a transaction. It could probably be argued that a 75% discount is
actually conservative in terms of trying to rebalance this discrepancy.

I'm not so sure that there is a perfect ratio given the arbitrary
complexity that inputs can have. I think you'd need some kind of dynamic
weighting that would be much more complex and would require significant
development resources to implement. I don't think we should let perfect be
the enemy of good given the timeline of this project.


> 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
> perspective.
>
> I'm unaware of this proposal, but offhand it doesn't make sense to me
given that the signatures of legacy transactions neither increase block
capacity nor are their signatures prunable. Seems like it would be
incentivizing suboptimal usage of a highly limited resource.

>
>
> 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.
>
> --
> Jeff Garzik
> CEO and Co Founder
> Bloq, Inc.
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170616/cf37eb8d/attachment.html>